On the build folder, type bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq where <image> is the image name (e.g. core-image-minimal). In case you want to know if a certain <package> is included on an image, just grep the output bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq | grep <package>

Some processor’s GPIO settings on the i.MX Pins Tool version 7 may not show allow to select direction and just show an option “Input/Output” as shown. This will be fixed, but the settings can be changed on the local processor data as a workaround. For more information and documentation for the Pins Tool for i.MX please visit its home page on the link below: https://www.nxp.com/design/designs/pins-tool-for-i-mx-application-processors:PINS-TOOL-IMX   First, find where the Pins Tool data package is stored. To do this open the Pins Tool and click Help > About. On the About screen click the Details button. Take also note of the name of the package that needs to be fixed.   Go to the location where the data package is stored and find the processor data. The file that would need to be updated is signal_configuration.xml    Find the GPIO pin data and change the directions from the string ““inOut”to the string “in out”. Then save this file.    Close and reopen the Pins Tool. The direction on the updated package should now show the options Input and Output.  

Check new updated version for with Morty here Step 1 : Get iMX Yocto AVS setup environment Review the steps under Chapter 3 of the i.MX_Yocto_Project_User'sGuide.pdf on the L4.X LINUX_DOCS to prepare your host machine. Including at least the following essential Yocto packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev u-boot-tools Install the i.MX NXP AVS repo Create/Move to a directory where you want to install the AVS yocto build enviroment. Let's call this as <yocto_dir> $ cd <yocto_dir> $ repo init -u https://source.codeaurora.org/external/imxsupport/meta-avs-demos -b master -m imx7d-pico-avs-sdk_4.1.15-1.0.0.xml Download the AVS BSP build environment: $ repo sync Step 2: Setup yocto for Alexa_SDK image with AVS-SETUP-DEMO script: Run the avs-setup-demo script as follows to setup your environment for the imx7d-pico board: $ MACHINE=imx7d-pico DISTRO=fsl-imx-x11 source avs-setup-demo.sh -b <build_sdk> Where <build_sdk> is the name you will give to your build folder. After acepting the EULA the script will prompt if you want to enable: Sound Card selection The following Sound Cards are supported on the build: SGTL (In-board Audio Codec for PicoPi) 2-Mic Conexant The script will prompt if you are going to use the Conexant Card. If not then SGTL will be assumed as your selection Are you going to use Conexant Sound Card [Y/N]? Install Alexa SDK Next option is to select if you want to pre-install the AVS SDK software on the image. Do you want to build/include the AVS_SDK package on this image(Y/N)? If you select YES, then your image will contain the AVS SDK ready to use (after authentication). Note this AVS_SDK will not have WakeWord detection support, but it can be added on runtime. If your selection was NO, then you can always manually fetch and build the AVS_SDK on runtime. All the packages dependencies will be already there, so only fetching the AVS_SDK source code and building it is required. Finish avs-image configuration At the end you will see a text according with the configuration you select for your image build. Next is an example for a Preinstalled AVS_SDK with Conxant Sound Card support and WiFi/BT not enabled. ==========================================================   AVS configuration is now ready at conf/local.conf             - Sound Card = Conexant                                     - AVS_SDK pre-installed                                       You are ready to bitbake your AVS demo image now:               bitbake avs-image                                        ========================================================== Step 3: Build the AVS image Go to your <build_sdk> directory and start the build of the avs-image There are 2 options Regular Build: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image With QT5 support included: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image-qt5 The image with QT5 is useful if you want to add some GUI for example to render DisplayCards. Step 4 : Deploying the built images to SD/MMC card to boot on target board. After a build has succesfully completed, the created image resides at <build_sdk>/tmp/deploy/images/imx7d-pico/ In this directory, you will find the imx7d-pico-avs.sdcard image or imx7d-pico-avs-qt5.sdcard, depending on the build you chose on Step3. To Flash the .sdcard image into the eMMC device of your PicoPi board follow the next steps: Download the bootbomb flasher Follow the instruction on Section 4. Board Reflashing of the Quick Start Guide for AVS kit to setup your board on flashing mode. Copy the built SDCARD file $ sudo dd if=imx7d-pico-avs.sdcard of=/dev/sd bs=1M && sync $ sync Properly eject the pico-imx7d board: $ sudo eject /dev/sd NXP Documentation Refer to the Quick Start Quide for AVS SDK to fully setup your PicoPi board with Synaptics 2Mic and PicoPi i.mx7D For a more comprehensive understanding of Yocto, its features and setup; more image build and deployment options and customization, please take a look at the i.MX_Yocto_Project_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document. For a more detailed description of the Linux BSP, u-boot use and configuration, please take a look at the i.MX_Linux_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document.

