i.MX Processors Knowledge Base

Discussions

In the i.MX 8M Plus LPDDR4 EVK board there are two Type-C port design. For the port0 is used to power supply no usb function, for the port1 used for USB function but without PD function. But in customer’s design, customer only use one USB design on their board, how to make the one USB work with the PD and USB function, we need to make the hardware design and software modify. This article only give method to realized it and have tested and realized the port1 PD function. 1 Introduction of the USB interface on i.MX8MP There are two USB 3.0 TypeC controllers with integrated PHY interface on the i.MX8MP: Backward compatibility with USB 2.0 Spread spectrum clock support The USB on the i.MX8MP supports USB3.0 and is compatible with USB2.0 downward. We can see that the upper layer is the universal layer for USB 2.0 and USB 3.0 operations. This is a common interface, buffer management block, list processor, used to schedule and control the status register (CSR) function： USB 2.0 physical layer and MAC layer USB 3.0 physical layer, link layer and MAC layer Features of USB 3.0: USB compliant version 3.0 (xHCI compatible) Supports operation as a stand-alone USB host controller USB dual role operation, configurable as host or device Ultra high speed (5Gbit/s), high speed (480Mbit/s), full speed (12Mbit/s) and low speed (1.5Mbit/s) operation. Support independent single port USB operation Support for four programmable bidirectional USB endpoints Support system memory interface with 40 bit addressing capability 2 Design of USB on Development Board The i.MX 8M Plus processor includes two USB 2.0/3.0 controllers and two integrated USB PHYs. USB supports both running as an independent USB host controller and dual role USB operation, and can be configured as a host or device. Therefore, the design of these two functions is implemented on the development board of i.MX8MP. We can see that on the development board, one USB1 is used for the USB Type-C port and the other USB2 is used for the USB 3.0 host port. USB Type-C port 0 (J5) is only used for power supply. It does not support USB data transfer. It is the only power port, so the system must always be powered. On the CPU side of the schematic diagram, we can also see that USB1 is the port for USB Type-C, and USB2 is the host for USB3.0. USB1 is designed as USB Type-C: USB2 USB3.0 Host design： Power design of the USB Type-C port： 3 Only one USB interface is used in the design (compatible with both USB PD function and USB dual roles function) Two USB Type-C ports are used on our development board. One is used to power the board separately, and the other is used as the function of USB Type-C. However, due to the limited design cost and chip layout and space on the board, some customers will use a USB interface to realize the dual role function of power supply and USB. How to achieve this? USB Device(Download mode)： USB　Host mode（power+device　Need the hub support PD function）: The specific implementation and design are as follows: 3.1 Hardware realize PTN5110 To realize the USB Type-C support power supply function, PTN5110 (USB PD TCPC PHY IC) chip is required to realize Type-C data logic and power control and management. The selection of PTN5110 is critical and important. PTN5110 is a single port USB PD (power supply) PHY IC that conforms to TCPC. It integrates Type-C configuration channel (CC) interface and USB PD physical layer functions into Type-C port manager (TCPM) that handles PD policy management. It complies with USB PD, Type-C and TCPC specifications. The IC is mainly aimed at applications in system platforms (such as laptops, desktops, Chromebooks, tablets, flip notebooks, etc.). Other application cases may be feasible, depending on the application architecture, such as docking stations, displays, accessories, cable adapters, smartphones, etc. It can support various Type-C applications: Sink, Source, Sink with accessory support or DRP. It executes Type-C CC simulation part (i.e. Rd/Rp/Ra detection, Rd/Rp indication) and PD Tx/Rx PHY and protocol state machine. PTN5110 supports TCPM in the system implementation of the following PD roles. PTN5110 integrates VCONN load switch, programmable current limit, reverse leakage current blocking and over temperature protection (OTP). It is equipped with two enable control outputs to control the load switch/FET in the VBUS pull and/or sink path. It can also perform VBUS voltage monitoring/measurement, VBUS forced discharge and discharge discharge. PTN5110 provides the main IO related functions for the main processor/TCPM, so that Type-C/PD interfaces can be easily controlled and managed through the TCPC interface. PTN5110 supports a wide range of power input voltages, providing platform integrators with great flexibility. PTN5110 can run on VBUS to support specific system use cases that require no power operation.https://www.nxp.com/products/interfaces/usb-interfaces/usb-type-c/usb-pd-phy-and-cc-logic/usb-pd-tcpc-phy-ic:PTN5110 The design only use the USB1： Here, it is required to weld R53 or R54. You can refer to this design completely. 2 Software modify Modify the BPS of the software: Take the newest released Linux 5.15.32_2.0.0 as example: In the u-boot /board/freescale/imx8mp_evk/imx8mp_evk.c It can be seen that the PD function of the port is turned off, so if you want to use USB1 for power supply, remove the following commands and turn on the PD function of USB1. “- .disable_pd = true,” Use the above action to enable Port1 PD function. Kernel section modify： Kernel section modify towards to PTN5110. Type-C Configure channel (CC) interface： root/drivers/usb/typec/tcpm/tcpci.c @@ -524,6 +524,7 @@ static int tcpci_vbus_force_discharge(struct tcpc_dev *tcpc, bool enable) static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool source, bool sink) { struct tcpci *tcpci = tcpc_to_tcpci(tcpc); + unsigned int reg; int ret; if (tcpci->data->set_vbus) { @@ -533,16 +534,20 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool source, bool sink) return ret < 0 ? ret : 0; } + ret = regmap_read(tcpci->regmap, TCPC_POWER_STATUS, &reg); + if (ret < 0) + return ret; + /* Disable both source and sink first before enabling anything */ - if (!source) { + if (!source && (reg & TCPC_POWER_STATUS_SOURCING_VBUS)) { ret = regmap_write(tcpci->regmap, TCPC_COMMAND, TCPC_CMD_DISABLE_SRC_VBUS); if (ret < 0) return ret; } - if (!sink) { + if (!sink && (reg & TCPC_POWER_STATUS_SINKING_VBUS)) { ret = regmap_write(tcpci->regmap, TCPC_COMMAND, TCPC_CMD_DISABLE_SINK_VBUS); if (ret < 0) Type-C port manager managed by PD (TCPM)： root/drivers/usb/typec/tcpm /tcpm.c @@ -340,6 +340,7 @@ struct tcpm_port { */ bool vbus_vsafe0v; + bool vbus_keep; bool vbus_never_low; bool vbus_source; bool vbus_charge; @@ -3662,7 +3663,8 @@ static void tcpm_reset_port(struct tcpm_port *port) port->rx_msgid = -1; port->tcpc->set_pd_rx(port->tcpc, false); - tcpm_init_vbus(port); /* also disables charging */ + if (!port->vbus_keep) + tcpm_init_vbus(port); /* also disables charging */ tcpm_init_vconn(port); tcpm_set_current_limit(port, 0, 0); tcpm_set_polarity(port, TYPEC_POLARITY_CC1); @@ -5834,6 +5836,9 @@ static void tcpm_init(struct tcpm_port *port) port->tcpc->init(port->tcpc); + port->vbus_present = port->tcpc->get_vbus(port->tcpc); + if (port->vbus_present) + port->vbus_keep = true; tcpm_reset_port(port); /* @@ -5872,7 +5877,10 @@ static void tcpm_init(struct tcpm_port *port) * Some adapters need a clean slate at startup, and won't recover * otherwise. So do not try to be fancy and force a clean disconnect. */ - tcpm_set_state(port, PORT_RESET, 0); + if (!port->vbus_keep) + tcpm_set_state(port, PORT_RESET, 0); + + port->vbus_keep = false; } static int tcpm_port_type_set(struct typec_port *p, enum typec_port_type type) Note: The software just needs to modify these two parts. You also need to mention to the proper the I2C port use, if not proper the driver of the PTN5110 can not driver. 4 Test In our i. MX8MP EVK development board show that R53 and R54 in the USB1 part of our development board are in DNP status, so VBUS_ IN is disconnected and no power comes in. Here, connect R53 or R54 with solder, so that VBUS_ IN, the power comes in again. After the power is connected. The board can be powered through USB1. 4.1 Download images to the emmc on the Board: Power from the USB1, set the boot mode to serial download mode, then go to download images finished. 4.2 Boot up the board from the EMMC Change the boot mode to boot up from EMMC，the board boot up, the log file is as following show： It will stop at the TCPC for the section of PTN5110 driver. By default, the PD function of port1 in the u-boot is turned off, so if you want to use USB1 for power supply, remove the following commands and turn on the PD function of USB1. “- .disable_pd = true,” After the PD function is turned on, the board can be started normally, but the whole part running to the kernel will be powered down, so the kernel part of PTN5110 still needs to be modified. After the patch modification of the above kernel part, the board can run normally. I also did the same experiment on the i.MX8MM EVK development board. The same phenomenon occurs when the kernel starts. Therefore, similar modifications to the above i. MX8MP can work normally. Summary: In one word i.MX8MP and i.MX8M series can realize the role of using a USB for power supply and USB Dual. The hardware design refers to our development board, and we must use the logic chip PTN5110. For software, refer to the above code modification.

