This document shares how to porting specific mfg sdk to specific Linux version. Then this document introduce how to configure labtool.  mfg tool is used for wireless product rf test and calibration. The setup environment:  DUT: EVK: iw612 QFN-IPA V2 Driver version: Linux_5_15_32_IMX8_SD-UART-BT-IW612-18.99.1.p154.38-18.99.1.p154.38- MXM5X18364.p19_V1-MGPL Labtool Package: MFG-AW-IW61X-MF-BRG-U16-WIN-X86-1.0.0.39.1-18.80.1.p154.38 o Host: Host board: i.MX8mm-evk OS: i.MX8mm Linux 5.15.32 demo image

Introduction HTTP is a protocol used to enable communication between web browsers and servers. A secure variation of this protocol is HTTPS, which adds encryption to protect data exchanged between the client and the server. This ensures that even if someone intercepts the communication, they cannot understand the transmitted information. In embedded systems and MCU-based applications, libraries such as mbedTLS are commonly used to implement secure communication. These libraries rely on cryptographic keys and digital certificates. For production environments, certificates are typically signed by a Certificate Authority (CA), which guarantees their authenticity and allows web browsers to trust the connection. However, when a certificate is generated manually (self-signed), web browsers do not inherently trust it. Despite this, self-signed certificates are a practical option for internal or development use cases, since the communication remains encrypted. Additionally, it is possible to configure client devices to trust these certificates when required.   Download OpenSSL First, verify whether OpenSSL is installed on your system. If not, it must be downloaded and installed. To check if OpenSSL is already installed, run next line in command prompt: openssl --version If the command is not recognized, OpenSSL is not installed. If OpenSSL is not already installed on your system, you can easily find installation instructions by searching the web for your specific operating system. There are many reliable step‑by‑step guides available for Windows, Linux, and macOS that explain how to download, install, and verify OpenSSL properly. Following an up‑to‑date guide for your OS will help ensure the installation is completed correctly and securely.   Preparation Select a folder where all keys and certificates will be stored. Open a command prompt in this folder and proceed with the following steps.   Create Keys NOTE: Please replace %%Name%% according to your preference. Create a private key for the Server Certificate openssl genrsa -out %%KeyName%%.key 2048 Create a private key to simulate Certificate Authority (CA) openssl genrsa -out %%CAKeyName%%.key 2048   Create Certificate Authority Generate a self-signed CA certificate: openssl req -x509 -new -nodes -key %%CAKeyName%%.key -sha256 -days 3650 -out %%CAName%%.crt   Create Server Certificate Config file to request certificate Create a configuration file named %%ConfigFileName%%.cnf using the following template, this can be created with Notepad. [req] default_bits = 2048 prompt = no distinguished_name = dn req_extensions = v3_req [dn] C=%%Country%% ST=%%State%% L=%%City%% O=%%Owner%% OU=%%Division%% CN=%%CommonName%% [v3_req] subjectAltName = @alt_names [alt_names] IP.1 = %%ServerIP%% Generate Certificate Signing Request (CSR) openssl req -new -key %%KeyName%%.key -out %%CertificateRequestName%%.csr -config %%ConfigFileName%%.cnf Sign Certificate with simulated CA openssl x509 -req -in %%CertificateRequestName%%.csr -CA %%CAName%%.crt -CAkey %%CAKeyName%%.key -CAcreateserial -out %%CertificateName%%.crt -days 365 -extensions v3_req -extfile %%ConfigFileName%%.cnf   Prepare to use with mbedTLS Convert private Key to DER (Distinguished Encoding Rules) openssl rsa -in %%KeyName%%.key -outform DER -out %%KeyName%%_key.der Convert Certificate to DER (Distinguished Encoding Rules) openssl x509 -in %%CertificateName%%.crt -outform DER -out %%CertificateName%%.der Convert Key DER to array in a source file xxd -i %%KeyName%%_key.der > %%KeyName%%_key.c Convert Certificate DER to array in a source file xxd -i %%CertificateName%%.der > %%CertificateName%%_cert.c   Install CA Certificate (Optional – Avoid Browser Warnings) To prevent browser warnings, install the CA certificate on the client device (PC, phone, etc.). Double-click the CA certificate file (.crt). Click Install Certificate. Select Local Machine. Choose Place all certificates in the following store. Click Browse and select Trusted Root Certification Authorities. Click Next → Finish. After this step, the system will trust certificates signed by this CA.

