Question: What’s the best way to rotate a MX6 image 90 degrees, thought the IPU correct? IPU is limited to 1024x1024. Apparently we don’t support frame buffer rotation in the IPU, so we have to use some middleware. I know that Android’s surface flinger uses the GPU but do you know what we can use in Linux that uses H/W acceleration also? It looks look like X-server can rotate only when the Vivante driver is not  loaded, which means the hardware is not implementing rotations. Answer: it should be possible to split the picture into two halves and rotate them separately. Well, two halves if you can reduce the line count to 1024 … otherwise it would be 4 rotates. X11 Xrandr will be implemented on GPU sometime this year. It's in the R&D queue but as low priority. They could use GC320 low level API to rotate (if they use linux frame buffer). It implies a blit but it would be done by GC320 they will probably need to use virtualFB too. The API documentation is the BSP documentation (iMX6.2D.API.pdf) Attached a simple source using the 2D low level API. VirtualFB: https://community.freescale.com/message/289198

Question: LVDS in split mode (dual lvds) is used. In this configuration, only LVDS0_CLK is used. What is the suggestion for the LVDS1_CLK?  The HW user guide says that if this is unused, then to leave it floating.  Would we also suggest the same for this case or would termination be more appropriate?  Or is there some possible way to gate this clock?  (if so, it isn't obvious in the RM) Answer: According to the MX6 Developer's Guide, any unused LVDS pins should be left floating, so the LVDS1_CLK pair, in this case should be left floating. In order to minimize any potential EMC, the lands for those balls should not have any additional traces leading away. To add a bit more information, the customer ran some tests and found that the clock gate bits for the LVDS1 are essentially ignored in Dual mode.  The only way to disable it is if they are both disabled which is not helpful in this case.  It seems that the Dual mode setting overrides the CG.

Some of SDIO cards need SD clock active for 4-bit mode, in order to generate interrupt. But i.MX6 SD controller enables SD clock gated by default, the attached patch is an example to disable SD clock gated. It's able to check if clock gated is enable or not by the register, "uSDHCx_PRES_STATE:SDOFF", of SD controller.

Description by Google:      Wi-Fi scan-only mode is a new platform optimization that lets users keep Wi-Fi scan on without connecting to a Wi-Fi network, to improve location accuracy while conserving battery. Apps that depend on Wi-Fi for location services can now ask users to enable scan-only mode from Wi-Fi advanced settings. Wi-Fi scan-only mode is not dependent on device hardware and is available as part of the Android 4.3 platform. Comments by Freescale:      In order to enable wifi scan mode, we should make sure wifi driver shouldn't be removed while switching off wifi from Setting. Additionally, android4.3 has introduced one CTS test to force us to change all loadable modules into kernel built in. The reason is loadable modules are often used by rootkits and other exploits. so there will be big risk in security. OK, now let's try to keep up with the pace of AOSP.      For AR6003, we are using compat-wireless driver which accommodates all linux kernel since 2.6.We are now using olca-3.4 wifi driver but our kernel version is 3.0.35.  It is not a simple change to be directly compiled into kernel since it is lack of the basic file structure for ath6kl driver. This has been double confirmed by support guy from Atheros. More terribly, Atheros has no plan to publish new version for AR6003 but just maintain it. Yeah, my pitiful baby. Say goodbye to scan mode.      This is why this document come into being. AR6003 is our default wifi module bounded to our imx6 serial board. So formal release will lose this important feature for this limitation. Here I will give out patches to enable this feature using another wifi module-----Realtek 8723as. Ok, now let's welcome this new star. Patches description:          Patch for kernel--------Change loadable driver modules to compiled into kernel, this will let wlan0 and p2p0 interfaces still can be operated although you have switched off wifi in Setting UI.      Patch for device/fsl--------Firstly, I delete one rfkill operation in init.rc which is obsolete for BT setting. If still keep it here, it will soft block wifi interface through mac80211 rfkill. Then I clean up some setting for wifi driver module.      Patch for hardware/libhardware_legacy-------Since wifi driver is already directly built in kernel, HAL will have no need to load driver now. Refactor it and optimize it. Test it manually:          If you have one sdio rtl8723as wifi module in hand, you can test it like the following to see wifi scan mode works: Firstly, disable wifi in Setting UI. then you can check netcfg result, you will see wlan0 and p2p0 are still there, only down state: Go "advanced" menu in wifi setting,Turning on the checkbox of "Scanning always available". Check netcfg result again, Oh Oh, wlan0 and p2p0 are up: Manually "scan" through "wpa_cli" tool, you will see it works:

Attached patch enable dual display on i.MX51 wince6. It will set DI0 as main display.

In our default release , the eboot logo only can be show on WVGA panel. Attached patch file can let the eboot logo show both on DVI XGA and RGB WVGA panel.

Question: After a JTAG Reset with his GHS MULTI Probe on i.MX6 Hardware, read the SRC_SRSR register the corresponding reset source bits (JTAG reset) are not set. The contents: SRSR = 0x1      WARM Boot = 0x0      jtag_sw_rst = 0x0      jtag_rst_b = 0x0      wdog_sw_rst = 0x0      ipp_user_reset_b = 0x0      cpu_reset_b = 0x0      ipp_reset_b = 0x1 Tried to reproduce this with my DSTRAM probe, and issued a "reset reset.system" command in DS-5 Debugger but Program Counter stays at current vaule. Obviously my SRSR bits don't change either. Answer: Seems " jtag_rst_b" is a HW reset, please check the connection between JTAG port and i.Mx6 JTAG_TRST pin. And confirm the waveform on rest pin when JTAG reset run.

We have a ATK tool which can program image, also it can burn fuse for i.MX51. Since fuse is one time program, so please take care the fuse can't be turn back after programmed.

Questions: 1.  Are there any hardware limitations (such as in the Host Controller IP block itself, how this IP block was implemented or in the DMA engine) to how many device endpoints the i.MX53 can handle on Host2 or Host3?  The Reference Manual notes that the OTG controller supports up to 8 endpoints but does not provide information on the Host Controller. 2.  Do any of the device validation tests for verifying the i.MX53 design (or USB cert tests) test compatibility/performance with multiple devices and multiple endpoints? 3.  What are the maximum number of endpoints Freescale has tested with? Problem Background: During extensive testing the customer observes 100% CPU utilization with only 6 endpoints (can be a combination of multi-endpoint devices or single-endpoint devices - see below for test configuration details) using our latest Linux reference BSP (2.6.35 Kernel).  They have tested with the Adeneo WEC7 BSP and the open source Linux kernel based on 3.11 for the QSB and have observed similar performance limitations. This has been tested with multiple packet sizes and device/endpoint configurations and no impact has been shown in varying these parameters. The customer did note that they are only receiving/processing a single interrupt at the 1ms boundary regardless of the number of devices/endpoints.  Processing this interrupt takes approximately 23us for one device and an additional 17us for each additional device endpoint after the first that is processed. The customer hardware configuration for their testing looks something like this: On the customer's board: [i.MX53 Host2/Host3] -> [SMSC 3315 USB High Speed ULPI PHY] -> [SMSC LAN9514 On-board 4-port USB 2.0 HS Hub] External: [SMSC LAN9514 Port #1] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #1-4 [SMSC LAN9514 Port #2] -> [SMSC USB2415 4-Port USB 2.0 HS Hub] -> Medical device w/ endpoints #5-8 [SMSC LAN9514 Port #3] ->  Medical device w/ endpoint #9 [SMSC LAN9514 Port #4] ->  Medical device w/ endpoint #10 Answer: Hosts do not have endpoints. Only devices have endpoints. EHCI compliance hosts, like all i.MX devices, use a linked list of queues (for bulk/control transport). Each queue has a queuehead that represents a corresponding endpoint and has the endpoint's capabilities. On the queue are transfer descriptors that have the information of which data is to be moved to/from the endpoint of the device. All of this is in main memory and read/written under DMA.  There is no limit on how many devices/endpoints a host can service, other than the amount of available main memory (DRAM). The CPU has to build the linked lists, but this is  normally not taking much bandwidth. My guess at this time is that there may be a problem in the USB driver, or the application that is using the driver, or a problem with data alignment. For efficient operation, data must be aligned on 32-bit boundaries. Buffers are best aligned on 64-byte boundaries.

Question: What is minimum requirement for VDDSNVS_IN voltage to keep RTC timing info in SNVS block? In the datasheet, there is requirement for VDDSNVS_IN input and it is 2.9V to 3.3V. Is it recommended requirement for RTC operation? Other security function is not used in SNVS and just interested in basic RTC fuction after power off. Answer: The finall answer is tha to folow our datasheet saying for no matter if you are only RTC keeping application. "The SNVS regulator takes the SNVS_IN supply and generates the SNVS_CAP supply which powers the real time clock and SNVS blocks. If  VDDHIGH_IN is present, then the SNVS_IN supply is internally shorted to the VDDHIGH_IN supply to allow coin cell recharging if necessary. The output voltage is roughly one third(1/3) of SNVS_IN. -- in the SNVS_CAP powered on-chip logics, need min 0.9v for normal operation, we can only guarantee the operation in this condition, whih means min SNVS_IN = 3*SNVS_CAP = around 2.7. with some margin, so min 2.8v is the requireent. Again, we can only guarantee the operation in this condition(VDD_SNVS_CAP >0.9v). The datasheet is correct : VDDSNVS_IN must not be less than 2.8 V (Table 6. Operating Ranges, of IMX6DQCEC,  Rev. 2.2, 07/2013 )  I guess you talked about operating condition in ON mode. In case of OFF mode, VSNVS output of PFUZE depends on LICELL input power and usually coincell can supply under 2.5V output. According to PFUZE spec, VSNVS output in OFF mode is under 1.8V. And as I know, LP (low power) part of SNVS is only operation al in OFF mode so I don't think VDDSNVS_IN requires over 3V in that condition. In my assumption, SNVS can maintain itis data and RTC if VDDSNVS_IN is over 1.1 ~ 1.3V in OFF mode but I just want to know what is our spec for it. If we consider low power modes of the i.MX6, then - according to Table 10 (Stop Mode Current and Power Consumption) of IMX6DQCEC, Rev. 2.3, 07/2013 (for example) - in "SNVS Only" mode VDD_SNVS_IN of 2.8V is considered. Here 2.8 V is taken as minimal value. At least, as we can see, there are no other specifications.

In the default release the SSI1 doesn't suport double FIFO in audio driver. Attached was the code to support double FIFO with updated DMA script.

In i.MX51 platfrom the PMIC 13892 also has a internal RTC. We can use this RTC instead of the i.mx51 SRTC. Attached was the implementation of it.

Currently the default i.MX51 wince release doesn't support high capacity MMC card. Attached was the patch of how to enable high capacity MMC card in i.mx51. Original Attachment has been moved to: High-capacity-MMC-support.zip

We use flash header which will be access by ROM code to do the NAND boot or secure boot. This is a document introduce the flash header.

In the i.MX51 default WINCE6  release, the eCSPI doesn't support multiple bursts mode and set the wait states. Attached was the document and code for how to enable the multiple bursts mode and how to set the wait states between two burst.

Question: How much control of the bitrate does the i.MX6's VPU provide? VPU API includes a bitrate setting in the EcnOpenParam, is this a maximum, minimum, or something else? To encode two 1280x1080 streams at 30fps with a bit rate of at least 20Mbps, from the information in the following thread, it looks like this isn't supported due to VPU bandwitdh, Is there any limit on bitrate due to the VPU's processing bandwidth?  I.e., if the stream is limited to one 1280x1080 channel, can we choose a maximum bit rate and if so, how do we determine what it is? Answer: The bitRate field in the EncOpenParam structure is the desired target bit rate in kbps. If 0, there is no rate control and frames are encoded based on the quantization parameter specified by the quantParam field in EncParam.structure. It seems upper limit is 20Mbps for 1280x1080@30fps. So you should specified bitrate=2000 in your use case. In general, the maximum bitrate is about 30Mbps. Vpu driver will return invalid parameter if the appointed bitrate reach out of the range (0, 32767kbps). Please refer to Q&A: MX6 VPU H.264 Dual Stream Encode Limits.

Question: Is it true ture that MX6 VPU is capable of encoding dual H.264 streams that are 1024x600 at 60fps?  There are slides that claim three 720p30 streams or two 1080p30 streams simultaneously. There is little guidance as to what the VPU limits in resolution, frame rate and bit rate are for other resoluitons and frame rates. Is there any information that can be used to decide if  the VPU can encode an arbitrary video stream or multiple arbitrary video streams?  Since memory bandwidth will enter into this decision at some point has anyone quantified the memory bandwidth requirements verses video resolution and frame rate? Answer: Maximum supported trhoughput,  is 72,576,000 pixels /s @ VPU frecuency of 266 mhz 2 x  1024 x 600 x 60hz = 73,728,000 So this is not supported. If framerate is lower i.e.  30hz  then it will be supported.

Hi All, The new i.MX 6 Q/D/DL/S/SL L3.0.35_4.1.0 GA release is now available on the http://www.freescale.com/site. ·         Files available                                   # Name Description 1 L3.0.35_4.1.0_LINUX_DOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Documentation. Includes Release Notes, Reference Manual, User guide. API   Documentation 2 L3.0.35_4.1.0_LINUX_MMDOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Documentation.   Includes CODECs Release Notes and User's Guide 3 L3.0.35_4.1.0_SOURCE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Source Code Files 4 L3.0.35_4.1.0_MM_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Sources 5 L3.0.35_4.1.0_AACP_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux AAC Plus Codec 6 L3.0.35_4.1.0_DEMO_IMAGE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Binary Demo Files 7 L3.0.35_4.1.0_UBUNTU_RFS_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux File System for the Ubuntu Images 8 i.MX_6D/Q_Vivante_VDK_146_Tools Set   of applications for the Linux L3.0.35_4.1.0 BSP, designed to be used by   graphics application developers to rapidly develop and port graphics   applications. Includes applications, GPU Driver with vprofiler enabled and   documentation. 9 IMX_6DL_6S_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6DualLite and i.MX   6Solo. 10 IMX_6DQ_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Quad and i.MX 6Dual. 11 IMX_6SL_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Sololite. ·         Target HW boards o   i.MX 6Quad SABRE-SDP o   i.MX 6Quad SABRE-SDB o   i.MX 6Quad SABRE-AI o   i.MX 6DualLite SABRE-SDP o   i.MX 6DualLite SABRE-AI o   i.MX 6SL EVK ·         New features o   BSP New Features on i.MX 6D/Q, i.MX 6DL/S and MX 6SL: §  HDCP §  CEC §  GPU4.6.9p12 §  Audio playback IRAM/SDMA §  V4L capture resize on MX6SL §  MX6DQ disable the double line fill feature of PL310 ·         Known issues o   For known issues and limitations please consult the release notes.

i.MX28 LCD driver 8080 bus interface mechanism please read readme.txt and it will teach you how to use it