Background PCIe interface of Android 12 prebuilt and Built image on iMX8MM mini is not coming up. The Android BSP doesn't enable the pcie driver. Solution 1. imx8mm_gki.fragment CONFIG_PHY_FSL_IMX_PCIE=m CONFIG_PCI_IMX6=m 2. device/nxp/imx8m/evk_8mm/SharedBoardConfig.mk $(KERNEL_OUT)/drivers/pci/controller/dwc/pci-imx6.ko \ Result evk_8mm:/ # dmesg | grep pci [ 0.561609] ehci-pci: EHCI PCI platform driver [ 6.515345] imx6q-pcie 33800000.pcie: supply epdev_on not found, using dummy regulator [ 6.524925] imx6q-pcie 33800000.pcie: EXT REF_CLK is used!. [ 6.560211] imx6q-pcie 33800000.pcie: PCIe PLL locked after 20 us. [ 6.567328] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges: [ 6.584463] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000 [ 6.593833] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000 [ 6.603140] imx6q-pcie 33800000.pcie: invalid resource [ 6.708123] imx6q-pcie 33800000.pcie: Link up [ 6.713393] imx6q-pcie 33800000.pcie: Link up [ 6.718586] imx6q-pcie 33800000.pcie: Link up, Gen1 [ 6.832372] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00 [ 6.840023] pci_bus 0000:00: root bus resource [bus 00-ff] [ 6.846535] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] [ 6.853805] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff] [ 6.861601] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400 [ 6.868529] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff] [ 6.876439] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref] [ 6.884101] pci 0000:00:00.0: supports D1 [ 6.888954] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold [ 6.899174] pci 0000:01:00.0: [1b4b:2b42] type 00 class 0x020000 [ 6.906127] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x000fffff 64bit pref] [ 6.914221] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x000fffff 64bit pref] [ 6.922740] pci 0000:01:00.0: supports D1 D2 [ 6.927854] pci 0000:01:00.0: PME# supported from D0 D1 D3hot D3cold [ 6.935200] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000 Gb/s with 5.0 GT/s PCIe x1 link) [ 6.962608] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff] [ 6.970251] pci 0000:00:00.0: BAR 15: assigned [mem 0x18100000-0x182fffff pref] [ 6.978426] pci 0000:00:00.0: BAR 6: assigned [mem 0x18300000-0x1830ffff pref] [ 6.986479] pci 0000:01:00.0: BAR 0: assigned [mem 0x18100000-0x181fffff 64bit pref] [ 7.001517] pci 0000:01:00.0: BAR 2: assigned [mem 0x18200000-0x182fffff 64bit pref] [ 7.010203] pci 0000:00:00.0: PCI bridge to [bus 01-ff] [ 7.016271] pci 0000:00:00.0: bridge window [mem 0x18100000-0x182fffff pref] [ 7.025830] pcieport 0000:00:00.0: PME: Signaling with IRQ 238 [ 7.033786] pcieport 0000:00:00.0: AER: enabled with IRQ 238

