Synchronize your source code Create your local branch Why should I create a local branch? Choose your board Start to build Synchronize your source code Source code you have is one week old now. So, first step is synchronize it. $ repo sync‍‍‍ Create your local branch $ repo start <new branch name> --all‍‍‍ Why should I create a local branch? If you change *any* source code (for choosing another preferred kernel, for example) and want to sync again, or use master instead of dylan, you may be able to rebase or sync your source code, even with changes. Or you found a bug, fixed that, and want to send a patch to community. Example of a system with 2 branches: zeus and new_feature (the asterisk shows the current branch)    $ repo branches * new_feature | in all projects zeus | in all projects‍‍‍ Choose your board The following command display the usage, with a list of all supported machines, all supported community distros and examples of Poky's distro: $ source setup-environment build‍ Usage: MACHINE=<machine> DISTRO=<distro> source setup-environment <build-dir> Usage: source setup-environment <build-dir> <machine> machine name <distro> distro name <build-dir> build directory The first usage is for creating a new build directory. In this case, the script creates the build directory <build-dir>, configures it for the specified <machine> and <distro>, and prepares the calling shell for running bitbake on the build directory. The second usage is for using an existing build directory. In this case, the script prepares the calling shell for running bitbake on the build directory <build-dir>. The build directory configuration is unchanged. Supported machines: apalis-imx6 ccimx6ulsbcexpress ccimx6ulsbcpro cgtqmx6 cm-fx6 colibri-imx6 colibri-imx6ull colibri-imx7 colibri-vf cubox-i imx233-olinuxino-maxi imx233-olinuxino-micro imx233-olinuxino-mini imx233-olinuxino-nano imx6dl-riotboard imx6qdl-variscite-som imx6q-dms-ba16 imx6qsabrelite imx6sl-warp imx6ul-pico imx7d-pico imx7s-warp m28evk m53evk nitrogen6sx nitrogen6x nitrogen6x-lite nitrogen7 nitrogen8m pcm052 tx6q-10x0 tx6q-11x0 tx6s-8034 tx6s-8035 tx6u-8033 tx6u-80x0 tx6u-81x0 ventana wandboard imx23evk imx25pdk imx28evk imx51evk imx53ard imx53qsb imx6qdlsabreauto imx6qdlsabresd imx6slevk imx6sllevk imx6sxsabreauto imx6sxsabresd imx6ulevk imx6ullevk imx7dsabresd imx7ulpevk imx8mmevk imx8mqevk imx8qmmek imx8qxpmek ls1012afrwy ls1012ardb ls1021atwr ls1043ardb ls1046ardb ls1088ardb ls1088ardb-pb ls2080ardb ls2088ardb lx2160ardb mpc8548cds p1020rdb p2020rdb p2041rdb p3041ds p4080ds p5040ds-64b p5040ds t1024rdb-64b t1024rdb t1042d4rdb-64b t1042d4rdb t2080rdb-64b t2080rdb t4240rdb-64b t4240rdb Supported Freescale's distros: fslc-framebuffer fslc-wayland fslc-x11 fslc-xwayland Available Poky's distros: poky-altcfg poky-bleeding poky poky-tiny Examples: - To create a new Yocto build directory: $ MACHINE=imx6qdlsabresd DISTRO=fslc-framebuffer source setup-environment build - To use an existing Yocto build directory: $ source setup-environment build ERROR: You must set MACHINE when creating a new build directory. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ An example of command line to setup the build environment is (read and answer if you accept EULA or not): MACHINE=imx8mmevk DISTRO=fslc-wayland source setup-environment build‍ (...) Do you accept the EULA you just read? (y/n) y EULA has been accepted. Welcome to Freescale Community BSP The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You can now run 'bitbake <target>' Common targets are: core-image-minimal meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support Your build environment has been configured with: MACHINE=imx8mmevk SDKMACHINE=i686 DISTRO=fslc-wayland EULA= ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now, you are in new created build directory. Your default build/conf/local.conf file can looks like: MACHINE ??= 'imx8mmevk' DISTRO ?= 'fslc-wayland' PACKAGE_CLASSES ?= 'package_rpm' EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-system-native = " sdl" CONF_VERSION = "1" DL_DIR ?= "${BSPDIR}/downloads/" ACCEPT_FSL_EULA = "1"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ For the current list of supported board, take a look on FSL Community BSP Release Notes 2.4 (Draft document) documentation Or, see the FSL Community BSP  Release Notes Start to build There are a huge list of images available. Some images includes more packages than others, you can see a list of FSL Community BSP images with description here. The list of supported images from Yocto Project (with description) is here. When an image has more packages included, it takes longer to build. Another way to list all the images you have installed in your metadata is: $ find ../sources -name *image*‍‍   For the goal of this training, any image is good, but a suggestion is presented in next command line: (make sure you are still in build directory) $ cd build $ bitbake core-image-base‍‍‍‍‍‍‍‍ Note (Sept2019): Required disk space for build image is ~31GB Go to Yocto Training - HOME Go to Task #1 - Download the source code Go to Task #3 - The build result

Gamma correction Displays usually presents a nonlinear bright response. For example, a frame buffer value of 100 will almost never give half the brightness of a value of 200. Historically, this is due to the physics of CRT monitors, but newer display technologies emulate the behavior. This is not only for compatibility, but for solid reasons based in the science of human visual perception. A first-order approximation to the non-linearity of a CRT is: L = ν ^ γ where L is the radiance (light intensity) from the display, ν is the voltage applied to the CRT gun (normally proportional to the digital value in the frame buffer), and γ (Greek letter “gamma”) is a constant particular to the monitor; it's the unknown parameter that makes it all work. It usually ranges from about 2.0 to about 2.5. One useful fact is that the gamma curve is linear in log-log space (i.e. logL as a function of logν), and γ is just the slope of that line. Example of gamma correction The dotted line indicates a linear transfer function (γ=1), the framebuffer gamma; the solid line shows how a typical CRT behaves; the dashed line represents the inverse function, the corrected gamma. How to correct gamma on i.MX using DP (Display Processor)? Gamma correction can be performed by IC (Image Converter) or DP (Display Processor) sub-blocks inside IPU. Current Linux kernel (3.10) provided by Freescale has an IOCTL that changes the related gamma parameters registers DP_GAMMA_C_SYNC<i> and DP_GAMMA_S_SYNC<i> on Display Processor block. The steps below shows how to change the gamma using user space applications: 1 - Declare a variable as mxcfb_gamma: struct mxcfb_gamma fb_gamma; 2 - Enable the gama correction: fb_gamma.enable = 1; 3 - Set the constk and slopek values, where i = 0 to 15 and x and y are respectively the new constk and slopek constant values: fb_gamma.constk[i] = x; fb_gamma.slopek[i] = y; 4 - Open the framebuffer device and call MXCFB_SET_GAMMA: fd_fb = open("/dev/fb0", O_RDWR, 0) ioctl(fd_fb, MXCFB_SET_GAMMA, &fb_gamma) Running the code above will immediately change the gamma value.

Hi,      Here share the hardfloat rootfs making document and related pkgs, please feel free for download best regards Jack