Introduction   In a previous article, we demonstrated how to import an RFC3394-wrapped key blob into ELS by manually performing the following operations: Deriving NXP_DIE_KEK_SK using CKDF-SP800-108 Importing the wrapped blob with mcuxClEls_KeyImport_Async() Deleting the temporary KEK after import While this approach provides full visibility into the underlying ELS operations, applications using the PSA Crypto API can achieve the same result with significantly less code. This article demonstrates how to use psa_import_key() together with PSA_KEY_LOCATION_S50_RFC3394_STORAGE to import a wrapped key blob stored in OTP. The PSA Oracle driver transparently handles the secure key loading sequence, including KEK derivation, key unwrapping, ELS slot management, and cleanup. Prerequisites FRDM-RW612 Key blob wrapped using RFC3394 format using HSM_STORE_KEY Key blob programmed to OTP fuses using LoadKeyBlob command. Required Headers: #include "mcux_els.h" #include "psa/crypto.h" #include "mcuxClPsaDriver_Oracle_Interface_key_locations.h" #include "fsl_romapi_otp.h" Step 0 – Read the Wrapped Key Blob from OTP The example reads the blob directly from OTP memory. static psa_status_t read_blob_from_otp(uint8_t *blob_data, uint32_t blob_length, uint32_t starting_fuse_index) { status_t otp_status; uint32_t num_fuse_words = blob_length / 4u; PRINTF("Reading %d fuse words starting from index %d\n", num_fuse_words, starting_fuse_index); otp_status = otp_init(DEFAULT_SYSTEM_CLOCK); if (otp_status != kStatus_Success) { PRINTF("Error: otp_init failed: 0x%x\n", otp_status); return PSA_ERROR_HARDWARE_FAILURE; } for (uint32_t i = 0u; i < num_fuse_words; i++) { uint32_t fuse_word = 0u; otp_status = otp_fuse_read(starting_fuse_index + i, &fuse_word); if (otp_status != kStatus_Success) { PRINTF("Error: Failed to read fuse word %d, status: 0x%x\n", starting_fuse_index + i, otp_status); return PSA_ERROR_HARDWARE_FAILURE; } /* Store fuse word as 4 bytes in little-endian order */ blob_data[i * 4u + 0u] = (uint8_t)((fuse_word >> 0u) & 0xFFu); blob_data[i * 4u + 1u] = (uint8_t)((fuse_word >> 8u) & 0xFFu); blob_data[i * 4u + 2u] = (uint8_t)((fuse_word >> 16u) & 0xFFu); blob_data[i * 4u + 3u] = (uint8_t)((fuse_word >> 24u) & 0xFFu); PRINTF(" Fuse[%d] = 0x%08X\n", starting_fuse_index + i, fuse_word); } PRINTF("Blob data read from OTP successfully\n"); return PSA_SUCCESS; } Each fuse word contains four bytes.   These words are assembled into a contiguous buffer: blob_data[i * 4 + 0] = (fuse_word >> 0) & 0xFF; blob_data[i * 4 + 1] = (fuse_word >> 8) & 0xFF; blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF; blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF; The resulting buffer contains the RFC3394 wrapped key. Step 1 – Configure PSA Key Attributes Before importing the blob, PSA key attributes must describe how the key should be managed. The most important configuration is the key location: psa_set_key_lifetime( &attributes, PSA_KEY_LIFETIME_FROM_PERSISTENCE_AND_LOCATION( PSA_KEY_PERSISTENCE_VOLATILE, PSA_KEY_LOCATION_S50_RFC3394_STORAGE)); The PSA_KEY_LOCATION_S50_RFC3394_STORAGE location informs the Oracle driver that: The provided data is an RFC3394-wrapped key blob. The blob requires unwrapping before use. NXP_DIE_KEK_SK must be derived automatically during key loading. In this example we used an AES 128-bit key. The key type and size must match the wrapped key: psa_set_key_type(&attributes, PSA_KEY_TYPE_AES); psa_set_key_bits(&attributes, 128); Usage permissions are then assigned: psa_set_key_usage_flags( &attributes, PSA_KEY_USAGE_ENCRYPT | PSA_KEY_USAGE_DECRYPT); Finally, specify the algorithm: psa_set_key_algorithm( &attributes, PSA_ALG_ECB_NO_PADDING); Step 2 – Import the Wrapped Blob The blob is imported using a single PSA API call: psa_import_key( &attributes, blob_data, blob_length, &key_handle); For developers familiar with the low-level ELS implementation, this single call effectively replaces: derive_nxp_die_kek_sk() import_wrapped_key_blob() delete_key_from_slot() At this point, PSA stores the wrapped blob and returns a key handle: psa_key_id_t key_handle; The returned handle is subsequently used for cryptographic operations. Next Steps At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary  NXP_DIE_KEK_SK  has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software. The next step is to validate the imported key by performing the operation it was provisioned for.  For this example, we used AES-ECB encryption: psa_cipher_encrypt( key_handle, PSA_ALG_ECB_NO_PADDING, plaintext, sizeof(plaintext), ciphertext, sizeof(ciphertext), &ciphertext_length); Step 4 – Cleanup Once the key is no longer required, destroy it using: psa_destroy_key(key_handle); This releases the PSA key object and allows the Oracle driver to clean up any associated secure resources. Unlike the low-level ELS implementation, the application does not need to explicitly manage ELS keyslots.   PSA vs Direct ELS Implementation Direct ELS API PSA Crypto API Derive KEK manually Automatic Import blob manually Automatic Manage keyslots Managed by Oracle Delete temporary KEK Automatic Greater control Simpler application code Higher implementation effort Faster integration   Both approaches ultimately leverage the same secure hardware mechanisms within RW612. The PSA approach simply abstracts the underlying ELS operations behind a standardized cryptographic interface.