1. Intro This document contains instructions to run run the SAI low power audio demo on the i.MX 8M Plus EVK. Here, the RPSMG to allows audio to be passed from the A53 cluster running Linux to the M7 core. The latter controls the on board WM8960 audio codec, which is connected to a 3.5 mm audio jack that allow us to play music using headphones. I will show the necessary steps to make the demo work and will add some GStreamer examples to demonstrate the demo's capabilities. TBD: update this with a nice diagram that depicts the A53 and M7 RPMSG channel. 2. Requirements Hardware MX 8M Plus EVK Headphones with 3.5 mm audio jack Type-C power supply for i.MX 8M Plus EVK Micro USB to USB adapter cable Software A recent prebuilt Linux BSP image from NXP.com ( we tested this on 5.15.35 and 5.15.5 releases) Windows 10 or Ubuntu 20.04 Workstation MCUXpresso SDK for i.MX 8M Plus ( available from: Welcome | MCUXpresso SDK Builder (nxp.com)) 3. Reference documentation for this example MCUXpresso SDK [1] Getting Started with MCUXpresso SDK for EVK-MIMX8MP Available within the MCUXpresso SDK package: \{INSTALL PATH}\SDK_X_X_X_EVK-MIMX8MP\docs [2] SAI low power audio README file Contains instructions for the SAI Low Power Audio Demo. Available within the MCUXpresso SDK package: \{INSTALL PATH}\SDK_X_X_X_EVK-MIMX8MP\boards\evkmimx8mp\demo_apps\sai_low_power_audio 4. Downloading a pre-built Linux BSP image for the i.MX 8M Plus I will make use of the prebuilt Linux Image for the i.MX 8M Plus EVK for demonstrating the demo works. At the moment of writing this time, I used the 5.15.32 release, although there are older releases like 5.10.5 that I tested and proved to work with no issues. This SAI Low Power Audio Demo shall work for other processors on the i.MX 8M family. Although specific instructions ( e.g. load address for M-core binary load) might require some adaptation. For M-core load address, please refer to the specific MCUXpresso SDK documentation for each processor. The prebuilt Linux image (5.15.32) for the i.MX 8M Plus EVK can be downloaded from here: https://www.nxp.com/webapp/Download?colCode=L5.15.32_2.0.0_MX8MP&appType=license You can download other releases from here: Embedded Linux for i.MX Applications Processors | NXP Semiconductors . Select a version and a board and select download. 5. Flashing the BSP image If you are using an Ubuntu 20.04 workstation, I recommend you to flash the image using dd. For this, you can refer to the i.MX Linux User's Guide: Section - 4.3.2 Copying the full SD card image - https://www.nxp.com/docs/en/user-guide/IMX_LINUX_USERS_GUIDE.pdf sudo dd if=.wic of=/dev/sdx bs=1M && sync NOTE: when using dd, ALWAYS, double check the of device that you are about to writing. Messing up with another location or partition will harm your system If you are following this document on a Windows machine: You can use the Universal Update Utility (UUU) to flash your image on either the board's eMMC or SD card. Document named UUU.pdf shall serve as your reference guide for further instructions and flashing examples. It is available along with UUU binary here: https://github.com/NXPmicro/mfgtools/releases Two examples are shown below for your convenience: SD card flash uuu -b sd_all bootloader rootfs.sdcard.bz2 eMMC flash uuu -b emmc_all bootloader rootfs.sdcard.bz2 uuu uuu.auto NOTE: UUU is also compatible with Ubuntu NOTE: there are other engineers who like to use BalenaEtcher for flashing their BSP images. I have tested it and works on both Ubuntu and Windows 10 machines. 6. Preparing the BSP and booting up M7 core using U-Boot I am writing this upon the instructions contained on the README file for the low power audio example [2]. Instructions ready to copy and paste will follow: Instruct U-Boot to pass to the kernel the rpmsg device tree to enable communication between the A53 cluster and the M7 one: u-boot=>setenv fdtfile imx8mp-evk-rpmsg.dtb u-boot=>saveenv Load the M7 example: u-boot=>setenv mmcargs 'setenv bootargs ${jh_clk} console=${console} root=${mmcroot} snd_pcm.max_alloc_per_card=134217728' u-boot=>saveenv Now, we need to load the M4 with the demo. Refer to [1] for further information. If running the BSP on an SD card, make sure the example binary is listed on the boot partition as follows: fatls mmc 1:1 You shall see something similar to this: imx8mp_m7_TCM_sai_low_power_audio.bin Open the serial terminal emulator for the M7. Out of the fourth ports listed when we plug the i.MX 8M Plus serial debug cable to the PC, the M7 is typically the last one listed. All the serial ports available to the workstation when the i.MX 8M Plus serial cable is connected to it. NOTE: you may require to install addtitional COM drivers if you are running on Windows. I like doing the previous step so I can see the result of the next commands issued in U-boot to load the M7 image. fatload mmc 1:1 0x48000000 imx8mp_m7_TCM_sai_low_power_audio.bin; cp.b 0x48000000 0x7e0000 20000; bootaux 0x7e0000 Here is an screenshot that shows how the U-Boot's response should look: U-Boot response when loading the SAI low power audio example to the Cortex M7 That should have prompted the following message on the M7 terminal: M7-core is up! Now, let’s move to user space! u-boot=> boot 7. Testing the example using a simple GStreamer pipeline As soon as the O.S. finishes booting. We can see that M7 terminal prompts the following: M7 is now in STOP mode; waiting for some audio to beat the room! Confirm that the WM8960 is listed as audio card as follows: cat /proc/asound/cards Listing avaialable audio cards. WM8960 should be present. Make note of the list. The wm8960 is listed a the third sound card. This is where I like to differ a bit from [2] and I suggest a quicker test in case of not having an audio file ready. We just simply use GStreamer to play an audiotest source. Please make sure to plug in your headphones onto the board’s 3.5 mm jack before. The following GStreamer pipeline is using the WM8960 as an audiosink. gst-launch-1.0 audiotestsrc ! alsasink device=hw:3 NOTE: please be cautious and not put the headphones directly in your head at the first attempt. The sound can be too loud to some people. This is what you should see on the M7 side: Stop the GStreamer pipeline issuing CTRL + C. M7 shall warn you about that: NOTE: you can use the aplay command to play audio as shown on [2]. However, I consider using a testsrc is much quicker and flexible for a quick test. 8. Additional information Feel free to go ahead and tweak the GStreamer pipeline to change audio test source properties. audiotest src. This command will let you know the available options: gst-inspect-1.0 audiotestsrc NOTE: you can navigate through the displayed list using the “d”key. Press “q’’ to quit. For example: For example, I am reproducing sound using a different setup based on the list above: gst-launch-1.0 audiotestsrc freq=4000 volume=0.8 wave=8 ! alsasink device=hw:3 9. Errata and future updates TBD: Add an example on how to define the default audio card and play the audio either using gst-play or building the pipeline using filesrc Comment on the limitations of the M7 core regarding sample rate and audio formats

