We are pleased to announce that Config Tools for i.MX v16.1 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) • Clocks – Disabling enabled clock outputs that have settings with shared bit-fields after reopening the configuration is fixed. – Clock slices with multiple outputs are supported. • TEE – An incorrect number of the MPU region attributes shown for the configuration of RT1180 is fixed. – An incorrect domain visibility and tab names when DAC is disabled on RT1180 is fixed.

Add SSI_ASRC_P2P support for imx6 based on Kernel 3.0.35.

Question: Two boards are used and practically identical - one using the i.MX6Solo, the other is using a Dual. The sw settings in both cases are identical (except IOMUX addresses). On the i.MX6Solo they do not see any packet loss, on the i.MX6Dual they do. I recommended modifying the MTU size, but this also did not help. So here my two questions: 1)      is there still some hw difference between the Ethernet block on the Solo and the Dual/Quad? 2)      They run the AHB at only 100MHz. Could that be a problem? If not, why do the two chips behave so differently? To increase the AHB clock to 133 MHz.appears to solve the packet corruption issue. Is the 100 MHz AHB clock really the root cause. Answer: The DualLite/Solo and SoloLite contain different ethernet controllers. The DL/S has a 1000M controller which requires the AHB bus to be greater than 125MHz, while the SL has a 100M controller. As the question was about the Solo and the Dual and both use the Gigabit Ethernet block I assume that both will require a minimum AHB clock of 125MHz.

Question: The description of the IOMUXC_GPR2 register is wrong. It contains exactly the same description as the LDB_CTRL register. The bits in the LDB_CTRL register work as advertised opposed to the GPR2 register. Answer: This is intentional. The LDB_CTRL description in the RM says "The register is implemented in the IOMUX Controller block (IOMUXC), as the register IOMUXC_GPR2.". And you will notice the two registers have the same address.

To get the FSL amrdecoder building and running on imx53 in 11.09 BSP: TIP: During debug for creation of these patches -> On the target, I had to make sure I had all the amr decoder libraries present, or it just wouldn't work. I narrowed those down by deleting "rm /root/.gstreamer-0.10/registry.arm.bin" and rerunning gst-inspect to rescan the plugins. With GST_DEBUG=3 I could see what libraries were missing and copied them over. But once everything was in place, it just worked. gst-launch playbin2 uri=file:////media/sd/media_file_with_amr_audio_encoding.3gp Attached are the new .spec files and patch files to get this to work. Regards, Randy

Q: To minimize i.MX6DL power consumption at stop mode, but needs i.MX6DL to wake-up by USB resume signal from Host PC. Can LDO_2P5(VDDHIGH_CAP) be powered off at stop mode in order to resume i.MX6DL by a USB resume signal that Host PC sends to i.MX6DL USBOTG(us as device mode only)? In other words, can USB OTG detect resume signal from Host PC and generate wakeup interrupt during stop mode with following LDO condition? -          LDO_USB is enabled and powered by USB_OTG_VBUS. -          LDO_2P5 is disabled during stop mode. -          LDO_1P1 is enabled during stop mode. The system uses LPDDR2, hence LDO_2P5 can be powered off at stop mode(I know this is not allowed for DDR3 as DDR IO need 2P5 as pre-driver). Actually tested on SDP, the system can not be resumed without LDO_2P5 as DDR IO need 2P5 for DDR3. A: Please note that disabling the LDO_2P5 supply, you are also disabling the DRAM, as the DRAM pre-drivers are powered by this supply(!). SDCKE is pulled down on the board, and it ensures that the DRAM is in proper state during DSM without LDO_2P5 power. we recommend to keep LDO_2P5 on at any mode(include DSM mode). ldo_2p5 is also one of power for USB phy.   4.3.2.2 LDO_2P5 The LDO_2P5 module implements a programmable linear-regulator function from VDD_HIGH_IN. The LDO_2P5 supplies the SATA Phy, USB Phy, LVDS Phy,   Actually I have tested on SDP, but we cannot resume the system without LDO_2P5 as DDR IO need 2P5 for DDR3.