目录 1 创建 i.MX8QXP Linux 5.4.24 板级开发包编译环境 ..... 3 1.1 下载板级开发包 ....................................................... 3 1.2 创建yocto编译环境: ................................................. 4 1.3 独立编译 ................................................................. 9 2 Device Tree .............................................................. 16 2.1 恩智浦的device Tree结构 ..................................... 16 2.2 device Tree的由来(no updates) ............................ 19 2.3 device Tree的基础与语法(no updates) ................. 22 2.4 device Tree的代码分析(no updates) ..................... 44 3 恩智浦i.MX8XBSP 包文件目录结构 .......................... 77 4 恩智浦i.MX8XBSP的编译(no updates) ..................... 79 4.1 需要编译哪些文件 ................................................. 79 4.2 如何编译这些文件 ................................................. 80 4.3 如何链接为目标文件及链接顺序 ............................ 81 4.4 kernel Kconfig ....................................................... 83 5 恩智浦BSP的内核初始化过程(no updates) .............. 83 5.1 初始化的汇编代码 ................................................. 85 5.2 初始化的C代码 ...................................................... 89 5.3 init_machine........................................................ 102 6 恩智浦BSP的内核定制 ........................................... 105 6.1 DDR修改 ............................................................. 106 6.2 IO管脚配置与Pinctrl驱动 ..................................... 107 6.3 新板bringup......................................................... 123 6.4 更改调试串口 ...................................................... 132 6.5 uSDHC设备定制(eMMC flash,SDcard, SDIOcard)137 6.6 LVDS LCD 驱动定制 ........................................... 147 6.7 LVDS LDB SerDas驱动支持 ............................... 150 6.8 MiPi DSI SerDas驱动支持 .................................. 156 6.9 V4L2框架汽车级高清摄像头/桥驱动：数字/模拟 . 160 6.10 GPIO_Key 驱动定制 .......................................... 177 6.11 GPIO_LED 驱动定制 ......................................... 181 6.12 Fuse nvram驱动 .................................................. 184 6.13 SPI与SPI Slave驱动 ........................................... 185 6.14 USB 3.0 TypeC 改成 USB 3.0 TypeA(未验证) .... 193 6.15 汽车级以太网驱动定制 ........................................ 193 6.16 i.MX8DX MEK支持 .............................................. 212 6.17 i.MX8DXP MEK支持 ........................................... 212 6.18 NAND Flash支持与烧录 ...................................... 213

In this doc will show how to adjust display brightness/contrast/saturation by using i.MX8  Display Controller (DC) Subsystem.   HW: i.MX8QXP MEK board SW: Linux 4.14.98_2.0.0 BSP release.   See i.MX 8DualXPlus/8QuadXPlus Applications Processor Reference Manual, Rev. 😧 This kind Matrix total number is 5 , that is 0/1/4/5/9. In this doc using Matrix0 to adjust whole display brightness/contrast/saturation. Matrix0 unit position is located between FramGen unit and Tcon unit, that means using Matrix0 will impact on the whole display contents. Note, this Matrix is applied on RGB color space.    The Matrix is consist of two parts: and  You can program any value into register of A11 to A44 and C1 to C4, Matrix will applied on input RGB data, then output RGB data will changed as you want. In this way, we can change the display brightness/contrast/saturation. The Matrix entry from A11 to A44, their register format is same as below: Each register entry of A11 to A44 , total 13 bit, bit 12 is symbol bit , bit 11 and bit 10 is integer bit, bit 9 to bit 0 is floating point bit. The Matrix entry from C1 to C4, their format is same as below: Each register entry of C1 to C4, total 13 bit, bit 12 is symbol bit, others are integer bit. Now let us choose the matrix that will be used for adjust brightness/contrast/saturation. See this link  https://docs.rainmeter.net/tips/colormatrix-guide/ So we can set matrix as below to change brightness/contrast/saturation   A11=c(sr+s)   A12=c(sg)    A13=c(sb)   A21=c(sb)     A22=c(sg+s)  A23=c(sb)   A31=c(sr)     A32=c(sg)    A33=c(sb+s)   C1=C2=C3=t+b   b as brightness , range[-1.0, 1.0], zero means no change , >0 will increases brightness, <0 will reduce brightness. c as contrast, range [0,2.0) , default is 1.0 , >1.0 is increase , <1.0 is reduce. s is saturation, range [0,1.0], default is 1.0.  Other matrix entry is related to alpha, in this doc not change it, just keep them as zero.     Note here sr,sb,sg value will depend on lumR/ lumG/ lumB constant value you choose, this value may depend on different color standard.   Due to each matrix value is floating point number, and in this doc , i.MX8X run Linux OS. So you can choose do floating point operation in user space program, then pass related register value into kernel space , let driver write them into register. But in this doc, to make Linux kernel driver more simple, I will convert floating point operation into integer operation , then user space app just pass brightness/contrast/saturation value into kernel space, then kernel driver to do left operation in kernel space. So 1024*c and 1024*s is integer number that user space app will passed into kernel space. And in kernel space could be do left integer number operation, then write register value. The kernel patch 8qxp_4.14.98_brightness_contrast_saturation.diff could be used on 4.14.98_2.0.0 BSP release. Test usage, need used one patch that for proptest which from libdrm test case, see 8qxp_prop_test.diff, recompile the proptest case. root@imx8qxpmek:~# ./proptest     //list current drm property CRTC 32         42 bringhtness:                 flags: range                 values: 0 131071                 value:0x0         43 contrast:                 flags: range                 values: 0 2048                 value:0x400         44 saturation:                 flags: range                 values: 0 1024                 value:0x400         45 update:                 flags: range                 values: 0 1                 value:0x0   I add four drm property , brightness, contrast, saturation, update. The “update property” should be set as 1 at last, otherwise kernel space will not update related property. Reference API usage ( in 8qxp_prop_test.diff) +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 42, b_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 43, c_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 44, s_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 45, 1);      //run cmd as below , will ask you input related brightness/contrast/saturation value , then will get result in display root@imx8qxpmek:~# ./proptest 32 crtc 45 1   input brightness [-1,1] 0.3 input contrast, >1.0 or <1.0 1.2 input saturation, [0,1] 0.3 brightness 0.300000  0x133 from [-1,1] percent contrast  1.200000  0x4cc >1.0 or <1.0 saturation 0.300000 0x133  from 0.0 to 1.0   Known Issue: For demo this feature , I need run proptest and weston at same time. Due to the set property drm ioctl default allowed by DRM master and DRM control client. But 4.14. kernel, removed the DRM control device node, so I changed to open drm render node fd, and allow DRM render client to using set property drm ioctl.  This is just a workaround, you may not use it. Reference: 1.https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf  2.https://docs.rainmeter.net/tips/colormatrix-guide/

                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网，视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.

INTRODUCTION REQUIREMENTS KERNEL DRIVER DEVICE NODE NFC LIBRARY TESTING NFC READER REFERENCES 1. INTRODUCTION This document is a step by step guide of the AN11697 PN7120 Linux Software Stack Integration Guidelines application note that can be downloaded from http://www.nxp.com/documents/application_note/AN11697.pdf . It explains how to add the PN7120 driver and NFC libraries to a Linux OS running in the i.MX6Q. 2. REQUIREMENTS The board used in this document is the Udoo Board thanks to the easy pin access. More information about this board can be found at Ultimate Single Board Mini PC for Android and Linux - UDOO A modified FSL L3.14.28 BSP. The modifications can be found in these 2 documents Basic Device Tree for the Udoo Board and  U-Boot Migration Example . If you have followed the previous documents, you already have a working yocto image and toolchain (meta-toolchain), if not you must follow this awesome training first Yocto Training - HOME . The OM5577/PN7120S demonstration kit. You can find more details of this board at http://www.nxp.com/documents/user_manual/UM10878.pdf 3. KERNEL DRIVER According to the AN11697.pdf we must follow the below steps: From the Linux source directory: $ cd drivers/misc $ git clone https://github.com/NXPNFCLinux/nxp-pn5xx.git Add the below line in the Makefile of the current directory obj-y += nxp-pn5xx/ Include the driver config in the drivers/misc/Kconfig file source "drivers/misc/nxp-pn5xx/Kconfig" Export the environment variables $ source source /opt/poky/1.7/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi $ export ARCH=arm $ export CROSS_COMPILE=$TARGET_PREFIX $ make imx_v7_defconfig Using menuconfig include the driver as module (<M>).  Compile the modules and install the .ko files into the target rootfs. $ make  modules You can send the .ko files with scp $ make  INSTALL_MOD_PATH=~/Desktop/modules modules_install $ cd ~/Desktop/modules $ sudo scp -r lib/modules/3.14.28+g91cf351/kernel root@<board_ip>:/lib/modules/3.14.28+g91cf351/ 4. DEVICE NODE The PN7120 interfaces with an MCU or MPU via I2C interface, therefore the device must be described into a i2c node. The signals used in the PN7120 are shown below: As you can see besides power, ground and I2C lines, an IRQ and Reset pins are needed. These pins must be configured as GPIO and one must generate an interrupt to the iMX6Q. The chosen connection is shown below: To achieve the above configuration, the device tree must be changed. The changes consist on adding a device node in the corresponding I2C bus, describing the PN7120. &i2c1 {         clock-frequency = <100000>;         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_i2c1>;         status = "okay";         pn547: pn547@28 {                 compatible = "nxp,pn547";                 reg = <0x28>;                 clock-frequency = <400000>;                 interrupt-parent = <&gpio6>;                 interrupt-gpios = <&gpio6 2 0>;                 enable-gpios = <&gpio5 22 0>;         }; }; The pinctrl_i2c1 phandle contains the I2C pins configuration. Make sure that the PADs connected to the PN7120 are not used in other device node. &iomuxc {         imx6q-udoo {                       ...                 pinctrl_i2c1: i2c1grp {                         fsl,pins = <                         MX6QDL_PAD_GPIO_5__I2C3_SCL             0x4001b8b1                         MX6QDL_PAD_GPIO_6__I2C3_SDA             0x4001b8b1                         >;                 };         }; }; After this you can generate the dtb file and send it with scp make dtbs sudo scp arch/arm/boot/dts/imx6q-udoo.dtb root@<board_ip>:/run/media/mmcblk0p1/imx6q-udoo.dtb NOTE: Attached you can find the complete dts and dtsi files used in this document. 5. NFC LIBRARY     To work with the PN7120 in Linux the libnfc-nci stack is needed. You can find more details in http://www.nxp.com/documents/application_note/AN11697.pdf​ . This sections explains how to cross-compile the libray and install the required files in the target (The below steps must be performed in the host). Get the library $  git clone https://github.com/NXPNFCLinux/linux_libnfc-nci.git Generate the configuration script $ ./bootstrap Mount the target rootfs to /mnt in the host. $ sudo mount /dev/sdX2 /mnt Generate the Makefile $ ./configure --host=arm-none-linux --prefix=/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr --sysconfdir=/mnt/etc Build and install the source code $ make $ make install After a succesful bulding the libraries and a application demo are built in .libs directory. Copy the libaries to /usr/lib directory of the target and nfcDemoApp to /usr/sbin $ cd linux_libnfc-nci/.libs $ sudo cp * /mnt/usr/lib/ 6. TESTING NFC READER     To test the application you have to follow the below steps on the target: Install the .ko file $ insmod /lib/modules/3.14.28+g91cf351/kernel/drivers/misc/nxp-pn5xx/pn5xx_i2c.ko Run the nfcDemoApp $  nfcDemoApp poll You should get a console output like the shown below when placing a NFC tag next to the NFC reader. 7. REFERENCES     Integrating NFC Controller library with KSDK http://www.nxp.com/documents/application_note/AN11697.pdf http://www.nxp.com/documents/user_manual/UM10878.pdf

