You can use TV Out on i.MX27ADS board by following these steps: Remove the R71 and solder it on R69 place; See the image before of this process: And after this process: Set SWITCH S15: 1 = on; [2-5] = off. See the image for more details: Add to your Linux command line (in Redboot) the following parameter: video=mxcfb:TV-NTSC After this modification, the video signal will operate at 27MHz, that are applicable just with TV-OUT card. The LCD card will not work at this frequency.

The miscellaneous service is in charge of providing access to all features not handled by the other services some examples include the following features: Subsystems controls - Some subsystems have settings that can be configured through the SCFW. For instance it is possible to set thresholds for a temperature alarm and get the temperature value of the sensor in different resources. For a complete list of resources and its controls please refer to the sc_fw_api document Chapter 5 Control List. DMA configurations - The SCFW provides access to DMA grouping and priority functions. Security functions - The SCFW provides some security functions such as: Image loading and authentication Fuse writing Life cycle management. Debug features - The SCFW provides some debug functionality through its miscellaneous service, some examples include:  Output a character through the SCU UART port Obtain SCFW build information (SCFW version) Obtain device Unique ID For a complete list of functions supported by your device please refer to the (SVC) Miscellaneous Service chapter of the sc_fw_api document.  This guide will cover the most common functions,  Getting and setting a control The process to get and set a control on a resource is the same for all available controls. Refer to the Control list chapter of your SoC SCFW API document for a complete list of the available controls. The following example will be based on an i.MX8QM.  The control list looks as follows: The table lists the controls available per resource as well as the width of the data to get/set, the 'Set' column describes whether a control is 'settable' or not, for instance the temperature sensor on the A53 resource can only be read/retrieved it cannot be 'written' (set) therefore the 'Y' (yes) in this column is missing, a brief description of the control is also provided. To get a control sc_misc_get_control must be called: uint32_t val; sc_misc_get_control(ipc, SC_R_A53, SC_C_TEMP, &val)‍;‍‍‍‍‍‍ By default all calls to get_control need a pointer to a 32 bit unsigned integer, the width field on the control list table defines the span of meaningful data. In the example above the data from the temperature sensor in the A53 resource is retrieved. This call returns SC_ERR_NONE whenever it succeeds. If the parameters are invalid it returns SC_PARM and if the caller does not have access to that resource it returns SC_ERR_NOACCESS. To set a control sc_misc_set_control must be called: uint32_t val = high_alarm_temperature_value; sc_misc_set_control(ipc, SC_R_A53, SC_C_TEMP_HI, val);‍‍‍‍‍‍‍‍ As in the get example sc_misc_set_control expects a 32 bit unsigned integer, it is the responsibility of the user to pass a value within the width limits defined in the control list table. In the example above the upper threshold for the A53 resource is being set/configured. The return values are the same as in sc_misc_get_control. Other functions There is a different method for getting/setting temperatures in a friendly human readable format, the method above uses a 'raw' format to interact with the temperature sensors in the resources, an easier way is to use the sc_misc_get_temp and sc_misc_set_temp functions. This functions return the temperature value in degrees Celsius as well as it's fractional part. To define whether to get/set the value for the temperature sensor itself or one of it's alarm the sc_misc_temp_t has been defined. SC_MISC_TEMP      -> Temperature sensor SC_MISC_TEMP_HIGH -> Upper threshold temperature sensor alarm SC_MISC_TEMP_LOW  -> Lower threshold temperature sensor alarm‍‍‍‍‍‍‍‍‍ For instance to get the temperature reading from the A53 resource the following call can be made: int16_t celsius; int8_t tenths; sc_misc_get_temp(ipc, SC_R_A53, SC_MISC_TEMP, &celsius, &tenths);‍‍‍‍‍‍‍‍‍ And to set the upper threshold alarm: int16_t celsius = 80; int8_t tenths = 0; /* Set High temperature alarm to 80 degrees Celsius */ sc_misc_set_temp(ipc, SC_R_A53, SC_MISC_TEMP_HIGH, celsius, tenths);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Unique ID of the chip as well as the build info of the SCFW can also be obtained through the miscellaneous service, the following example queries for this information: /* Getting SCFW version information */ uint32_t build_version; uint32_t commit_hash; sc_misc_build_info(ipc, &build_version, &commit_hash);‍‍‍ /* Getting Device Unique ID */ uint32_t ID_L; uint32_t ID_H; /* The ID is a 64-bit number ID_L stores the lower 32-bit portion and ID_H the 32-bit upper portion */ sc_misc_unique_id(ipc, &ID_L, &ID_H);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Refer to the sc_fw_api document for a definition of the remaining miscellaneous functions. https://community.nxp.com/docs/DOC-342654 

