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

The customer would like to test BT.656 using Test mode. Is it supported? 38.4.3.3 Test mode in RM shows only one CSIx_SENS_CONG setting. Does it mean Test mode support only one as follows? Does Test mode support other settings? CSIx_EXT_VSYNC = 0x1 CSIx_DATA_WIDTH = 0x1 CSIx_SENS_DATA_FORMAT = 0x0 CSIx_PACK_TIGHT = 0x0 CSIx_SENS_PRTCL = 0x1 CSIx_SENS_PIX_CLK_POL = 0x1 CSIx_DATA_POL = 0x0 CSIx_HSYNC_POL = 0x0 CSIx_VSYNC_POL = 0x0 For example, customer want to know if Test mode support  CSIx_SENS_PRTCL=0x2or 0x3 instead of 0x1? customer want to know if Test mode support CSIx_SENS_DATA_FORMAT=0x1or 0x2 instead of 0x0? Answer: CSI CM TEST MODE is working as below: 1,only ungated mode. 2,data width should be configured to 8 3,data format should be configured to rgb888 It cannot be other format such as bt656. It uses CSI1_TST_CTRL register to configure {R,G,B} 24 bit value and taking it as RGB888/YUV444 format for further process.  The generated image size is due to the configured width & height in the registers.

Inside IPU there are two block where color space conversion can be made: IC (Image Converter) and DP (Display processor). On Linux, the CSC parameters are located at IPU (IC and DP) drivers, linux/drivers/mxc/ipu3 folder. All negative coefficients are represented using two's complement. Linux Image Converter driver: The parameters are set on function _init_csc: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_ic.c?h=imx_3.14.28_1.0.0_ga static void _init_csc(struct ipu_soc *ipu, uint8_t ic_task, ipu_color_space_t in_format, ipu_color_space_t out_format, int csc_index) { /* * Y = 0.257 * R + 0.504 * G + 0.098 * B + 16; * U = -0.148 * R - 0.291 * G + 0.439 * B + 128; * V = 0.439 * R - 0.368 * G - 0.071 * B + 128; */ static const uint32_t rgb2ycbcr_coeff[4][3] = { {0x0042, 0x0081, 0x0019}, {0x01DA, 0x01B6, 0x0070}, {0x0070, 0x01A2, 0x01EE}, {0x0040, 0x0200, 0x0200}, /* A0, A1, A2 */ }; /* transparent RGB->RGB matrix for combining */ static const uint32_t rgb2rgb_coeff[4][3] = { {0x0080, 0x0000, 0x0000}, {0x0000, 0x0080, 0x0000}, {0x0000, 0x0000, 0x0080}, {0x0000, 0x0000, 0x0000}, /* A0, A1, A2 */ }; /* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));   G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));   B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128); */ static const uint32_t ycbcr2rgb_coeff[4][3] = { {149, 0, 204}, {149, 462, 408}, {149, 255, 0}, {8192 - 446, 266, 8192 - 554}, /* A0, A1, A2 */ }; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Linux Display Processor driver: The parameters are set on constants (rgb2ycbcr_coeff and ycbcr2rgb_coeff): http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_disp.c?h=imx_3.14.28_1.0.0_ga /* Y = R * 1.200 + G * 2.343 + B * .453 + 0.250;   U = R * -.672 + G * -1.328 + B * 2.000 + 512.250.;   V = R * 2.000 + G * -1.672 + B * -.328 + 512.250.;*/ static const int rgb2ycbcr_coeff[5][3] = { {0x4D, 0x96, 0x1D}, {-0x2B, -0x55, 0x80}, {0x80, -0x6B, -0x15}, {0x0000, 0x0200, 0x0200}, /* B0, B1, B2 */ {0x2, 0x2, 0x2}, /* S0, S1, S2 */ }; /* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));   G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));   B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128); */ static const int ycbcr2rgb_coeff[5][3] = { {0x095, 0x000, 0x0CC}, {0x095, 0x3CE, 0x398}, {0x095, 0x0FF, 0x000}, {0x3E42, 0x010A, 0x3DD6}, /*B0,B1,B2 */ {0x1, 0x1, 0x1}, /*S0,S1,S2 */ };‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Freescale's PF0100 PMIC should have VDDIO power tied to the same supply as the associated I2C supply on MX6. There is a momentary on-chip sneak path on power-up if VDDIO is wired per the i.MX6 SABRE-AI automotive development platform. As a result, I2C power rail P3V3_DELAYED rises prematurely due to backfeed from P3V3 through the I2C port. Note that on SABRE-AI, P3V3 powers up before P3V3_DELAYED. Existing SABRE-AI design: PF0100 VDDIO is wired to P3V3. Corrective action for mass production: Wire PF0100 VDDIO to P3V3_DELAYED; same supply as the associated I2C supplies on MX6 (NVCC_EIM0 and NVCC_GPIO). Laboratory results attached.