We are pleased to announce that Pins Tool for i.MX v4 is now available.   The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Documented and easy to understand source code CSV Report and Device Tree File   To download the installer for all platforms, please login to our download site via:  http://www.nxp.com/pinsimx   Please refer to Pins Tool Documentation  for installation and quick start guides.   Overview of Changes - version 4 Added ability to import configuration from existing MEX file (for selected tools) Added common Functions group toolbar across all tools Added option to not generate YAML Pins tool: multiselect in Routed pins view supported Syntax coloring supported in Sources view Export sources wizard simplified Several bug fixed and performance improved Quick start guide added   Community https://community.nxp.com/community/imx 

        The document will introduce how to setup cross‐compiling environment for android android7.1.1 BSP on Ubuntu 16.04.2 LTS, The purpose is to help i.MX customers create android BSP environment quickly, from this, save customer’s time and let them focus on the development of their product. Customer can compile android7.1.1 BSP according to the following steps: ‐‐Installing Ubuntu160.4.2 LTS 1. Running software updater to update system       Customer can download ubuntu‐16.04.2‐desktop‐amd64.iso from https://www.ubuntu.com/download/desktop Then install it to VMware workstation player v12 or PC, after finishing installation, use “Software Updater” to update system. 2. Installing necessary packages    Before compiling android7.1.1 source code, we need to install some neccesary software packages, see following, please! $ sudo apt-get install gnupg $ sudo apt-get install flex $ sudo apt-get install bison $ sudo apt-get install gperf $ sudo apt-get install build-essential $ sudo apt-get install zip $ sudo apt-get install zlib1g-dev $ sudo apt-get install libc6-dev $ sudo apt-get install lib32ncurses5-dev $ sudo apt-get install x11proto-core-dev $ sudo apt-get install libx11-dev $ sudo apt-get install lib32z1-dev $ sudo apt-get install libgl1-mesa-dev $ sudo apt-get install tofrodos $ sudo apt-get install python-markdown $ sudo apt-get install libxml2-utils $ sudo apt-get install xsltproc $ sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 $ sudo apt-get install gcc-multilib g++-multilib $ sudo apt-get install subversion $ sudo apt-get install openssh-server openssh-client $ sudo apt-get install uuid uuid-dev $ sudo apt-get install zlib1g-dev liblz-dev $ sudo apt-get install liblzo2-2 liblzo2-dev $ sudo apt-get install lzop $ sudo apt-get install git-core curl $ sudo apt-get install u-boot-tools $ sudo apt-get install mtd-utils $ sudo apt-get install android-tools-fsutils $ sudo apt-get install openjdk-8-jdk 3. Downloading android7.1.1 source code, u‐boot, linux kernel 3.1 Downloading android7.1.1 source code 3.1.1 Getting source code from google .    if users can access google site, she can get source code accroding to steps in "Android_User's_Guide.pdf" released by NXP 3.1.2 Getting source code from the server of tsinghua university( this is for customer in China ) Steps: (1) Getting repo # cd ~ # mkdir myandroid # mkdir bin # cd bin # git clone https://aosp.tuna.tsinghua.edu.cn/android/git-repo.git/ # cd git‐repo # cp ./repo ../ (2) Modifying repo File Open ~/bin/repo file with 'gedit' and Change google address From REPO_URL = 'https://gerrit.googlesource.com/git-repo' To REPO_URL = ' https://gerrit-google.tuna.tsinghua.edu.cn/git-repo (3) Setting email address # cd ~/myandroid # git config --global user.email "email address" # git config --global user.name "name" [ Email & Name should be yours] (4) Modifying manifest.xml # ~/bin/repo init -u https://aosp.tuna.tsinghua.edu.cn/android/platform/manifest -b android-7.1.1_r13 # cd ~/myandroid/.repo # gedit manifest.xml Then change the value of fetch to " https://aosp.tuna.tsinghua.edu.cn/android/ ", like following: <manifest> <remote name="aosp" fetch="https://aosp.tuna.tsinghua.edu.cn/android/" /> <default revision="refs/tags/android-5.1.1_r1" ...... (5) # ~/bin/repo sync [Note] During runing repo sync, maybe errors will occur like the following: ...... * [new tag] studio‐1.4 ‐> studio‐1.4 error: Exited sync due to fetch errors Then 'repo sync' exits. But don't worry about it, continue to run the command please ! " ~/bin/repo sync", downloading source code will be continous. 3.2 Getting uboot source code $ cd ~/myandroid/bootable $ mkdir bootloader $ cd bootloader $ git clone git://git.freescale.com/imx/uboot-imx.git uboot-imx $ cd uboot-imx $ git checkout n7.1.1_1.0.0-ga 3.3 Downloading linux kernel $ cd ~/myandroid $ git clone git://git.freescale.com/imx/linux-imx.git kernel_imx $ cd kernel_imx $ git checkout n7.1.1_1.0.0-ga 4. Downloading android7.1.1 BSP source code and patch it above source code 4.1 Android7.1.1 BSP can be downloaded from the link: Android OS for i.MX Applications Processors|NXP  ---Board Support Packages (66) After downloading it, copy it to /opt/ 4.2 Patch it to android source code $ cd ~/myandroid $ source /opt/android_N7.1.1_1.0.0_source/code/N7.1.1_1.0.0/and_patch.sh $ help $ c_patch /opt/android_N7.1.1_1.0.0_source/code/N7.1.1_1.0.0/ imx_N7.1.1_1.0.0 If everything is OK, "c_patch" generates the following output to indicate the successful patch: 5. Compiling android7.1.1 BSP source code for i.MX boards $ export ARCH=arm $ export CROSS_COMPILE=~/myandroid/prebuilts/gcc/linux-x86/arm/armlinux-androideabi-4.9/bin/arm-linux-androideabi- $ cd ~/myandroid $ source build/envsetup.sh $ lunch sabresd_6dq-user $ make –j2   (Using 2 CPU cores to compile) Probably, users will enconter this error during compiling: [Solve it like this:] $ export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g" $  cd ~/myandroid $ ./prebuilts/sdk/tools/jack-admin kill-server then run "make " to continue compiling. After compiling, we can see images in output path: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Hope above items can help you! If customers have questions about the document, she can submit case to me by our saleforce system. the following is how to submit cases to us: ******************************************************************************************************************************************* In case a new customer is asking how to submit a technical case on nxp.com ,here is a template for your reference. 1) Please visit www.nxp.com and click on Support on the top of the webpage. 2) Select Sales and Support under Support Resources session. 3) Scroll down to the bottom ,click on “hardware & Software” . 4) Register by your business email to enter NXP Community 5) Get verification email and verify your account. 6) Select "contact support" on the top and click “submit a new case” to start the process. ******************************************************************************************** Then label : "please forward it to TIC Weidong Sun" in your content , I can get it. NXP TIC team Weidong.Sun 2017-03-16 in Shanghai China