Introduction When provisioning secrets into an RW612 device, one common requirement is to securely load cryptographic keys without ever exposing the plaintext key material to application software. The EdgeLock Secure Subsystem (ELS) provides a secure mechanism for accomplishing this by allowing a wrapped key blob to be imported directly into an ELS key slot. The wrapping key is derived from device-unique root material inside the secure enclave. This article demonstrates how to: Derive the die-specific NXP_DIE_KEK_SK Import and unwrap the blob using ELS Store the resulting key in an ELS keyslot Remove temporary key material after provisioning The imported key never exists in plaintext in application memory, significantly reducing the attack surface compared to software-based key management. Understanding the Key Hierarchy Before looking at the implementation, it is useful to understand the different keys involved. NXP_DIE_MK_SK(NXP_DIE_INT_MK_SK) This is the 256-bit die master key derived from UDF and PUF using the KEYPROV operation. Characteristics: Die unique Not exportable Used as a root-of-trust Occupies key slot 0 on RW612 The key is loaded via dedicated secret key bus from PUF into ELS and XOR with a UDF derived key using KEYPROV, where it is used as a main key for further derivation of all remaining keys used by ROM. Applications never directly access the key material. NXP_DIE_KEK_SK This 256-bit key is derived from the master key using CKDF. It used for the wrapping of RFC3394 blobs stored in the OTP fuse region. Purpose: Acts as a Key Encryption Key (KEK) Used only for wrapping or unwrapping other keys Can be generated dynamically when needed In this example the KEK is stored temporarily in key slot 5. Imported Key The final key imported from the wrapped blob depends on how the blob was originally generated using the HSM provisioning flow (for example, via HSM_STORE_KEY and later loaded with loadkeyblob ). The imported key may represent a customer-defined security asset such as: Customer master key ( CUST_CKDFK_FLAG ) HKDF master key ( CUST_HKDFK_FLAG ) HMAC key ( CUST_HMACK_FLAG ) CMAC key ( CUST_CMACK_FLAG ) AES key ( CUST_AESK_FLAG ) Key unwrap-only key ( CUST_KUOK_FLAG ) Regardless of the key type, the import process remains the same. The key material is never exposed to application software during this process. Once imported, the key can be used directly by ELS for the cryptographic operations associated with its intended purpose, while remaining protected within the secure subsystem. Prerequisites FRDM-RW612 Key blob wrapped using RFC3394 format using HSM_STORE_KEY Key blob programmed to OTP fuses using LoadKeyBlob command. Required Headers: #include "mcux_els.h" #include "mcuxClEls.h" #include "mcux_pkc.h" #include "fsl_romapi_otp.h"   Step 1 – Derive NXP_DIE_KEK_SK The wrapped blob is protected using a Key Encryption Key (KEK). On RW612, the KEK can be derived from the device master key ( NXP_DIE_MK_SK ) using the official recipe constants. The derivation operation uses  masterKeyIdx = 0;  which corresponds to NXP_DIE_MK_SK  and produces a new key in the target slot. Example: static const uint8_t derivation_data[12] = { 0x94, 0xbe, 0x03, 0xac, 0x8b, 0x59, 0x32, 0x45, 0x11, 0x7f, 0xf8, 0x3f }; mcuxClEls_Ckdf_Sp800108_Async( masterKeyIdx, target_slot, targetKeyProperties, derivation_data);   Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);   Verify that the derived key slot becomes active before proceeding. Step 2 – Retrieve the Wrapped Blob The example reads the blob directly from OTP memory. otp_fuse_read(starting_fuse_index + i, &fuse_word); Each fuse word contains four bytes.   These words are assembled into a contiguous buffer:   blob_data[i * 4 + 0] = (fuse_word >> 0) & 0xFF; blob_data[i * 4 + 1] = (fuse_word >> 8) & 0xFF; blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF; blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF; The resulting buffer contains the RFC3394 wrapped key. Step 3 – Import and Unwrap the Blob Once the KEK exists and the blob has been retrieved, the import operation can begin. Configure ELS for RFC3394 import: mcuxClEls_KeyImportOption_t options; options.word.value = 0; options.bits.kfmt = MCUXCLELS_KEYIMPORT_KFMT_RFC3394; Perform the import: mcuxClEls_KeyImport_Async( options, blob_data, blob_length, kek_slot, target_slot); Parameters: Parameter Purpose blob_data Wrapped key blob blob_length Blob size kek_slot Slot containing NXP_DIE_KEK_SK target_slot Destination keyslot   Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); If successful, ELS unwraps the blob internally and places the resulting key into the destination key slot. No plaintext key material is exposed to software. Step 4 – Clean Up Temporary KEK After the blob has been imported, delete the temporary KEK: mcuxClEls_KeyDelete_Async(kek_slot); mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); This leaves only the imported key resident inside ELS. Next Steps At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary NXP_DIE_KEK_SK has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software. The next step is to validate the imported key by performing the operation it was provisioned for. Depending on the key type, this may include: AES encryption or decryption operations HMAC generation or verification CMAC generation or verification HKDF-based key derivation Importing or unwrapping additional key material Secure firmware or data encryption workflows A successful cryptographic operation confirms that: The blob was read correctly from storage. The NXP_DIE_KEK_SK derivation completed successfully. The RFC3394 unwrap operation succeeded. The key was installed into the intended ELS keyslot with the expected properties. For production deployments, this import mechanism provides a secure method for provisioning customer keys generated with the HSM tooling while ensuring that plaintext key material never leaves the ELS security boundary.

 