ESAI module in i.MX6D/I.MX6D/I.MX6DL/I.MX6S supports several RESET funtions: Reset ESAI Core, Reset both Transmitter and Receiver, Reset Transmitter individually, Reset Receiver individually, Reset Transmitter FIFO and Reset Receiver FIFO. Below is a simple diagram for these RESET functions, which shows reset object and related register configurations. 1.Reset ESAI Core After setting ESAI_ECT ERST bit to be 1, ESAI core and configuration registers will be reset, but Transmitter and Recevier FIFOs can't be reset by the operation. 2. Reset both Transmitter and Receiver After setting ESAI_PCRC & ESAI_PRRC to be 0x000, Transmitter and Receiver can both be reset, The RESET is also called "Personal Reset" in it's reference manual. About PCRC & PRRC bits functionality, we can see the table: From the table, ESAI_PCRC=0x000 and ESAI_PRRC=0x000 will make ESAI disconnet external ESAI pins, and ESAI's Tranmitter and Receiver can't communicate with external audio codec.  See ESAI_PCRC and ESAI_PRRC register below: ---ESAI_PCRC register ---ESAI_PRRC register There are 12 bits in each register to contorl "DISCONNECTION" OR "CONNECTION" with ESAI pins. So for normal operations of ESAI, these 2 registers can't be changed. 3.Reset Transmitter & Receiver individually By setting ESAI_TCR[TPR]=1, Transmitter can be reset individually, and not affect Receiver. By setting ESAI_RCR[RPR]=1, Receiver can be reset individually, and not affect Transmitter . In reference manual, the reset is called "personal reset / individual reset", actually they means the same thing: --Reset Transmitter individually. --Reset Receiver individually. 4.Reset Transmitter FIFO and Reset Receiver FIFO ---By setting ESAI_TFCR[TFR]=1, Tranmitter FIFIO can be reset. ---By setting ESAI_RFCR[RFR]=1, Receiver FIFO can be reset. The Reset requires ESAI is operational, which means at least one pin is defined as an ESAI pin. NXP TIC team Weidong Sun

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 is a HW design checklist for customer's reference. Please read and fill it in carefully before requesting a schematic review. Rev3.1 @2016.10.19 -- 1. Add i.MX6DQP related contents.