Added two functions in DDR_Stress_Tester V1.0.2, find the attachment for the details. 1. Check the actual boot mode settings in H/W target board 2. Add test option for bit flip and bit spread walking test

The OpenSSL recipe halts saying it can't find find.pl . How to resolve this problem?   From the blog, linked below : create file find.pl in /etc/perl.   Missing find.pl compiling OE - Kemp's blog    "find.pl" content :   warn "Legacy library @{[(caller(0))[6]]} will be removed from the Perl core distribution in the next major release. Please install it from the CPAN distribution Perl4::CoreLibs. It is being used  at @{[(caller)[1]]}, line @{[(caller)[2]]}.\n";   # This library is deprecated and unmaintained. It is included for # compatibility with Perl 4 scripts which may use it, but it will be # removed in a future version of Perl. Please use the File::Find module # instead.   # Usage: #              require "find.pl"; # #              &find('/foo','/bar'); # #              sub wanted { ... } #                            where wanted does whatever you want. $dir contains the #                            current directory name, and $_ the current filename within #                            that directory. $name contains "$dir/$_". You are cd'ed #                            to $dir when the function is called. The function may #                            set $prune to prune the tree. # # For example, # # find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune # # corresponds to this # #              sub wanted { #               /^\.nfs.*$/ && #               (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) && #               int(-M _) > 7 && #               unlink($_) #               || #               ($nlink || (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_))) && #               $dev < 0 && #               ($prune = 1); #              } # # Set the variable $dont_use_nlink if you're using AFS, since AFS cheats.   use File::Find ();   *name                            = *File::Find::name; *prune                            = *File::Find::prune; *dir                            = *File::Find::dir; *topdir                            = *File::Find::topdir; *topdev                            = *File::Find::topdev; *topino                            = *File::Find::topino; *topmode              = *File::Find::topmode; *topnlink              = *File::Find::topnlink;   sub find {   &File::Find::find(\&wanted, @_); }   1;

The Linux L4.9.11_1.0.0 RFP(GA) for i.MX6 release files are now available on www.nxp.com    Files available: # Name Description 1 L4.9.11_1.0.0-ga_images_MX6QPDLSOLOX.tar.gz i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 2 L4.9.11_1.0.0-ga_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 3 L4.9.11_1.0.0-ga_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 4 L4.9.11_1.0.0-ga_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 5 L4.9.11_1.0.0-ga_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  6 L4.9.11_1.0.0-ga_mfg-tools.tar.gz i.MX Manufacturing Toolkit for Linux L4.9.11_1.0.0 BSP 7 L4.9.11_1.0.0-ga_gpu-tools.tar.gz L4.9.11_1.0.0 i.MX VivanteVTK file 8 bcmdhd-1.141.100.6.tar.gz The Broadcom firmware package for i.MX Linux L4.9.11_1.0.0 BSP. 9 imx-aacpcodec-4.2.1.tar.gz Linux AAC Plus Codec for L4.9.11_1.0.0 10 fsl-yocto-L4.9.11_1.0.0.tar.gz L4.9.11_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide.   Target boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board (Beta Quality)   What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes, see: README: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/README?h=imx-morty ChangeLog: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/ChangeLog?h=imx-morty

This guide walks you through setting up and building the Yocto SDK, customizing a device tree (DTS), and compiling the kernel for NXP i.MX platforms. It is designed to simplify the process, from downloading tools to creating functional images for embedded devices. Prerequisites Required Software: A Linux-based operating system (Ubuntu/Debian recommended). Git installed (sudo apt install git). Yocto dependencies: $ 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 python3-subunit zstd liblz4-tool file locales libacl1 ​ Hardware: An NXP i.MX-based development board (i.MX6, i.MX7, i.MX8, or i.MX9). Sufficient storage space   1. Downloading the Repository Start by downloading the necessary tools and repository. If the ~/bin folder does not already exist, create it: $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH   2. Compile the Yocto SDK: Create and navigate to a release directory: $: mkdir <release> $: cd <release>   Initialize and sync the repo: $: repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] $: repo sync   Set up the environment and build the SDK: $: [MACHINE=<machine>] [DISTRO=fsl-imx-<backend>] source ./imx-setup-release.sh -b bld-<backend> $: bitbake <image recipe> -c populate_sdk   Example: $: mkdir Yocto_SDK $: cd Yocto_SDK $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $: repo sync $: MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland $: bitbake imx-image-full -c populate_sdk   Recommendation: Use the full image (imx-image-full) to include all available packages and libraries.   Run the generated .sh file to install the SDK: sudo ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh   The final .sh file is located in: bld-xwayland/tmp/deploy/sdk/   3. Cloning the Kernel Repository (linux-imx repository)   Clone the kernel source matching the version of the Yocto SDK you built earlier:   $: git clone https://github.com/nxp-imx/linux-imx.git -b <Kernel-version>   EXAMPLE: $: git clone https://github.com/nxp-imx/linux-imx.git -b lf-6.6.52-2.2.0   4. Customizing the Device Tree Device trees can be modified or created based on your hardware setup.   Device Tree Locations:   iMX6 and iMX7: arch/arm/boot/dts/nxp/imx/   iMX8 and iMX9: arch/arm64/boot/dts/freescale/   If you create a new device tree, add it to the respective Makefile:   iMX8 and iMX9: arch/arm64/boot/dts/freescale/Makefile   iMX6 and iMX7: arch/arm/boot/dts/nxp/imx/Makefile     5. Setting Up the Cross-Compilation Environment To prepare for kernel compilation, source the environment setup script. Assuming the Yocto SDK is installed in /opt, run:   EXAMPLE: $ source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux   6. Configuring the Kernel Make configuration adjustments as needed:   iMX8 and iMX9: arch/arm64/configs/imx_v8_defconfig   iMX6 and iMX7: arch/arm/configs/imx_v7_defconfig   Use the appropriate configuration command:   iMX8 and iMX9: $: make imx_v8_defconfig   iMX6 and iMX7: $: make imx_v7_defconfig   7. Compiling Device Trees Only   To compile only the device tree files, run: $: make dtbs   8. Compiling the Kernel Finally, compile the kernel image using: $ make -j $(nproc)   The resulting kernel image will be located in: iMX8 and iMX9: arch/arm64/boot/   iMX6 and iMX7: arch/arm/boot/   References: IMX YOCTO PROJECT USERS GUIDE IMX LINUX USERS GUIDE  IMX REFERENCE MANUAL   