The purpose of this guide is to demonstrate the capability of the RW61x MCU generating an example application using Wi-Fi and Bluetooth features by combining the functionalities of the Wi-Fi shell and Bluetooth peripheral examples from the Zephyr repository using the FRDM-RW612.  The demo provides access to several Wi-Fi features controllable through a serial terminal while being able to test several GATT services from the Bluetooth Peripheral along the NXP's IoT Toolbox App.  Environment: MCUXpresso for Visual Studio Code. Zephyr v4.3.0. Zephyr SDK v0.17.4. FRDM-RW612. First, it is required to import both the Wi-Fi Shell and Bluetooth Peripheral examples to the workspace: Select "Import Example from Repository" in the Quickstart Panel. 2026-03-11_16-46-59.jpg Select the Wi-Fi shell example and click on the "Import" button: wifishell.png Select Bluetooth Peripheral example and click on the "Import" button: bluetoothperipheral.png Once the examples have been imported to your workspace, copy the content from the main file of the peripheral example to the main file of the Wi-Fi shell example in order to add the Bluetooth functionality and required initialization to the Wi-Fi example.  RomanVR_0-1776293609904.png In this step you may overwrite the contents from the main file of the integration project, as it only contains an empty main structure. Then copy the configurations from the "prj.conf" file of the peripheral example to the "prj.conf" file of the modified Wi-Fi Shell example to enable Bluetooth functionality and services. RomanVR_1-1776293644227.png IMPORTANT: Be careful of not erasing the settings in the prj.conf file of the modified example, just add the new ones below. Build the example by pressing the build button or by doing right click and then "Build Project" as shown: build.png Flash or debug the example. To flash it, right click over the project's name and select "Flash the Selected Target" and select the "zephyr.elf" file. generated_file.png If you wish to debug the project, click on the green arrow beside the build button used earlier. Once flashed the project, open a serial terminal with the following configuration: Baudrate: 115200 Stopbits: 1 Data: 8 bits Parity: none In the terminal you should get the following output after a reset, in which initialization logs of both Bluetooth and Wi-Fi are printed: terminal_logs.png As printed on the Bluetooth logs, the integrated peripheral example starts advertising, to test this feature, you may use the NXP IoT Toolbox "Heart Rate" tool, which will allow to pair with the board as shown in the image below: iot_toolbox_pairing.jpg To start the pairing, tap on the "Set PHY" box and select the preferred PHY. Once paired, you should be able to see the heart rate indication increasing and decreasing as shown: heart_rate_tool.jpg On the serial terminal you will be able to see the following logs once paired with your phone: bt.png To test the Wi-Fi shell features, you may display all of the NXP-Wi-Fi features by writing in the terminal "nxp_wifi help", as well as "wifi help" to see the commands to use the default Wi-Fi features to scan/connect to a network. To test the connection to an access point, do a "wifi scan" to display the available networks, once identified the network to join, write "wifi connect …" with the rest of the required attributes to join the network, then you should get an output similar to the following: wifi_terminal.png Notice that you are able to do this while connected to the heart rate tool in the mobile application via Bluetooth, demonstrating the capability of having both a Wi-Fi and Bluetooth connections working concurrently.