According to EHSET_v1.01.pdf description (http://testusb.com/EHHS.html), the USB physical certification test are from 2 sides. One test case is PC running USB-IF HSET utility as being USB host to test the target board being USB device; the other case is target board acting as USB host to initate test signals to a test fixture. The principle of test modes supported are based on Vid/Pid pair  during enumration by host whoever takes. Apply the attached patch (I use r13.4.1 kernel_imx tree), then enable "FSL_USB_TEST_MODE" in kernel config, rebuild uImage to get the test modes support kernel.

Attached you can find a document that explains how to add Wi-Fi support in the iMX28evk using Yocto.

Enabling Dual Display in Ubuntu with the i.MX53 Quick Start Board Here you will learn how to enable two displays in a Ubuntu system running in an iMX53 Quick Start Board. We assume here that you already have a micro SD card with a valid Ubuntu image (including uboot, Linux kernel and Ubuntu filesystem). You can use the original SD card that comes with the i.MX53 Quick Start Board, which brings an image of Ubuntu or, if you do not have the original SD card, you can reproduce it by downloading Ubuntu binaries package (L2.6.35_MX53_ER_1101_IMAGE) from Freescale iMX53qsb download area. You will also need to update U-boot and kernel binaries in the SD card with more recent images. You can find the most recent binaries (L2.6.35_MX53_ER_1109_IMAGE_) from Freescale iMX53qsb download area as well. Introduction To enable dual display, you need to perform two tasks: Enable two displays at kernel level Configure your Xorg server accordingly Enabling Two Displays at Kernel Level To enable two displays at kernel level means to map one display interface to fb0 device and the other to fb1 device. So first thing is to choose which interface will be the primary one, mapped as fb0. As an example, we consider the VGA interface as primary in this tutorial. Second thing is to choose one of the other available external video interfaces to be secondary, mapped as fb1 device in the system. We consider the 4.3" seiko LCD display in this tutorial as the secondary interface. Once chosen primary and secondary interfaces, we need to configure kernel video arguments accordingly. The arguments are available in specific variables in the U-boot that comes with the Ubuntu binaries. You can see them (HDMI, VGA, etc.) by printing the U-boot environment variables from the U-boot shell, but you will probably not find those variables in other versions of U-boot and their contents will probably need to be adapted to the kernel version in use, as arguments recognized by kernel modules varies considerably between kernel versions. You can always refer to the Linux Release Notes documents for video arguments. It's available for each Linux BSP that can be found on the Freescale website. For the 1109 BSP, we have the following video arguments (extracted from i.MX53_START_Linux_BSP_Release_Note.pdf that comes with L2.6.35_11.09.01_ER_docs.tar.gz downloaded from here - IMX53_1109_LINUXDOCS_BUNDLE😞 VGA: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga SEIKO LCD: video=mxcdi0fb:RGB24,SEIKO-WVGA di0_primary Both are considered primary, because these are the arguments for single display setups. Now that we have video arguments for both desired interfaces, we only need to merge them together removing the primary argument from the one that is the secondary. In our case, we need to pass the following arguments to the kernel: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA For this, we can add these arguments to one of the variables that are used in the boot process. We can add the content to bootarg_base, for instance. In the U-boot command line, execute following commands to setup the environment: setenv vga_and_seiko 'video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 vga_and_seiko' saveenv After applying a reset and booting the board, you shall have both interfaces enabled, but the secondary will not be used by the Xorg server until we complete the next step. Configuring Xorg Server Now that we have two video interfaces properly configured and mapped to /dev/fb0 and /dev/fb1 devices, we need to tell Xorg server how to use them. Here is an example of xorg.conf file that you can use to replace the default one, found at /etc/X11: Section "InputDevice" Identifier     "Generic Keyboard" Driver          "kbd" Option          "XkbRules"     "xorg" Option          "XkbModel"     "pc105" Option          "XkbLayout"     "us" EndSection  Section "InputDevice" Identifier     "Configured Mouse" Driver          "mouse" Option          "CorePointer" EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 0" Driver          "imx" Option          "fbdev"               "/dev/fb0"  # This option only recognized when "mxc_epdc_fb" frame buffer driver in # use.  Values are "RGB565" (default, 16-bit RGB), "Y8" (8-bit gray), # and "Y8INV" (8-bit gray inverted). Option          "FormatEPDC"               "Y8INV"  EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 1" Driver          "imx" Option          "fbdev"               "/dev/fb1"  EndSection  Section "Monitor" Identifier     "Configured Monitor 0" EndSection  Section "Monitor" Identifier     "Configured Monitor 1" EndSection  Section "Screen" Identifier     "Screen 0" Monitor          "Configured Monitor 0" Device          "i.MX Accelerated Framebuffer Device 0"  # These "Display" SubSection's are needed for working with the # "mxc_epdc_fb" frame buffer driver. SubSection     "Display" Depth     8 Visual     "StaticGray" EndSubSection SubSection     "Display" Depth     16 Visual     "TrueColor" EndSubSection EndSection  Section "Screen" Identifier     "Screen 1" Monitor          "Configured Monitor 1" Device          "i.MX Accelerated Framebuffer Device 1" EndSection  Section "ServerLayout" Identifier     "Xinerama Layout" Screen          "Screen 0" Screen          "Screen 1" RightOf "Screen 0" EndSection  Section "ServerFlags" Option          "Xinerama"          "true" EndSection Results The following picture shows the i.MX 53 QSB running the extended desktop previously configured. You can see the VGA monitor with a Firefox instance and the SEIKO LCD display with a calc instance.

The lastest iMX28 WinCE 6.0 BSP "WCE600_MX28_SDK1008" has a UART RX DMA data lost issue. Test case to duplicate the issue: Connect iMX28 UART1 and PC with UART cable, then run some UART test application on iMX28 and PC side, PC can send a file to IMX28, file size should bigger than the default RX DMA buffer size 1024 bytes, then from iMX28 side, there will be data lost. The attached "SERIALAPP.zip" is the updated UART driver code to fix this issue, you can unzip and update it to "wince600\platform\common\src\soc\common_fsl_v2_pdk1_9\serialapp" folder, and rebuild the WinCE image. The followed improvement had been implemented in this update for UART RX DMA: 1. Added DMA recover code.     When UART error happens in DMA mode, the driver will re-initialize the DMA for next transfer.. 2. Set UART DMA timeout interrupt to 5ms. "#define SERIAL_DMA_RX_TIMEOUT      5"     After UART DMA interrupt happens, the IST need copy data from DMA buffer to MDD buffer, so it needs time. The default BSP had set this delay to 31 bits transfer time, this is very short, if the PC send "DMA buffer + 1" bytes to iMX28, after first DMA buffer full interrupt happens, the second DMA timeout interrupt will happen in a short time, this interrupt will be lost, because the driver is still processing the pre-interrupt. 3. Updated MDD code to make sure the buffer send to PDD is always bigger than the RX DMA buffer.     This MDD code modification will only active in DMA mode, so there is no impact for PIO mode. 4. Update UART DMA interrupt handler code.     When UART DMA interrupt happens, set up the next DMA transfer at once, so DMA can continue to receive data with another DMA buffer, the same time the IST will copy data from pre-DMA buffer to MDD buffer.

Note, the tools described in this page are deprecated and are no longer maintained.  For the latest maintained i.MX 6/7 series DDR tools, the user can find these here: i.MX 6/7 Series DDR Tool Release Hi All, DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay calibration on the target board to match the layout of the board and archive the best DDR performance. In addition, the stress test can help the user to verify the DDR performance on their boards.   The following are the features supported: • Support i.MX6Q, i.MX6D, i.MX6DL, iMX6S, i.MX6SL, and i.MX6SX DDR calibration. • Support DDR3 write leveling, DQS gating, Read/Write Delay auto-calibration. • Support LPDDR2 Read/Write Delay auto-calibration. • Support 16 bits, 32 bits, and 64 bits data bus. • Support fixed-mapping 2-channel LPDDR2. • Support DDR stress test between the frequency 135MHz and 672 MHz   If  USB OTG port is not available on customer board, please use the images in DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip. The bin files in the packages can be loaded by uboot and elf files are used by JTAG load.  Please note when the image is loaded by u-boot, the DDR is initialized by u-boot (reference flash_header.S).   To run ddr stress test from u-boot, CONFIG_SPLASH_SCREEN must be disabled in u-boot. Because when enter self refresh mode in ddr stress test, DRAM access will be blocked. If splash screen in u-boot is enabled, IPU will continuously access DRAM, so the system will hang up. If you have other DMA access in u-boot, it must be disabled.   If customer uses different RX/TX pin for UART, please contact FAE.   UART1 6DQ 6DL 6SL 6SX TX CSI0_DAT10/ALT3 CSI0_DAT10/ALT3 UART1_TXD/ALT0 GPIO1_IO04/ALT0 RX CSI0_DAT11/ALT3 CSI0_DAT11/ALT3 UART1_RXD/ALT0 GPIO1_IO05/ALT0   The commands to run ddr test in i.MX6Q uboot: U-Boot > fatload mmc 2:1 0x907000 ddr-stress-test-mx6dq.bin U-Boot > go 0x907000     For i.MX6Q/6D 4K interleaved LPDDR2, please use version v1.0.3.1. i.MX6 DDR Stress Test Tool V1.0.3.1 for LPDDR2 4K interleaved mode For i.MX6/i.MX7 DDR Stress Test Tool with GUI interface, please use version V2.x: i.MX6/7 DDR Stress Test Tool V2.10   History V1.0.3:  i.MX6SoloX is supported.

Ramdisk is unnecessary thing for some embedded systems, but it's required for Android . You can develop an Android system with no ramdisk (initrd/initramfs), just follow these steps: 1) Remove RAMDISK support from kernel: General setup  --->             [ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support Create a single rootfs: cd myandroid/out/target/product/imx51_BBG mkdir rootfs sudo cp -a system rootfs/ sudo cp -a root/* rootfs/ sudo cp -a recovery rootfs/ Since you are using a single filesystem, then comment out these lines from rootfs/init.rc: #mount ext3 /dev/block/mmcblk0p2 /system #mount ext3 /dev/block/mmcblk0p2 /system ro remount #mount ext3 /dev/block/mmcblk0p5 /data nosuid nodev #mount ext3 /dev/block/mmcblk0p6 /cache nosuid nodev Create just one partition into your MMC or Flash memory: Partition 1: 200MB+ as EXT3 will be used as system(rootfs). Remember to skip 4MB to save kernel. It is a good idea to create a second partition (VFAT) to mount as /data to save user files. Mount that "system" partition and copy all content of rootfs: sudo mount /dev/sdb1 -t ext3 /mnt sudo cp -a .../target/product/imx51_BBG/rootfs/* /mnt sudo umount /mnt Now just setup your bootloader parameter correctly (i.e. MMC Partition 1): setenv bootargs_base 'setenv bootargs root=/dev/mmcblk0p1 rootfstype=ext3 console=ttymxc0,115200 noinitrd'

In some cases it is desired to directly have progressive content available from a TV-IN interface through the V4L2 capture device. In the BSP, HW accelerated de-interlacing is only supported in the V4L2 output stream. Below is a patch created against a rather old BSP version that adds support for de-interlaced V4L2 capture. The patch might need to be adapted to newer BSPs, However, the logic and functionality is there and should shorten the development time. This patch adds another input device to the V4L2 framework that can be selected to perform the deinterlacing on the way to memory. The selection is done by passing the index “2” as an argument to the VIDIOC_S_INPUT  V4L2 ioctl. Attached is also a modified the tvin unit test to give an example of how to use the new driver. An example sequence for running the test is as follows: modprobe mxc_v4l2_capture ./mxc_v4l2_tvin_vdi.out -ow 720 -oh 480 -ol 10 -ot 20 -f YU12 Some key things to note: This driver does not support resize or color space conversion on the way to memory. The requested format and size should match what can be provided directly by the sensor. The driver was tested on a Sabre AI Rev A board running Linux 12.02. This code is not an official delivery and as such no guarantee of support for this code is provided by Freescale.

The attached patch applies to iMX6_Platform_SDK for i.MX6 Dual and Quad and brings 2 additional SDMA memory to memory scripts: fixed destination address, increasing source address fixed source address, increasing destination address. With this patch, the new scripts are also integrated in the SDMA Test menu of the Platform SDK. I created these scripts starting from the ROM script ap_to_ap. In order to dump the content of the SDMA ROM, I used mxc_printSDMAcontext function which is also included in the attached patch and can be invoked when needed.

1 How to build out userdata.img and cache.img The default fsl android  bsp don't support userdata.img and cache.img. You need add the below patch to build  out these images. The hardware for below patch is imx7D. You can adjust your patch according your hardware. diff --git a/imx7/BoardConfigCommon.mk b/imx7/BoardConfigCommon.mk index 14e4881..c207727 100644 --- a/imx7/BoardConfigCommon.mk +++ b/imx7/BoardConfigCommon.mk @@ -61,7 +61,11 @@ BOARD_BOOTIMAGE_PARTITION_SIZE :=  16777216 BOARD_RECOVERYIMAGE_PARTITION_SIZE := 16777216 BOARD_SYSTEMIMAGE_PARTITION_SIZE := 377487360 +BOARD_USERDATAIMAGE_PARTITION_SIZE := 576716800 +TARGET_USERIMAGES_USE_EXT4 := true +BOARD_CACHEIMAGE_PARTITION_SIZE := 69206016 +BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4 BOARD_FLASH_BLOCK_SIZE := 4096 TARGET_RECOVERY_UI_LIB := librecovery_ui_imx - +TARGET_USERIMAGES_SPARSE_EXT_DISABLED := true 2  How to add  pre-install apk. I add a content pre-app in device/fsl/imx7. helloworld.apk is the added pre-install apk. diff --git a/imx7/pre-app/AnTutuV2.4.apk b/imx7/pre-app/helloworld.apk new file mode 100755 index 0000000..a96003a Binary files /dev/null and b/imx7/pre-app/AnTutuV2.4.apk differ diff --git a/imx7/sabresd_7d.mk b/imx7/sabresd_7d.mk index d7c5c76..11be86c 100644 --- a/imx7/sabresd_7d.mk +++ b/imx7/sabresd_7d.mk @@ -27,7 +27,8 @@ PRODUCT_COPY_FILES += \         device/fsl/common/input/20b8000_kpp.idc:system/usr/idc/20b8000_kpp.idc \         device/fsl/common/input/20b8000_kpp.kl:system/usr/keylayout/20b8000_kpp.kl \         device/fsl/sabresd_7d/audio_policy.conf:system/etc/audio_policy.conf \ -       device/fsl/sabresd_7d/audio_effects.conf:system/vendor/etc/audio_effects.conf +       device/fsl/sabresd_7d/audio_effects.conf:system/vendor/etc/audio_effects.conf \ +       device/fsl/imx7/pre-app/*:data/. 3 What are userdata.img and cache.img for? userdata.img: we need to integrate some customized APKs which should be preinstalled but should be able removed/updated by end user after product delivery. Which means they cannot be installed as system APPs in /system/app folder but User APPs in /data/app folder. At this point, we need compile userimage by ourself. Cache.img: /cache include the content when apk start running. You may storage some special content which app need. I have not find any advantage to pre-build cache.img. Note:      a. The  userdata.img and cache.img's format is sparse ext4 image. You need convert it through simg2img.           The  tool simg2img located at lp5.1_sabresd_7d_4_20/out/host/linux-x86/bin/simg2img           You can use below command to get raw ext4 userdata.img which can be burned into emmc/sd.           out/host/linux-x86/bin/simg2img userdata.img userdata_raw.img     b. BOARD_USERDATAIMAGE_PARTITION_SIZE BOARD_CACHEIMAGE_PARTITION_SIZE define the size of data and cache partition Reference: https://community.freescale.com/docs/DOC-105215

The decommission of the git.freescale.com has caused some problems to BSPs dependent on packages stored in this repository. All contents on git.freescale.com have been moved to one of three locations: NXP · GitHub  (github.com/NXP) NXP Micro · GitHub  (github.com/NXPMicro) https://source.codeaurora.org/external/imx/   In the case of some older Android BSP this causes an error when fetching the imx-firmware packages originally stored in this repository. A workaround to this is to switch the original location to the new location. To do this we would need to manually create a build directory and initialize repo to locally load the manifest files and then make this change. Android BSP won’t require this workaround. Please note that this workaround only addresses this specific error that may show up when running the script included on the BSP release. We will be using the Oreo o8.0.0_1.0.0_ga BSP release as an example. Sources for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Design_Tools_Tab Documentation for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Documentation_Tab    1) Initialize the repo. If you have tried running the imx_android_setup.sh script the android build directory should already have been created. If this is the case, please skip to the next step. If not, please create it either by running imx_android_setup.sh or manually with the following commands (using the android setup script is preferred): $ mkdir android_build Once inside the build directory, initialize the repo and then sync it: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest.git -b imx-android-oreo -m imx-o8.0.0_1.0.0_ga.xml $ repo sync   2) Find and edit the Android Manifest. Once inside the build directory after synching, enter the repo manifests directory by executing the following command while inside the android build directory $ cd .repo/manifests  And look for the corresponding Android manifest. In this case imx-o8.0.0_1.0.0_ga.xml Open this file in any text editor (use sudo if running in a directory which requires it) In this case we’ll exemplify with nano $nano imx-o8.0.0_1.0.0_ga.xml And change the git://git.freescale.com/proprietary/  to git://github.com/NXP/ Also the path for imx-firmware so the complete line goes from: <project path="vendor/nxp/imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ To the following: <project path="imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ The manifest should look like the following. Save the file with these changes.   Now you can run the imx_android_setup.sh build script successfully. Since the repo was already synced it won’t fetch the manifests again and the change we made will persist, which will allow to find the imx-firmware package on its new location.

       Of all the i.MX serials SoC, i.MX28/i.MX6UL/i.MX7D/S use Synchronous Audio Interface(SAI) to support audio applications. SAI supports I2S, AC97, TDM and code/DSP interfaces. The SAI interface consists of these signals: SAI_MCLK         ------------  used to provide working clock for external audio device , such as audio codec. SAI_RX_BCLK  ------------  bit clock for receiving channle. SAI_RX_DATA   ------------  data of receiving channel. SAI_RX_SYNC  ------------  Frame Synchronous signal of Left and right channel for receiving channel. SAI_TX_BCLK  ------------  bit clock for transmitting channel. SAI_TX_DATA   ------------  data of transmitting channel SAI_TX_SYNC  ------------  Frame Synchronous signal of Left and right channel for transmitting channel.         According to above signals, SAI has 2 channels: receive and transmit, and these 2 channels have their own clock: bit clock and frame SYNC, so they can work independently, it means PLAY and CAPTURE can be operated simultaneously, that is to say, SAI works at Asynchronous mode this moment.        In the document, we will discuss several usages of SAI on hardware design when it works at I2S(SYNC) mode. we will take i.MX6UL as an example, and for i.MX7D/S, usages are similar. 1. IOMUX of SAI From i.MX6UL reference manual, there are 3 SAI modules in i.MX6UL: SAI1 , SAI2 & SAI3, see page 2529 in IMX6ULRM.pdf. As common applications, we will use 2 interface of SAIs. 2. Hardware connections for I2S mode Either CPU is Master or Codec is Master, hardware connections are same. (1) Single audio codec or (2) Dual audio codec (3) Audio codec + Bluetooth PCM or (4) Audio codec + Bluetooth PCM + 4G PCM or     [Note]   Attachments are schematics of WM8958 and MAX98089, which are not released by NXP, just for users who are interested in i.MX audio applications reference. If you want to use WM98089 or WM8958, please contact their manufactures and confirm if schematics are correct, so don't use them directly for your solution. NXP China TIC i.MX team Weidong Sun

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343777 

MX6X_eMMC_turning_2014.11.11_V2.doc

The i.MX6 DL/S L3.035_3.0.4 patch release is now available onwww.freescale.com ·         Files available # Name Description 1 L3.0.35_3.0.4_TEMP_PATCH This patch release is based on the i.MX 6DualLite/6Solo   Linux L3.0.35_3.0.0 release. The purpose of this patch release is fix the   miscalibration issue for the thermal sensor.

When boot from battery, then plug in 5V cable, the actual charging current can't reach the preset charging current. It is because the HEADROOM_ADJ is not correctly set. Please use attached mx28_chargingcurrent_limit_bootfrombattery.patch. Grace

Question: 1)      Is WDOG2 somehow accessible from customers code in normal mode? Is it only used within the trust zone to protect against DOS attacks from normal world?) 2)      Is there any mechanism preventing changing of the watchdog registers like being able to write them only during a period after Reset? If yes, which registers are protected? Answer: WDOG1 and WDOG2 are identical the only difference is how the signals are connected. There is nothing presenting someone from using both WDOGs for non-secure purposes. There is no time window for WDOG access but there are some write-once only bits in the register, which can be written only once after reset, after that all following writes will be ignored. They are clearly described in the RM. The bits are: WDZST, WDBG, WDW, WDE, WDT, WIE, WICT, and PDE.

