[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342654 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345629 

Tel Aviv, December 2013   Variscite announces the support of Yocto over its iMX6 System-on-Modules   Variscite, a leading manufacturer of embedded solutions and System-on-Modules and Freescale’s Connected Partner, is pleased to announce the support of Yocto v4.1 Dora release over all Variscite’s iMX6 embedded products. Variscite develops, produces and manufactures a powerful range of System-on-Modules (SoM) and Single-Board-Computers (SBC), consistently setting market benchmarks in terms of speed and innovation. Today Variscite’s cost sensitive high performance portfolio serves over a thousand c ustomers in over 50 countries worldwide. The Yocto project was announced in 2010 to enable the creation of Linux distributions for embedded software that are independent of the underlying architecture of the embedded software itself. Variscite’s support of Yocto over its iMX6 solutions aligns with the company’s strategy to provide its customers with a complete set of leading embedded software and hardware solution, reducing development risk, cost and time-to-market. Variscite’s Yocto v4.1 Dora release supports iMX6 Solo, Dual Lite, Dual and Quad processors with a variety of speed grades, memory sizes and interfaces. More information can be found in: http://www.variwiki.com/index.php?title=Yocto_V4.1_Dora#Supported_hardware_and_features   About Variscite:   In less than a decade Variscite has taken a leading position in the System-on-Modules (SoM) design and manufacturing market. A trusted provider of development and consulting services for a variety of embedded platforms, Variscite transforms clients’ visions into successful products. Learn more about Variscite by visiting: www.variscite.com or contacting: Variscite Sales, [email protected] , +972-9-9562910

There are two ways to enable support for the imx95-19x19-evk board:   1.  Directly replace the flash.bin from the Yocto release. 1). depoly LSDK2512 on imx95-15x15-evk board which is supported in Debian LSDK2512     A:    $ flex-installer -i pf -d /dev/sdX -F     B： $ flex-installer -i auto -m imx95evk -d /dev/sdX   2). Download prebuild flash.bin for imx95-19x19-evk board from Yocto release:     A: download： https://www.nxp.com/webapp/sps/download/license.jsp? colCode=L6.12.20-2.0.0_MX95&appType=file1&DOWNLOAD_ID=null     B： Extract the downloaded file to obtain the flash.bin file: imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all   3). Overwrite flash.bin     $ sudo umount /dev/sdX; sudo dd if=imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all of=/dev/sdX bs=1024 seek=32   4). Insert the prepared SD card into the board and power it on. After entering the U-Boot prompt， set the boot command:     => setenv bootcmd "setenv bootargs 'root=/dev/mmcblk1p3 rw rootwait console=ttyLP0,115200 earlycon';ext2load mmc 1:1 0x90400000 Image;ext2load mmc 1:1 0x93000000 imx95-19x19-evk.dtb;booti 0x90400000 - 0x93000000"; saveenv     => reset   The Debian system will start automatically.   2. Build the BSP image using FlexBuild: 1).  clone the Flexbuild source code and apply the patch as attached. 2). build the bsp and boot images:       $ bld bsp -m imx95evk       $ bld boot -m imx95evk or download the pre-built image at: http://sun.ap.freescale.net/images/debian/lsdk2512/firmware_imx95evk_19x19_sdboot.img 3). install the image:       $ ./flex-installer -f firmware_imx95evk_sdboot.img -d /dev/sdX -m imx95evk -b boot_IMX_arm64_lts_6.12.20.tar.zst -r rootfs_lsdk2512_debian_imx95evk.tar.zst 4).  Insert the prepared SD card into the board and power it on. After entering the U-Boot prompt, run the following command to boot board:       u-boot=> bootflow scan -lb