BSP: L5.15.5_1.0.0 Platform: i.MX8MPlus EVK Background The function lpddr4_mr_read in BSP always return zero and this casue the customer can't use it to read MR registers in DRAM. This is a simple demo for reading MR registers. Patch Code diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 0f1e832c03..fd68996a23 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -721,6 +721,8 @@ int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); +unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr); + void update_umctl2_rank_space_setting(unsigned int pstat_num); void get_trained_CDD(unsigned int fsp); diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c index 33bbbc09ac..85e40ffbbe 100644 --- a/board/freescale/imx8mp_evk/spl.c +++ b/board/freescale/imx8mp_evk/spl.c @@ -150,6 +150,40 @@ int board_fit_config_name_match(const char *name) return 0; } #endif +void lpddr4_get_info() +{ + int i = 0, attempts = 5; + + unsigned int ddr_info = 0; + unsigned int regs[] = { 5, 6, 7, 8 }; + + for(i = 0; i < ARRAY_SIZE(regs); i++){ + unsigned int data = 0; + data = lpddr4_mr_read(0xF,regs[i]); + ddr_info <<= 8; + ddr_info += (data & 0xFF); + switch (i) + { + case 0: + printf("DRAM INFO : Manufacturer ID = 0x%x",ddr_info); + if(ddr_info & 0Xff) + printf(", Micron\n"); + break; + case 1: + printf("DRAM INFO : Revision ID1 = 0x%x\n",ddr_info); + break; + case 2: + printf("DRAM INFO : Revision ID2 = 0x%x\n",ddr_info); + break; + case 3: + printf("DRAM INFO : I/O Width and Density = 0x%x\n",ddr_info); + break; + default: + break; + } + } + +} void board_init_f(ulong dummy) { @@ -187,6 +221,8 @@ void board_init_f(ulong dummy) /* DDR initialization */ spl_dram_init(); + + lpddr4_get_info(); board_init_r(NULL, 0); } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..f45eeaf552 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -194,8 +194,15 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr) tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0)); } while ((tmp & 0x8) == 0); tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0)); - tmp = tmp & 0xff; reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4); + + while (tmp) { //try to find a significant byte in the word + if (tmp & 0xff) { + tmp &= 0xff; + break; + } + tmp >>= 8; + } return tmp; } Test Result