What is HOB? Hob is a graphical user interface for BitBake. Its primary goal is to enable a user to perform common tasks more easily. It basically runs the Bitbake commands on the background while showing a Graphic User Interface. Hob may not work correctly with Daisy metadata as it is getting deprecated in favor of a new web based interface for Yocto under the name Toaster. Here is what you can do with the current version of Hob on the Freescale Community BSP and BSP Release. - Build images - Edit existing image recipes - Create your own image recipes Note: HOB will write the local.conf file and make modifications which may conflict with baking images outside of HOB. In this case you may need to re-run the environment initialization in order to restore the local.conf file. Starting HOB Once the environment has been initialized (using the setup-environment script on the Freescale Community BSP or the fsl-setup-release on the Freescale BSP Release) use the command below. $ hob & The GUI should then appear: You may then select the MACHINE for which you will build and the Layers of your project. HOB  will take and updated the local.conf and bblayers.conf values so the desired BSP layers will already be selected and available MACHINES on these layers will appear on the drop down menu. Once these options are set HOB will parse the recipes and create a dependency tree in order to show available images for that MACHINE. Image File System Types Advance configuration options include image file system types. Please note that HOB does not support the sdcard format so if it is needed it has to be added manually on the local.conf file and then run bitbake outside of HOB. As HOB changed the local.conf file even if the sdcard format was originally available it may be rewrite and no longer available until the following line is added to local.conf. IMAGE_FSTYPES="tar.bz2 ext3 sdcard" Recipes screen On the recipes screen we can see the recipes included on the image and available recipes, then also package groups. Time to bake! After these configurations you may either build the packages using HOB interface or run Bitbake outside of HOB. (In case you wish to have your image on the sdcard format please see the earlier image types clarification) The resulting image will be stored on <BUILD>/tmp/deploy/images/<MACHINE> You may also save your image recipe with the selected customizations.