This article describes how to speed-up the Linux boot time on i.MX 6ULZ to under 2s. Software: Linux BSP 6.12.20-2.0.0 Boot device: SD card The attached imx6ulz-fast-boot.tar.gz archive contains a series of patches which reduces the boot time of the i.MX 6ULZ to ~1.9s. What you'll find in the archive: U-Boot patches: Set the BOOTDELAY to 0 in U-Boot Increase the CPU frequency from 396MHz to 792MHz Add quiet to the kernel bootargs, to suppress the kernel's output during boot Kernel patches: Trim down the kernel to create a minimal version Use LZ4 compression type for the kernel image Minimal rootfs based on BusyBox How to? 1. Prepare the Yocto environment according to Section 3, 4, 5 in i.MX Yocto Project User's Guide. Version 6.12.20-2.0.0, for other versions, you may need to make adjustments. 2. Unzip the imx6ulz-fast-boot.tar.gz archive in the sources directory of your Yocto environment just created. cd ~/imx-yocto-bsp/sources tar -xvpzf imx6ulz-fast-boot.tar.gz -C . 3. Remove additional machine features. Add the configuration below in your conf/local.conf: MACHINE_FEATURES:remove = "\ optee \ alsa \ touchscreen screen \ wifi bluetooth \ bcm4339 bcm43455 \ nxp8987-sdio nxpwifi-all-sdio \ rtc qemu-usermode"  4. Build the image. bitbake core-image-busybox The resulted core-image-busybox-imx6ulz-14x14-evk.rootfs.wic should have ~38M. 5. Write the image on an SD card, and boot. It should boot under 2s from reset to prompt. If you are connected to the serial port of the board, press any key continuously to stop in U-Boot.

Background : Some customer wants to know the DRAM's MR register value. But, For now, we do not have any documentation or binary to complete this. So, this article aim to show how to read this register.   Hardware environment : i.MX8ULP EVK board Software environment : uboot-imx : lf_v2024.04   1. The related registers information are as following:   DENALI CTL 165 [READ MODEREG[24:8]] Read the specified memory mode register from specified chip when start bit set. Bits (7:0) define the memory mode register and bits (15:8) define the chip select. Set bit (16) to 1 to trigger.   DENALI CTL 166 [PERIPHERAL MRR - DATA[31:0]] Data and chip returned from memory mode register read requested by the READ MODEREG parameter. Bits (7:0) indicate the read data and bits (15:8) indicate the chip. READ-ONLY   2. Test result :         Type the below command: mrr <chip_select MR_register>  Like the below picture, when type the mrr 0 c, it means the chip select is 1 and the MR register is MR12, then the value of MR12 register can be output , is 0x1c.     Note : When read the MR register, must make sure the register has read right. Because most of MR register only have write right. you can check about it on JDEC spec document.   If you want to get the test binary file, please contact to me, i will send it to you.

This document explains how to enable and test Bluetooth 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) in the i.MX Linux BSP.   Environment   i.MX Linux BSP 6.6.52-2.2.0 (based on Yocto scrathgap) i.MX 93 EVK (2 units) An Embedded Artists 2EL M.2 module with the Murata LBES5PL2EL module (containing NXP IW612) is inserted into the i.MX 93 EVK's M.2 slot and connected to the onboard Wi-Fi/BT antenna. One i.MX 93 EVK will serve as the Peripheral device, while the other will act as the Central device. It should also work with i.MX 8 and 9 series evaluation kit equipped with Bluetooth LE modules.   Configurations   Although the Linux kernel includes a Bluetooth 6LoWPAN driver, it is disabled in the i.MX Linux BSP. Therefore, we will modify the kernel configuration to enable it. Add 2 settings below in kernel configuration file (imx_v8_defconfig) to build the required drivers as modules: CONFIG_6LOWPAN=m CONFIG_BT_6LOWPAN=m These settings can be found in the following section of the Linux kernel menuconfig. CONFIG_6LOWPAN: Depends on: NET [=y] && IPV6 [=y] Location: -> Networking support (NET [=y]) -> Networking options -> 6LoWPAN Support (6LOWPAN [=m]) CONFIG_6LOWPAN  CONFIG_BT_6LOWPAN: Depends on: NET [=y] && BT_LE [=y] && 6LOWPAN [=y] Location: -> Networking support (NET [=y]) -> Bluetooth subsystem support (BT [=y]) -> Bluetooth Low Energy (LE) features (BT_LE [=y]) -> Bluetooth 6LoWPAN support (BT_6LOWPAN [=m]) Rebuild the image containing the Linux kernel and make sure that the required drivers are present in the following paths. /lib/modules/6.6.52-ge0f9e2afd4cf-dirty/kernel/net/6lowpan/6lowpan.ko /lib/modules/6.6.52-ge0f9e2afd4cf-dirty/kernel/net/bluetooth/bluetooth_6lowpan.ko   Operations for Peripheral device   Boot the Peripheral device EVK and log in as the root user. NXP i.MX Release Distro 6.6-scarthgap imx93-11x11-lpddr4x-evk ttyLP0 imx93-11x11-lpddr4x-evk login: root Load the NXP Bluetooth UART driver to enable Bluetooth. # modprobe btnxpuart Start the Bluetooth hci0 interface with the hciconfig command. # hciconfig hci0 up Type hciconfig command to check the BD Address of the Bluetooth hci0 interface and confirm that its status is "UP RUNNING". # hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:12:34:56 ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNING RX bytes:862 acl:0 sco:0 events:59 errors:0 TX bytes:1085 acl:0 sco:0 commands:58 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx93-11x11-lpddr4x-evk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, HCI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) Load the Bluetooth 6LoWPAN driver. # modprobe bluetooth_6lowpan Enable Bluetooth 6LoWPAN. # echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable Start Bluetooth advertising and waits for a connection request from the Central device. # bluetoothctl advertise on   Operations for Central device   Boot the Central device EVK and log in as the root user. NXP i.MX Release Distro 6.6-scarthgap imx93-11x11-lpddr4x-evk ttyLP0 imx93-11x11-lpddr4x-evk login: root Load the NXP Bluetooth UART driver to enable Bluetooth. # modprobe btnxpuart Start the Bluetooth hci0 interface with the hciconfig command. # hciconfig hci0 up Type hciconfig command to check the BD Address of the Bluetooth hci0 interface and confirm that its status is "UP RUNNING". # hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:AB:CD:EF ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNING RX bytes:862 acl:0 sco:0 events:59 errors:0 TX bytes:1085 acl:0 sco:0 commands:58 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx93-11x11-lpddr4x-evk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, HCI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) Load the Bluetooth 6LoWPAN driver. # modprobe bluetooth_6lowpan Enable Bluetooth 6LoWPAN. # echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable Send a connection request to the Peripheral device. (In this example, the BD address of the Peripheral device is D0:17:69:12:34:56.) # echo "connect D0:17:69:12:34:56 1" > /sys/kernel/debug/bluetooth/6lowpan_control After waiting for a few tens of seconds, the bt0 network interface will appear. (At the same time, the bt0 network interface will appear on the Peripheral device that accepted the connection.) # ifconfig bt0 bt0: flags=4161<UP,RUNNING,MULTICAST> mtu 1280 inet6 fe80::d017:69ff:feab:cdef prefixlen 64 scopeid 0x20<link> unspec D0-17-69-AB-CD-EF-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 9 bytes 884 (884.0 B) RX errors 0 dropped 4 overruns 0 frame 0 TX packets 13 bytes 1069 (1.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 The Central device and Peripheral device are now connected via Bluetooth 6LoWPAN.   Testing Send a ping from the Central device to the Peripheral device. (In this example, the IPV6 address of the Peripheral device is fe80::d017:69ff:fe12:3456.) # ping6 fe80::d017:69ff:fe12:3456%bt0 PING fe80::d017:69ff:fe12:3456%bt0 (fe80::d017:69ff:fe12:3456%bt0) 56 data bytes 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=1 ttl=64 time=181 ms 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=2 ttl=64 time=125 ms 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=3 ttl=64 time=67.7 ms 64 bytes from fe80::d017:69ff:fe12:3456%bt0: icmp_seq=4 ttl=64 time=56.1 ms ...   Benchmarking   Run the iperf3 server on the Peripheral device. # iperf3 -s Run the iperf3 benchmark on the Central device. For example, check the TCP connections. # iperf3 -V -c fe80::d017:69ff:fe12:3456%bt0 You can also check UDP connections. For example, the following example sends UDP 200Kbps bandwidth. # iperf3 -V -c fe80::d017:69ff:fe12:3456%bt0 -u -b 200K   Disclaimer   This document is provided as a reference for utilizing NXP products. Please refer to the official product manuals and application notes for formal specifications. Due to differences in software versions and other conditions, actual behavior may differ from the descriptions provided. This document does not verify all functions, so please be sure to conduct appropriate validation and testing to ensure suitability for your intended use.  

  Background : Some customer want to test the LPDDR4/X ECC feature based on the i.MX93 chip, But, for now, Our DDR Config Tool do not release this test chosen. And our ECC guide only tell the ECC feature function, does not tell the customer how to test it. So in this article, Will show you more details about ECC feature and how to run the ECC test use uboot command. But I won't put the source code of the test here, You can download the binary run the test on the i.MX93 EVK board.   HW : i.MX93 EVK board with 2GB LPDDR4 SW : 6.1.1-1.0.0   ECC Introduce what is ECC?       ECC is the abbreviation of Error Correction Code. Its function is to automatically detect and repair some minor errors in the memory to prevent data errors. How does ECC work? We can think of it as an "automatic proofreader", and its workflow is roughly as follows:  When writing data: The memory controller generates a "check code" (similar to the fingerprint of the data) for each piece of data. This check code will be stored together with the data. When reading data: The memory controller will recalculate the "fingerprint". Then compare the previously stored check code to see if there is any difference. If a difference is found: If it is just a 1-bit error, ECC can automatically correct it. But, If there are multiple errors, ECC can at least detect them and issue a warning.   ECC test step: 1. Flash the attachment file to the imx93 board. 2. Enter the uboot, run the "ecc --help" command, you will see the below help output message   3. For example : ecc 0x80000000 0x90000000, it will test the ecc feature with on bit error detect and correct , 2 bits errors detect with 256MB DRM size.   if you need this ECC_ test binary file, please contact me, i will share it to you        