This document describes how to use the RW61x DevHSM Loader Application in combination with an OEM Manufacturing Firmware (OEM MFW) to perform secure device provisioning. Two DevHSM loader images are available depending on the boot flow: RW61x_DevHSM_Loader_ISP_Boot_FW.sb3 → Used when loading via ISP boot mode. This method communicates via UART, USB, I2C or SPI RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 → Used for zero‑touch provisioning from external flash. This method communicates via SWD or JTAG. Both flows ultimately load and execute an OEM Manufacturing Firmware (OEM_MFW.sb3) that provisions the device (e.g., secure keys, identities, certificates, etc.). You may generate this firmware using the SEC tool.  The DevHSM Loader firmwares are provided in the SEC tool package once downloaded. The SEC tool by default will use the ISP loader application.   1. DevHSM Loader Using ISP Boot Mode Firmware Image RW61x_DevHSM_Loader_ISP_Boot_FW.sb3 This method uses the boot ROM ISP protocol. It’s commonly used during development, factory bring‑up, or initial programming before flash is configured. Procedure Step‑by‑step Boot the device in ISP boot mode Ensure the correct boot pins are set so the device enters ISP mode and communicates with blhost. Download the DevHSM Loader Firmware Use the receive-sb-file command to send RW61x_DevHSM_Loader_FW.sb3 over the serial interface. Verify updated device state Use get-property 0x1 to confirm the firmware was accepted and the boot state changed accordingly. Download and execute OEM MFW (OEM_MFW.sb3) Once the DevHSM Loader is active, send the provisioning firmware SB3 file. The OEM MFW will load, execute, and begin provisioning operations. Example Script: set blhost=blhost.exe set comport=COMxx,115200 set timeout=-t 100000 %blhost% -p %comport% -- get-property 0x1 pause blhost.exe -p %comport% %timeout% -- receive-sb-file RW61x_DevHSM_Loader_ISP_Boot_FW.sb3 pause %blhost% -p %comport% -- get-property 0x1 pause blhost.exe -p %comport% %timeout% -- receive-sb-file OEM_MFW.sb3   2. DevHSM Loader Using FlexSPI Boot Mode (Zero‑Touch Provisioning) Firmware Image RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 In this flow, the device boots directly from external flash (FlexSPI). This is intended for zero‑touch provisioning scenarios, such as factory lines where devices must self‑provision automatically on first boot. You have two options for placing the OEM Manufacturing Firmware (OEM MFW) in flash.  Option 1: Fixed OEM MFW Address (0x08010000) Required Flash Layout Address Purpose 0x08000400 Flash Configuration Block (FCB) 0x08001000 DevHSM Loader FlexSPI Boot Firmware 0x08010000 OEM_MFW.sb3 Steps Program the FCB at 0x08000400 Must match the external flash device in use (size, timing, SPI mode, etc.). Program RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 at 0x08001000 Program OEM_MFW.sb3 at 0x08010000 On next boot, the DevHSM Loader automatically locates the OEM MFW at 0x08010000 and executes it. Option 2: OEM MFW at Custom Address If you want OEM_MFW.sb3 to reside at a different address, you must provide a configuration block at a fixed location: Configuration Block Location: 0x08006000 Size: 64 bits Format: Magic word (0x4448534D) || OEM_MFW target address Example @0x08020000: 4448534D00000208 This tells the DevHSM Loader where the OEM MFW is stored. Steps Program the FCB at 0x08000400 Write configuration block at 0x08006000 First 32 bits: 0x4448534D Next 32 bits: address of OEM_MFW.sb3 Program RW61x_DevHSM_Loader_FlexSpi_Boot_FW.sb3 at 0x08001000 Program OEM_MFW.sb3 at the desired flash address   Provisioning Behavior on Next Boot When the device powers up: The DevHSM loader initializes, Reads the fixed or custom location of the OEM MFW, Loads and executes OEM_MFW.sb3, OEM MFW provisions the device and may optionally: Configure dual‑boot setups, or Reprogram a new application at 0x08001000. Important Note The OEM_MFW.sb3 is responsible for installing or updating the device’s operational application after provisioning. It must either load the new app at the configured offset or reprogram the default application location (0x08001000).        