The purpose of this document is to provide extended guidance for the selection of compatible LPDDR4 memory devices that are supported by the i.MX 91 series of processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity.   LPDDR4 - Maximum Supported Densities SoC Max Data bus width Maximum density Assumed memory organization Notes i.MX 91 (i.MX 91xx) 16-bit 16 Gb / (2 GB) single rank, single channel device with 17-row addresses (R0 - R16) 1, 2, 3   LPDDR4 - List of Validated Memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes i.MX 91 16 Gb / (2 GB) Micron MT53E1G16D1FW-046 AAT:A MT53E1G16D1ZW-046 AAT:C 5    2 Gb / (256 MB)  Winbond  W66BP6NBHAHJ 4 8 Gb / (1 GB) Nanya NT6AN512M16AV-J1I   4 Gb / (512 MB) Nanya NT6AN256M16AV-J1I 4 8 Gb / (1 GB) ISSI IS43LQ16512B-046BLI 4 12 Gb / (1.5 GB) Micron MT53E768M16D1ZW-046 4 16 Gb / (2 GB) Intelligent Memory IMAG16L4KBBG 4 2 Gb / (256 MB) Nanya NT6AN128M16AV-J1 4 4 Gb / (512 MB) UniIC SCB11N4G160BF-04ZI 4 4 Gb / (512 MB) ISSI IS43LQ16256B-053BLI 4 4 Gb / (512 MB) Winbond W66CP6RBHAHJ 4     Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences. NOTE: LPDDR4 devices from certain memory vendors may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low-speed operation is planned in the use case, please consult with the memory vendor about the configuration aspects and possible customization of the memory device so correct functionality is ensured. Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4B (LPDDR4). 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 SoC also supports dual rank single channel devices therefore, 16Gb/2GB density can be also achieved by using a dual rank single channel device with 16-row addresses (R0 - R15). Note 4: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 5: The memory part number is not recommended for new designs and superseded by a new part number

Q:Is there an issue using odd DIV_SELECT values? When setting the CPU clock (maybe others also) in uboot, the code will only use even valuesfor the DIV_SELECT field. There is nothing in the Reference Manual or Errata that indicates only even values can be used for this field. There were 2 SR's that had conflicting answers and we are trying to determine what can be used. The CPU freq setting trying to be achieved is 996MHz. With a 24MHz source, you need 24MHz x 41.5 = 996MHz. Since the DIV_SELECT is x2, a value of 83 would be needed. A: Below is the DIV_SELECT description of ARM PLL, since the Fin is 24MHz, so there is no odd issue of DVI_SELECT, as 24 / 2 = 12MHz. Such as for 996M, this value is 83, that is fine. "This field controls the pll loop divider. Valid range for divider value: 54-108. Fout = Fin * div_select/2.0." This document was generated from the following discussion: mx6Q PLL Setting

The refine to TV mode of R10.3.1 causes dual video function fail. The attached patch recovers dual video function. Attached dual_video.patch only work for RGB output (HDMI support). For legacy TVout (YUV output), the extra patch is necessary, see the attached "legacy_tvout.zip". Refer to Dual video with single UI on i.MX53 SMD with Android R10.4  for setup.

The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system?

GUI Guider version:  1.9.x, 1.10.x LVGL version: v8.x.x , v9.x.x Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Target  software requirements:  BSP 6.6 or higher  Hardware requirements: FRDM i.MX 93 Development Board i.MX 93 Evaluation Kit FRDM i.MX 91 Development Board i.MX 91 Evaluation Kit i.MX95  Steps: 1. Export your project from the folder GUI-Guider-Projects to your Linux PC. Chavira_0-1769722552100.png 2. Build an image for iMX9 using The Yocto Project. Based on iMX Yocto Porject Users Guide set directories and download the repo a. Based on iMX Yocto Porject Users Guide set directories and download the repo $ mkdir imx-bsp-6.6 $ cd imx-bsp-6.6 $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $ repo sync Use distro fsl-imx-xwayland and select machine imx93evk and use this commnad with a build folder name: $ MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh - b bld-imx93evk b. Use bitbake command to start the build process. Also, add the -c populate_sdk to get the toolchain. $ bitbake imx-image-full -c populate_sdk  c. Install the Yocto toolchain located on <build-folder>/tmp/deploy/sdk/.  $ sudo sh ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh d. Install ninja utility on the build host $ sudo apt update $ sudo apt upgrade -y $ sudo apt install ninja-build   3. Once your Yocto SDK has been generated and installed, you can build the required binaries using the script attached to this post.      a) Place the script           Copy the script into the same directory where your meta-gui-guider folder is located.      b) Run the script to build the Gui Guider binary           The script includes several options to rebuild, clean, or use a different toolchain in                case you are working with a Yocto SDK version other than the default one (6.6-scarthgap). Build Options Build the Gui Guider binary using the default Yocto SDK ./guider_1.9_project_builder.sh Build the Gui Guider binary using another Yocto SDK version ./guider_1.9_project_builder.sh -t <yocto_sdk_path>/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake Prepare the source code before building ./guider_1.9_project_builder.sh -p Clean the previous build and recompile (Use -t if needed to specify a different toolchain) ./guider_1.9_project_builder.sh -c   4. The generated Gui Guider binary can be found at the following path: /meta-gui-guider/recipes-graphics/gui-guider/gui-guider/build/gui_guider Copy this binary to your board using either USB or SCP, and then execute it directly on the target device.   Using this method provides the flexibility to modify the source code before compilation. This is important because, by default, some configuration options are not available when using Gui Guider directly or when compiling inside Yocto. If you encounter any issues during this process, please open a new thread so we can assist you. Best regards, Chavira