This guide provides a clear overview of how different versions of GUI Guider integrate with LVGL and the supported rendering backends: DRM and Wayland. It also explains how to configure and run your application based on the selected backend. Switching between backends is straightforward—simply modify a few lines in the lv_conf.h file, located in the lvgl folder of the code generated by GUI Guider.   Default Rendering Backends by GUI Guider Version GUI Guider Version LVGL v8 LVGL v9 1.9.1 DRM WAYLAND 1.9.0 WAYLAND WAYLAND   Note: Only one configuration (DRM or Wayland) can be used at a time. Configuration Settings in lv_conf.h To use DRM, set the following: #define LV_USE_WAYLAND 0 #define LV_USE_LINUX_DRM 1   To use Wayland, set: #define LV_USE_WAYLAND 1 #define LV_USE_LINUX_DRM 0   Running LVGL with DRM Before launching the gui_guider binary in DRM mode, you must stop the Weston service: systemctl stop weston ./gui_guider Note: These steps must be executed via the debug console or over SSH, as stopping Weston will disable the desktop environment and make the local display unavailable Running LVGL with Wayland No special steps are required. Simply run the binary: ./gui_guider   You can refer to the following guides to learn how to compile GUI Guider binaries according to the version you are using: Build GUI Guider projects for iMX93 (GUI GUIDER 1.9.X)  Build GUI Guider projects for iMX93 (GUI GUIDER 1.6.x, 1.7.x, 1.8x)   

Questions: 1.  Are there any hardware limitations (such as in the Host Controller IP block itself, how this IP block was implemented or in the DMA engine) to how many device endpoints the i.MX53 can handle on Host2 or Host3?  The Reference Manual notes that the OTG controller supports up to 8 endpoints but does not provide information on the Host Controller. 2.  Do any of the device validation tests for verifying the i.MX53 design (or USB cert tests) test compatibility/performance with multiple devices and multiple endpoints? 3.  What are the maximum number of endpoints Freescale has tested with? Problem Background: During extensive testing the customer observes 100% CPU utilization with only 6 endpoints (can be a combination of multi-endpoint devices or single-endpoint devices - see below for test configuration details) using our latest Linux reference BSP (2.6.35 Kernel).  They have tested with the Adeneo WEC7 BSP and the open source Linux kernel based on 3.11 for the QSB and have observed similar performance limitations. This has been tested with multiple packet sizes and device/endpoint configurations and no impact has been shown in varying these parameters. The customer did note that they are only receiving/processing a single interrupt at the 1ms boundary regardless of the number of devices/endpoints.  Processing this interrupt takes approximately 23us for one device and an additional 17us for each additional device endpoint after the first that is processed. The customer hardware configuration for their testing looks something like this: On the customer's board: [i.MX53 Host2/Host3] -> [SMSC 3315 USB High Speed ULPI PHY] -> [SMSC LAN9514 On-board 4-port USB 2.0 HS Hub] External: [SMSC LAN9514 Port #1] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #1-4 [SMSC LAN9514 Port #2] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #5-8 [SMSC LAN9514 Port #3] ->  Medical device w/ endpoint #9 [SMSC LAN9514 Port #4] ->  Medical device w/ endpoint #10 Answer: Hosts do not have endpoints. Only devices have endpoints. EHCI compliance hosts, like all i.MX devices, use a linked list of queues (for bulk/control transport). Each queue has a queuehead that represents a corresponding endpoint and has the endpoint's capabilities. On the queue are transfer descriptors that have the information of which data is to be moved to/from the endpoint of the device. All of this is in main memory and read/written under DMA.  There is no limit on how many devices/endpoints a host can service, other than the amount of available main memory (DRAM). The CPU has to build the linked lists, but this is  normally not taking much bandwidth. My guess at this time is that there may be a problem in the USB driver, or the application that is using the driver, or a problem with data alignment. For efficient operation, data must be aligned on 32-bit boundaries. Buffers are best aligned on 64-byte boundaries.