BlueZ5 provides support for the core Bluetooth layers and protocols. It is flexible, efficient and uses a modular implementation. BlueZ5 has implemented the Bluetooth low level host stack for Bluetooth core specification 4.0 and 3.0+HS which includes GAP, L2CAP, RFCOMM, and SDP. Besides the host stack, BlueZ5 has also supported the following profiles itself or via a third party software. Profiles provided by BlueZ: A2DP 1.3 AVRCP 1.5 DI 1.3 HDP 1.0 HID 1.0 PAN 1.0 SPP 1.1 GATT (LE) profiles: PXP 1.0 HTP 1.0 HoG 1.0 TIP 1.0 CSCP 1.0 OBEX based profiles (by obexd): FTP 1.1 OPP 1.1 PBAP 1.1 MAP 1.0 Provided by the oFono project: HFP 1.6 (AG & HF)Supported Profiles BlueZ5 has been supported in the latest Freescale Linux BSP release, so it would be pretty easy to generate the binaries for Bluetooth core stack and its profiles. In order to support A2DP sink on a SabreSD board, the following software should be downloaded and installed onto the target rootfs too. sbc decoder version 1.3 (http://www.kernel.org/pub/linux/bluetooth/sbc-1.3.tar.gz) PulseAudio 5.0 (http://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-5.0.tar.xz) PulseAudio package has some dependencies with bluetooth and sbc packages, and pulseaudio will detect if the two packages have been built and then decide which pulse plugin modules to be generated. So the building order will be 1) bluez5_utils or bluez_utils   2) sbc   3) pulseaudio. After compile and install the above software onto the target rootfs, you should be able to see the following executable under the directory /usr/bin From BlueZ5: bluetoothctl, hciconfig, hciattach (Needed by operating a UART bluetooth module) From PulseAudio: pulseaudio, pactl, paplay If the building dependency has been setup correctly, the following pulse plugin modules should be located under the directory /usr/lib/pulse-5.0/modules module-bluetooth-discover.so      module-bluetooth-policy.so        module-bluez5-device.so   module-bluez5-discover.so Edit the file /etc/dbus-1/system.d/pulseaudio-system.conf, and add the following lines in red: <policy user="pulse">     <allow own="org.pulseaudio.Server"/>    <allow send_destination="org.bluez"/>     <allow send_interface="org.freedesktop.DBus.ObjectManager"/> </policy> Edit the file /etc/dbus-1/system.d/bluetooth.conf, and add the following lines: <policy user="pulse">      <allow send_destination="org.bluez"/>      <allow send_interface="org.freedesktop.DBus.ObjectManager"/> </policy> Adding the following settings at the bottom of the pulseaudio system configuration file which locates in /etc/pulse/system.pa ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif load-module module-switch-on-connect load-module module-alsa-sink device_id=0 tsched=true tsched_buffer_size=1048576 tsched_buffer_watermark=262144 On the system that can automatically detect the alsa cards, the above line #13 should be removed.  Also make sure "auth-anonymous=1" is added to the following line, which can resolve the issue: "Denied access to client with invalid authorization data". load-module module-native-protocol-unix auth-anonymous=1 Selecting a audio re-sampling algorithm and configuring the audio output by adding the following settings to the file daemon.conf locating in /etc/pulse resample-method = trivial enable-remixing = no enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 48000 alternate-sample-rate = 24000 default-sample-channels = 2 Pulseaudio can be started as a daemon or as a system-wide instance. To run PulseAudio in system-wide mode, the program will automatically drop privileges from "root" and change to the "pulse" user and group. In this case, before launching the program, the "pulse" user and group needs to be created on the target system.  In the example below, "/var/run/pulse" is the home directory for "pulse" user. adduser -h /var/run/pulse pulse addgroup pulse-access adduser pulse pulse-access Because PulseAudio needs to access the sound devices, add the user "pulse" to the "audio" group too. adduser pulse audio Starting bluetoothd and pulseaudio: /usr/libexec/bluetooth/bluetoothd -d & pulseaudio --system --realtime & To verify if the pulseaudio has been set up correctly, you can play a local wave file by using the following command. If you can hear the sound, the system should have been configured correctly. paplay -vvv audio8k16S.wav After setting up the pulseaudio, launch bluetoothctl to pair and connect to a mobile phone. After connecting to a mobile phone, you should be able to see the following information in bluetoothctl console: [bluetooth]# show Controller 12:60:41:7F:03:00         Name: BlueZ 5.21         Alias: BlueZ 5.21         Class: 0x1c0000         Powered: yes         Discoverable: no         Pairable: yes         UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)         UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)         UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)         UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)         UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)         UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)         UUID: Message Access Server     (00001132-0000-1000-8000-00805f9b34fb)         UUID: Phonebook Access Server   (0000112f-0000-1000-8000-00805f9b34fb)         UUID: IrMC Sync                 (00001104-0000-1000-8000-00805f9b34fb)         UUID: OBEX File Transfer        (00001106-0000-1000-8000-00805f9b34fb)         UUID: OBEX Object Push          (00001105-0000-1000-8000-00805f9b34fb)         UUID: Vendor specific           (00005005-0000-1000-8000-0002ee000001)         UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)         UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)         Modalias: usb:v1D6Bp0246d0515         Discovering: no If you can see the audio sink UUID, you are ready to enjoy the bluetooth music now.

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. The aggregator portion of the i.MX Power Profiling System sits between the "smart" current sensor boards and the host computer. It provides power and signal connections to each connected sensor board. The communication is done over I2C, where three I2C bus extenders (PCA9518) effectively provide a dedicated bus to each I2C device, to better allow for cabling.  More information will follow... A photo, layout images and schematic attached below.   MBED source for the FRDM-KL25Z is available here: 30848-KL25Z-AGGREGATOR    Smart Sensor Connections At each smart sensor header JP0-JP13, these are the connections provided: 5V: powers the 3.3V regulator on each sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX0: I2C clock line  SDA/RX0: I2C data line  SWD_CLK:  global line for triggering smart sensors to make measurements RESET_B:  global line for resetting all smart sensor boards SWD_IO_n: individual select line for each smart sensor I2C Bus Connection Three I2C bus extenders (PCA9518) provide buffered connections between the FRDM board and all the connected smart sensors. The bus extenders were added to allow for longer cables between the aggregator and the smart sensor boards. Each bus extender has five ports and along with connections that allow extending the bus to more bus extenders. Gate Supply The aggregator contains a boost regulator that boost the 5V input from the FRDM board to 12V. The boosted voltage is fed to each of the smart sensor headers. It's used by the smart sensor board to pull up the gates of the switching FETs above any of the rails under test by at least 4.5V in order to benefit from a lower Rds(on). Caution must be exercised with some older FRDM boards since the 5V from the USB connection passes through diodes with a maximum current of 200mA.  The boost regulator and the load presented by the smart sensor boards may exceed the diode's limit and damage it. (Yes, it's happened... two older FRDM-KL25Z boards were used during development. One of them failed with the diode shorted (~0.05 Ohms), so everything kept working. The other failed with a  short of ~45 Ohms, so it kind of worked but not really...) Application Code for Aggregator  To date, application code has only been developed for the FRDM-KL25Z board. The latest application code resides at: https://os.mbed.com/users/r14793/code/30848-KL25Z-AGGREGATOR/, with the latest binary attached below. SWD Programming of Smart Sensors  Connectors J5 and JP15 are provided as an adapter for programming the smart sensor boards via SWD. JP15 provides power to the smart sensor board, since they have no direct 3.3V input for the KL05Z. An SWD programmer (or suitably modified FRDM-KL05Z board) connects to J5. Both connections use 10-pin 0.05"-spaced ribbon cables. Additionally, when a smart sensor is connected to JP15, J6 provides access to the UART pins of the smart sensor (the I2C pins on the smart sensor also mux out the UART of the KL05Z). No hardware changes are necessary at all; changing the code running on the smart sensor is all that's required. In fact, during the initial prototyping of the smart sensors, the serial UART connection was used instead of I2C. Modify Aggregator To Use SWD Dongle To Program Smart Sensor:  Add a wire as shown on the bottom side of the aggregator board as shown below. This ties 3.3V on the aggregator to the debug header, enabling the voltage level translators on the dongle to communicate with the KL05Z on the smart sensor board.  

The Linux L4.14.98_1.0.0_GA; and SDK2.5 for 8QM/8QXP Post GA, SDK2.5.1 for 7ULP GA3 release are now available. Linux on IMX_SW web page, Overview -> BSP Updates and Releases -> Linux L4.14.98_2.0.0 SDK on https://mcuxpresso.nxp.com Files available: Linux:  # Name Description 1 imx-yocto-L4.14.98_2.0.0_ga.zip L4.14.98_2.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip 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 3 L4.14.98_2.0.0_ga_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 L4.14.98_2.0.0_ga_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 L4.14.98_2.0.0_ga_images_MX7DSABRESD.zip i.MX 7Dual SABRESD Linux Binary Demo Files  6 L4.14.98_2.0.0_ga_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  7 L4.14.98_2.0.0_ga_images_MX8MMEVK.zip i.MX 8MMini EVK Linux Binary Demo Files  8 L4.14.98_2.0.0_ga_images_MX8MQEVK.zip i.MX 8MQuad EVK Linux Binary Demo files 9 L4.14.98_2.0.0_ga_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 L4.14.98_2.0.0_ga_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.tar.gz System Controller Firmware (SCFW) porting kit of L4.14.98_2.0.0 12 imx-aacpcodec-4.4.5.tar.gz Linux AAC Plus Codec v4.4.5 13 VivanteVTK-v6.2.4.p4.1.7.8.tgz Vivante Tool Kit v6.2.4.p4.1.7.8   SDK: On https://mcuxpresso.nxp.com/, click the Select Development Board, EVK-MCIMX7ULP//MEK-MIMX8QM/MEK-MIMX-8QX to customize the SDK based on your configuration then download the SDK package.  Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD and SABRE-AI Boards MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board 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 of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-sumo ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-sumo#

Hi All, The i.MX6 Android R13.4.1.04 patch release is now available onwww.freescale.com ·         Files available # Name Description 1 IMX6_R13.4.1.04_ANDROID_PATCH This patch release is based on the i.MX 6 Android R13.4.1   release. The purpose of this patch release is correct the PFD workflow in   U-Boot, fix the miscalibration issue for the thermal sensor and corrects   ramp-up time of the internal LDOs

The document includes the following contents: (1)document how to port ov5646 to android jb4.2.2 (2) ov5645 driver for Linux 3.0.35 (3) ov5645 schematic based on i.MX6Q/DL (4)ov5645 for android camera HAL   [Note:]      P5V29A-0JG is a camera module based on OV5645, and PAO532-0JG is based on OV5640, both manufactured by NINGBO SUNNY OPOTECH CO.LTD (China), If customer wants to use them on i.MX6 platform, can send me email to ask for datasheets of P5V29A & PAO532 , or discuss corresponding questions on porting.   Email: weidong.sun@freescale.com

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