This patch series enables the external 3.3 V and 5 V power rails used by the Raspberry Pi expansion connector on the i.MX93-QSB, i.MX93-FRDM, and i.MX91-FRDM boards. These regulators were already defined in the device tree but left disabled by default. By activating them, the RPI-compatible expansion header can properly power external modules, HATs, and add‑on boards. Changes by board: i.MX93-QSB Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   i.MX93-FRDM Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   i.MX91-FRDM Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   Purpose: Provide proper power to the Raspberry Pi compatible expansion port. Improve hardware compatibility for users attaching external HATs or modules. Align all i.MX9 reference boards to use a consistent power‑tree configuration for the RPI connector.

We are pleased to announce that Config Tools for i.MX v25.12 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) DDR tool – Support for detecting multiple boards connected to the host system is added. – Automatic detection and selection of newly connected COM ports is implemented. – A Connection Test option to validate connectivity before running tests on the target is introduced. – i.MX 93 EVK LP4 configuration is added. – Training execution time information for i.MX 95 and i.MX 943 is included in logs. – Bus signal naming in the UI to align with i.MX pin naming conventions is consolidated. – CA bus values for i.MX943 with LPDDR4 are updated. – DRAM density calculation for i.MX 95 and i.MX 943 with LP4/4x is corrected. – Incorrect calculation of number of banks for i.MX 8M with DDR3L is fixed. – CS1_BNDs calculation for i.MX 91 is corrected. SerDes tool – i.MX 943 RFP support is added. System Manager – The ability to export user configuration in the CFG format is added. – Information about atomic resources to the Details view is added. – Generation and configuration of the config_fusa.h file is supported. – Resource and template assignment is improved. – Grayed-out resource assignments for unavailable configuration parameters in the Resources view are implemented. – Validation of configuration and user input is improved. – Problem decorators to the System and Boot view are added. – Design of the Boot and Details view is improved. – 5600 MT/s for i.MX 95 and i.MX 943 with LPDDR5 is enabled. – LP4/4x settings for DDR_SDRAM_ZQ_CNTL for i.MX 95 and i.MX 943 are updated. – Dual-rank configurations for i.MX 91 and i.MX 93 are updated. – LP4/4x configuration to support non-binary densities for i.MX 95 and i.MX 943 is updated. – Support for non-binary aligned LP4 density for i.MX 91 is added. – FRDM board support (LPDDR4X 15x15 at 4000 MT/s) for i.MX 95 is added. – Timing file discrepancies for i.MX 8MN with DDR3L are fixed. – Issue where changing PHY log level did not update generated code is fixed.