Test environment i.MX8MP EVK LVDS0 LVDS-HDMI bridge(it6263) Uboot2022, Uboot2023 Background Some customers need show logo using LVDS panel. Current BSP doesn't support LVDS driver in Uboot. This patch provides i.MX8MPlus LVDS driver support in Uboot. If you want to connect it to LVDS panel , you need port your lvds panel driver like simple-panel.c Update [2022.9.19] Verify on L5.15.32_2.0.0 0001-L5.15.32-Add-i.MX8MP-LVDS-driver-in-uboot 'probe device is failed, ret -2, probe video device failed, ret -19' is caused by below code. It has been merged in attachment. // /* Only handle devices that have a valid ofnode */ // if (dev_has_ofnode(dev) && !(dev->driver->flags & DM_FLAG_IGNORE_DEFAULT_CLKS)) { // /* // * Process 'assigned-{clocks/clock-parents/clock-rates}' // * properties // */ // ret = clk_set_defaults(dev, CLK_DEFAULTS_PRE); // if (ret) // goto fail; // } [2023.3.14] Verify on L5.15.71 0001-L5.15.71-Add-i.MX8MP-LVDS-support-in-uboot [2023.9.12] For some panel with low DE, you need uncomment CTRL_INV_DE line and set this bit to 1. #include <linux/string.h> @@ -110,9 +111,8 @@ static void lcdifv3_set_mode(struct lcdifv3_priv *priv, writel(CTRL_INV_HS, (ulong)(priv->reg_base + LCDIFV3_CTRL_SET)); /* SEC MIPI DSI specific */ - writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - + //writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); + //writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); } [2024.5.15] If you are uing simple-panel.c, need use below patch to set display timing from panel to lcdif controller. diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c index f9281d5e83..692c96dcaa 100644 --- a/drivers/video/simple_panel.c +++ b/drivers/video/simple_panel.c @@ -18,12 +18,27 @@ struct simple_panel_priv { struct gpio_desc enable; }; +/* define your panel timing here and + * copy it in simple_panel_get_display_timing */ +static const struct display_timing boe_ev121wxm_n10_1850_timing = { + .pixelclock.typ = 71143000, + .hactive.typ = 1280, + .hfront_porch.typ = 32, + .hback_porch.typ = 80, + .hsync_len.typ = 48, + .vactive.typ = 800, + .vfront_porch.typ = 6, + .vback_porch.typ = 14, + .vsync_len.typ = 3, +}; + @@ -100,10 +121,18 @@ static int simple_panel_probe(struct udevice *dev) return 0; } +static int simple_panel_get_display_timing(struct udevice *dev, + struct display_timing *timings) +{ + memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); + + return 0; +} static const struct panel_ops simple_panel_ops = { .enable_backlight = simple_panel_enable_backlight, .set_backlight = simple_panel_set_backlight, + .get_display_timing = simple_panel_get_display_timing, }; static const struct udevice_id simple_panel_ids[] = { @@ -115,6 +144,7 @@ static const struct udevice_id simple_panel_ids[] = { { .compatible = "lg,lb070wv8" }, { .compatible = "sharp,lq123p1jx31" }, { .compatible = "boe,nv101wxmn51" }, + { .compatible = "boe,ev121wxm-n10-1850" }, { } }; [2024.7.23] Update patch for L6.6.23(Uboot2023)

The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products. It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket. LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini 32-bit 64Gb/8GB dual rank, dual-channel device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano 16-bit 32Gb/4GB dual rank, single-channel device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus 32-bit 64Gb/8GB dual rank, dual-channel device with 17-row addresses (R0-R16) 1, 2 LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 24Gb/3GB MT53B768M32D4NQ-062 WT:B (Micron) 15 32Gb/4GB MT53D1024M32D4DT-046 AAT:D (Micron) 14 4Gb/512MB IS43LQ16256B-062BLI (ISSI) 5, 14 8Gb/1GB IS43LQ32256B-062BLI (ISSI) 5, 14 i.MX 8M Mini 16Gb/2GB MT53D512M32D2DS-053 WT:D (Micron) 15 16Gb/2GB M56Z16G32512A (ESMT) 5, 14 32Gb/4GB MT53E1G32D2FW-046 WT:A (Micron) 5, 14 64Gb/8GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 14 i.MX 8M Nano 16Gb/2GB C1612PC2WDGTKR-U (Kingston) 15 32Gb/4GB MT53E2G32D4DT-046 AIT:A (Micron) 5, 13, 15 8Gb/1GB MT53D512M32D2DS-053 WT:D (Micron) 13, 15 i.MX 8M Plus 48Gb/6GB MT53E1536M32D4DT-046 WT:A (Micron) 15 64Gb/8GB MT53E2G32D4DE-046 AUT:C (Micron) 5, 14 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table: Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode. DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini 32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano 16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus 32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 DDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 32Gb/4GB 4x MT40A512M16JY-083EAAT (Micron) 15 i.MX 8M Mini 16Gb/2GB 2x MT40A512M16LY-075:E (Micron) 15 i.MX 8M Nano 16Gb/2GB 1x MT40A1G16RC-062E:B (Micron) 15 i.MX 8M Plus 64Gb/8GB 4x MT40A1G16RC-062E:B (Micron) 15 16Gb/2GB NT5AD512M16C4-JRI (Nanya) 14 DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus i.MX 8M Plus does not support DDR3L DDR3L - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Validated part number (vendor) Notes i.MX 8M Quad 16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 i.MX 8M Mini 16Gb/2GB 4x MT41K256M16TW-107 AAT (Micron) 14 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed May 16th 2024 Note 15: Part is obsolete. Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715