Preface With i.MX android, it is often infeasible to directly build an OTA package with a newer android version and apply that OTA package to a device running old version of Android. For example, the OTA package buit with i.MX android-13.0.0_2.0.0 release for evk_8mm cannot be direclty applied on the evk_8mm board running the image built with i.MX android-11.0.0_1.0.0. In this article, the reason why directly cross-version OTA is infeasible in i.mx android is firstly explained. Then what should be takein into consideration and done before cross-version OTA are described.   The way Google update the system for its device Once Google first time releases a device, it is called a "launch device". it has: codename. Take pixel 3a xl as an example, the codename is bonito Android version. For pixel 3a xl, it's Android 9.0 kernel version. For pixel 3a xl, it's 4.9 PRODUCT_SHIPPING_API_LEVEL. For pixel 3a xl, it is set to be 28, the same as the SDK version of that Android version. FCM target level. For pixel 3a xl, it's 3 After the system code is updated to a new version, an OTA package can be built with the lunch target aosp_bonito-user or aosp_bonito-userdebug for pixel 3a xl, let's call the updated device "retrofit device" codename is not changed. its device configuration still can be found in "device/google/bonito/" Android version. it is the version the OTA updated to. Four android versions are supported, here they are android 9, 10, 11, 12, which means pixel 3a xl can at most upgraded to android12. "device/google/bonito/" is introduced in android9, and removed in android13. kernel version. not changed after OTA PRODUCT_SHIPPING_API_LEVEL. Not changed in OTA, so after the OTA, the value of property "ro.product.first_api_level" is different from the SDK version. FCM target level. not changed after OTA. The FCM target level is in the device manifest.xml, corresponds to a specific version of system compatibility.matrix.xml, so HALs provided by this device does not need to have much changes if the FCM target level is not changed. This is the way Google maintains the system for their devices. This is not the way i.MX Android devices are maintained. The way i.MX Android update the system to a new version for maintained device when the code is upaded to a new version for maintained imx devices, all the device are taken as "launch device", so compaired to the previous version, in the new system for the device: the kernel version is changed PRODUCT_SHIPPING_API_LEVEL is changed FCM target level is changed. Physical partitions may also be changed The FCM target level change means there may be some big changes in the HALs provided by this device. The PRODUCT_SHIPPING_API_LEVEL change means quite many code logic based on the property "ro.product.first_api_level" execute in different flow. Fro the partition changes, the OTA package directly build with this updated code often cannot be applied, for example, a new image for the new partition cannot be applied on the board running old system, as it does not have the partition for the image. Things cannot be changed during OTA To make things more clear that why direct cross-version OTA is infeasible, it is necessary to know that there are things cannot be changed during OTA. 1. physical partitions cannot be changed during OTA. related features are: * dynamic partition * gki * boot header version 2. user data on theuserdata partition should not be changed, or data loss may occur during OTA. the related features are: * encryption options encryption options should not be changed, to make new version of android can recognize the data encrypted by the old version of android. For some  fs_mgr encrypt options, the product_shipping_api_level impacts on the final encryption parameters passed to the kernel. take a look at the following code, even with the same fs_mgr encryption option, if the first_api_level is different, the final encryption parameter is different in different android version. android10 system/extras/libfscrypt/fscrypt.cpp if (filenames_encryption_mode == FS_ENCRYPTION_MODE_AES_256_CTS) { // Use legacy padding with our original filenames encryption mode. return FS_POLICY_FLAGS_PAD_4; } else if (filenames_encryption_mode == FS_ENCRYPTION_MODE_ADIANTUM) { // ...snip... return (FS_POLICY_FLAGS_PAD_16 | FS_POLICY_FLAG_DIRECT_KEY); } // ...snip... return FS_POLICY_FLAGS_PAD_16; android11 system/extras/libfscrypt/fscrypt.cpp if (!is_gki && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4; } else { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16; } android12 system/extras/libfscrypt/fscrypt.cpp if (first_api_level <= __ANDROID_API_Q__ && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4; } else { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16; }  The fscrypt version will also impact the result. If not sepcified, the default "version" would be "v1" if the "product_shipping_api_level <= 29" or the default "version" would be "v2". Some fscrypt functions like "casefold" and "project id" will depend on fscrypt "v2", these functions are enabled by including the "$(call inherit-product, $(SRC_TARGET_DIR)/product/emulated_storage.mk)" in "device/nxp". The "emulated_storage.mk" must not be included if fscrypt "v1" is used.  * the userdata partition filesystem type ext4 (used before i.mx android 13.0.0) f2fs (used from i.mx android 13.0.0) * The filesystem for the emulated storage on the userdata partition sdcardfs fuse 3. The boot control info in misc partition should be able to be recognized before and after OTA related feature is: * bootcontrol HAL 4. The bootargs passed by u-boot to kernel cannot be changed if the bootloader is not updated The related feature is: * bootconfig is used to pass boot args from android12.0.0_1.0.0. used with vendor boot header v4.   it should be known that if dual bootloader of postinstall is used, bootloader can be updated.   For these related features. Google does not implement or change them for a "retrofit device", just imlement for change the features for a "launch device", makes direct cross-version OTA feasible for them, because things cannot be changed during OTA are the same between different android versions. For i.mx android, to implement new features for all maintaied devices, things can be changed during OTA are often changed when update to a new version of android. which makes direct cross-version OTA infeasible.    For the ease of reference, list some feature change history here: * physical partition change history   P9.0.0_2.3.0 10.0.0_1.0.0 10.0.0_2.0.0 11.0.0_1.0.0 12.0.0_1.0.0 12.1.0_1.0.0 13.0.0_1.0.0 14.0.0_1.0.0 bootloader_a/b 4MB 4MB 4MB 4MB 4MB 16MB 16MB 16MB dtbo_a/b 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB boot_a/b 48MB 48MB 64MB 64MB 64MB 64MB 64MB 64MB init_boot_a/b - -   -   - 8MB 8MB vendor_boot_a/b - -   64MB 64MB 64MB 64MB 64MB misc 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB metadata 2MB 2MB 2MB 2MB 16MB 16MB 64MB 64MB presistdata 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB super - - 7168MB 3584MB 4096MB 4096MB 4096MB 4096MB fbmisc 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB vbmeta_a/b 1MB 1MB 1mb 1MB 1MB 1MB 1MB 1MB system_a/b 2560MB 1536MB - -   - - - vendor_a/b 256MB 512MB - -   - - - product_a/b - 1792MB - -   - - -   boot_a/b: 48MB → 64MB, Image becames bigger ater enabling some debug options vendor_boot_a/b: boot header v3. Vendor boot and boot header v3 are MUST to enable GKI feature.  init_boot_a/b: The init binary in ramdisk is moved from boot.img to init_boot.img. flash gki image from Google does not impact on the vendor modifications on init.   for the metadata partition: 2MB → 16MB, requirement of vts "-m vts_gsi_boot_test -t MetadataPartition#MinimumSize" 16MB → 64MB, to make the partition be formated as f2fs, 32MB is not enough, 64MB is used. metadata partition was firstly mounted in android11, when enable the user data checkpoint feature * gki feature history Firstly introduced in android11. Some codes are built into modules, put the modules in vendor_boot_a/b partition. vendor_boot_a/b partitions are also firstly introduced in android11 GKI prebuilt binary was integrated from android12   The way to handle cross-version OTA for i.mx android Here are the steps align the partitions within the OTA base code and the OTA target code if the product may be in the development stage, and the OTA base  code can be modified: reserve partitions in OTA base code. for example, OTA from 10 to 11, reserver the vendor_boot partition in android10 partitiont able although there is not vendor_boot.img. change the selinux rules to have update_engine to be able to update this partition. enlarge some partitions in the OTA base code as in the OTA target code. for examples, the bootloader partitions is 16MB in android13. if OTA from android12 to android13 and the android 12 code can be modified, enlarge the bootloader partition to 16MB. as data in userdata and metadata partition is not touched during OTA, modify the mount options of userdata and metadata partitions in OTA target code to be the same as the one in OTA base code. if the product partitions are already shipped, only the OTA target code can be modified:  as data in userdata and metadata partition is not touched during OTA, modify the mount options of userdata and metadata partitions in OTA target code to be the same as the one in the OTA base code. change the partition size to align with the OTA base code partitions like vendor_boot and/or init_boot may need to be removed. remove/change the features related to the removed or changed partitions if dual bootloader is not used: recently in android version update, vendor_boot and init_boot partitions are added, this is related to boot image header version, the images in these partitions are loaded and verified by uboot, so if dual bootloader is not used, uboot code related to these things need to be changed. check the code related to "struct boot_img_hdr" in uboot. the a/b slot metadata format may be changed between the OTA base code and the OTA target code , this a/b slot metadata is accessed by both Android bootctrl HAL and uboot, as dual bootloader is not used, uboot is not upaded, the updated Android bootctrl HAL should also use the same format to access the file. a postinstall mechanism can be used to update the uboot images, but as there is no fallback for the update failure, the risks need to be evaluated. check whether the OTA package can be applied and whether the updated system can boot up an failure example: OTA from android10 to android12, the system fail to boot up because of the PRODUCT_SHIPPING_API_LEVEL/"ro.product.first_api_level" value difference, different encryption options are used for userdata partitions. so the PRODUCT_SHIPPING_API_LEVEL value need to be changed to be the same as the one in the OTA base code. as PRODUCT_SHIPPING_API_LEVEL is changed, the FCM target version and related HALs may also need to be changed, including changes in device manifest.xml and compatibility_matrix.xml. need to check the commit history about what is changed together with the FCM target version change.   For dynamic partitions, there are something to be noticed: OTA from the image without dynamic partitions to use dynamic partitions: Refer to the code in android10.0.0_2.0.0, there is a demonstration to update 10.0.0_1.0.0 to 10.0.0_2.0.0. In 0.0.0_1.0.0, dynamic partition is not enabled. check the variable "TARGET_USE_RETROFIT_DYNAMIC_PARTITION" and related configurations. OTA from dynamic partitions to virtual A/B, for example, OTA from android10 to android11 inherit the file "build/make/target/product/virtual_ab_ota_retrofit.mk" the first time when update from android10 to android11 with OTA, inherit the "build/make/target/product/virtual_ab_ota_retrofit.mk", the BOARD_NXP_DYNAMIC_PARTITIONS_SIZE is set as dynamic paritition is used. the second time, the device is runing android11 with retrofit virtual A/B feature, this time OTA again, but not cross version, inherit "build/make/target/product/virtual_ab_ota.mk" instead, and the BOARD_NXP_DYNAMIC_PARTITIONS_SIZE  can be set as virtual A/B feature is used. Devices that were upgraded to dynamic partitions can’t retrofit virtual A/B. if there are new dynamic partitions in OTA target code, like vendor_dlkm, no additional changes need to be made for it. Then the customers need to do full xTS test to guarantee the quality.  

The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4/4X memory devices that are supported by the i.MX 93 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. The i.MX 93 series of processors supports different packages, and each have their own maximum supported LPDDR4/4x data rates. Please refer to the respective datasheets. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. NOTE: Some of the LPDDR4/4X devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. LPDDR4/4X - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 93 (i.MX 93xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4/4X - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 93 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G16D1FW-046 AAT:A  (Z32N) MT53E1G16D1ZW-046 AAT:C (Z42N) 7   4, 8 8 Gb/ (1 GB) Micron LPDDR4/4x: MT53D512M16D1DS-046 AAT (Z11M) 4, 10 16 Gb/ (2 GB) Micron LPDDR4/4x: MT53E1G32D2FW-046 AUT:B (Z42M) 4, 5, 10 8 Gb/ (1 GB) Nanya LPDDR4: NT6AN512M16AV-J1I LPDDR4x: NT6AP512M16BV-J1I 4, 8 4 Gb/ (512 MB) Nanya LPDDR4x: NT6AP256M16AV  4, 8 16 Gb/ (2 GB) Kingston LPDDR4: D1611PM3BDGUI-U 4, 8 16 Gb/ (2 GB) Kingston LPDDR4: C1612PC2WDGTKR-U  7, 9 4 Gb/ (512 MB) ISSI LPDDR4: IS43LQ16256B-062BLI 4, 8 2Gb / (256 MB) ISSI LPDDR4: IS43LQ16128A-062BSLI 4, 6, 8   8 Gb/ (1 GB) CXMT LPDDR4/4x: CXDB4CBAM-EA-M 4, 9 16 Gb/ (2 GB) JSC LPDDR4x: JSL4BAG167ZAMF  4, 8 8 Gb/ (1 GB) JSC LPDDR4x: JSL4B8G168ZAMF-05x  4, 8 4 Gb/ (512 MB) JSC LPDDR4x: JSL4A4G168ZAMF-05 4, 8 2Gb / (256 MB) Winbond  LPDDR4x: W66BQ6NBHAGJ 4, 6, 8 8Gb / (1 GB) IM (Intelligent Memory) LPDDR4x: IM8G16L4JCB-046I 4, 11 16Gb / (2 GB) IM (Intelligent Memory) LPDDR4/4x: IMAG16L4KBBG 4, 8 4Gb / (512 MB) Samsung LPDDR4: K4F4E164HD-THCL 4, 8 8 Gb / (1 GB) AM (Alliance Memory) LPDDR4X: AS4C512M16MD4V-053BIN 4, 8 4 Gb / (512 MB) ISSI LPDDR4/4X: IS43LQ16256B-053BLI 4, 8 8 Gb / (1 GB) ISSI LPDDR4/4X: IS46LQ16512B-046BLA2 4, 8 32 Gb / (4GB) 16 Gb / (2Gb) usable by i.MX93 ISSI LPDDR4/4X: IS46LQ32K01B-046BLI 4, 8   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B/JESD209-4-1 (LPDDR4/4X). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4/4X devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: This is a dual channel x32 device. Since i.MX93 only supports 16-bit LPDDR4/X data bus, it can only interface with one of the channels and therefore, utilize only half of the device's density. As indicated in the table - the device has 32Gb/4GB density however, only 16Gb/2GB can be used. There is no functional problem with using only one channel of a dual channel device as the channels are independent in LPDDR4/4X.  Note 6: This is a new JEDEC 100 ball package, half the size of the standard 200 ball package. This 100 ball package has the same performance and functionality as the 200 ball package, and has the added advantage of being smaller and cheaper than the standard package. Note 7: This device has been EoLed by the manufacturer and has been updated by a new memory part number  Note 8: Part is active. Reviewed Nov 2025 Note 9: Part is obsolete. Note 10: This device will be EoLed in Q2 24 by the manufacturer and will not be updated by a new memory part number Note 11: DQ eye marginalities were identified during TSA analysis. vTSA and stability testing did not identify any issues.

The following setup is done on i.MX 93. For i.MX 8M the same steps are valid and can be followed. Prerequisites Prepare the Yocto environment. $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-langdale -m imx-6.1.1-1.0.0.xml $ repo sync  Set the build environment. $ DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-evk source imx-setup-release.sh -b build-imx93 Add the 32-bit support to the image For i.MX 8M / i.MX 93, building 32-bit applications on 64-bit OS can be supported using the multilib configuration. Multilib offers the ability to build libraries with different target optimizations or architecture formats and combine these together into one system image.  Building a 32-bit application requires the following statements in conf/local.conf. The configuration specifies a 64-bit machine as the main machine type and adds multilib:lib32, where those libraries are compiled with the armv7athf-neon tune, and then includes to the image the lib32 packages. # Define multilib target require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 = "armv7athf-neon" # Add the multilib packages to the image IMAGE_INSTALL:append = " lib32-glibc lib32-libgcc lib32-libstdc++" Multilib is not supported with the debian package management. It requires the RPM system. Check and comment out the two package management lines in conf/local.conf to go to the default RPM. PACKAGE_CLASSES = "package_deb" EXTRA_IMAGE_FEATURES += "package-management" Build the image. bitbake imx-image-core Cross-compile a 32-bit application This section shows how to use the Linux SDK to cross-compile a simple C application into a 32-bit binary. Generate the SDK, which includes the tools, toolchain, and small rootfs to compile against to put on host machine: DISTRO=fsl-imx-wayland MACHINE=imx93-11x11-lpddr4x-evk bitbake core-image-minimal -c populate_sdk Set the SDK environment with the following command before building: source /opt/fsl-imx-wayland/6.1-langdale/environment-setup-armv7at2hf-neon-pokymllib32-linux-gnueabi Implement a simple hello world application: cat hello_world_32.c #include <stdio.h> int main() { printf("Hello, World!"); return 0; } $CC hello_world_32.c -o hello_world_32 Check the file's type: $ file hello_world_32 hello_world_32: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=0a5042a0309858e0b10b12175a155cfbfb4c6a80, for GNU/Linux 3.2.0, with debug_info, not stripped Copy the binary to the Linux rootfs. Run the application on i.MX 93 Boot the board and run the application: root@imx93-11x11-lpddr4x-evk:~# ./hello_world_32 Hello, World!  

1.Test environment Board: i.MX8MPlus, RM67199 BSP: uboot 2022.04, linux-6.1.1-1.0.1 2.Modification of uboot  In uboot, you need comment the video_link_shut_down and dm_remove_devices_flags in announce_and_cleanup function. #if defined(CONFIG_VIDEO_LINK) //video_link_shut_down(); #endif board_quiesce_devices(); printf("\nStarting kernel ...%s\n\n", fake ? "(fake run for tracing)" : ""); /* * Call remove function of all devices with a removal flag set. * This may be useful for last-stage operations, like cancelling * of DMA operation or releasing device internal buffers. */ // #ifndef CONFIG_POWER_DOMAIN // dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL); // /* Remove all active vital devices next */ // dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL); // #endif cleanup_before_linux(); }  After doing this, the uboot logo will not be cleaned before Linux PM framework. 3.Modification of Linux You need add  CONFIG_LOGO=n into defconfig file to disable kernel logo.  3.1 Disable the power down of mediamix and mipi-dphy in gpcv2.c Please add below code into the beginning of  imx_pgc_power_down function if ((strcmp(genpd->name, "mipi-phy1") == 0) || (strcmp(genpd->name, "mediamix") == 0)) { return 0; }  3.2 Only reset lcdif in the last call of drm framework Please modify imx_lcdifv3_runtime_resume function like this. The imx_lcdifv3_runtime_resume function will be called two times, thus the lcdif will be reset two times.We can let it only reset last time,which before the rootfs mount. bool rst = false; ////////////////////////////// static int imx_lcdifv3_runtime_resume(struct device *dev) { int ret = 0; struct lcdifv3_soc *lcdifv3 = dev_get_drvdata(dev); if (unlikely(!atomic_read(&lcdifv3->rpm_suspended))) { dev_warn(lcdifv3->dev, "Unbalanced %s!\n", __func__); return 0; } if (!atomic_dec_and_test(&lcdifv3->rpm_suspended)) return 0; /* set LCDIF QoS and cache */ if (of_device_is_compatible(dev->of_node, "fsl,imx93-lcdif")) regmap_write(lcdifv3->gpr, 0xc, 0x3712); request_bus_freq(BUS_FREQ_HIGH); ret = lcdifv3_enable_clocks(lcdifv3); if (ret) { release_bus_freq(BUS_FREQ_HIGH); return ret; } ////////////////////////////// if (rst) { /* clear sw_reset */ writel(CTRL_SW_RESET, lcdifv3->base + LCDIFV3_CTRL_CLR); rst = false; } rst = true; ////////////////////////////// /* enable plane FIFO panic */ lcdifv3_enable_plane_panic(lcdifv3); return ret; } 4.Conclusion The uboot logo will be cleaned at log "imx-drm 1.0.0 20120507 for display-subsystem on minor 1". The boot time of  systemd service on evk is very long. For weston.service, it needs 3 seconds. From log here we test, the pcie and ethernet probe after drm system also cost about 1 second. If you want to reduce the boot time of other modules, you can try to reduce the system service and disable pcie/ethernet drivers if you don't need them. [ 2.505616] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 1 [ 2.620324] imx6q-pcie 33800000.pcie: iATU unroll: enabled [ 2.620335] imx6q-pcie 33800000.pcie: iATU regions: 4 ob, 4 ib, align 64K, limit 16G [ 2.720689] imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up [ 2.820996] imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up [ 2.821003] imx6q-pcie 33800000.pcie: Link up, Gen2 [ 2.821010] imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up [ 2.821112] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00 [ 2.821119] pci_bus 0000:00: root bus resource [bus 00-ff] [ 2.821126] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] [ 2.821133] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff] [ 2.821161] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 [ 2.821176] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff] [ 2.821187] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref] [ 2.821232] pci 0000:00:00.0: supports D1 [ 2.821237] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold [ 2.824664] pci 0000:01:00.0: [1b4b:2b42] type 00 class 0x020000 [ 2.824725] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x000fffff 64bit pref] [ 2.824761] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x000fffff 64bit pref] [ 2.825066] pci 0000:01:00.0: supports D1 D2 [ 2.825072] pci 0000:01:00.0: PME# supported from D0 D1 D3hot D3cold [ 2.835499] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff] [ 2.835511] pci 0000:00:00.0: BAR 15: assigned [mem 0x18100000-0x182fffff pref] [ 2.835519] pci 0000:00:00.0: BAR 6: assigned [mem 0x18300000-0x1830ffff pref] [ 2.835530] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x181fffff 64bit pref] [ 2.835561] pci 0000:01:00.0: BAR 2: assigned [mem 0x18200000-0x182fffff 64bit pref] [ 2.835590] pci 0000:00:00.0: PCI bridge to [bus 01-ff] [ 2.835598] pci 0000:00:00.0: bridge window [mem 0x18100000-0x182fffff pref] [ 2.835899] pcieport 0000:00:00.0: PME: Signaling with IRQ 218 [ 2.897767] Console: switching to colour frame buffer device 135x120 [ 3.098361] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device [ 3.111239] pps pps0: new PPS source ptp0 [ 3.316650] fec 30be0000.ethernet eth0: registered PHC device 0 [ 3.323645] imx-dwmac 30bf0000.ethernet: IRQ eth_lpi not found [ 3.329593] imx-dwmac 30bf0000.ethernet: force_sf_dma_mode is ignored if force_thresh_dma_mode is set. [ 3.340074] imx-dwmac 30bf0000.ethernet: User ID: 0x10, Synopsys ID: 0x51 [ 3.346883] imx-dwmac 30bf0000.ethernet: DWMAC4/5 [ 3.351684] imx-dwmac 30bf0000.ethernet: DMA HW capability register supported [ 3.358825] imx-dwmac 30bf0000.ethernet: RX Checksum Offload Engine supported [ 3.365966] imx-dwmac 30bf0000.ethernet: Wake-Up On Lan supported [ 3.372113] imx-dwmac 30bf0000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 3.379778] imx-dwmac 30bf0000.ethernet: Enabled L3L4 Flow TC (entries=8) [ 3.386573] imx-dwmac 30bf0000.ethernet: Enabled RFS Flow TC (entries=10) [ 3.393373] imx-dwmac 30bf0000.ethernet: Enabling HW TC (entries=256, max_off=256) [ 3.400950] imx-dwmac 30bf0000.ethernet: Using 34 bits DMA width [ 3.608045] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 3.613580] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 1 [ 3.621621] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220fe6d hci version 0x110 quirks 0x0000002001010010 [ 3.631059] xhci-hcd xhci-hcd.1.auto: irq 226, io mem 0x38200000 [ 3.637197] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller [ 3.642698] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 2 [ 3.650365] xhci-hcd xhci-hcd.1.auto: Host supports USB 3.0 SuperSpeed [ 3.657695] hub 1-0:1.0: USB hub found [ 3.661473] hub 1-0:1.0: 1 port detected [ 3.665669] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [ 3.674445] hub 2-0:1.0: USB hub found [ 3.678220] hub 2-0:1.0: 1 port detected [ 3.683428] imx-cpufreq-dt imx-cpufreq-dt: cpu speed grade 7 mkt segment 2 supported-hw 0x80 0x4 [ 3.693184] Hot alarm is canceled. GPU3D clock will return to 64/64 [ 3.702683] sdhci-esdhc-imx 30b50000.mmc: Got CD GPIO [ 3.703346] mxc-mipi-csi2-sam 32e40000.csi: supply mipi-phy not found, using dummy regulator [ 3.716645] : mipi_csis_imx8mp_phy_reset, No remote pad found! [ 3.722602] mxc-mipi-csi2-sam 32e40000.csi: lanes: 2, hs_settle: 13, clk_settle: 2, wclk: 1, freq: 500000000 [ 3.739353] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA [ 3.752018] isi-m2m 32e00000.isi:m2m_device: Register m2m success for ISI.0 [ 3.759172] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 3.768303] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 3.787598] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 3.795171] ALSA device list: [ 3.796227] platform regulatory.0: Falling back to sysfs fallback for: regulatory.db [ 3.799186] No soundcards found. [ 3.819630] EXT4-fs (mmcblk2p2): mounted filesystem with ordered data mode. Quota mode: none. [ 3.828212] VFS: Mounted root (ext4 filesystem) on device 179:2. [ 3.834944] devtmpfs: mounted

Hello, here Jorge. On this post I will explain how to configure, record and play audio using an i.MX 8MIC-RPI-MX8 Board. Requirements: I.MX 8M Mini EVK Linux Binary Demo Files - i.MX 8MMini EVK (L5.15.52_2.1.0) i.MX 8MIC-RPI-MX8 Board Serial console emulator (Tera Term, Putty, etc.) Headphones/speakers The 8MIC-RPI-MX8 accessory board is designed for voice enabled application prototyping and development on the i.MX 8M family. The board plugs directly into the 40-pin expansion connector on the i.MX 8M Mini and Nano EVK’s. Some features about this board are: 8 PDM Microphones 8 monochrome LEDs 4 multi-color LEDs 2 status LEDs 4 pushbuttons Microphone Mute Switch Microphone geometry switch Connecting the i.MX 8MIC-RPI-MX8 Board. The i.MX 8MIC-RPI-MX8 Board has a 40-pin expansion connector that you can plug it directly to the EVK board. Ensure that pin 1 of the 8MIC-RPI-MX8 is aligned with pin 1 on the EVK J1001 as is showed on the next figure:  Selecting the device tree on the board. Once the pre-compiled image is flashed on the board (Flashing Linux BSP using UUU) and you connected the 8MIC-RPI-MX8 it is necessary to select the correct device tree to handle 8MIC board. On U-boot check the available .dtb files on the BSP using the next command: u-boot=> fatls mmc 2:1 And you will get the corresponding list of .dbt files:  On this case we are working with an I.MX 8M Mini EVK and the corresponding .dtb file is: imx8mm-evk-8mic-revE.dtb To select it you need to set the environment variable and save it with: u-boot=> setenv fdtfile imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Doble check it using: u-boot=> printenv fdtfile   Now it is time to boot Linux using the next command: u-boot=> boot Recording audio with the i.MX 8MIC-RPI-MX8 Board. The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system. ALSA has the following significant features: Efficient support for all types of audio interfaces, from consumer sound cards to professional multichannel audio interfaces. Fully modularized sound drivers. SMP and thread-safe design. User space library (alsa-lib) to simplify application programming and provide higher level functionality. Support for the older Open Sound System (OSS) API, providing binary compatibility for most OSS programs. Once we are on Linux, we can check our audio codecs detected on the board using: arecord -l   Now, to record audio we need to use the ALSA arecord command to start recording with IMX8 boards, there are different options that you can check on the next link. On this case we are going to use the next: arecord -D hw:imxaudiomicfil -c8 -f s16_le -r48000 -d10 sample.wav -D: selects the device. -c: selects the number of channels on the recording. -f: selects the format. -r: selects the sample rate. -d: determinate the duration recording time in seconds. sample.wav: Is the name of the resulting audio file. Running the last command, we started to record audio. It is time to make some noise and record it!   Playing audio from IMX8 boards. Now it is time to connect our headphones or speakers to the jack.   Also, as on arecord command you can check the devices where you can play audio from the board using the next command: aplay -l And you will get all the codecs to play audio:   To play our recordings we need to use the ALSA aplay command, it is important to select the correct audio codec to hear the audio from the jack on the board: aplay -Dplughw:3,0 sample.wav -D: selects the device. sample.wav: Is the name of audio file to play   Hope this will helpful for people who wants to record audio using PDM microphones and playing audio from IMX8 boards. Best regards.

What is Automotive Grade Linux? Automotive Grade Linux is a collaborative, open source project that brings together automakers, suppliers, and technology companies for the purpose of building Linux-based, open source software platforms for automotive applications that can serve as de facto industry standards. AGL address all software in the vehicle: infotainment, instrument cluster, heads-up-display (HUD), telematics, connected car, advanced driver assistance systems (ADAS), functional safety, and autonomous driving. Architecture The Automotive Grade Linux Software Architecture diagram is below. The architecture consists of five layers. The App/HMI layer contains applications with their associated business logic and HMI. The Application Framework layer provides the APIs for creating both managing and running applications on an AGL system. The Services layer contains user space services that all applications can access. The Operating System (OS) layer provides the Linux kernel and device drivers along with standard OS utilities. For IVI (In Vehicle Infotainment) system a full fledged demo is available. Supported Boards The following table briefs about the various hardware platforms, supported by AGL : BOARD $MACHINE ARCHITECHTURE BeagleBone bbe arm32   beaglebone arm32       i.MX 6 cubox-i arm32   imx6qdlsabreauto arm32   nitrogen6x arm32       i.MX 8 imx8mqevk arm64   imx8mqevk-viv arm64       Snapdragon dragonboard-410c arm64   dragonboard-820c arm64       ARC HS hsdk ARC       virtio virtio-aarch64 arm64   AGL Components AGL includes some major components showing as follow: agl-compositor waltham-receiver_waltham-transmitter rba drm-leasemanager appfw cynagora. pyagl pipewire_wireplumber agl-compositor When the AGL project was started, weston was chosen as the compositor, which is the reference implementation of a Wayland compositor, while for window management functionality it relied on ivi-shell (In-Vehicle Infotainment) together with an extension, called wayland-ivi-exension.   Waltham protocol is a IPC library similar to Wayland, developed with networking in mind. It operates over TCP sockets, while the wayland protocol only works locally over a UNIX socket. It retains wayland-esque paradigm, making use of XMLs to describe the protocol, and it follows an object-oriented design with an asynchronous architecture. DRM Lease Manager The DRM Lease Manager is used in AGL to allocate display controller outputs to different processes. Each process has direct access to its allocated output via the kernel DRM interface, and is prevented from accessing any other outputs managed by the display controller. PyAGL  PyAGL was written to be used as a testing framework replacing the Lua afb-test one, however the modules are written in a way that could be used as standalone utilities to query and evaluate apis and verbs from the App Framework Binder services in AGL. PipeWire / WirePlumber AGL uses the PipeWire daemon service to provide audio playback and capture capabilities. PipeWire is accompanied by a secondary service, WirePlumber (also referred to as the session manager), which provides policy management, device discovery, configuration and more. Applications can connect to the PipeWire service through its UNIX socket, by using either the libpipewire or libwireplumber libraries as a front-end to that socket. How to port AGL in i.MX8qm get agl source as follow: repo init -b koi -uhttps://git.automotivelinux.org/AGL/AGL-repo repo sync apply patches in attachment add file agl_imx8qmmek.inc to path 'meta-agl\meta-agl-bsp\conf\include'. add files 40_bblayers.conf.inc, 50_local.conf.inc and 50_setup.sh to path 'meta-agl\templates\machine\imx8qmmek'. build as follow: source meta-agl/scripts/aglsetup.sh -f -m imx8qmmek agl-demo bitbake agl-demo-platform Then the wic image can be flashed into i.mx8qm showing as below:

This article will describe one suggestion for one issue that UART continuously generate RX interrupts and receive 0xFF even when Rx line is continuously high in some cases on imx6 series. Below I will explain with imx6DL. Some settings are just to make it easier to reproduce. BSP version: L5.4.70-2.3.0 Board HW: MCIMX6DL-SDB When issue happen Config imx6DL UART3 as the serial port to 1200 baud, 8-N-1 format. Keep the RX Line high. Make the RX line low and keep it for a short time (360 usec-370 usec).   At this condition, you will find that the UART will continuously generate RX interrupts and show receiving 0xFF even you make the RX line return to be high. Why issue happen The low time is not in the correct range and out of our spec. In the imx6DL AEC document, there is one chapter named UART Receiver like blow   If using 1200 band, that means one valid bit time is 833 usec. And there is a definition that “tolerate 1/(16 x Fbaud_rate) tolerance in each bit”. That’s means in the case of 1200 baud. A range of valid bit is 781 to 885 usec. But is reproducing, the Low level time is 360 usec. This time out of range will make UART state machine to be confused. How to fix Actually, the best way is following our spec. If there is such an unknown situation in the customer’s environment, then the following method could be regarded as a suggestion to fix the issue meet by the customer. The interrupt handler will check USR1[AWAKE]. 2    If AWAKE is asserted, clear it and proceed as usual (assume we have valid data), else, check if USR1[AGTIM] is asserted. 3    if AGTIM is asserted, clear it and proceed as usual, else perform software reset (assume we have invalid data). Checking AGTIM is for one race condition when the RX fifo has some characters (less than RXTL) but no more data is coming in. When following this procedure, the UART will perform a software reset when a block interrupt occurs. Notes: From customer report, error could be cleared if a valid start-bit is detected on the RX line. This needs to be verified by the customer themselves. Test code has been included in attachment.   Besst Regards