LSIO_GPIO0_IO0x toggling on i.MX8QM Issue customer met: Customer met LSIO_GPIO0_IO0x not toggling on i.MX8QM, they are working through the software on their board, part of that involves getting a few GPIO pins working. They have been using several GPIO pins for a while now, we have some simple toggles and some others where we bit bang i2c, all of those have worked fine. However, They have not been able to get 3 pins to either read or set successfully at all: LSIO_GPIO0_IO00 (SIM0_CLK) LSIO_GPIO0_IO01 (SIM0_RST) LSIO_GPIO0_IO02 (SIM0_IO) 1\ Reproduce on our i.MX8QM EVK board  a. Check the hardware connection Check the LSIO_GPIO0_IO00 (SIM0_CLK), LSIO_GPIO0_IO01 (SIM0_RST) and LSIO_GPIO0_IO02 (SIM0_IO) connection in our i.MX8QM EVK board. In the default design in NXP i.MX8QM EVK board, the pins SIM0_CLK, SIM0_RST and SIM0_IO connect to the SIM CARD on the base board. Rita_Wang_0-1763386260542.png   Rita_Wang_1-1763386260561.png   Rita_Wang_2-1763386260597.png     b. To make these pins work as GPIO pins In the default pins mux, default pins mux on the SIM0, to make these pins work as GPIO, need to mux them to the GPIO functions. SIM0_CLK (SIM0_CLK)   Rita_Wang_3-1763386260613.png   SIM0_RST (SIM0_RST) Rita_Wang_4-1763386260627.png   SIM0_IO (SIM0_IO) Rita_Wang_5-1763386260641.png     c. In the source code change these pins mux to GPIO configuration: Defalt setting for these pins : linux-imx/arch/arm64/boot/dts/freescale/imx8qm-mek.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   pinctrl_sim0: sim0grp {                              fsl,pins = <                                            IMX8QM_SIM0_CLK_DMA_SIM0_CLK           0xc0000021                                            IMX8QM_SIM0_IO_DMA_SIM0_IO                 0xc2000021                                            IMX8QM_SIM0_PD_DMA_SIM0_PD               0xc0000021                                           IMX8QM_SIM0_POWER_EN_DMA_SIM0_POWER_EN                         0xc0000021                                            IMX8QM_SIM0_RST_DMA_SIM0_RST            0xc0000021                              >;               }; Linux dts should set them to GPIO0 functions:               IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021               IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021               IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 Build the source code, download the images to board, test on the SIM pins to see if these pins can work or not. Test on the J45 pins 3,5,6. Rita_Wang_6-1763386260714.png   Test the SIM_CLK as an example: Test commands in Linux echo 480 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction #output high echo 1 > /sys/class/gpio/gpio480/value #measure the PINs #output low echo 0 > /sys/class/gpio/gpio480/value #measure the PINs Found these pins can not toggling well. 2\ Go next further test and consideration Foud the SCU_GPIO0_00, SCU_GPIO0_01, SCU_GPIO0_02 are also configurate as GPIO function in the SCFW,  in the default setting for the SC_P_SCU_GPIO0_00is the function GPIO0_00 , and when setting the SIM0_CLK to GPIO0_00 function then the GPIO0_00 can not work normally. So if setting the SIM0_CLK as GPIO0_00 function, then we need to set the SC_P_SCU_GPIO0_00 this PIN to others function, so that no conflict of them. Even no use the pin SC_P_SCU_GPIO0_00 in hardware, we also need to set them to others function to avoid the conflict. SCU_GPIO Pins mux: SCU_GPIO0_00 (SCU_GPIO0_00) Rita_Wang_7-1763386260735.png   SCU_GPIO0_01 (SCU_GPIO0_01) Rita_Wang_8-1763386260755.png   SCU_GPIO0_02 (SCU_GPIO0_02)       Rita_Wang_9-1763386260774.png   Tested the PINs "SIM0_CLK, SIM0_IO, SIM0_RST" on iMX8QM MEK with base board. All of them works fine.  The key points are already listed. VDD_SIM0 power should be supplied (It is 3.3V on MEK from PF8100 LDO) Rita_Wang_10-1763386260858.png   Linux dts should set them to GPIO0 functions:     IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021     IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021     IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 The default IOMUX for PINs SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 should be changed from 0 to others.  Test on MEK, we used followed codes in SCFW board_init():     else if (phase == BOOT_PHASE_FINAL_INIT)     {         /* Configure SNVS button for rising edge */         SNVS_ConfigButton(SNVS_DRV_BTN_CONFIG_RISINGEDGE, SC_TRUE);           /* Init PMIC if not already done */         pmic_init();         pad_force_mux(SC_P_SCU_GPIO0_00, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_01, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_02, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);     }  Note: In SCFW, should also set SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 to other functions, because they are set to GPIO0_0x function default, if two PINs set to the same functions, such as SIM0_CLK_DMA pin and SCU_GPIO0_00 pin are set to GPIO0_00 together, the function will not work correctly.   Test commands in LInux: echo 480 > /sys/class/gpio/export echo 481 > /sys/class/gpio/export echo 482 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction echo out > /sys/class/gpio/gpio481/direction echo out > /sys/class/gpio/gpio482/direction #output high echo 1 > /sys/class/gpio/gpio480/value echo 1 > /sys/class/gpio/gpio481/value echo 1 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct high  ( 3V ) #output low echo 0 > /sys/class/gpio/gpio480/value echo 0 > /sys/class/gpio/gpio481/value echo 0 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct low ( 0V ) The test result is based on real measurement on iMX8QM MEK.  Rita_Wang_11-1763386260939.jpeg   Note: 1\In customer's side If still not work, To confirm the issue, please suggest customer build SCFW with parameter "-m", then use followed commands to dump the IOMUX registers: md 0x41F80000 1 md 0x41F80040 1 md 0x41F80080 1 md 0x41F82140 1 md 0x41F82180 1 md 0x41F83000 1   The "md" command should run from SCFW debug UART, not linux/uboot UART. 2\Make sure the hardware in customer's side VDD_SIM0 power should be supplied .    

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33 core. This patch is based on lpuart_edma example.   Hardware test point: Zhiming_Liu_0-1745308428114.png   You will get such log from LPUART2 if we enter 3 on keyboard LPUART EDMA example Send back received data Echo every 8 characters 33333333   Modify M33 debug console from LPUART1 to LPUART2 is similiar.