This document summary BT classical RF parameters and give examples of nxp wif&bt product Bluetooth rf test and results analysis. The document includes:  Introduction BT key parameters Test Procedure & Result Analysis

 

Learn how to bring Wi-Fi connectivity to Zephyr’s projects based on the FRDM-RW612 board. This guide walks you through adapting the Ethernet-based mqtt_publisher sample to work over Wi-Fi using Zephyr v4.2.0. You'll explore the built-in wifi/shell example, configure the networking stack, and create a custom shell command to control MQTT publishing. Perfect for developers building IoT applications that need seamless cloud communication over wireless networks.

Hardware : i.MX8MN-EVK Wi-Fi module on the board is 88W8987. Software: BSP is i.MX Yocto Linux BSP L6.12.3_1.0.0.   Topics: Introduction of Wi-Fi driver configuration file : wifi_mod_para.conf  How to load the Wi-Fi driver How to configure the WPA2/WPA3  5G/2G connection How to use wpa_supplicant to connect to the AP Introduction of some wpa_supplicant.conf parameters    

Hardware board : NXP i.MX8MN-EVK  Wi-Fi module on the board is 88W8987. Software : BSP is i.MX Yocto Linux BSP L6.12.3_1.0.0.   Topic: Wi-Fi driver configuration :  wifi_mod_para.conf file How to load the Wi-Fi driver How to use hostapd to configure the 2G connection (uap0) How to start the uap0 2G connection How to use hostapd to configure the 5G connection (uap0) How to start the uap0 5G connection uap0 + ethernet connection    