Hi, this is a smart server called Duckbill in a thumb-drive format based on the i.MX283. It's a really low cost solution usable with or without casing. It is intended to be set up as a small home-server for automation purposes. It comes with Debian Linux as operation system but without any specific user programs.  The stick can be operated either at a USB power adaptor or at a USB port of your router.  Since Duckbill runs Linux you are totally free in software development. The internal connectors can be used as UART, SPI, I2C, ADC or GPIO. So it's up to everyone to develop his own expansion board. 1. Duckbill without casing (top) 2. Duckbill without casing (bottom) 3. Duckbill with casing 4. Duckbill for development purposes 5. Duckbill with integrated EnOcean module If you want to know more about this product: http://www.i2se.com/homeautomation.html

[中文翻译版] 见附件   原文链接： eIQ Machine Learning Software for i.MX Linux 4.14.y 

Question: To eliminate the need for pull-ups AND  pull-downs on the gpio boot override pins to save board space, does anyone know when in the boot rom that the GPIO pins are sampled and whether the internal Pull Downs are already enabled? Is this true for all the GPIO override pins? To just be able to provide an external Pull-up to specify boot options and NOT both pull-up and pull-down option. Can this be done? Answer: The pull-ups and pull-downs are active while POR_B is low (as defined in the datasheet). The pins are sampled on the 2 nd rising edge of RTC_XTALO before the rising edge of POR_B. As a caution, on-chip pull-up/downs are very weak and are primarily intended for controlling the pin (keeping it from logically wiggling) if the pin is not connected at all. If a pin is connected out to a trace, relaying on the on-chip PU/PD alone could be a little risky. Since the PU/PD is weak, it's possible to have noise coupled onto the pin. [Similar to Brett's comment above].

Random Number Generator - RNGA Download rng-tools: http://downloads.sourceforge.net/sourceforge/gkernel/rng-tools-2.tar.gz This tool tests the link between a random number generator hardware and the kernel's PRNG (pseudo-random number generator). ./ltib -m shell LTIB> cd rpm/BUILD/ LTIB> cp ~/hwrandom/rng-tools-2.tar.gz . LTIB> tar zxvf rng-tools-2.tar.gz LTIB> cd rng-tools-2 LTIB> ./configure --host=arm-linux LTIB> make LTIB> sudo cp rngtest /tftpboot/ltib/home/ Restart your board and execute this command in the board's console: $ cat /dev/hwrng | /home/rngtest -c 1000

I have imx53 quick sort board i downloaded u-boot-mx53.bin and uImage to loade that into the board and dowloaded rootfs.ext2.gz in the L2.6.35_11.09.01_ERimages and i did partitions on 1GB memory card and loaded that u-boot-mx53.bin,uImage images on to the 500mb of NTFS filesystem and loaded and rootfs.ext2.gz on to the othe 500mb of ext4 file system the i inserted memorycard in to the board but u-boot logs are not comming what will be the solution

The i.MX21ADS board needs a flash programmer software called iMX21ADS_TOOLKIT or just HAB. This programmer evolved to current ATK. You can download iMX21ADS_TOOLKIT here.  

When I use QMediaPlayer (Qt5.1.1) to play a FHD video, the CPU (imx6dl) usage turns very high and the output is not fluid and also has some frame drop. I found a patch that claims to solve this problem (links below are taking about the same thing) : adding zero-copy-QSGVideoNode for imx6 - Qt by Digia https://www.mail-archive.com/[email protected]/msg08580.html After patch appliance and recompilation of Qt Library and program rebuild, the performance issue remains the same. Does anybody know how to enable this property correctly? Have I missed some points or mandatory steps? Any comment will be appreciated, thanks!

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343715 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343777 

MX6X_eMMC_turning_2014.11.11_V2.doc