imx7 supports TRULY-WVGA-TFT3P5581E display, the connector is J30, which is a connector on the imx7d board, normally, one can find the part number from BOM file, but imx7 Sabre-SDB board  BOM file missed this information. got connector information from expert team as below: The connector manufacture’s part number is: DF40C-24DS-0.4V(51)   For more detailed information about sabre board information information is available from nxp.com in the Design files for i.MX7Dual   For data sheet of this, which is under NDA, if you need it, pls create a salesforce case to get this, I couldn’t post this on public community.

Question: How to enable touch functions on LVDS1/SabreAI base board? what should be soldered in order to connect the signals to i2c what to add in the Linux kernel (board-mx6q_sabreauto.c) BTW.: Why did we leave these disconnected? Is there any conflict on i2c? Answer: You can mount R305 and R306 to support touch on LVDS1, no code modification was needed. The only limitation is that the two LVDS's touch can't be connected to same I2C port, because they are using the same I2C address. Question: How is this working because the touch interrupt signal from LVDS1 called LCD1_TOUCH_INT_B is connected to pin21 on J44 on base board which is left floating (TP1) on CPU card P1A connector? Are both LVDS needed to work in the same time. Answer: That's the problem, the LVDS1 touch interrupt pin hasn't been connected to IMX6 CPU. Maybe you can use the SabreSD board, the two touch are ready on that board.

Attached is the Kernel image needed to construct the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Hi all !      I found a problem, wiif connection issue .  When I connect to WiFi hotspots, reported a warning ！     <4>RTL871X: assoc success <4>------------[ cut here ]------------ <4>WARNING: at net/wireless/sme.c:482 __cfg80211_connect_result+0x2f4/0x32c() <4>Modules linked in: 8188eu <4>[<c0054044>] (unwind_backtrace+0x0/0x138) from [<c008c1b8>] (warn_slowpath_common+0x4c/0x64) <4>[<c008c1b8>] (warn_slowpath_common+0x4c/0x64) from [<c008c1ec>] (warn_slowpath_null+0x1c/0x24) <4>UpdateHalRAMask8188EUsb => mac_id:0, networkType:0x0b, mask:0x000fffff <4>     ==> rssi_level:0, rate_bitmap:0x000ff015 <4>[<c008c1ec>] (warn_slowpath_null+0x1c/0x24) from [<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) <4>[<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) from [<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) <4>[<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) from [<c0686ec0>] (cfg80211_event_work+0x24/0x54) <4>[<c0686ec0>] (cfg80211_event_work+0x24/0x54) from [<c00a66f0>] (process_one_work+0x12c/0x494) <4>[<c00a66f0>] (process_one_work+0x12c/0x494) from [<c00a6bc8>] (worker_thread+0x170/0x3cc) <4>[<c00a6bc8>] (worker_thread+0x170/0x3cc) from [<c00aacbc>] (kthread+0x80/0x88) <4>[<c00aacbc>] (kthread+0x80/0x88) from [<c004d408>] (kernel_thread_exit+0x0/0x8) <4>---[ end trace 14efbc2d6eba2439 ]---       This document was generated from the following discussion: