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:
What is a device tree? The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command line, etc. Sometimes, the device tree is confused with the Linux Kernel configuration, but the device tree specifies what devices are available and how they are accessed, not whether the hardware is used. The device tree is a structure composed of nodes and properties: Nodes: The node name is a label used to identify the node. Properties: A node may contain multiple properties arranged with a name and a value. Phandle: Property in one node that contains a pointer to another node. Aliases: The aliases node is an index of other nodes. A device tree is defined in a human-readable device tree syntax text file such as .dts or .dtsi. The machine has one or several .dts files that correspond to different hardware configurations. With these .dts files we can compile them into a device tree binary (.dtb) blobs that can either be attached to the kernel binary (for legacy compatibility) or, as is more commonly done, passed to the kernel by a bootloader like U-Boot. What is Devshell? The Devshell is a terminal shell that runs in the same context as the BitBake task engine. It is possible to run Devshell directly or it may spawn automatically. The advantage of this tool is that is automatically included when you configure and build a platform project so, you can start using it by installing the packages and following the setup of i.MX Yocto Project User's Guide on section 3 “Host Setup”. Steps: Now, let’s see how to compile your device tree files of i.MX devices using Devshell. On host machine. Modify or make your device tree on the next path: - 64 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm64/boot/dts/freescale - 32 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm/boot/dts To compile, it is needed to prepare the environment as is mentioned on i.MX Yocto Project User's Guide on section 5.1 “Build Configurations”. $ cd ~/imx-yocto-bsp $ DISTRO=fsl-imx-xwayland MACHINE=<machine> source imx-setup-release.sh -b <build directory> $ bitbake -c devshell virtual/kernel (it will open a new window) On Devshell window. $ make dtbs (after finished, close the Devshell window) On host machine. $ bitbake -c compile -f virtual/kernel $ bitbake -c deploy -f virtual/kernel This process will compile all the device tree files linked to the machine declared on setup environment and your device tree files will be deployed on the next path: ~/imx-yocto-bsp/<build directory>/tmp/deploy/images/<machine> I hope this article will be helpful. Best regards. Jorge.
View full article
  Anyone who want to use this solution should get reference design and firmware from Lontium. Hardware Here is the block diagram of LT9611UXC Demo Board. As the MIPI port of our EVK can provide 5V, 3V3 and 1V8.We can remove useless DC-DC chips from reference design. Below is the LT9611UXC Demo Board. Software Download the firmware into LT9611UXC. In Linux side, we need to drive the MIPI to output signals with standard timings of 1080P. Panel type diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts index 1732b5c72380..c6a829be541f 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts @@ -696,13 +716,17 @@ &ldb_phy { &mipi_dsi { status = "okay"; + panel@0{ + compatible = "nxp,lt9611uxc"; + reg = <0>; + status = "okay"; }; }; &snvs_pwrkey { diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 4f78bbf63f33..90d99f12515b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -4997,6 +4997,34 @@ struct panel_desc_dsi { unsigned int lanes; }; +static const struct drm_display_mode lt9611_panel_mode = { + .clock = 148500, + .hdisplay = 1920, + .hsync_start = 1920 + 88, + .hsync_end = 1920 + 88 + 44, + .htotal = 1920 + 88 + 44 + 148, + .vdisplay = 1080, + .vsync_start = 1080 + 4, + .vsync_end = 1080 + 4 + 5, + .vtotal = 1080 + 4 + 5 + 36, +}; + +static const struct panel_desc_dsi lt9611_panel = { + .desc = { + .modes = &lt9611_panel_mode, + .num_modes = 1, + .bpc = 8, + .size = { + .width = 62, + .height = 110, + }, + .connector_type = DRM_MODE_CONNECTOR_DSI, + }, + .flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_NO_EOT_PACKET | MIPI_DSI_MODE_VIDEO_SYNC_PULSE, + .format = MIPI_DSI_FMT_RGB888, + .lanes = 4, +}; + static const struct drm_display_mode auo_b080uan01_mode = { .clock = 154500, .hdisplay = 1200, @@ -5201,6 +5229,9 @@ static const struct panel_desc_dsi osd101t2045_53ts = { static const struct of_device_id dsi_of_match[] = { { + .compatible = "nxp,lt9611uxc", + .data = &lt9611_panel, + },{ .compatible = "auo,b080uan01", .data = &auo_b080uan01 }, {
View full article
This documents describes how to add the NFC support to i.MX8M mini evk running Yocto. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on i.MX Linux 4.14.78_1.0.0 BSP software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_LINUX_DOCS. Just flash the demo image (downloaded from here: https://www.nxp.com/lgfiles/updates/NFC/LINUX_L4-14-78_IMAGE_MX8MMEVK.zip) following guidelines from i.MX_Linux_User's_Guide document (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above). Then in a terminal you can run the demo application included in the image executing the command:    # nfcDemoApp poll Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger such display: Adding PN7150 support to imx-linux-sumo release: Pre-condition is to have L4.14.78_1.0.0 release installed and already built as described in i.MX Yocto Project User's Guide (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above) :     $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest  -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml     $ repo sync     $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source fsl-setup-release.sh -b build_dir     $ bitbake fsl-image-validation-imx Then to add PN7150 support to your imx-linux-sumo environment, follow below step by step guidelines: In the sources directory, download the meta-nxp-nfc layer from https://github.com/NXPNFCLinux/meta-nxp-nfc     $ git clone https://github.com/NXPNFCLinux/meta-nxp-nfc.git  Define hardware connection between CPU and PN7150 in device-tree adding the following lines to file build_dir/tmp/work-shared/imx8mmevk/kernel-source/arch/arm64/boot/dts/freescale/fsl-imx8mm-evk.dts: @@ -227,6 +227,8 @@                         fsl,pins = <                                 MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL                  0x400001c3                                 MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA                  0x400001c3 +                               MX8MM_IOMUXC_ECSPI2_MOSI_GPIO5_IO11             0x41 +                               MX8MM_IOMUXC_ECSPI2_MISO_GPIO5_IO12             0x41                         >;                 };   @@ -747,6 +749,13 @@         pinctrl-0 = <&pinctrl_i2c3>;         status = "okay";   +       pn54x: pn54x@28 { +               compatible ="nxp,pn547"; +               reg = <0x28>; +               interrupt-gpios = <&gpio5 11 0>; +               enable-gpios = <&gpio5 12 0>; +       }; +         pca6416: gpio@20 {                 compatible = "ti,tca6416";                 reg = <0x20>; Add the meta-nxp-nfc layer to the build definition updating file build_dir/conf/bblayers.conf with: BBLAYERS += " ${BSPDIR}/sources/meta-nxp-nfc" Add the meta-nxp-nfc layer components to the image definition updating file build_dir/conf/local.conf with: IMAGE_INSTALL_append = " kernel-module-nxp-pn5xx nxp-nfc-bin " Re-build the linux kernel:     $ bitbake -f -c compile linux-imx && bitbake -f -c deploy linux-imx Build meta-nxp-nfc layer:     $ bitbake nxp-nfc Re-build the complete image to include the modifications:     $ bitbake fsl-image-validation-imx Then you can flash the updated image to your i.MX8M mini evk and run the demo application as described in above "Quick start using demo image" chapter. Reference: This porting have been done (demo image and instructions) following guidelines provided in AN11679_PN71xx_Linux_Software_Stack_Integration_Guidelines document.
View full article
Tips collected from zhaoyang-b49593 and dandouglass-b41520 while enabling redundant boot: Using i.MX 8MQ, same method can be applied for other i.MX devices that support redundant boot, see SoC Reference Manual. As described on the RM, if primary image authentication fails the ROM can reset and try booting a secondary image. This feature is only available on closed mode with properly signed binaries, otherwise the ROM boots the primary image despite the auth failure. For the i.MX 8MQ, the secondary image must start with spl, not HDMI firmware. Note, there is no ROM redundancy for the hdmi fw, if it is corrupt user can store a 2nd copy on a different memory address and update at run time. Steps to generate a dual spl image: 1. Build and Sign bootable binary (spl, u-boot, atf, fw, etc) Use the Yocto BSP or follow this post to build outside the Yocto environment. To sign the binary, follow the documentation on u-boot source: <u-boot>/doc/imx/habv4/guides/mx8m_secure_boot.txt Program image to the SD card: dd if=signed_flash.bin of=<sd path> bs=1024 seek=33 After boot you can use "hab_status" to verify that no events were generated: u-boot=> hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 2. Corrupt spl on your boot image You can corrupt anywhere on the spl signed area. For easier visualization at boot time we can corrupt the SPL banner. First create a copy: cp signed_flash.bin signed_flash_corrupt.bin Find the banner: hexdump -C signed_flash.bin | grep 2019 00020190 26 1c 40 92 04 00 80 d2 05 01 80 52 c4 20 04 aa |&.@........R. ..| 0002eac0 32 30 31 39 2e 30 34 2d 30 30 30 32 39 2d 67 34 |2019.04-00029-g4| 000dde10 3a 20 20 00 55 2d 42 6f 6f 74 20 32 30 31 39 2e |: .U-Boot 2019.| 0002eac3 is on spl area, where "9" for 2019 is, replace by "X" printf "X" > X dd if=X of=signed_flash_corrupt.bin seek=$((0x2eac3)) bs=1 conv=notrunc Verify corrupt binary hexdump -C -s 0x2eac0 -n 64 signed_flash_corrupt.bin 0002eac0 32 30 31 58 2e 30 34 2d 30 30 30 32 39 2d 67 34 |201X.04-00029-g4| 0002ead0 37 63 31 39 32 32 20 28 41 70 72 20 32 37 20 32 |7c1922 (Apr 27 2| Transfer image to SD Card dd if=signed_flash_corrupt.bin of=<sd path> bs=1024 seek=33 Now, you should see hab events after running "hab_status" on u-boot 3. Create a secondary boot image This can be the same content as your primary image without the HDMI fw or it can be a different spl image. For easier visualization, we can change the SPL banner, on the code this time. Modify banner at ./common/spl/spl.c as: - puts("\nU-Boot " SPL_TPL_NAME " " PLAIN_VERSION " (" U_BOOT_DATE " - " + puts("\nSecondary U-Boot " SPL_TPL_NAME " " PLAIN_VERSION " (" U_BOOT_DATE " - " As mentioned above, we want our boot image without the HDMI fw, when running imx-mkimage use the flash_evk_no_hdmi target: make SOC=iMX8MQ flash_evk_no_hdmi Sign the image as in step 1. If you program the new image to the SD you should see the new banner. Make sure to run hab_status to confirm that no HAB events are generated. 4. Program SRK Hash and Close SoC Follow the documentation on u-boot source for SRK programming and closing the device: <u-boot>/doc/imx/habv4/guides/mx8m_secure_boot.txt Before closing the SoC, but after the SRK is programmed, try your images to confirm no HAB events are generated. Be careful with this step, errors could brick your board. This step is irreversible. After closing the SoC it will only boot signed images. 5. Create dual bootloader image We can concatenate our binaries to create a single file, let's use 2MB distance between primary and secondary images: For the working primary image: objcopy -I binary -O binary --pad-to 0x200000 --gap-fill=0x00 signed_flash.bin 1st-spl_pad.bin cat 1st-spl_pad.bin secondary2_nohdmifw_signed_flash.bin > 1st-spl_pad_2nd-spl.bin Or for the corrupt primary image experiment: objcopy -I binary -O binary --pad-to 0x200000 --gap-fill=0x00 signed_flash_corrupt.bin 1st-spl_pad.bin cat 1st-spl_pad.bin secondary2_nohdmifw_signed_flash.bin > 1st-spl_pad_2nd-spl.bin Program it to the SD card on 0x8400 offset (33k) dd if=1st-spl_pad_2nd-spl.bin of=<sd path> bs=1024 seek=33 && sync 6. Add Secondary image table Follow the format on the RM, this is only 20 bytes long. For a 2MB distance between the table and the secondary image we can use "0x1000" on the firstSectorNumber field. 2MB/512 = 4096 (0x1000) The perl script attached, genSecTable.pl, can be used to generate it. perl genSecTable.pl 0x1000 Program it to the SD card on 0x8200 offset dd if=secTable.bin of=<sd path> bs=1 seek=$((0x8200)) && sync 7. Verify secondary image is booting If using the corrupt primary image, you should see the spl with the "Secondary U-Boot SPL..." banner. You can also read the persist secondary boot bit. u-boot=> md.l 0x30390098 1 30390098: 40000000 ...@ The work can be extended patching spl for in case of u-boot authentication failure, spl can try to authenticate and jump to the secondary u-boot.
View full article
  Introduction   Prior to 6.1.22_2.0.0 BSP release, Bluetooth interface are based on the tty line discipline framework, so we need to use hciattach tool to enable it in the user space. From 6.1.22_2.0.0 BSP, the nxp bluetooth driver no longer needs the help of the userspace hciattach tool, and the tty port bound by bluetooth also won't be exported to the user space, so you cannot find the corresponding tty device anymore. So, you won't see the (/dev/ttymxcX), for the Bluetooth interface. All jobs has been done in the new NXP Bluetooth driver. New Method   The new NXP Bluetooth UART Driver is based on a server driver for the NXP BT serial protocol, which can enable the built-in Bluetooth device inside an NXP BT chip. This driver has a Power Save feature that will put the chip into a sleep state whenever there is no activity for 2000ms and will be woken up when any activity is to be initiated over UART.  Device Tree support The new BT framework requires adding a "bluetooth" sub node with a device compatibility string to the attached UART node in the dts file &uart1 { bluetooth { compatibility = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; #Optional. Default is considered 115200 if this parameter not defined. }; };   Note: The parameter ‘compatibility = “nxp,88w8987-bt”’ will use for 88W8987, IW416, 88Q9098, IW612 chipsets and need to change for 88W8997 with parameter ‘compatibility = “nxp,88w8997-bt”’.   Note: ’fw-init-baudrate’ parameter depends on the module vendor. The Murata and Azuere wifi modules support in BSP release uses the default value -- 115200. We strongly recommend looking at the module vendor-specific baud rate parameter. Note: For the old 88Q9098 Murata 1XL module that uses the 3Mbps by default, please add the fw-init-baudrate = <3000000> property in dts files to make it work. Enable Guide   Use wifi interface to load combo (wifi & bt) firmware and enable BT Need to load wifi driver first, then load the BT driver, otherwise, BT driver suspend/resume test will fail. This is a HW limitation, since NXP wifi and BT module use the same power control pin(W_DISABLE1#), if we don't load the wifi driver, SDIO bus will power down the wifi chip during suspend resume, which may cause the BT chip also been powered down and cannot work after resume back. So we need to load the wifi driver to make sure SDIO bus won't power down the BT chip to make sure BT functions can work during suspend resume. modprobe moal mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart or insmod mlan.ko insmod moal.ko mod_para=nxp/wifi_mod_para.conf insmod btnxpuart   Unload UART Driver modprobe moal Make sure run hciconfig hci0 up or hciconfig hci0 reset or bluetootctl power on before unload btnxpuart driver. If we don't open hci0 interface, the driver cannot send change to 115200 baud rate command to BT chip, which causes the host and BT chip baud rate mismatch, the host still uses 115200bps talk to the BT chip which now use 3Mbps, it cannot work anymore. So we need to make sure open the hci0 interface before unload btnxpuart driver.   mod_para=nxp/wifi_mod_para.conf modprobe btnxpuart sleep 3 hciconfig hci0 up #Note: Need to up hci interface before unload the BT module hcitool -i hci0 cmd 3F 23 02 00 00 modprobe -r btnxpuart modprobe -r moal sleep 3​ For better reference: Please find the I.MX 8MQ Linux getting started user guide, UM11483, Chapter "7.1 Bring-up using NXP Bluetooth UART driver"  Bluetooth Deep Sleep Feature App Note AN13920, Chapter 6 Load NXP UART driver module NOTE: Please do not run the power save feature for Murata IW612 2EL Module Regards, Mario
View full article
Hello everyone, In this document I'll explain on how to build the UUU (Universal Update Utility) using windows 10 PC. This may be useful in case of adding custom commands to run during the flash using built-in scripts, be it for debugging, fuse blowing, etc. First we need to download and install Visual Studio community, for this guide I'll use community 2019, version it is available here: https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=16 For workloads select Universal Windows Platform development.   When installing, make sure to select and install the Git for windows complement, at the top select Individual components, this will display a new list, scroll down to code tools and you will find Git for windows, check this box In case Visual Studio is already installed, you may open the installer again and chose modify, this will let you install the complement as well. After the installation is complete we may run the git commands on the power shell. Now open the windows power shell and type the following commands: git clone https://github.com/NXPmicro/mfgtools.git // clones the MFGTool (UUU) source code from the github cd mfgtools // enters the mfgtools folder we just cloned git submodule init // creates the local configuration file for the submodules git submodule update // set the submodules to the commit specified by the main repository. At this point we can edit the built in scripts to add our custom commands, for this guide I'll add the printenv uboot command at the end of the flashing process. For this I'll enter the folder mfgtools/uuu, and edit emmc_burn_all.lst with any text editor, i.e. Notepad ++, add the command FB: ucmd printenv.   Save and close the editor, it is possible to add most uboot commands like for example the fuse commands to burn eFuses. Then we can now build the tool, opening msvc/uuu-static-link.sln with Visual studio, select solution uuu-static-link.sln   And finally build the solution: The executable (uuu.exe) would be at the following path: mfgtools\msvc\x64\Debug   Finally we run the built in script we modified and check the results. Find attached both the powershell and uboot logs, I tested this using an i.MX8MN with L5.4.47_2.2.0, running the following command: ./uuu.exe -v -b emmc_all imx-boot-imx8mnevk-sd.bin-flash_evk imx-image-full-imx8mnevk.wic Hope this may found useful for anyone trying to achieve something similar.
View full article
Basic Linear Algebra Subprograms (BLAS) is a specification that prescribes a set of low-level routines for performing common linear algebra operations such as vector addition, scalar multiplication, dot products, linear combinations, and matrix multiplication. OpenBLAS is an optimized BLAS library which is uesd for deep learning accelerator in Caffe/Caffe2. I enable it in Yocto (Rocko) by adding bb file. And I build on i.MX6QP, i.MX7ULP and i.MX8MQ and also run its test example successfully. You can find test example(openblas_utest) under folder image/opt/openblas/bin of OpenBLAS work directory. Currently, version 0.3.0 is supported in the bb file. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ update to v 0.3.6 and enable mutli-thread by set USE_OPENMP=1 and USE_THREAD=4 when compiling this library.
View full article
Purpose This is early communication to notify i.MX 8M Dual/8M QuadLite/8M Quad customers of a potential incorrect PCIe power supply configuration on certain NXP BSP Linux and Android versions. Description The PCIE_VPH power supply is selectable in software  between 1.8V and 3.3V. When the PCIE_VPH supply is configured to operate at 3.3V, the 1.8V internal regulator (disabled by default) must be enabled to prevent overstress conditions on the PCIe PHY. If the 1.8V internal regulator is left disabled when the PCIE_VPH supply is configured to operate at 3.3V, it could potentially impact the product lifetime of the device.   Impact •i.MX 8M Dual/8M QuadLite/8M Quad (other i.MX processors are not impacted) •Only Impacts Linux/Android kernel versions earlier than L5.4.70_2.3.2 or Linux 5.10.9_1.0.0 releases MITIGATION •When the PCIE_VPH supply is configured to operate at 3.3V users need to enable the internal regulator by setting the IOMUXC_GPR_GPR14 and IOMUXC_GPR_GPR16 registers - PCIE1_VREG_BYPASS and PCIE2_VREG_BYPASS bit to 0. •There are 3 software patches for each release. Software patch details in the Code Aurora Forum (CAF): •For L5.4.70_2.3.2 patch release, the git log references are: •MLK-25349-3 PCI: imx: clear vreg bypass when pcie vph voltage is 3v3 •MLK-25349-2 arm64: dts: imx8mq-evk: add one regulator used to power up pcie phy •MLK-25349-1 dt-bindings: imx6q-pcie: add one regulator used to power up pcie phy • •The L5.4.70_2.3.2, LF_5.10 Q2 and later BSP releases correctly configure and enable the internal regulator by setting the IOMUXC_GPR_GPR14 and IOMUXC_GPR_GPR16 registers The Patch MLK-25349 which correctly enables the internal regulator is already included in the L5.4.70_2.3.2 patch release and release versions after it. MITIGATION •The following branches of Linux/Android BSP releases contain the MLK-25349 patch. The patch is attached below for each respective release.   •Other branches which are not listed should try to apply the nearest Patch version patch. If a user encounters any conflicts in applying, they should back porting from below nearest patch release version below. imx_4.9.51_ga, imx_4.9.y_android_imx8m_ga_v2                           - Patch attached  imx_4.9.88_ga, imx_4.9.y_android_2.0.0_ga                                   - Patch attached  imx_4.14.y and imx_4.14.98_2.3.0, imx_4.14.98_2.3.0_android     - Patch attached  imx_4.19.y and imx_4.19.35_1.1.0, imx_4.19.35_1.1.0_android     - Patch attached  imx_5.4.y, imx_5.4.3_2.0.0, imx_5.4.3_2.0.0_android                     - Patch attached Documentation Change Description – 1 of 3 for Datasheet Updated Datasheets and Reference Manual will be published to nxp.com. Updated Hardware Design guide and Schematics have already been published on nxp.com.  Updated the descriptions of PCIE_VPH in the Datasheet Table 8, "Operating ranges"     Documentation Change Description – 2 of 3 for Reference Manual (RM) Updated the description of field 12 "PCIE1_VREG_BYPASS" in 8.2.4.15 GPR14 General Purpose Register (IOMUXC_GPR_GPR14)           Documentation Change Description – 3 of 3 for RM Updated the description of field 12 "PCIE2_VREG_BYPASS" in 8.2.4.17 GPR16 General Purpose Register (IOMUXC_GPR_GPR16)   REFERENCES •i.MX 8M Dual / 8M QuadLite / 8M Quad Product Lifetime Usage  •i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Industrial Products •i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Consumer Products •i.MX 8MDQLQ Hardware Developer’s Guide  •i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual  
View full article
Before reading: only a personal works and sharing, not any form of "release". I didn't find any confidential information from the packages. So, I'm publishing it here. This is only for testing purpose. Do NOT use it for building a product. Use it at your own risk!! Yocto is flexible and powerful, and also, big and slow (when building). Sometimes we only need to build uboot or kernel or some piece of testing code. It's really a waste of time to build-up the whole Yocto environment which may cost over 50GB disk space and over 3 hours of building. I've made some scripts and sum them up to form a toolset for building uboot, kernel and some testing code out of Yocto environment. It's only a simple container and expect to use with uboot and kernel source code from formal Freescale release and a SDK built from Yocto project. GitHub source repo:       https://github.com/gopise/gopbuild What’s made off (a full package, not only the container): 1.    Some scripts and configurations files. 2.    SDK built from Yocto. 3.    Uboot/kernel from specific version. 4.    A hello-world to demonstrate how to build app in this environment. 5.    A slimmed rootfs binary from specific BSP pre-built as base. Will customize base on the source under “rootfs” folder. Only a placeholder in the container-only version. How to use it: Several common used board configurations have been included in the script: 6qsabresd/6qsabreai/6qpsabreai. You can add more into the “gopbuild” script easily. The “sabresd” has been set as default.      If you want to build all for sabresd (First of all, de-compress the package): cd <de-compressed-folder> source envsetup [It will prompt for selecting board configuration to be built. Choose one by input corresponding number or click <ENTER> for default board.] gmk ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍      If you want to build specific module for default board, such as uboot: gmk uboot ‍‍‍‍‍‍‍‍‍      Build kernel for sabreai board instead of default device: gmk kernel sabreai ‍‍‍‍‍‍‍‍‍      Clean everything? gmk all clean ‍‍‍‍‍‍‍‍‍ After a successfully full build, you will get everything under “output” folder, including a log folder contains full build log:      “u-boot.imx/zImage/rootfs.tar.bz2/*.dtb”, can be used with MFG or uuu.      “fsl-image.sdcard”, can be burn into SD card directly. "Ready-for-building" Package: The "gopbuild" itself is a "container-only" package which doesn't contain any source or SDK. I've also made some packages based on latest BSP release for i.MX6/i.MX7/i.MX8. These packages are "ready-for-build" package which you can de-compress and build it directly. -------------------------------------------------------------------------------------------------- URL:https://pan.baidu.com/s/1Xlh1OBGsTRXez_NQw-Rjxg Password: gdc9 -------------------------------------------------------------------------------------------------- Note: 1. To build for i.MX8 (8QM/8MQ/8QXP), you need L4.14.* or above. 2. To build for i.MX8, please download the SCFW from i.MX software page       i.MX Software and Development Tools | NXP      After download, decompress corresponding package for specific chip and put it under "/platform/scfw/". Take i.MX8QXP for example:             /platform/scfw/scfw_export_mx8qx/ All material (uboot/kernel/test code and SDK) are from official Yocto release. Thanks!
View full article
On behalf of Gopise Yuan. This is an update for the DRM framebuffer capture tool I used to share with the team. Some enhancement added. Might be useful for debugging some display related issues.   Some special notes: Behavior of DRM subsystem is different between L4.x and L5.x. For L4.x, you can capture the RGB buffer without any problem. But, there’s no API for YUV (multi-plane) buffer. To capture YUV, need to apply “kernel_0001-drm-Add-getfb2-ioctl_L4.14.98.patch”. For L5.x, mapping/capturing the internal buffer is not allowed by default due to security reason. A simple change in “0001-drm-enable-mapping-of-internal-object-for-debugging_L5.x.patch” can disable this guard. Capture raw data only. RGB and YUV (packed/planar, 420/422) supported. Support de-tile on “Amphion tile” (VPU, NV12 only) and “Super tile” (Vivante GPU). Please use “-t” to enable this. Other tile might not be supported. This is a static linked binary. You can run it on any ARM64 based Linux/Android system in theory (prerequisites in item #1). If you need source code, come to me.   To get more details on how to use it, use “-?” option: DRM screen capture DRM based screen capture program Usage:     ./drmfbcap [OP] [ARG] [OP] OPeration (optional):     -v Show version.     -? Show help information.     -i Show information about target DRM device only (no capture).     -t Perform de-tile for tile format.     -d DRM device to open. [ARG] should contain the path to the device node. Default: '/dev/dri/card0'     -o Output folder. [ARG] should contain the path to the output folder. Default: '.'     -p Specific plane # to capture. [ARG] should contain the plane number. If no '-p' specified, capture all planes   Example:     ./drmfbcap   Capture all planes on default DRM device.     ./drmfbcap -d /dev/dri/controlD64   Capture all planes on '/dev/dri/controlD64' device.     ./drmfbcap -p 44 -t -o /sdcard   Capture plane 44, do de-tile after capture and then output to /sdcard/.   Raw buffer capture will be done for each enabled/target plane and one file for each. Captured file will be saved to './' if not specified. --- By Gopise, 2022/08   Updated_2023_10_16: continuous capture (repeat mode) support with this link: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/DRM-screen-capture-tool/ta-p/1725363
View full article
目录 1 i.MX8Mmini 板级开发包镜像结构 ............................... 2 2 创建 i.MX8Mmini Linux 4.14.78_ga 板级开发包编译环境 3 2.1 下载板级开发包 ...................................................... 3 2.2 创建yocto编译环境: ................................................ 4 2.3 编译sdk及安装 ........................................................ 7 2.4 独立编译 ................................................................. 8 3 DDR配置,测试与输出 ............................................ 13 4 i.MX8Mmini ATF ...................................................... 15 5 FSL Uboot SPL 定制 ............................................... 17 5.1 SPL的编译............................................................ 17 5.2 SPL的启动流程 .................................................... 26 5.3 SPL的定制............................................................ 33 6 FSL Uboot 定制 ....................................................... 39 6.1 FDT支持 ............................................................... 40 6.2 DM(driver model)支持 .......................................... 45 6.3 Uboot目录 结构 .................................................... 59 6.4 Uboot编译 ............................................................ 61 6.5 Uboot初始化流程 .................................................. 62 6.6 uboot 定制 ............................................................ 72 6.7 uboot debug信息 .................................................. 78
View full article
All below changes are done based on imx_android-10.0_5.4.y. mek_8qm enable uSD 8987 wifi            1. hardware rework                no hardware rework required            2. patches The patch is attached as 0001-8qm-usd-8987-wifi.patch mek_8qm enable M.2 8987 wifi            1. hardware rework                no hardware rework required            2. patches The patch is attached as 0001-8qm-m2-8987-wifi.patch evk_8mq enable uSD 8987 wifi            1. hardware rework                no hardware rework required            2. patches diff --git a/imx8m/evk_8mq/BoardConfig.mk b/imx8m/evk_8mq/BoardConfig.mk index db7c4991..4d130cc0 100644 --- a/imx8m/evk_8mq/BoardConfig.mk +++ b/imx8m/evk_8mq/BoardConfig.mk @@ -136,7 +136,8 @@ ifeq ($(TARGET_USE_DYNAMIC_PARTITIONS),true) TARGET_BOARD_DTS_CONFIG ?= imx8mq:imx8mq-evk-no-product.dtb else # imx8mq with HDMI display - TARGET_BOARD_DTS_CONFIG ?= imx8mq:imx8mq-evk-pcie1-m2.dtb + TARGET_BOARD_DTS_CONFIG ?= imx8mq:imx8mq-evk-usd-wifi.dtb + # imx8mq with MIPI-HDMI display TARGET_BOARD_DTS_CONFIG += imx8mq-mipi:imx8mq-evk-lcdif-adv7535.dtb # imx8mq with HDMI and MIPI-HDMI display diff --git a/imx8m/evk_8mq/SharedBoardConfig.mk b/imx8m/evk_8mq/SharedBoardConfig.mk index 330ab1c5..a6654bad 100644 --- a/imx8m/evk_8mq/SharedBoardConfig.mk +++ b/imx8m/evk_8mq/SharedBoardConfig.mk @@ -7,10 +7,10 @@ PRODUCT_IMX_TRUSTY := true #Enable this to disable product partition build. #IMX_NO_PRODUCT_PARTITION := true -#NXP 8997 wifi driver module +# NXP 8987 wifi driver module BOARD_VENDOR_KERNEL_MODULES += \ - $(KERNEL_OUT)/drivers/net/wireless/marvell/mrvl8997/wlan_src/mlan.ko \ - $(KERNEL_OUT)/drivers/net/wireless/marvell/mrvl8997/wlan_src/pcie8xxx.ko + $(KERNEL_OUT)/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/mlan.ko \ + $(KERNEL_OUT)/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/moal.ko # mipi-panel touch driver module BOARD_VENDOR_KERNEL_MODULES += \ diff --git a/imx8m/evk_8mq/UbootKernelBoardConfig.mk b/imx8m/evk_8mq/UbootKernelBoardConfig.mk index 5aa1ce35..4c3378f0 100644 --- a/imx8m/evk_8mq/UbootKernelBoardConfig.mk +++ b/imx8m/evk_8mq/UbootKernelBoardConfig.mk @@ -14,7 +14,7 @@ endif TARGET_BOOTLOADER_CONFIG += imx8mq-evk-uuu:imx8mq_evk_android_uuu_defconfig TARGET_KERNEL_DEFCONFIG := imx_v8_android_defconfig -# TARGET_KERNEL_ADDITION_DEFCONF ?= android_addition_defconfig +TARGET_KERNEL_ADDITION_DEFCONF ?= android_addition_defconfig diff --git a/imx8m/evk_8mq/android_addition_defconfig b/imx8m/evk_8mq/android_addition_defconfig new file mode 100644 index 00000000..f51bd5ff --- /dev/null +++ b/imx8m/evk_8mq/android_addition_defconfig @@ -0,0 +1,2 @@ +CONFIG_WLAN_VENDOR_NXP=y +CONFIG_MXMWIFIEX=m diff --git a/imx8m/evk_8mq/early.init.cfg b/imx8m/evk_8mq/early.init.cfg index 9262d953..70097a1c 100644 --- a/imx8m/evk_8mq/early.init.cfg +++ b/imx8m/evk_8mq/early.init.cfg @@ -1,3 +1,3 @@ insmod vendor/lib/modules/mlan.ko -insmod vendor/lib/modules/pcie8xxx.ko sta_name=wlan uap_name=wlan wfd_name=p2p max_vir_bss=1 cfg80211_wext=0xf cal_data_cfg=none p2p_enh=1 fw_name=pcieuart8997_combo_v4.bin +insmod vendor/lib/modules/moal.ko sta_name=wlan uap_name=wlan wfd_name=p2p max_vir_bss=1 cfg80211_wext=0xf cal_data_cfg=none fw_name=sdiouart8987_combo_v0.bin insmod vendor/lib/modules/synaptics_dsx_i2c.ko diff --git a/imx8m/evk_8mq/evk_8mq.mk b/imx8m/evk_8mq/evk_8mq.mk index 7db1b212..210f8971 100644 --- a/imx8m/evk_8mq/evk_8mq.mk +++ b/imx8m/evk_8mq/evk_8mq.mk @@ -250,9 +250,9 @@ PRODUCT_PACKAGES += \ PRODUCT_PACKAGES += \ bt_vendor.conf -# NXP 8997 Wifi and Bluetooth Combo Firmware +# NXP 8987 Wifi and Bluetooth Combo Firmware PRODUCT_COPY_FILES += \ - vendor/nxp/imx-firmware/nxp/FwImage_8997/pcieuart8997_combo_v4.bin:vendor/firmware/pcieuart8997_combo_v4.bin + vendor/nxp/imx-firmware/nxp/FwImage_8987/sdiouart8987_combo_v0.bin:vendor/firmware/sdiouart8987_combo_v0.bin # Wifi regulatory PRODUCT_COPY_FILES += \ The patch is attached as 0001-8mq-usd-8987-wifi.patch evk_8mq enable M.2 8987 wifi            1. hardware rework                hardware rework required ( Be aware: after this rework, uSD is not working!)            2. patches diff --git a/imx8m/evk_8mq/BoardConfig.mk b/imx8m/evk_8mq/BoardConfig.mk index db7c4991..0cca9b8e 100644 --- a/imx8m/evk_8mq/BoardConfig.mk +++ b/imx8m/evk_8mq/BoardConfig.mk @@ -136,7 +136,8 @@ ifeq ($(TARGET_USE_DYNAMIC_PARTITIONS),true) TARGET_BOARD_DTS_CONFIG ?= imx8mq:imx8mq-evk-no-product.dtb else # imx8mq with HDMI display - TARGET_BOARD_DTS_CONFIG ?= imx8mq:imx8mq-evk-pcie1-m2.dtb + TARGET_BOARD_DTS_CONFIG ?= imx8mq:imx8mq-evk-usdhc2-m2.dtb + # imx8mq with MIPI-HDMI display TARGET_BOARD_DTS_CONFIG += imx8mq-mipi:imx8mq-evk-lcdif-adv7535.dtb # imx8mq with HDMI and MIPI-HDMI display diff --git a/imx8m/evk_8mq/SharedBoardConfig.mk b/imx8m/evk_8mq/SharedBoardConfig.mk index 330ab1c5..a6654bad 100644 --- a/imx8m/evk_8mq/SharedBoardConfig.mk +++ b/imx8m/evk_8mq/SharedBoardConfig.mk @@ -7,10 +7,10 @@ PRODUCT_IMX_TRUSTY := true #Enable this to disable product partition build. #IMX_NO_PRODUCT_PARTITION := true -#NXP 8997 wifi driver module +# NXP 8987 wifi driver module BOARD_VENDOR_KERNEL_MODULES += \ - $(KERNEL_OUT)/drivers/net/wireless/marvell/mrvl8997/wlan_src/mlan.ko \ - $(KERNEL_OUT)/drivers/net/wireless/marvell/mrvl8997/wlan_src/pcie8xxx.ko + $(KERNEL_OUT)/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/mlan.ko \ + $(KERNEL_OUT)/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/moal.ko # mipi-panel touch driver module BOARD_VENDOR_KERNEL_MODULES += \ diff --git a/imx8m/evk_8mq/UbootKernelBoardConfig.mk b/imx8m/evk_8mq/UbootKernelBoardConfig.mk index 5aa1ce35..4c3378f0 100644 --- a/imx8m/evk_8mq/UbootKernelBoardConfig.mk +++ b/imx8m/evk_8mq/UbootKernelBoardConfig.mk @@ -14,7 +14,7 @@ endif TARGET_BOOTLOADER_CONFIG += imx8mq-evk-uuu:imx8mq_evk_android_uuu_defconfig TARGET_KERNEL_DEFCONFIG := imx_v8_android_defconfig -# TARGET_KERNEL_ADDITION_DEFCONF ?= android_addition_defconfig +TARGET_KERNEL_ADDITION_DEFCONF ?= android_addition_defconfig # absolute path is used, not the same as relative path used in AOSP make diff --git a/imx8m/evk_8mq/android_addition_defconfig b/imx8m/evk_8mq/android_addition_defconfig new file mode 100644 index 00000000..f51bd5ff --- /dev/null +++ b/imx8m/evk_8mq/android_addition_defconfig @@ -0,0 +1,2 @@ +CONFIG_WLAN_VENDOR_NXP=y +CONFIG_MXMWIFIEX=m diff --git a/imx8m/evk_8mq/early.init.cfg b/imx8m/evk_8mq/early.init.cfg index 9262d953..70097a1c 100644 --- a/imx8m/evk_8mq/early.init.cfg +++ b/imx8m/evk_8mq/early.init.cfg @@ -1,3 +1,3 @@ insmod vendor/lib/modules/mlan.ko -insmod vendor/lib/modules/pcie8xxx.ko sta_name=wlan uap_name=wlan wfd_name=p2p max_vir_bss=1 cfg80211_wext=0xf cal_data_cfg=none p2p_enh=1 fw_name=pcieuart8997_combo_v4.bin +insmod vendor/lib/modules/moal.ko sta_name=wlan uap_name=wlan wfd_name=p2p max_vir_bss=1 cfg80211_wext=0xf cal_data_cfg=none fw_name=sdiouart8987_combo_v0.bin insmod vendor/lib/modules/synaptics_dsx_i2c.ko diff --git a/imx8m/evk_8mq/evk_8mq.mk b/imx8m/evk_8mq/evk_8mq.mk index 7db1b212..210f8971 100644 --- a/imx8m/evk_8mq/evk_8mq.mk +++ b/imx8m/evk_8mq/evk_8mq.mk @@ -250,9 +250,9 @@ PRODUCT_PACKAGES += \ PRODUCT_PACKAGES += \ bt_vendor.conf -# NXP 8997 Wifi and Bluetooth Combo Firmware +# NXP 8987 Wifi and Bluetooth Combo Firmware PRODUCT_COPY_FILES += \ - vendor/nxp/imx-firmware/nxp/FwImage_8997/pcieuart8997_combo_v4.bin:vendor/firmware/pcieuart8997_combo_v4.bin + vendor/nxp/imx-firmware/nxp/FwImage_8987/sdiouart8987_combo_v0.bin:vendor/firmware/sdiouart8987_combo_v0.bin The patch is attached as 0001-8mq-m2-8987-wifi.patch
View full article
    Test environment: MPU6050 module,i.MX8MP,Android11_2.4.0 This solution ported the MPU6050 module on Android to realize auto rotation of screen.      
View full article
One of the most popular use cases for embedded systems are projects destinated to show information and interact with users. These views are called GUI or Graphic User Interface which are designed to be intuitive, attractive, consistent, and clear. There are many tools that we can use to achieve great GUIs, mostly implemented for platforms such as Web, Android, and iOS. Here, we will need to introduce the concept of framework, basically, it is a set of tools and rules that provides a minimal structure to start with your development. Frameworks usually comes with configuration files, code snippets, files and folders organization helping us to save time and effort. Also, it is important to review the concept of SDK or Software Development Kit which is a set of tools that allows to build software for specific platforms. Usually supplies debugging tools, documentation, libraries, API’s, emulators, and sample code. Flutter is an open-source UI software development kit by Google that help us to create applications with great GUIs on different platforms from a single codebase. Depends on the reference, you can find Flutter defined as a framework or SDK and both are correct, however, an SDK could be a best definition thanks to Flutter supplies a wide and complete package to create an application in which framework is also included. This article is aimed at those that are in a prototyping stage looking for a different tool to develop projects. Also, this article pretends to be a theoretical introduction explaining the most important concepts. However, is a good practice to learn more about reviewing the official documentation from Flutter. (Flutter documentation | Flutter) Here is the structure used throughout this article: What is Flutter? Flutter details Platforms Programming language Official documentation Flutter for embedded systems What is Flutter? Flutter was officially released by Google in December 2018 with a main aim, to give developers a tool to create applications natively compiled for mobile (Android, iOS), web and desktop (Windows, Linux) from a single codebase. It means that as a developer, Flutter will create a structure with minimal code, configuration files, build files for each operating system, manifests, etc. in which we will add our custom code and finally build this code for our preferred OS. For example, we can create an application to review fruit and vegetable information and compile for Android and iOS with the same code. A basic Flutter development process based on my experience looks like the following diagram: Flutter has the following key features: Cross-platform development. Flutter allows the developer to create applications for different platforms using a single codebase. It means that you will not need to recreate the application for each platform you want to support.   Hot-reload. This feature allows the developer to see changes in real time without restarting the whole application, this results in time savings for your project.   High Performance Flutter apps achieve high performance due to the app code is compiled to native ARM code. With this tool no interpreters are involved.   UI Widgets Flutter supplies a set of widgets (UI components such as boxes, inputs text, buttons, etc.) predefined by UI systems guidelines Material on Android and Cupertino for iOS. Source: Material 3 Design Kit | Figma Community Source: Design - Apple Developer   Great community support. This feature could be subjective but, it is useful when we are developing our project find solutions to known issues or report new ones. Because of Flutter is an open source and is widely implemented in the industry this tool owns a big community, with events, forums, and documentation. Flutter Details Supported Platforms With Flutter you can create applications for: Android iOS Linux Debian Linux Ubuntu macOS web Chrome, Firefox, Safari, Edge Windows Supported deployment platforms | Flutter Programming Language Flutter use Dart, a programming language is an open-source language supported by Google optimized to use on the creation of user interfaces. Dart key features: Statically typed. This feature helps catching errors making the code robust ensuring that the variable’s value always match with the declared variable’s type. Null safety. All variables on Dart are non-nullable which means that every variable must have a non-null value avoiding errors at execution time. This feature also, make the code robust and secure. Async/Await. Dart is client-optimized which means that this language was specially created to ensure the best performance as a client application. Async/Await is a feature part of this optimization making easier to manage network requests and other asynchronous operations. Object oriented. Dart is an object-oriented language with classes and mixin. This is especially useful to use on Flutter with the usage of widgets. Compiler support of Just-In-Time (JIT) and Ahead-of-Time (AOT) JIT provides the support that enables the Hot Reload Flutter feature that I mentioned before. It is a complex mechanism, but Dart “detects” changes in your code and execute only these changes avoiding recompiling all the code. AOT compiler produces efficient ARM code improving start up time and performance. Official documentation Flutter has a rich community and documentation that goes from UI guidelines to an Architectural Overview. You can find the official documentation at the following links: Flutter Official Documentation: Flutter documentation | Flutter Flutter Community: Community (flutter.dev) Dart Official Documentation: Dart documentation | Dart Flutter for embedded systems So far, we know all the excellent features and platforms that Flutter can support. But, what about the embedded systems? On the official documentation we can find that Flutter may be used for embedded systems but in fact there is no an official supported platform. This SDK has been supported by their community, specially there is one repository on GitHub supported by Sony that provides documentation and Yocto recipes to support Flutter on embedded Linux. To understand the reason to differentiate between Flutter for Linux Desktop with official support and to create a specific Flutter support for embedded Linux is important to describe the basics of Flutter architecture. Based on the Flutter documentation the system is designed using layers that can be illustrated as follows:   Source: Flutter architectural overview | Flutter We can see as a top level “Framework” which is a high-level layer that includes widgets, tools and libraries that are in contact with developers. Below “Framework,” the layer “Engine” is responsible of drawing the widgets specified in the previous layer and provides the connection between high-level and low-level code. This layer is mostly written in C++ for this reason Flutter can achieve high performance running applications. Specifically for graphics rendering Flutter implements Impeller for iOS and Skia for the rest of platforms. The bottom layer is “Embedder” which is specific for each target and operating system this layer allows Flutter application to run as a native app providing the access to interact with different services managed by the operating systems such as input, rendering surfaces and accessibility. This layer for Linux Desktop uses GTK/GDK and X11 as backend that is highly dependent of unnecessary libraries and expensive for embedded systems which have constrained resources for computation and memory. The work around founded by Sony’s Flutter for Embedded Linux repository is to change this backend using a widely implemented backend for embedded systems Wayland. The following image illustrates the difference between Flutter for Linux Desktop and Flutter for Embedded Linux.   Source: What's the difference between Linux desktop and Embedded Linux · sony/flutter-embedded-linux Wiki · GitHub   Source: What's the difference between Linux desktop and Embedded Linux · sony/flutter-embedded-linux Wiki · GitHub Here is the link to the mentioned repository: GitHub - sony/flutter-elinux: Flutter tools for embedded Linux (eLinux) Finally, I would like to encourage you to read the official Flutter documentation and consider this tool as a great option compared to widely used tools on embedded devices such as Qt or Chromium. Also, please have a look to a great article written by Payam Zahedi delving into the implementation of Flutter for Embedded Linux measuring performance and giving conclusions about the usage of Flutter in embedded systems. (Flutter on Embedded Devices. Learn how to run Flutter on embedded… | by Payam Zahedi | Snapp Embedded | Medium).    
View full article
BSP: L5.15.5_1.0.0   Platform: i.MX8MPlus EVK   1. Parameter preparation For more parameter calculation, please refer to: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-8M- Mini-Register-Programming-Aid-DRAM-PLL-setting/ta-p/111209  For 1866MHz LPDDR4, we need a DRAM PLL size of 933MHz. The PLL dividing parameters are: m=622,p=16,s=0, k=0.   2. Calibration and stress test with DDR Tool 2.1 Creating a test script for 1866MHz Here we copy the script from another file (e.g. 2000MHz) and modify the contents of the script.   2.2 Modify the script to adapt to 1866MHz 2.3 Download the test script After selecting the ddr script we created, click on the download button   2.4 Calibrating the stress test Set the core clock of the chip's cpu to 1.2GHz, then click the Calibration button to calibrate, then click Gen Code to generate the lpddr4_timing.c file. Set the start frequency to 1866MHz for the stress test.   2.5 Modify lpddr4_timing.c We need to modify the generated lpddr4_timing.c file to change the maximum speed to 3732MTS.   3. SPL patch After getting the correct lpddr4_timing.c file, the SPL code also needs to be modified to add support for the 933MHz DRAM PLL. diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c index e39f238fdf...5622a6334e 100644 --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c @@ -55,6 +55,7 @@ static struct imx_int_pll_rate_table imx8mm_fracpll_tbl[] = { PLL_1443X_RATE(650000000U, 325, 3, 2, 0), PLL_1443X_RATE(600000000U, 300, 3, 2, 0), PLL_1443X_RATE(594000000U, 99, 1, 2, 0), + PLL_1443X_RATE(933000000U, 622, 16, 0, 0), PLL_1443X_RATE(400000000U, 400, 3, 3, 0), PLL_1443X_RATE(2660000U, 266, 3, 3, 0), PLL_1443X_RATE(167000000U, 334, 3, 4, 0), diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..ebd005bc2b 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -117,6 +117,10 @@ void ddrphy_init_set_dfi_clk(unsigned int drate) dram_pll_init(MHZ(1000)); dram_disable_bypass(); break; + case 3732: + dram_pll_init(MHZ(933)); + dram_disable_bypass(); + break; case 3200: dram_pll_init(MHZ(800)); dram_disable_bypass();   4. Test results   Reference blog. DDR Tool: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467  RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8MPlus-m865S-DDR-Register-Programming-Aids-RPA/ta-p/1235352 
View full article
L5.4.3_1.0.0 release is now available on IMX_SW landing page: BSP Updates and Releases -> Linux ->Linux L5.4.3_1.0.0. Documentation -> Linux -> Linux 5.4.3_1.0.0 Documentation Files available: # Name Description 1 imx-yocto-LF_L5.4.3_1.0.0.zip i.MX L5.4.3_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 LF_v5.4.y-1.0.0_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualLite, i.MX 6Solox Linux Binary Demo Files 3 LF_v5.4.y-1.0.0_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 LF_v5.4.y-1.0.0_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 LF_v5.4.y-1.0.0_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  6 LF_v5.4.y-1.0.0_images_MX8MMEVK.zip i.MX 8M Mini EVK Linux Binary Demo Files  7 LF_v5.4.y-1.0.0_images_MX8MNEVK.zip i.MX 8M Nano EVK Linux Binary Demo Files  8 LF_v5.4.y-1.0.0_images_MX8MQEVK.zip i.MX 8M Quad EVK Linux Binary Demo files 9 LF_v5.4.y-1.0.0_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 LF_v5.4.y-1.0.0_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.10.1.tar.gz System Controller Firmware (SCFW) porting kit v1.2.10.1 for L5.4.3_1.0.0   Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 8M Nano EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board   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 of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-zeus ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-zeus      
View full article
current bsp fixed the lvds pixel clock up to 74.25Mhz for single channel and 148.5Mhz for dual channel, if customer wants to know why and how to change it, maybe can refer to the enclosed file, hope helpful for you
View full article
Hello there. Here is a good way to use U-boot in an efficient way with custom scripts. The bootscript is an script that is automatically executed when the boot loader starts, and before the OS auto boot process. The bootscript allows the user to execute a set of predefined U-Boot commands automatically before proceeding with normal OS boot. This is especially useful for production environments and targets which don’t have an available serial port for showing the U-Boot monitor. This information can be find in U-Boot Reference Manual.   I will take the example load a binary file in CORTEX M4 of IMX8MM-EVK. In my case, I have the binary file in MMC 2:1 called gpio.bin and I will skip those steps because that is not the goal.   First, you need the u-boot-tools installed in your Linux machine: sudo apt install u-boot-tools   That package provide to us the tool mkimage to convert a text file (.src, .txt) file to a bootscript file for U-Boot.   Now, create your custom script, in this case a simple script for load binary file in Cortex M4: nano mycustomscript.scr  and write your U-Boot commands: fatload mmc 2:1 0x80000000 gpio.bin cp.b 0x80000000 0x7e0000 0x10000 bootaux 0x7e0000   Now we can convert the text file to bootscript with mkimage. Syntax: mkimage -T script -n "Bootscript" -C none -d <input_file> <output_file> mkimage -T script -n "Bootscript" -C none -d mycustomscript.scr LCM4-bootscript   This will create a file called LCM4-bootscript (Or as your called it).   A way to load this bootscript file to U-Boot is using the UUU tool, in U-Boot set the device in fastboot with command: u-boot=> fastboot 0 Then in linux with the board connected through USB to PC run the command: sudo uuu -b fat_write LCM4-bootscript mmc 2:1 LCM4-bootscript   Now we have our bootscript in U-Boot in MMC 2:1.   Finally, we can run the bootscript in U-Boot: u-boot=> load mmc 2:1 ${loadaddr} LCM4-bootscript 158 bytes read in 2 ms (77.1 KiB/s) u-boot=> source ${loadaddr} ## Executing script at 40400000 6656 bytes read in 5 ms (1.3 MiB/s) ## No elf image at address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD...   And the Cortex M4 booted successfully:    I hope this can helps to you.   Best regards.   Salas.  
View full article