Customer can force PCIE to work at GEN1/GEN2 mode if PCB layout is not good. Pls refer to: linux/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt:40:- fsl,max-link-speed: Specify PCI gen for link capability. Must be '2' for i.MX8M: diff --git a/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi b/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi index f4dcf7ac3c98..262db6f93cb2 100755 --- a/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi @@ -1314,7 +1314,7 @@ <&clk IMX8MQ_CLK_PCIE1_AUX>, <&clk IMX8MQ_CLK_PCIE1_PHY>; clock-names = "pcie", "pcie_bus", "pcie_phy"; - fsl,max-link-speed = <2>; + fsl,max-link-speed = <1>; ctrl-id = <0>; power-domains = <&pcie0_pd>; status = "disabled"; @@ -1344,7 +1344,7 @@ <&clk IMX8MQ_CLK_PCIE2_AUX>, <&clk IMX8MQ_CLK_PCIE2_PHY>; clock-names = "pcie", "pcie_bus", "pcie_phy"; - fsl,max-link-speed = <2>; + fsl,max-link-speed = <1>; ctrl-id = <1>; power-domains = <&pcie1_pd>; status = "disabled"; diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c index 54459b52f526..a63de7e7bae0 100644 --- a/drivers/pci/dwc/pci-imx6.c +++ b/drivers/pci/dwc/pci-imx6.c @@ -1548,6 +1548,7 @@ static int imx_pcie_establish_link(struct imx_pcie *imx_pcie) u32 tmp; int ret; + dw_pcie_dbi_ro_wr_en(pci); /* * Force Gen1 operation when starting the link. In case the link is * started in Gen2 mode, there is a possibility the devices on the i.MX8/8x: fsl-imx8dx.dtsi pcieb: pcie@0x5f010000 { /* * pcieb phyx1 lane1 in default, adjust it refer to the * exact hw design. */ . . . . . power-domains = <&pd_pcie>; fsl,max-link-speed = <1>; /* 3=gen3, 1=gen1 */ hsio-cfg = <PCIEAX2PCIEBX1>; hsio = <&hsio>; ctrl-id = <1>; /* pcieb */ cpu-base-addr = <0x80000000>; status = "disabled"; }; pci-imx6.c @@ -1799,6 +1799,7 @@ static int imx_pcie_establish_link(struct imx6_pcie *imx6_pcie) u32 tmp; int ret; + dw_pcie_dbi_ro_wr_en(pci); /* * Force Gen1 operation when starting the link. In case the link is * started in Gen2 mode, there is a possibility the devices on the @@ -1870,11 +1871,13 @@ static int imx_pcie_establish_link(struct imx6_pcie *imx6_pcie) dev_info(dev, "Link: Gen2 disabled\n"); } + dw_pcie_dbi_ro_wr_dis(pci); tmp = dw_pcie_readl_dbi(pci, PCIE_RC_LCSR); dev_info(dev, "Link up, Gen%i\n", (tmp >> 16) & 0xf); return 0; err_reset_phy: + dw_pcie_dbi_ro_wr_dis(pci); dev_dbg(dev, "PHY DEBUG_R0=0x%08x DEBUG_R1=0x%08x\n", dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0), dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG1));

Useful information about push buttons. Physical level. When there is a change of voltage level on P0-P7 pins, PCA9555PW will generate interrupt on INT pin. The driver (running on SoC) can read the status of P0-P7 pins via I2C (SCL/SDA pins) and generate separate interrupts for each of P0-P7 pins. This is why this driver acts as interrupt controller. Consider next configuration: One push button changes level on P4 pin, tempting PCA9555PW to generate interrupt. Interrupt from PCA9555PW is connected to GPIO5 IP-core (inside of SoC), and it uses line #9 of that GPIO5 module to notify CPU about interrupt. So we can say that PCA9555PW is cascaded to GPIO5 controller. GPIO5 also acts as interrupt controller, and it's cascaded to GIC interrupt controller. Device tree properties. The meaning of properties is as follows: interrupt-controller property defines that device generates interrupts; it will be needed further to use this node as interrupt-parent in each push button node. #interrupt-cells defines format of interrupts property; in our case it's 2 : 1 cell for line number and 1 cell for interrupt type interrupt-parent and interrupts properties are describing interrupt line connection Interrupt handling. CPU now is in interrupt context in GIC interrupt handler. From gic_handle_irq() it calls handle_domain_irq() , which in turn calls generic_handle_irq() . See Documentation/gpio/driver.txt for details. Now we are in SoC's GPIO controller IRQ handler. SoC's GPIO driver also calls generic_handle_irq() to run handler, which is set for each particular pin. See for example how it's done in omap_gpio_irq_handler() . Now we are in PCA9555PW IRQ handler. PCA9555PW IRQ handler calls handle_nested_irq() . Finally, gpio_keys_gpio_isr() is called. The following steps allow you to enable rgb led's and push buttons on 8MIC-RPI-MX8 board with i.MX 8M Mini Applications Processor Evaluation Kit (EVKB). You have to use a led driver and change the device tree. On the Host. Cloning the Linux kernel repository. Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone https://source.codeaurora.org/external/imx/linux-imx This guide will use the following commit which corresponds to Kernel 5.10.35-2.0. cd linux-imx/ git checkout -b RGB ef3f2cfc6010 Patching the device tree. Download the "0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch" file attached to this post and copy it into linux-imx directory, then apply the patch. cp 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch ~/linux-imx/ cd ~/linux-imx/ patch < 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch When prompted, select the file to patch: File to patch: arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts patching file arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk-8mic-revE.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk-8mic-revE.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. Compiling the Led driver. Obtain the leds-pca995x.h file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/include/linux/platform_data/leds-pca995x.h Copy it into the next path: cp leds-pca995x.h ~/linux-imx/include/linux Create a new directory. mkdir ~/linux-imx/PCA9955 Create a makefile. cd ~/linux-imx/PCA9955 vim Makefile KERNEL_ROOT?=~/linux-imx obj-m += leds-pca995x.o all: make -C $(KERNEL_ROOT) M=$(PWD) modules clean: make -C $(KERNEL_ROOT) M=$(PWD) clean Press the key "Esc" and then: :wq Obtain the leds-pca995x.c file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/drivers/leds/leds-pca995x.c Copy it into the next path: cp leds-pca995x.c ~/linux-imx/PCA9955 Obtain 0001-PCA9955BTW.patch file and copy it into the next path: cp 0001-PCA9955BTW.patch ~/linux-imx/PCA9955 Apply the patch. patch < 0001-PCA9955BTW.patch Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate .ko file. cd ~/linux-imx/PCA9955 make all Copy the .ko file to the EVK, for example with scp: scp leds-pca995x.ko root@192.168.100.105:/home/root NOTE: The linux version of .ko file must be the same as EVK. On the EVK. Switching the device tree. To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk-8mic-revE.dtb Partition_1/ Reboot the board. reboot Stop on u-boot and modify the .dtb file to use the device tree for 8mic board. u-boot=> editenv fdtfile edit: imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Saving Environment to MMC... Writing to MMC(1)... OK u-boot=> boot Installing a led driver. Execute the following command to load the led driver into the kernel. insmod leds-pca995x.ko And you will see something like: [ 249.359103] leds_pca995x: loading out-of-tree module taints kernel. [ 249.366864] ALL [ 249.368740] ALL 0 [ 249.370667] ALL 1 [ 249.372609] ALL 2 [ 249.374536] ALL 2 [ 249.376475] ALL 2 [ 249.378401] ALL 2 [ 249.380338] ALL 2 [ 249.382264] ALL 2 [ 249.384202] ALL 2 [ 249.386127] ALL 2 [ 249.388063] ALL 2 [ 249.389989] ALL 2 [ 249.391913] ALL 2 [ 249.393847] ALL 2 [ 249.395774] ALL 2 [ 249.397709] ALL 2 [ 249.399635] ALL 2 [ 249.401568] ALL 2 [ 249.403496] ALL 3 Turning on a Led. If you changed the device tree, you can turn on a led with the following command: echo 250 > /sys/class/leds/pca995x\:blue0/brightness To turn off a led: echo 0 > /sys/class/leds/pca995x\:blue0/brightness The red, blue and green leds can be turned on at different intensities provided. Testing the push buttons. If you changed the device tree, you can test the push buttons with the following command: evtest Select the correct number: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: 30370000.snvs:snvs-powerkey /dev/input/event1: sw_keys /dev/input/event2: gpio_ir_recv Select the device event number [0-2]: 1 And you will see: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sw_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 67 (KEY_F9) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Properties: Testing ... (interrupt to exit) Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------ Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------

1.overwrite the sources/meta-freescale/recipes-security/optee-imx with optee-imx.zip 2.add below code to conf/local.conf DISTRO_FEATURES_append += " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" MACHINE_FEATURES_append += "optee" DISTRO_FEATURES_append += "optee" IMAGE_INSTALL_append += "optee-test optee-os optee-client optee-examples" 3.bitbake optee-examples or bitbake imx-image-xxx You can directly install optee-examples_3.11.0-r0_arm64.deb in your device.

Symptoms When configure a gpio pin for a driver in the dts/dtsi file like below example, e.g. a-switch { compatible = "a-switch-driver"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_switch>; gpios = <&lsio_gpio1 1 GPIO_ACTIVE_HIGH>; status = "okay"; }; pinctrl_switch: switch_gpio { fsl,pins = < IMX8QXP_SPI2_SDO_LSIO_GPIO1_IO01 0x21 >; }; then you may get the error when request the gpio in the driver during the kernel boot up. Error message like this: a-switch: failed to request gpio a-switch: probe of a-switch failed with error -22 Linux version: L5.4.x Diagnosis Because the gpio_mxc_init function run before the function imx_scu_driver_init. The pm_domains for gpio is not ready before running mxc_gpio_probe, so gpio request will be failed. Solution There are two ways to resolve this issue 1. Build the driver as a module. i.e. select the driver in kernel’s menuconfig as “M”. Then , run “insmod” to load the driver after the kernel boot up. OR 2. Apply below patch, let gpio driver init after scu driver. diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c index 1dfe513f8fcf..52b5799040b3 100644 --- a/drivers/gpio/gpio-mxc.c +++ b/drivers/gpio/gpio-mxc.c @@ -892,7 +892,7 @@ static int __init gpio_mxc_init(void) return platform_driver_register(&mxc_gpio_driver); } -subsys_initcall(gpio_mxc_init); +device_initcall(gpio_mxc_init);

This note show how to use the open source gstreamer1.0-rtsp-server package on i.MX6QDS and i.MX8x to stream video files and camera using RTP protocol. The i.MX 6ULL and i.MX 7 doesn't have Video Processing Unit (VPU). Real Time protocol is a very common network protocol for delivering media over IP networks. On the board, you will need a GStreamer pipeline that encodes the raw video, adds the RTP payload, and sends over a network sink. A generic pipeline would look as follows: video source ! video encoder ! RTP payload ! network sink Video source: often it is a camera, but it can be a video from a file or a test pattern, for example. Video encoder: a video encoder as H.264, H.265, VP8, JPEG and others. RTP payload: an RTP payload that matches the video encoder. Network sink: a video sync that streams over the network, often via UDP. Prerequisites: MX6x o MX8x board with the L5.10.35 BSP installed. A host PC with either Gstreamer or VLC player installed. Receiving h.264/h.265 Encoded RTP Video Stream on a Host Machine Using GStreamer GStreamer is a low-latency method for receiving RTP video. On your host machine, install Gstreamer and send the following command: $ gst-launch-1.0 -v udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! videoconvert ! autovideosink sync=false Using Host PC: VLC Player Optionally, you can use VLC player to receive RTP video on a PC. First, in your PC, create a sdp file with the following content: stream.sdpv=0m=video 5000 RTP/AVP 96c=IN IP4 127.0.0.1a=rtpmap:96 H264/90000 After this, with the GStreamer pipepline on the device running, open this .sdp file with VLC Player on the host PC. Sending h.264 and h.265 Encoded RTP Video Stream GStreamer provides an h.264 encoding element by software named x264enc. Use this plugin if your board does not support h.264 encoding by hardware or if you want to use the same pipeline on different modules. Note that the video performance will be lower compared with the plugins with encoding accelerated by hardware. # gst-launch-1.0 videotestsrc ! videoconvert ! x264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Note: Replace <host-machine-ip> by the IP of the host machine. In all examples you can replace videotestsrc by v4l2src element to collect a stream from a camera i.MX8X # gst-launch-1.0 videotestsrc ! videoconvert ! v4l2h264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 i.MX 8M Mini Quad/ 8M Plus # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 i.MX6X The i.MX6QDS does not support h.265 so the h.264 can work: # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Using Other Video Encoders While examples of streaming video with other encoders are not provided, you may try it yourself. Use the gst-inspect tool to find available encoders and RTP payloaders on the board: # gst-inspect-1.0 | grep -e "encoder"# gst-inspect-1.0 | grep -e "rtp" -e " payloader" Then browse the results and replace the elements in the original pipelines. On the receiving end, you will have to use a corresponding payload. Inspect the payloader element to find the corresponding values. For example: # gst-inspect-1.0 rtph264pay Install rtp in your yocto different form L5.10.35 BSP, to install gstreamer1.0-rtsp-server in any Yocto Project image, please follow the steps below: Enable meta-multimedia layer: Add the following on your build/conf/bblayers.conf: BBLAYERS += "$"${BSPDIR}/sources/meta-openembedded/meta-multimedia" Include gstreamer1.0-rtsp-server into the image: Add the following on your build/conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server" Run bitbake and mount your sdcard. Copy the binaries: Access the gstreamer1.0-rtsp-server examples folder: $ cd /build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-rtsp-server/$version/build/examples/.libs Copy the test-uri and test-launch to the rootfs /usr/bin folder. $ sudo cp test-uri test-launch /media/USER/ROOTFS_PATH/usr/bin Be sure that the IPs are correctly set: SERVER: => ifconfig eth0 $SERVERIP CLIENT: => ifconfig eth0 $CLIENTIP Video file example SERVER: => test-uri file:///home/root/video_file.mp4 CLIENT: => gst-launch-1.0 playbin uri=rtsp://$SERVERIP:8554/test You can try to improve the framerate performance using manual pipelines in the CLIENT with the rtspsrc plugin instead of playbin. Follow an example: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test caps = 'application/x-rtp' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! queue max-size-buffers=0 ! imxv4l2sink sync=false Camera example SERVER: => test-launch "( imxv4l2src device=/dev/video0 ! capsfilter caps='video/x-raw, width=1280, height=720, framerate=30/1, mapping=/test' ! vpuenc_h264 ! rtph264pay name=pay0 pt=96 )" CLIENT: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test ! decodebin ! autovideosink sync=false The rtspsrc has two properties very useful for RTSP streaming: Latency: Useful for low-latency RTSP stream playback (default 200 ms); Buffer-mode: Used to control buffer mode. The slave mode is recommended for low-latency communications. Using these properties, the example below gets 29 FPS without a sync=false property in the sink plugin. The key achievement here is the fact that there is no dropped frame: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test latency=100 buffer-mode=slave ! queue max-size-buffers=0 ! rtph264depay ! vpudec ! imxv4l2sink

In some cases, i.MX board connect to different module. It has very tiny changes, such as just one gpio different driver strength. We can build an entire new software to handle this requirement. Here we introduce another way, using u-boot to modify the device tree(dtb) at runtime. Here is u-boot fdt command for How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709 run loadfdt fdt addr ${fdt_addr_r} fdt print /soc/bus/pinctrl/uart3grp fdt rm /soc/bus/pinctrl/uart3grp fdt print serial2 fdt set serial2 status disabled fdt print serial2 fdt print gpio4 fdt resize fdt mknode gpio4 gpio_hog_demo fdt set gpio4/gpio_hog_demo gpio-hog fdt set gpio4/gpio_hog_demo gpios <7 0> fdt set gpio4/gpio_hog_demo output-high fdt print gpio4 run mmcargs run loadimage booti ${loadaddr} - ${fdt_addr_r} root@imx8mmevk:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-5 ( |PCIe DIS ) out hi gpio-13 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-15 ( |cd ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/30210000.gpio, 30210000.gpio: gpio-38 ( |? ) out hi gpio-42 ( |reset ) out lo ACTIVE LOW gpio-51 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-80 ( |status ) out hi gpiochip3: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpio-117 ( |PCIe reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-135 ( |gpio_hog_demo ) out hi gpio-141 ( |spi1 CS0 ) out hi ACTIVE LOW gpio-149 ( |wlf,mute ) out hi ACTIVE LOW root@imx8mmevk:~# [ 33.758914] VSD_3V3: disabling dtc_utils-v1.6.1-win-x86_64.zip by msys2

Application Note AN13872 Enabling SWUpdate on i.MX 6ULL, i.MX 8M Mini, and i.MX 93 is available on www.nxp.com SWUpdate: Embedded Systems become more and more complex. Software for Embedded Systems have new features and fixes can be updated in a reliable way. Most of time, we need OTA(Over-The-Air) to upgrade the system. Like Android has its own update system. Linux also need an update system. SWUpdate project is thought to help to update an embedded system from a storage media or from network. However, it should be mainly considered as a framework, where further protocols or installers (in SWUpdate they are called handlers) can be easily added to the application. Mongoose daemon mode: Mongoose is a daemon mode of SWUpdate that provides a web server, web interface and web application. Mongoose is running on the target board(i.MX8MM EVK/i.MX8QXP MEK).Using Web browser to access it. Suricatta daemon mode: Suricatta regularly polls a remote server for updates, downloads, and installs them. Thereafter, it reboots the system and reports the update status to the server. The screenshot is SWUpdate scuricatta working with hawkbit server.

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

i.MX8MP USB PD realized

Enable PCIE function in Android12 BSP on i.MX8MM EVK

Running the SAI Low Power Audio Example using GStreamer - Using the i.MX 8M Plus

i.MX8MM RMII TXC OUTPUT

Demo code of lpddr4_mr_read for reading MR registers in DRAM

i.MX8 serials GPIO input and output setting tips

Add i.MX8MP LVDS driver in uboot

i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide

[i.MX8/8X/8M]Force PCIE to work at GEN1/2 mode

Enable RGB LED's and push buttons on 8MIC-RPI-MX8 board.

Porting MPU6050 on Android to realize auto rotation of screen

Enable SFTP on i.MX

Enable SSH on i.MX

Build optee-examples in yocto(hardkott)

i.MX8M/8X GPIO probe failed

Audio / Video trough Camera stream and gstreamer on i.MX6DQS and i.MX8

u-boot runtime modify Linux device tree(dtb)

Debugging method of linux kernel

How to use gpio-hog demo

SWUpdate OTA i.MX8MM EVK / i.MX8QXP MEK