i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
imx8mm platform on 4.14.78/98 GA Android  LCD MIPI panel or HDMI display may appear some strange color stride .  This is  one patch for this issue. 
View full article
恩智浦BSP的内核定制 ........................................... 103 6.1 IO管脚配置与Pinctrl驱动 .................................... 103 6.2 新板bringup ........................................................ 118 6.3 更改调试串口: .................................................. 127 6.4 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 133 6.5 LVDS LCD 驱动定制 .......................................... 142 6.6 GPIO_Key 驱动定制 .......................................... 145 6.7 GPIO_LED 驱动定制 ......................................... 149 6.8 Fuse nvram驱动 ................................................. 152 6.9 SPI与SPI Slave驱动 ........................................... 153 6.10 USB 3.0 TypeC 改成 USB 3.0 TypeA(未验证) ... 160 6.11 汽车级以太网驱动定制 ....................................... 160
View full article
Platform: imx8qxp mek b0. OS: android imx-p9.0.0_2.1.0-auto-ga. Hardware block: brief: Android p9 ga enabled the hardware partition, so it is impossible to share dpu between AP and m4, and seamless switching can be achieved by keeping the last m4 ui frame until android ui is ready. To achieve seamless switch between android A core and M4 core on android ga, user needs to modify two parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core M4 code: modify dpu pipes, share memory with android partition.        Switching flow:        M4 release and move camera, dpu to android partition and share the display buffer memory with android, android will not init the dpu subsyses that have been inited by m4 and will keep the m4 last frame ui until android ui is ready. Imx8qxp dpu block: Android and M4 shared dpu path:
View full article
iMX8QXP/iMX8QM have hardware JPEG decoder: The JPEG-D-X core. This is the example code to use this hw decoder in M4 SDK to decode JPEG files. M4_JPEG_DECODER_SDK_2.5.1.7z The attached "rear_view_camera_jpegdec.tar.bz2" is the updated source code for "SDK\boards\mekmimx8qx\demo_apps\rear_view_camera". It is based on SDK 2.5.1 for iMX8QXP MEK. The "rear_view_camera_jpegdec.patch" is the modified code, it hasn't included the added "fsl_jpeg_dec.c" and "fsl_jpeg_dec.h".   The testing used two 256*256 JPEG files, they are RGB color space. We used followed commands to build them into flash.bin: ./mkimage_imx8 -soc QX -rev B0 -append ahab-container.img -c -scfw scfw_tcm.bin -m4 m4_rear_view_camera.bin 0 0x34FE0000 --data demo_rgb.jpg 0x84000000 --data demo_rgb2.jpg 0x84008000 -out flash.bin   If customer need change the JPEG resoluion, they can change them in file "fsl_jpeg_dec.h", APP_JPEG_SIZE_OF_KB is the JPEG file length in memory, aligned in KB.   #define APP_JPEG_WIDTH (256) #define APP_JPEG_HEIGHT (256) #define APP_JPEG_SIZE_OF_KB (32) #define APP_JPEG_FORMAT JPEG_RGB #define APP_JPEG_BUFFER (0x84000000)   To created RGB format JPEG file from RGB data, the customer can use linux unit test application "/unit_tests/JPEG/encoder_test.out". M4_JPEG_DECODER_WINDOW_MODE_SDK_2.5.1.7z Based on JEPG decoder, added DPU CSC support and render JEPG decoded video in overlay window. The architecture is followed: NXP logo is put in FetchLayer0 with RGB565 format, after LayerBlend0, it will be the prim layer for LayberBlend1 (FetchLayer0 can't be used as prim layer for LayerBlend), the JPEG decoder output is put to FetchDecoder0. RGB888 format, and it will be resize to 640*480, and put to x=100, y=100 of the display. (Only the sec layer of LayerBlend can be window mode). Some limitation for layer selection in LayerBlend:
View full article
Please join us for a webinar tomorrow - July 30 at 10 AM CDT. Register here: https://info.cranksoftware.com/resources/modernize-embedded-graphics-ultra-low-power-ui-nxpcranksoftware NXP’s i.MX 7ULP applications processor, alongside Crank's Storyboard GUI design and development software, gives embedded teams the best of both worlds – rich 2D/3D performance with MCU-level low power. Join Brian Edmond and Nik Jedrzejewski to get a technical deep dive into the i.MX 7ULP and Storyboard and learn: the latest trends in graphics for battery-powered devices hardware features of the i.MX 7ULP, including the Heterogeneous Domain Computing architecture how to leverage Storyboard's hybrid rendering solution when switching between 2D and 3D graphics to minimize power consumption   PANELLISTS Brian Edmond, President, Crank Software Nik Jedrzejewski, i.MX Product Manager, NXP
View full article
The Guide is how to use Ubuntu filesystem with i.MX8 series platform.At present, I had try it on i.MX8QXP with 4.14.98 kernel with ubuntu16.04. The Document will be continuously updated with enable VPU, ubuntu18.04. The desktop we can chose Gnome or weston.  Because driver  support issue, gc7000 series gpu not support render Gnome destop but it can render weston destop.  Update 2019/7/31: Ubuntu-i.MX8-weston.pdf   Feature: weston + ubuntu18.04 + 4.14.98 kernel VPU (enable with gplay or gst-play)  GPU (could render desktop and run GPU demo under root privileges on Weston Desktop) I also try ubuntu with gnome desktop, ubuntu18.04 can not run gnome, need use ubuntu19.04. But Gnome Desktop just render by CPU.  ------------------------------------------------------------------------------------- Update 2020/3/6: Ubuntu-i.MX8M.pdf Just a simple guide for IMX8M series, will be  continuously updated. 
View full article
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/
View full article
Brief introduction on i.MX Android
View full article
Brief introduction on the aarch64 linux kernel memory mapping layout and basic management stuffs.  Contents include: Kernel's virtual memory layout and mapping after running i.MX8QM/QXP kernel reserved memory layout Kernel memory allocation method and technology (Buddy, cma, ION...) DMA buffer management, SWIOTLB, IOMMU GPU memory management How to customize the memory for different use cases How to avoid using CMA for a better stability and performance
View full article
Several customers met uuu failure because their board doesn't use same CC logic (ptn5110) of i.MX8MM EVK. For this problem it's able to disable CC logic and to force device mode of u-boot. Shared the patch based on 4.14.78 for reference.
View full article
Several customers met problem on audio codec porting. In order to figure out cpu dai setting problem or codec dai problem. Create the dummy codec for test purpose.  What this dummy codec can do This dummy codec can play up to 8 channels and record up to 6 channels. Connect SAI1 TX data pin with SAI1 RX data pin for loopback test. Environment Verified with i.MX8MM EVK  Based on Linux BSP L4.14.78 Files Kernel patch 0001-multiple-channels-dummy-audio-codec 0002-Add-capture-for-multiple-channels User space setting /etc/asound.conf /usr/share/alsa/cards/aliases.con /usr/share/alsa/cards/DUMMY.conf Audio test content PCM_48_16_8_160000_1_29_jazzshort.wav The alsa command for loopback test with multiple channels  aplay -D surround51:CARD=dummyaudio PCM_48_16_8_160000_1_29_jazzshort.wav | arecord -D surround51:CARD=dummyaudio --disable-channels --disable-format --disable-resample -f S16_LE -r 48000 -c 6 -d 5 -v test.wav
View full article
This document simply introduce how to change uboot for porting new PHY on imx7D customized board   Background: Current imx7D Sabresd board uses BCM54220B0KFBG PHY, the customized board wants to use KSZ9031 as PHY on the yocto 4.9.88 version, the customized board uses only one ethernet port on ENET2 port according to the imx7D Sabresd board   Requirement: Refer to the yocto user guide of 4.9.88 version, built your own image, for simple, you can built core-image-minimal, and download the 4.9.88 mfgtool to program        The document of 4.9.88: https://www.nxp.com/webapp/Download?colCode=L4.9.88_2.0.0_LINUX_DOCS        mfgtool for downloading: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX6_L4.9.88_2.0.0_MFG_TOOL&appType=file2&location=null&DOWNLOAD_ID=null&lang_cd=en        Design files: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=iMX7D-SABRE-DESIGNFILES&appType=file1&DOWNLOAD_ID=null&lang_cd=en     adding customized code in u-boot head file: refer to the customized board schematic as below:     This board use eth2 as ethernet port, the code mx7dsabresd.h(path: yocto-L4.9.88_2.0/build-x11/tmp/work/imx7dsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/include/configs) /* Network */ #ifdef CONFIG_DM_ETH #define CONFIG_FEC_MXC #define CONFIG_MII #define CONFIG_FEC_XCV_TYPE             RGMII #define CONFIG_FEC_ENET_DEV       0   #define CONFIG_PHYLIB #define CONFIG_PHY_BROADCOM /* ENET1 */ #if (CONFIG_FEC_ENET_DEV == 0) #define IMX_FEC_BASE              ENET_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x0 #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth0" #else #define CONFIG_ETHPRIME                 "FEC0" #endif #elif (CONFIG_FEC_ENET_DEV == 1) #define IMX_FEC_BASE              ENET2_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x1 #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth1" #else #define CONFIG_ETHPRIME                 "FEC1" #endif #endif     Change the source code as below, add two macro definition and change the PHY address according to the schematic: /* Network */ #define CONFIG_PHY_MICREL #define CONFIG_PHY_MICREL_KSZ9031   #ifdef CONFIG_DM_ETH #define CONFIG_FEC_MXC #define CONFIG_MII #define CONFIG_FEC_XCV_TYPE             RGMII   #define CONFIG_FEC_ENET_DEV       0     #define CONFIG_PHYLIB #define CONFIG_PHY_BROADCOM /* ENET1 */ #if (CONFIG_FEC_ENET_DEV == 0) #define IMX_FEC_BASE              ENET_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x1 #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth0" #else #define CONFIG_ETHPRIME                 "FEC0" #endif #elif (CONFIG_FEC_ENET_DEV == 1) #define IMX_FEC_BASE              ENET2_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x2   #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth1" #else #define CONFIG_ETHPRIME                 "FEC1" #endif #endif       adding customized code in u-boot source file: the source code named mx7dsabresd.c (path: yocto-L4.9.88_2.0/build-x11/tmp/work/imx7dsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/board/freescale/mx7dsabresd)         Don’t forget include the micrel.h file        Focus on the setup_fec fuction   Imx7d Sabresd board uses gpio_spi 5 as reset pin so the source code as below: ret = gpio_lookup_name("gpio_spi@0_5", NULL, NULL, &gpio)                if (ret) {               printf("GPIO: 'gpio_spi@0_5' not found\n");     The customized board uses GPIO1_IO03 as reset pin, so the source code was changed to : imx_iomux_v3_setup_pad(MX7D_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(NO_PAD_CTRL)); ret = gpio_request(IMX_GPIO_NR(1, 3), "enet_phy_rst"); gpio_direction_output(IMX_GPIO_NR(1, 3), 0);        mdelay(20);        gpio_direction_output(IMX_GPIO_NR(1, 3), 1);       udelay(100);         Focus on the function board_phy_config fuction Use this function to set the phy rx, tx data pad skew and clock pad skew, for ksz9031, can refer to the UDOO board, then change the setting source code as below: /* control data pad skew - devaddr = 0x02, register = 0x04 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);        /* rx data pad skew - devaddr = 0x02, register = 0x05 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);        /* tx data pad skew - devaddr = 0x02, register = 0x05 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);        /* gtx and rx clock pad skew - devaddr = 0x02, register = 0x08 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_CLOCK_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x03FF);       Build the uboot source code then program to the customized board, the log file as below: U-Boot 2017.03-imx_v2017.03_4.9.88_2.0.0_ga+gb76bb1b (Apr 20 2019 - 17:51:51 +0800)   CPU:   Freescale i.MX7D rev1.3 996 MHz (running at 792 MHz) CPU:   Commercial temperature grade (0C to 95C) at 32C Reset cause: POR Model: Freescale i.MX7D SabreSD Board Board: i.MX7D SABRESD RevC in secure mode DRAM:  1 GiB PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 MMC:   FSL_SDHC: 0, FSL_SDHC: 1 Display: TFT43AB (480x272) Video: 480x272x24 In:    serial Out:   serial Err:   serial switch to partitions #0, OK mmc1(part 0) is current device Net:   Error: ethernet@30bf0000 address not set. eth0: ethernet@30be0000 Error: ethernet@30bf0000 address not set.   Ending: Don’t worry about this error message, because you don’t set correct mac address, one has two option to set this, For one, you can add mac address in the uboot manually, like setenv ethaddr 00:11:22:33:44:55     another option is add CONFIG_NET_RANDOM_ETHADDR=y in the configure file, then you don’t need to set mac address manually, would get a random mac address   this document just simply introduce how to change the source code in the u-boot, you also need to change the kernel dts file and kernel file to support the new PHY, the kernel has the same process, the phy address, the phy settings, and the gpio pins, hope this document give you some hints to port the new PHY
View full article
Summary: The i.MX 8M-Mini can boot from QSPI flash using a dedicated boot image. The boot config settings are not correctly documented in the EVK Board Hardware User's Guide Rev 0 from 02/2019. In the document i.MX_Linux_User's_Guide.pdf  in the BSP documentation 4.14.98 the settings are correctly given in Table 38 Details: To generate a bootable file for the QSPI with Yocto, you need to include the following setting into local.conf: UBOOT_CONFIG = "fspi" If you don't want/need to make a complete build, just rebuild u-boot: bitbake -c deploy u-boot-imx Alternatively the file imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi included already in the BSP demo packages will work as well Program the image into QSPI: With UUU:   uuu -b qspi imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi With u-boot: u-boot=> fatls mmc 0:1 14557696   Image    …   1446848   imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi 11 file(s), 0 dir(s) u-boot=> sf probe SF: Detected n25q256a with page size 256 Bytes, erase size 4 KiB, total 32 MiB u-boot=> fatload mmc 0:1 0x40480000 imx-boot-imx8mmevk-fspi.bin-flash_evk_flexspi 1446848 bytes read in 79 ms (17.5 MiB/s) u-boot=> sf erase 0x0 0x200000 SF: 2097152 bytes @ 0x0 Erased: OK u-boot=> sf write 0x40480000 0x0 0x200000 device 0 offset 0x0, size 0x200000 SF: 2097152 bytes @ 0x0 Written: OK u-boot=> sf read 0x50000000 0x0 0x200000 device 0 offset 0x0, size 0x200000 SF: 2097152 bytes @ 0x0 Read: OK u-boot=> cmp.b 0x40480000 0x50000000 0x200000 Total of 2097152 byte(s) were the same u-boot=> Set boot config jumpers correctly and power on the board (no SD-card in the slot) 8M-Mini Rev A and Rev B boards:  01xxxxx0 0000x001 8M-Mini Rev C boards: 0110xxxxxx 00100x0010
View full article
Instrumenting A Board To instrument a board, the connection between the power supply and the target device needs to be broken, usually via a series resistor that's placed on the board. Sometimes the inductor needs to be lifted if no series resistor was included on the rail by the board's designer. In the ideal case, through-hole connections were also provided on the board for the connection of these off-board sensors. Here are three close-up photos that show several boards that have been instrumented: In all three cases, the sensors stand in place via the two outer current carrying wires. The middle and right used insulated wires where as the one on the left used bare wires. In all three cases, the sensor's + connection needs to go towards the power supply and the - connection goes to the target device. The outer wires here are 24-26 gauge. (The relatively heavy gauge wire is used to keep the series resistance of inserting a smart sensor to a minimum.) The ground connection is the middle hole of the smart sensor. In the left and middle photos, a 30 gauge wire connects to the middle hole ground connection on the  board. In the right photo, the ground wire was more conveniently added to a big cap just below the bottom of edge of the photo. Here are wider angle view photos of two of the boards above: The sensors on the left are free-standing since the current carrying wires are stiff enough to hold them upright. Care must be taken since too much flexing will cause a wire to break. Too much bending can also cause a short to the board (and that's why insulated wires were used on these boards). The board on the right has the sensors laying parallel to the board. They are not affixed to the board, but a wire is wrapped around the bundle of ribbon cables out of view past the right edge of the photo. For boards without the through hole connections, the smart sensors need to be immobilized to keep from pulling the SMT pads off the board. If there is room on the board or sides of connectors or large components, the sensors may be attached down with foam double-sticky tape (see photo below, sensor affixed on top i.MX7ULP): For boards where there are no convenient unpopulated areas or there are too many sensors, some other means needs to be devised to immoblize the smart sensors. In the left photo below, two inductors per sensor have been flipped and the two sensors inserted to instrument the two rails. The solder pads on the inductors would easily be broken off by any movement of the smart sensors, so a cage with clamps to hold the ribbon cables was 3D printed. On the back side, there is room for the aggregator to be zip tied to the bottom plate, so the instrumented board can be moved as a single unit with minimal flexing of the ribbon cables.
View full article
Why reset EPDC When TCE underrun occurs repeatedly, EPDC might lock up and the signal to panel continues. There is chance to cause panel damage. The attached patch provides a way to reset EPDC to cut the signal out and recover EPDC from lockup. The patch is based on L4.1.15. As for TCE underrun, QoS patch has obvious improvement. https://community.nxp.com/docs/DOC-343599
View full article
Tool: VMware Workstation Player Linux Distribution : Ubuntu 16.04 1. Create the VM in VMware Workstation. 2. Select the .iso file to install the Ubuntu 16.04 in the VM. 3. In "Specify Disk Capacity", I recommend the disk size is 200GB. 4. Then click "Finish" to create the VM. 5. If you have local mirror sources, change the source in /etc/apt/source.list. This will speed up a lot when you download the Linux packages and software. 6. Type these two commands to update the Ubuntu system. - sudo apt-get update - sudo apt-get upgrade 7. Install Yocto Project host packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev $ sudo apt-get install libsdl1.2-dev xterm sed cvs subversion coreutils texi2html docbook-utils python-pysqlite2 help2man make gcc g++ desktop-file-utils libgl1-mesa-dev libglu1-mesa-dev mercurial autoconf automake groff curl lzop asciidoc u-boot-tools 8.Install the repo a. Create a bin folder in the home directory. $ 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 b. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH If you cannot download the repo from google, please try this one: Git Repo | 镜像站使用帮助 | 清华大学开源软件镜像站 | Tsinghua Open Source Mirror  9. Yocto project setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.0.0_ga.xml $ repo sync 10. Building an image The syntax for the fsl-setup-release.sh script is shown below. $ DISTRO=<distro name> MACHINE=<machine name> source fsl-setup-release.sh -b <build dir> $ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-xwayland $ bitbake fsl-image-qt5-validation-imx or $ bitbake core-image-full-cmdline (smaller size of rootfs) (for more examples, please refer to the i.MX_Yocto_Project_User's_Guide.pdf) 11. U-boot and Kernel Source code in Yocto u-boot : imx-yocto-bsp/build-xwayland/tmp/work/<board_name>/u-boot-imx kernel : imx-yocto-bsp/build-xwayland/tmp/work/<board_name>/linux-imx 12. Deploy folder of the images imx-yocto-bsp/build-xwayland/tmp/deploy/images/<board_name> Some useful commands for your information: 1. Kernel Menuconfig $ bitbake linux-imx -c menuconfig 2. Rebuild the u-boot and kernel source code $ bitbake u-boot-imx -c compile -f $ bitbake linux-imx -c compile -f 3. Rebuild the whole project to generate the images to deploy folder again for example, if you build the fsl-image-qt5-validation-imx before , then type this: $ bitbake fsl-image-qt5-validation-imx -f Reference: (1) Download the BSP and the Documentation   :  i.MX Software | NXP 
View full article
UPDATE: Note that this document describes eIQ Machine Learning Software for the NXP L4.14 BSP release. Beginning with the L4.19 BSP, eIQ Software is pre-integrated in the BSP release and this document is no longer necessary or being maintained. For more information on eIQ Software in these releases (L4.19, L5.4, etc), please refer to the "NXP eIQ Machine Learning" chapter in the Linux User Guide for that specific release.  Original Post: eIQ Machine Learning Software for iMX Linux 4.14.y kernel series is available now. The NXP eIQ™ Machine Learning Software Development Environment enables the use of ML algorithms on NXP MCUs, i.MX RT crossover processors, and i.MX family SoCs. eIQ software includes inference engines, neural network compilers, and optimized libraries and leverages open source technologies. eIQ is fully integrated into our MCUXpresso SDK and Yocto development environments, allowing you to develop complete system-level applications with ease. Source download, build and installation Please refer to document NXP eIQ(TM) Machine Learning Enablement (UM11226.pdf) for detailed instructions on how to download, build and install eIQ software on your platform. Sample applications To help get you started right away we've posted numerous howtos and sample applications right here in the community. Please refer to eIQ Sample Apps - Overview. Supported platforms eIQ Machine learning software for i.MX Linux 4.14.y supports the L4.14.78-1.0.0 and L4.14.98-2.0.0 GA releases running on i.MX 8 Series Applications Processors. For more information on artificial intelligence, machine learning and eIQ Software please visit AI & Machine Learning | NXP.
View full article
In new iMX8QM and iMX8QXP BSP, it had implemented hardware partition to split the resource and memory regions. The default Android Auto BSP had given example for shared memory between M4 and A core, it is used for RPMSG. Here is an example to add a new shared memory for iMX8QXP MEK board with Android Auto P9.0.0_GA2.1.0 BSP, which can be accessed in both M4, Uboot and Linux Kernel. The new shared memory region is from 0xF6000000 to 0xFDFFFFFF, total 128MB, it covers the RPMSG region too. RPMSG shared memory is moved to 0xF6000000 ~ 0xF6BFFFFF, total 12MB. vendor_nxp_fsl-proprietary_uboot-firmware.patch SCFW patch for board file to change the old shared memory region (0x90000000~0x90BFFFFF) to new shared memory region (0xF6000000~0xFDFFFFFF). This patch is applied to android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/board-imx8qxp.c, after patched, copy this file to SCFW porting kit and build out a new SCFW image, put it to "android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/mx8qx-scfw-tcm.bin". vendor_nxp-opensource_uboot-imx.patch This is the Uboot patch to map the shared memory region, if Uboot doesn't need access these memory, this patch is not needed. vendor_nxp-opensource_kernel_imx.patch This is the kernel patch to map the shared memory region. Note: VPU reserved memory address shouldn't be changed, otherwise it will impact the VPU function. So the new reserved memory region had been moved to 0xF600000~0xFDFFFFFF. vendor_nxp_mcu-sdk-auto_SDK_MEK-MIMX8QX.patch M4 patch for RPMSG address changed from 0x90000000 to 0xF6000000. Note: 1. In this example, we put the two shared memory regions together, then it will not split the memory region used in Linux. Another reason for such modification is the limitation of memory region counts in SCFW. 2. Since the RPMSG shared memory had been moved from 0x90000000 to 0xF6000000, the M4 code who used shared memory should also be changed. 2019-07-29 Update: When "#define PHYS_SDRAM_2_SIZE  0x0" in Uboot, it will create a 0 size memory region, this will impact the Uboot shared memory patch. Added the "uboot_imx8_cpu.patch" to avoid such issue.
View full article
After rework the board, enable two OTG controllers in Linux DTB file and disable VBUS valid comparator when in suspend mode by clear USB_OTGx_PHY_CTL2 bit 16.  Then we get the following power data on suspend mode  Suspend Mode     ****  The page is under internal check ****
View full article
Why raising QoS priority for EPDC Eink has been developing higher resolution panel. With higher resolution, TCE underrun problem is observed more easily. Highest QoS priority can provide obvious improvement. What's TCE underrun TCE is Timing Controller Engine which is responsible for TFT scan frame refreshes. The pixel FIFO (PIX_FIFO) is used to load working buffer pixel data for TCE. When FIFO underrun, TCE_UNDERRUN_IRQ interrupt is triggered, and TCE underrun log pops up in kernel log. The pixel data is processed by TCE to generate TFT voltage control pixels for panel. If an underrun occurs, unknown data is used and that can damage the panel. About the patch The patch raises EPDC reading to highest priority (QoS='f'), so the EPDC reading becomes real time channel in MMDC configuration. The patch is based on L4.1.15 kernel. Stress test of unit test can pass with 1920x1440 configuration.
View full article