The article will introduce the following contents. No.1 Preparation          1. Ubuntu 20.04 Host          2. Downloading Mass Market Driver(FP92)source code No.2 For ARM Platform          1. Toolchain For cross compilation          2. Linux Kernel source code of target board          3. Building Linux Kernel source code of target board          4. Building NXP Wi-Fi Mass Market Driver source code No.3 For X86 Platform          1. Compilation on different ubuntu version 1.1 Ubuntu 16.04 LTS 1.2 Ubuntu 18.04 LTS 1.3 Ubuntu 20.04 LTS 1.4 Ubuntu 22.04 LTS         2. Cross Compilation on Ubuntu 20.04 LTS 2.1 Linux kernel 4.9 2.2 Linux kernel 5.10 2.3 Linux kernel 6.12 No.4 Conclusion     NXP TIC Connectivity Team Weidong Sun Apr-18-2025

The article described steps on how to enable SDIO Wi-Fi & Bluetooth on M.2 interface. The main contents are like below: ========================= 1. Introduction  2. Steps            2.1 Board Configurations            ① BoardConfig.mk            ② evk_8mp.mk            ③ SharedBoardConfig.mk            ④ imx8mp_gki.fragment           2.2 Wi-Fi & Bluetooth Configurations            ① wifi_mod_para.conf            ② bt_vendor.conf            ③ vendor_interface.cc  3. Building & Downloading images to i.MX8MP-EVK          3.1 Building images          3.2 Downloading images  4. Running Android images to verify Wi-Fi & Bluetooth  =========================   For other versions of Android bsp or SDIO Wi-Fi/BT on M.2, same steps.   NXP TIC Connectivity Team, Weidong Sun    

The article introduces steps on how to transmit files between IW612 Bluetooth and remote devices on linux platform.   NXP TIC Connectivity Team Weidong Sun

The article introduces the following contents related to 88W9098. 1. Introduction     1.1 Software Tools     1.2 Hardware Tools     1.3 Diagram of connections 2. Configurations     2.1 Loading Wi-Fi driver     2.2 Connecting external AP          2.2.1 mlan0 to external AP with 5G          2.2.2 mmlan0 to Mobile with 2.4G 2.3 Configuring iptables 2.4 DHCP service on ethernet 3. Wi-Fi Bridge Verification     3.1 Verification of Ethernet to mlan0     3.2 Verification of Ethernet to mmlan0   NXP TIC Connectivity Team Weidong Sun