The Linux L4.9.11_1.0.0 RFP(GA) for i.MX6 release files are now available on www.nxp.com    Files available: # Name Description 1 L4.9.11_1.0.0-ga_images_MX6QPDLSOLOX.tar.gz i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 2 L4.9.11_1.0.0-ga_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 3 L4.9.11_1.0.0-ga_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 4 L4.9.11_1.0.0-ga_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 5 L4.9.11_1.0.0-ga_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  6 L4.9.11_1.0.0-ga_mfg-tools.tar.gz i.MX Manufacturing Toolkit for Linux L4.9.11_1.0.0 BSP 7 L4.9.11_1.0.0-ga_gpu-tools.tar.gz L4.9.11_1.0.0 i.MX VivanteVTK file 8 bcmdhd-1.141.100.6.tar.gz The Broadcom firmware package for i.MX Linux L4.9.11_1.0.0 BSP. 9 imx-aacpcodec-4.2.1.tar.gz Linux AAC Plus Codec for L4.9.11_1.0.0 10 fsl-yocto-L4.9.11_1.0.0.tar.gz L4.9.11_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide.   Target boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board (Beta Quality)   What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes, see: README: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/README?h=imx-morty ChangeLog: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/ChangeLog?h=imx-morty

This documents describes how to add the NFC support to i.MX8M mini evk running Android Pie. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 VEN signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on Android P9.0.0 Pie (P9.0.0_1.0.0, 4.14 kernel) i.MX software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/docs/en/supporting-information/android_p9.0.0_1.0.0-ga_docs.zip. Just flash the demo image (downloaded from here:https://www.nxp.com/lgfiles/updates/NFC/ANDROID_P9-0-0_PN7150_IMAGE_8MMEVK.zip) following guidelines from i.MX_Android_Quick_Start document (part of Android P9.0.0_1.0.0 Documentation package mentioned above). The NFC support is then included in the device settings, as shown in below screenshot of the device: Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger a sound notification: Unfortunately the Android demo image doesn't embed a web browser, so it won't be automatically open when the NFC tag content (an URL to the demo kit web page) is read. Otherwise (if a web browser is installed) you could see such page opening on the device: Adding PN7150 support to imx-android-pie release: If you wish to add PN7150 support to your imx-android-pie environment, just apply the patches (imx-p9.0.0_1.0.0-ga_pn7150_patches.tar.gz file attached) from the ${MY_ANDROID} source code root folder (refer to i.MX_Android_User_Guide document part of Android P9.0.0_1.0.0 Documentation package mentioned above).  $ patch -p1 -d device/fsl/ <device_fsl.patch  $ patch -p1 -d packages/apps/Nfc <packages_apps_Nfc.patch  $ patch -p1 -d hardware/nxp/nfc <hardware_nxp_nfc.patch  $ patch -p1 -d vendor/nxp <vendor_nxp.patch  $ patch -p1 -d vendor/nxp-opensource/kernel_imx/ <vendor_nxp-opensource_kernel_imx.patch When building, the PN7150 support will then be included to the android image, as shown in the demo image described above. Reference: This porting have been done (demo image and patches creation) following guidelines provided in AN11690_NXP-NCI_Android_Porting_Guidelines document.

This doc show: on i.MX8QXP MEK board, configure ov5640 sensor(parallel interface) output 5MP(2592x1944) RAW(Bayer) data at 15fps, and Parallel Capture Subsystem and Image Sensor Interface capture RAW RGB data, and i.MX8QXP GPU debayer RAW data then display image. HW: i.MX8QXP MEK board, MEK base board (to place the parallel camera), ov5640 sensor. SW: Linux 4.14.98_2.0.0 BSP, and patches in this doc.   Configure at camera sensor side A Bayer filter is a color filter array (CFA) for arranging RGB color filters on a square grid of photosensors. The filter pattern is 50% green, 25% red and 25% blue, hence is also called BGGR, RGBG ,GRGB, or RGGB. The ov5640 has an image array capable of operating at up to 15 fps in 5 megapixel (2592x1944) resolution. OV5640 support output formats: RAW(Bayer), RGB565/555/444,CCIR656, YUV422/420, YCbCr422, and compression. To make ov5640 output 5MP RAW data at 15fps, check my kernel patch imx8-ov5640-raw-capture-driver-4.14.98_2.0.0.diff which apply on i.MX Linux 4.14.98_2.0.0 BSP kernel code. Parallel interface ov5640, use ov5640_raw_setting[] array of drivers/media/platform/imx8/ov5640_v3.c. This register setting is come from ov5640 software application note and data sheet. Configure at i.MX8QXP side The Parallel Capture Subsystem consists of the Parallel Capture Interface (BT 656) and associated peripherals. It interfaces to the Parallel CSI sensor. This allows for up to 24 RGB data bits in parallel or for RGB components on consecutive clocks (up to 10-bit color depth). The formats supported are RGB, RAW and YUV 422. Below is Parallel Capture Subsystem diagram: For RAW format data, CSI_CTRL_REG of Parallel Capture Subsystem need configured as my patch, otherwise found cannot get correct data.   The multiple input sources (MIPI CSI, Parallel Capture) captures the pixel data and feeds it to the ISI. The ISI is responsible for capturing and pre-processing the pixel data from multiple input sources and storing them into the memory. Below is ISI diagram: For RAW format data, it should be bypass any processing pipeline of ISI, just use ISI to save it to memory.   Capture test code To capture the RAW data and save it to file, check my patch imx8_ov5640_raw_captupre_test_4.14.98_2.0.0_ga.diff which apply on i.MX Linux 4.14.98_2.0.0 BSP unit test code. Note the usage is: ./imx8_cap.out -of -cam 1 -fr 15 -fmt BA81 -ow 2592 -oh 1944 -num 100   Display RAW data The RAW data cannot be displayed directly, debayer process is needed to get complete red, green, blue color for each pixel. The debayer process if run on CPU, will cost much CPU time. To save CPU time, debayer could done by GPU. The method is, captured RAW data upload to GPU as texture , then GPU will do the debayer, then full color of each pixel will be got, then display it. To upload RAW camera data to GPU with zero memory copy, i will use i.MX8QXP GPU extension GL_VIV_direct_texture. It create a texture with direct access support. API glTexDirectVIVMap,  which support mapping a user space memory or a physical address into the texture surface. The API glTexDirectVIVMap need logic and physical address of data buffer, so i will allocate data buffer from g2d lib, it is dma-buffer also get logic/physical address of buffer, then queue it as DMABUF to v4l2 capture driver, after dequeue got RAW camera data, pass it to GPU for debayer. GPU side, I will use OpenGL shader code from "Efficient, High-Quality Bayer Demosaic Filtering on GPUs". Check my patch imx8_debayer-gpusdk-5.3.0.diff which apply on i.MX GPU SDK 5.3.0 code. Note, here i only do is debayer, no extra process.   Known issue One thing is ov5640 output 5MP at 15fps, compare with output 5MP at 5fps, there are more noise of camera data at 15fps case. My debug found is, this noise seems come from ov5640 itself.   Reference: a>https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.0.0_MX8QXP&appType=license c>https://github.com/NXPmicro/gtec-demo-framework d>ov5640 data sheet e>ov5640 software application note f>Efficient, High-Quality Bayer Demosaic Filtering on GPUs https://www.semanticscholar.org/paper/Efficient%2C-High-Quality-Bayer-Demosaic-Filtering-on-McGuire/088a2f47b7ab99c78d41623bdfaf4acdb02358fb

This article is rather short that only mentions the script that is needed to make an iMX93EVK act as a USB mass storage device so that whenever you connect your iMX device to a windows/linux system via USB, it should get enumerated something like a usb drive.  The storage that is used in this example is mmc so the expectation is that you have inserted a mmc card in the slot. Below is the script:- #!/bin/sh   # This composite gadget include function: # - MASS STORAGE     # # Exit status is 0 for PASS, nonzero for FAIL # STATUS=0   # Check if there is udc available, if not, return fail UDC_DIR=/sys/class/udc if test "$(ls -A "$UDC_DIR")"; then echo "The available udc:" for entry in "$UDC_DIR"/* do echo "$entry" done else STATUS=1 echo "No udc available!" exit $STATUS; fi   id=1; udc_name=ci_hdrc.0 #back_file=/dev/mmcblk1 back_file=/tmp/lun0.img   mkdir /sys/kernel/config/usb_gadget/g$id cd /sys/kernel/config/usb_gadget/g$id   # Use NXP VID, i.MX8QXP PID echo 0x1fc9 > idVendor echo 0x12cf > idProduct   mkdir strings/0x409 echo 123456ABCDEF > strings/0x409/serialnumber echo NXP > strings/0x409/manufacturer echo "NXP iMX USB Composite Gadget" > strings/0x409/product   mkdir configs/c.1 mkdir configs/c.1/strings/0x409   echo 5 > configs/c.1/MaxPower echo 0xc0 > configs/c.1/bmAttributes   mkdir functions/mass_storage.1 echo $back_file > functions/mass_storage.1/lun.0/file ln -s functions/mass_storage.1 configs/c.1/   echo $udc_name > UDC First execute the script. After that insert the g_mass_storage module in the kernel by executing :- modprobe g_mass_storage file=/dev/mmcblk1 removable=1 In the dmesg output, you will see something like below:-   After that you can connect a C type USB cable to the USB1 port of imx93evk and the other end to any USB ports of a laptop. The moment it is connected, you would be able to see a USB drive similar to what you get when we connect a pen-drive. 

Information about the transition from the NXP Demo Experience to GoPoint for i.MX Application Processors.

Environment BSP: L6.1.22_2.0.0​ Platform: i.MX93 Links:  https://github.com/NXP/swupdate-scripts https://github.com/nxp-imx-support/meta-swupdate-imx   The AN13872 provides us the swupdate yocto layer, swupdate-scripts and test steps, but there is still much to add. The purpose of this knowledge base is to provide customized advice. 1.How to port meta-swupdate-imx to any yocto version you want? As meta-swupdate-imx only provide kirkstone version, we can upgrade or degrade it based on this version. We will take L6.1.22_2.0.0​ porting steps as an example. 1.1 Download Yocto layer  cd imx-yocto-bsp/sources git clone https://github.com/sbabic/meta-swupdate.git -b mickledore git clone https://github.com/nxp-imx-support/meta-swupdate-imx.git 1.2 Modify  Yocto layer  imx-yocto-bsp/sources/meta-swupdate-imx/conf/layer.conf   You can find swupdate version in imx-yocto-bsp/sources/meta-swupdate/recipes-support/swupdate/ 1.3 Handle patches in meta-swupdate-imx/recipes-bsp/u-boot/files/ About patchs in sources/meta-swupdate-imx/recipes-bsp/u-boot/files/ and imx-yocto-bsp/sources/meta-swupdate-imx/recipes-support/swupdate/files/, you need use devtool to unpack uboot and swupdate into workspace and add changes manunally for development. CONFIG_ENV_OFFSET_REDUND=CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE   sources/meta-swupdate-imx/recipes-bsp/u-boot/u-boot-imx_%.bbappend 2.How to flash base image? Use uuu or dd command, just like common imx-image-xxx 3.swupdate-scripts porting suggestions 3.1 Partition table You can modify partition table refer the size of images. For different soc, the first offset is different. If you are porting i.MX8MP based on iMX8MM, the offset should be 32K.   3.2 Some errors 3.2.1 This error indicates that you need enlarge size of rootfs. e2fsck 1.45.5 (07-Jan-2020) The filesystem size (according to the superblock) is 887599 blocks The physical size of the device is 768000 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?    3.2.2 You need upgrade e2fsck verison. e2fsck 1.46.5 (30-Dec-2021) /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4 has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4: ********** WARNING: Filesystem still has errors ********** resize2fs 1.46.5 (30-Dec-2021) resize2fs: Filesystem has unsupported feature(s) (/home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_ass  solution: wget https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.47.0/e2fsprogs-1.47.0.tar.xz tar -xf e2fsprogs-1.47.0.tar.xz cd e2fsprogs-1.47.0/ ./configure make -j16 sudo make install   3.2.3 mtools /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 58: mdir: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 68: mdir: command not found solution: sudo apt-get install mtools

i.MX8 VPU hardware decoder support below video codec: H.265 HEVC Main Profile 4Kp60 Level 5.1 H.264 AVC Constrained Baseline, Main and High profile H.264 MVC WMV9 / VC-1 Simple, Main and Advanced Profile MPEG 1 and 2 Main Profile at High Level AVS Jizhun Profile (JP) MJPEG4.2 ASP, H.263, Sorenson Spark Divx 3.11, with Global Motion Compensation (GMC) ON2/Google VP6/VP8 RealVideo 8/9/10 JPEG and MJPEG A/B Baseline   i.MX8 VPU Linux driver is implemented based on V4L2 standard. Chromium beside software video decoding, it also support hardware video decoder(VideoDecodeAccelerator),  there are some kind of VideoDecodeAccelerator, one of them is V4L2VDA. Please note V4L2VDA is using V4l2 api, so it is possible that change V4L2VDA to enable Chromium hardware video playback on i.MX8.   This doc share patch to add chromium video decode accelerate by using i.MX8QM/i.MX8QXP VPU. It will support chromium H.264, H.265, VP8 hardware video decode. H.264 and H.265 need use mp4 container. VP8 use webm container.   HW: i.MX8QM/i.MX8QXP MEK board, 1080P HDMI display, mouse, keyboard SW: i.MX8 5.10.72_2.2.2 yocto bsp release(which included chromium 91.0), and patch in this doc   Patch description: imx8-5.10.72-vpudrv-update.diff, update i.MX8  5.10.72_2.2.2 kernel vpu driver to https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/mxc/vpu_malone?h=lf-5.15.y&id=fa7c67e2c9ed4fb8392fa258f931d6996339a17a chromium-ozone-wayland_91.0.4472.114.bb.diff, change meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_91.0.4472.114.bb for adding some compile flags, etc. 5.10.72-merge.patch, this patch change chromium source code to add video decode accelerate by using i.MX8 VPU.   Build steps: 1>Download i.MX8 5.10.72_2.2.2 yocto release from nxp.com 2>apply chromium-ozone-wayland_91.0.4472.114.bb.diff to change meta-browser/meta-chromium/recipes-browser/chromium/chromium-ozone-wayland_91.0.4472.114.bb 3>put 5.10.72-merge.patch to folder path_of_yocto-5.10.72-2.2.2/sources/meta-browser/meta-chromium/recipes-browser/chromium/files/ 3>apply imx8-5.10.72-vpudrv-update.diff to i.MX8 5.10.72_2.2.2 kernel 4>under the yocto image build folder, add "CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" to file path_of_yocto-5.10.72-2.2.2/folder-of-bld/conf/local.conf 5>run bitbake to build rootfs image   Test steps: After system boot up, put some video clip under /home/root/video then run below cmd (do not run chromium without any parameter, as that will start chromium with some other setting, you can check /usr/lib/chromium/chromium-wrapper) "/usr/lib/chromium/chromium-bin   --no-sandbox --ozone-platform=wayland --enable-features=VaapiVideoDecoder  --enable-accelerated-video-decode   --enable-clear-hevc-for-testing --ignore-gpu-blacklist --window-size=1920,1180  /home/root/video" then use mouse to click video clip and will start playback.   Reference: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors:IMX8-SERIES https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX https://www.chromium.org/audio-video/#:~:text=codec%20and%20container%20support https://github.com/igel-oss/meta-browser-hwdecode/blob/master/recipes-chromium/chromium/files/0001-Add-support-for-V4L2VDA-on-Linux.patch      

This is a detailed programming aid for the registers associated with i.MX 8MNano (m815S) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.

Host TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. U-Boot will download the Linux kernel and dtb file using tftp and then the kernel will mount (via NFS) its root file system on the computer hard drive. 1. TFTP Setup   1.1.1 Prepare the TFTP Service   Get the required software if not already set up. On host for TFTP: Install TFTP on Host $ sudo apt-get install tftpd-hpa   (Note: There are a number of examples in various forums, etc, of how to automatically start the TFTP service - but not all are successful on all Linux distro's it seems! The following may work for you.)   Start the tftpd-hpa service automatically by adding a command to /etc/rc.local. $ vi /etc/rc.local   Now, just before the exit 0 line edit below command then Save and Exit. $ service tftpd-hpa start  Now, To control the TFTP service from the command line use: $ service tftpd-hpa restart    To check the status of the TFTP service from the command line use: $ service tftpd-hpa status   1.1.1 Setup the TFTP Directories Now, we have to create the directory which will contain the kernel image and the device tree blob file. $ mkdir -p /imx-boot/imx6q-sabre/tftp Then, copy the kernel image and the device tree blob file in this directory. $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/zImage /imx-boot/imx6q-sabre/tftp $ cp {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/<dtb file> /imx-boot/imx6q-sabre/tftp   OR we can use the default directory created by yocto {YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}/ The tftpd-hpa service looks for requested files under /imx-boot/imx6q-sabre/tftp The default tftpd-hpa directory may vary with distribution/release, but it is specified in the configuration file: /etc/default/tfptd-hpa. We have to change this default directory with our directory   Edit default tftp directory $ vi /etc/default/tftpd-hpa   Now, change the directory defined as TFTP_DIRECTORY with your host system directory which contains kernel and device tree blob file. Using created directory TFTP_DIRECTORY=”/imx-boot/imx6q-sabre/tftp” OR Using Yocto directory path TFTP_DIRECTORY=”{YOCTO_BUILD_DIR}/tmp/deploy/images/{TARGET}” Restart the TFTP service if required $ service tftpd-hpa restart   1.2 NFS Setup 1.2.1 Prepare the NFS Service Get the required software if not already set up. On host for NFS: Install NFS on Host $ sudo apt-get install nfs-kernel-server The NFS service starts automatically. To control NFS services : $ service nfs-kernel-server restart To check the status of the NFS service from the command line : $ service nfs-kernel-server status 1.2.2 Setup the NFS Directories Now, we have to create the directory which will contain the root file system. $ mkdir -p /imx-boot/imx6q-sabre/nfs   Then, copy the rootfs in this directory. $ cp -R {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs/* /imx-boot/imx6q-sabre/nfs   OR we can use the default directory created by yocto. $ {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs 1.2.3 Update NFS Export File The NFS server requires /etc/exports to be configured correctly to access NFS filesystem directory to specific hosts. $ vi /etc/exports Then, edit below line into the opened file. <”YOUR NFS DIRECTORY”> <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex. If you created custom directory for NFS then, /imx-boot/imx6q-sabre/nfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check) Ex: /imx-boot/imx6q-sabre/nfs 192.168.*.*(rw,sync,no_root_squash,no_subtree_check) OR /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs <YOUR BOARD IP>(rw,sync,no_root_squash,no_subtree_check)   Now, we need to restart the NFS service. $ service nfs-kernel-server restart   2 Target Setup   We need to set up the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters, setenv serverip 192.168.0.206       //This must be your Host IP address The path where the rootfs is placed in our host has to be indicated in the U-Boot, Ex. // if you choose default folder created by YOCTO setenv nfsroot /{YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs   OR // if you create custom directory for NFS setenv nfsroot /imx-boot/imx6q-sabre/nfs Now, we have to set kernel image name and device tree blob file name in the u-boot, setenv image < zImage name > setenv fdt_file <dtb file name on host> Now, set the bootargs for the kernel boot, setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp' Use printenv command and check loadaddr and fdt_addr environment variables variables for I.MX6Q SABRE, loadaddr=0x12000000 fdt_addr=0x18000000   Also, check netboot environment variable. It should be like below, netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${image}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi; Now, set environment variable bootcmd to boot every time from the network, setenv bootcmd run netboot Now finally save those variable in u-boot: saveenv Reset your board; it should now boot from the network: U-Boot 2016.03-imx_v2016.03_4.1.15_2.0.0_ga+ga57b13b (Apr 17 2018 - 17:13:43 +0530)  (..) Net:   FEC [PRIME] Normal Boot Hit any key to stop autoboot:  0   Booting from net ... Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'zImage'. Load address: 0x12000000 Loading: #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         #################################################################         ###########################################################         2.1 MiB/s done Bytes transferred = 6578216 (646028 hex) Using FEC device TFTP from server 192.168.0.206; our IP address is 192.168.3.101 Filename 'imx6q-sabresd.dtb'. Load address: 0x18000000 Loading: ####         1.8 MiB/s done Bytes transferred = 45893 (b345 hex) Kernel image @ 0x12000000 [ 0x000000 - 0x646028 ] ## Flattened Device Tree blob at 18000000   Booting using the fdt blob at 0x18000000   Using Device Tree in place at 18000000, end 1800e344 switch to ldo_bypass mode!   Starting kernel ...

According to iMX6DQRM chapter 46 (On-Chip OTP Controller), the UID field is located at offsets 0x410 and 0x420 from the base address of the OCOTP.  That is: OTP Bank0 Word1 - contains the first word of the UID OTP Bank0 Word2 - contains the second word of the UID. md.l 21bc410 021bc410: d72d7372 d72d7372 d72d7372 d72d7372    rs-.rs-.rs-.rs-. 021bc420: 906709d4 906709d4 906709d4 906709d4 ..g...g...g...g. Comparing to the read information under Linux shell: cat /proc/cpuinfo ......... Serial : 906709d4d72d7372 The value is identical from uboot and linux kernel reading back.

Host : Ubuntu 11.10 Part 1. Installation of QNX 6.50 and QNX 6.50 SP1        1.1 Create an account and activate the created account that will be assigned an 30-days evaluation serial numberin then on www.qnx.com, and download qnxsdp-6.5.0-201007091524-linux.bin, qnxsdp-6.5.0SP1-201206271006-linux.bin;        1.2 Execute "sudo apt-get install ia32-libs"        1.3 Execute "sudo -E /your/path/qnxsdp-6.5.0-201007091524-linux.bin", follow the guides as prompted, enter the received evaluation serial number, then the installation of QNX 6.50 will be done;        1.4 Logout, and re-login, so far typing "qconfig" will return the following messages:         --------------------------------------------------------------------------------------------------------------------- alanz@alanz-VirtualBox:~$ qconfig QNX Installations   Installation Name: QNX Software Development Platform 6.5.0             Version: 6.5.0      Base Directory: /opt/qnx650            QNX_HOST: /opt/qnx650/host/linux/x86          QNX_TARGET: /opt/qnx650/target/qnx6         ---------------------------------------------------------------------------------------------------------------------        1.5 Execute "sudo chmod a+rw /etc/qnx/license/licenses"        1.6 Execute "sudo -E /your/path/qnxsdp-6.5.0SP1-201206271006-linux.bin"        1.7 Logout, and re-login, so far typing "qconfig" will return the following messages:         --------------------------------------------------------------------------------------------------------------------- alanz@alanz-VirtualBox:~$ qconfig QNX Installations   Installation Name: QNX Software Development Platform 6.5.0             Version: 6.5.0      Base Directory: /opt/qnx650            QNX_HOST: /opt/qnx650/host/linux/x86          QNX_TARGET: /opt/qnx650/target/qnx6 Additional Packages    Package Name: QNX Software Development Platform         Version: 6.5.0SP1            Base: QNX SDP 6.5.0    Installation Path: /opt/qnx650         ---------------------------------------------------------------------------------------------------------------------        1.8 Download bsp-nto650-freescale-mx6q-sabrelite-trunk-201301161142.zip, and unzip it; Part 2. Build i.MX6Q SabreLite QNX BSP        2.1 Edit a envsetup.sh as following:         --------------------------------------------------------------------------------------------------------------------- #!/bin/bash export QNX_HOST=/opt/qnx650/host/linux/x86 export QNX_JAVAHOME=/opt/qnx650/_jvm export QNX_TARGET=/opt/qnx650/target/qnx6 export QNX_CONFIGURATION=/etc/qnx export ARCH=arm export CPULIST=arm export VARIANTLIST=v7 export MAKEFLAGS=-I/opt/qnx650/target/qnx6/usr/include export PATH=$PATH:/opt/qnx650/host/linux/x86/usr/bin export QCONFIG=/opt/qnx650/target/qnx6/usr/include/qconfig.mk export BSP_ROOT_DIR=/home/alanz/Downloads/QNX_Software/i.MX6Q_SabreLite4QNX         ---------------------------------------------------------------------------------------------------------------------        Note: BSP_ROOT_DIR is the BSP unzip directory.        2.2 Execute "make clean", then "make". The generated file will be under images/ifs-mx6q-sabrelite.raw Part 3. Running i.MX6Q SabreLite QNX BSP        3.1 Copy images/ifs-mx6q-sabrelite.raw to SD;        3.2 Modify u-boot environment as following:         --------------------------------------------------------------------------------------------------------------------- setenv loadaddr '0x10800000' setenv bootcmd_sd 'mmc dev 0; fatload mmc 0:1 ${loadaddr} ifs-mx6q-sabrelite.raw; go ${loadaddr}' setenv bootcmd 'run bootcmd_sd' saveenv boot         ---------------------------------------------------------------------------------------------------------------------        3.3 Connect i.MX6Q SabreLite w/ serial and ethernet, turn on, type "qconn" and "ifconfig" in the serial shell. Part 4. Debug w/ QNX Momentics IDE        4.1 Type "qde" to activate Momentics IDE        4.2 On the top-right corner, there exist several icons named in "xxx perspective" to switch the main window according to current selected "perspective" context. Click "QNX System Information Perspective" to create a target to conect and debug as following depicted.        4.3 Switch to "C/C++ perspective" to create QNX C/C++ project as following depicted.        4.4 Switch to "Debug perspective" to perform "Debug Configuration" as following depicted.        Then it can debug program on target i.MX6Q SabreLite board.

Instruction On Linux OS, we have two major audio system API to play/record audio pcm, alsa-lib and pulseaudio. Pulseaudio is in Freescale Ubuntu root fs release, while alsa-lib is used by default in LTIB release. This article is to tell how to configure alsa-lib by configuration file. Architecture Alsa-lib has a set of standard API which allows application to develop easily. At the same time, it provides a scalable mechanism to fulfill its features, including resample, channels remix, sound mixing from different applications, and so on. As above figure describes, alsa plugin provide fundamental function, and the whole pipeline makes customization possible. Alsa-lib API pretend to be an alsa device and provide a name for caller to open. What kind of plugin the name represents for is decided by configuration. For example, pcm.card0 {    type hw    card 0 } card0 is the fake alsa device name, with type hw, which represents for the first real alsa device. pcm.plug {     @args [ SLAVE ]     @args.SLAVE {         type string     }     type plug     slave.pcm $SLAVE } plug is the fake alsa device name, with type plug, which represents for audio conversion processor. In addition, it's also receive arguments from application that make it more flexible. When we call snd_pcm_open(.., "plug:card0",..); in the application, we create a pipeline which will first convert the source pcm to sound card 0 capable pcm if necessary in "plug" plugin, then play it to sound card 0 in "card0" plugin.  "slave.pcm" is the key to link different plugins. The number of arguments could be more than one, with definition pcm.xxx {     @args [ arg1 arg2 arg3 ]     @args.arg1 { type string }     @args.arg2 { type string }     @args.arg3 { type string }     ... } The argument could also have default value, please refer to /usr/share/alsa/alsa.conf. To pass the arguments, use snd_pcm_open(.., "xxx:arg1,arg2,arg3",..); From the name, we can always follow the pipeline to the last plugin, which type might be hw(to alsa driver), file(to file), or others (pulse, bluetooth...) to network, protocol stack and so on. The Configuration Files In configuration file, we mainly define the fake alsa device name. The root configuration file is /usr/share/alsa/alsa.conf, which will load additional configuration files which might overwrite previous name definition in the previously loaded file. The load sequence is: 1. /usr/share/alsa/alsa.conf 2. /usr/share/alsa/alsa.conf.d/* 3. /etc/asound.conf for administrator 4. $(HOME)/.asoundrc for certain user In practice, alsa applications (e.g. aplay or speaker-test) are always using "default" as the fake device name, so that the most important thing to customize your own pipeline is to overwirte "default". For example, pcm.dmix_44100{     type dmix     ipc_key 5678293     ipc_key_add_uid yes     slave{         pcm "hw:0,0"         period_time 10000         format S16_LE         rate 44100     } } pcm.!default{     type plug     route_policy "average"     slave.pcm "tee:dmix_44100,/home/wayne/a.pcm" } The "!" in "pcm.!default" means forcing overwrite. The pipeline defined above is as following figure: The next example is the "default" definition on ubuntu root fs. pcm.!default {     type pulse     hint {         show on         description "Playback/recording through the PulseAudio sound server"     } } The only alsa plugin is "pulse", and the pipeline is as following: Additional Resources There are a lot of alsa plugins developed, with various configuration parameters, I won't list them in detail. Please refer to .asoundrc - ALSA wiki for more details.

1) nfs I burn the uboot to board by mfgtool, then starting the kernel by nfs, when the board boot up, I set a) ipaddr and b)serverip, then I set the c)"setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs", this is sample, you need choose correct folder for yours, this is for imx6q, d) set the mdt file,then run the netboot. 2) program uboot to the qspi, then boot from SD card 3) change the mfgtool to program uboot, kernel to the qspi attched the ucl2.xml setenv bootcmd 'run bootargsset; sf probe; sf read ${loadaddr} 0xA00000 0x600000; sf read ${fdt_addr} 0x800000 0x10000; bootz ${loadaddr} - ${fdt_addr}'

Overview: This document is written for Freescale customers who have Freescale AC3 release packages (excluded package). (If you did not have the AC3 release package, you can disregard this document.) Freescale OMX Player in Android release supports audio track selection when playing files with multiple audio tracks. However, most customers don't use this enhanced API to select the audio track even if current audio codec is not supported. To avoid a soundless output when partial audio track can be played, this document provides the method to select the available audio track automatically to play. The patch in this document is not included in our current release because it did not match with our track selection rule - play the first track. If you have any idea with this issue, feel free to add comments into this document. Issue description: Software: R13.4-GA or R13.4.1 Android releases Hardware: MX6Dual/Quad SabreSD board Test source: 1.mkv Test Step: 1. Lunch Gallery from main menu. 2. Play the video And you can see the watch the video without any sound Root Reason: The file has 2 audio track DTS & AC3: audio track 1 is DTS and track 2 is AC3. OMX Player will choose the first audio track to play as default audio track, which is DTS audio. However, the software only supports the AC3 audio codec, so it could not set up audio decoder for DTS track. If we choose to play the AC3 track, sounds could be heard. How to fix: The audio track index is set in GMPlayer::LoadParser(). You can get audio format to check whether it is supported by decoder. Please see the patch audio_track_slection.diff

This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.

Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind.   Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide.   Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido‍‍  Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer.   BBLAYERS += " ${BSPDIR}/sources/meta-engicam "‍   This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf   IMAGE_INSTALL_append += "wf111-driver"‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work.   Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled:   CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default.   This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility   Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options.  Content of the config fragment:   CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set‍‍‍‍‍‍‍‍‍‍‍‍‍    Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory:   We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy:  <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment)   We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend   The linux-imx_3.14.52.bbappend file would contain the following:   SRC_URI += "file://WF111.cfg"  do_configure_append() {          #this is run from         #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git          cat ../*.cfg >> ${B}/.config  }‍‍‍‍‍‍    After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍‍