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.

Fix cdc_ether connection over usb0 stalls and cannot recover after transmitting few MByte data The patch is modified from ENGR00278073.

Question: Did we tested active PCIe components while the Cortex-A9 was in Sleep Mode (suspend to memory)? Answer: It's a known issue that PCIe can't support suspend/resume. And can't be built in kernel image if the system want suspend/resume. I think PCIe will be active while core is in sleep more. Is it different scenario? No, the pcie core is not active, it is in L2 state after suspend, and it can't resume back to L0 state when system resume is called. So, DO NOT let pcie do suspend operation right now. BTW, the tested device: * INTEL x1 1000M CT network card. * INTEL iwl wifi cards. * x1 pcie to usb3.0 card Yes, this patch had been tested on imx_3.0.35_4.0 release, and would be merged into next 3.0.35 release. TO1.2 is used. We tested the Patch against imx_3.0.35_4.0 release

Quaestion: What does exactly the RNG_TRIM after burning the SRK hash table? There is no such thing on the former i.MX HAB procedure. What would a random generator stuff bring here? Additionnally, there is the possibility to lock the SRK shadow register via an OTP bit. Is it recommeneded to lock it? if not, is it really possible to change the SRK hash value by modofying the shadow register value before performing the SRK hash key check in a HAB boot process? One last question: the PKI requires the user to enter a certificate lifetime. Does that really mean that openssl will refuse generating new signatures once the certificates lifetime is expired? Answer: 1. The intent of the of the RNG_TRIM fuses is for Freescale to essentially extendthe amount of time the RNG4 in CAAM has to generate entropy.  The longer this period the more likely it is that RNG4 will generate entropy that will pass its internal statistical tests.  The reason for the fuses is HAB (in the Closed configuration only) instantiates the RNG by default and needs some external indication on how to progran the RNG4 in CAAM to ensure the internal HW statistical tests will pass.  This was to allow the RNG to be useable by application code after execution has left the ROM.  However this requires that the RNG_TRIM fuse value be fully characterized across numerous conditions temperature, voltage etc.  This effort is still on going.  For customers performing secure boot (in Closed configuration) we recommend they follow Section 6.3 of http://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf.  In this case the RNG4 can be instantiated by CAAM driver code which can be easily changed if required. 2. Yes, once the SRK hash is provisioned to the SRK_HASH field it is recommended to blow the corresponding SRK_LOCK fuse.  If the SRK_LOCK fuse is not blown then additional fuses in the SRK_HASH field can be blown.  This will cause devices in the closed configuration to fail to boot.  i.e. "bricking" the device. 3. Please see https://community.freescale.com/message/334186#334186 for the answer to your question on the certificate validity period.

Question: To connect an FPGA to the i.MX6Q over LVDS.,to connect the 2 LVDS channels in split mode. The datasheet indicates the driver output max skew due to different propagation time of rising and falling edge. For the sake of the design of their FPGA interface, it would be also interesting to get the skew between the 2 LVDSn_CLK (of the 2 channels) as well as the intrachannel- skew. Answer: Backend database are checked. We can provide the result in the view of design. Since we do not check inter-channel skew in production, the following may not be guaranteed.  At the core boundary, we found that, timing skews between every data and clock are within 30ps. Path from core boundary to PAD are matched by analog layout, should produce some skew well below 30ps also. As the result, I think, all LVDS signal can be considered as one single group, and skew in datasheet can apply to any signal.

Question: The description of the IOMUXC_GPR2 register is wrong. It contains exactly the same description as the LDB_CTRL register. The bits in the LDB_CTRL register work as advertised opposed to the GPR2 register. Answer: This is intentional. The LDB_CTRL description in the RM says "The register is implemented in the IOMUX Controller block (IOMUXC), as the register IOMUXC_GPR2.". And you will notice the two registers have the same address.

Question: Two boards are used and practically identical - one using the i.MX6Solo, the other is using a Dual. The sw settings in both cases are identical (except IOMUX addresses). On the i.MX6Solo they do not see any packet loss, on the i.MX6Dual they do. I recommended modifying the MTU size, but this also did not help. So here my two questions: 1)      is there still some hw difference between the Ethernet block on the Solo and the Dual/Quad? 2)      They run the AHB at only 100MHz. Could that be a problem? If not, why do the two chips behave so differently? To increase the AHB clock to 133 MHz.appears to solve the packet corruption issue. Is the 100 MHz AHB clock really the root cause. Answer: The DualLite/Solo and SoloLite contain different ethernet controllers. The DL/S has a 1000M controller which requires the AHB bus to be greater than 125MHz, while the SL has a 100M controller. As the question was about the Solo and the Dual and both use the Gigabit Ethernet block I assume that both will require a minimum AHB clock of 125MHz.

Question: Is SN65LVDS315 (MIPI CSI-1) compatible with our i.MX6 MIPI CSI-2 interface? CSI-2 extends CSI-1 with multiple lanes, but both standards use the same D-PHY layer. Answer: No, the i.MX6 MIPI CSI-2 interface is not compatible with CSI-1 devices. Standards that require backward compatibility to legacy standards always state that the standards are backward compatible. The CSI-2 standard does not say that. (I have a copy of the standard and I have read it specfically for that reason)  The CSI-2 standard does say that a specifically designed PHY, built to D-PHY MIPI01 specification is used for CSI-2. The PHY's used for CSI-1 and CSI-2 are different and they are not compatible. There are some processors that do have compatiblity for CSI-1 and CSI-2, but if you read closer, you will find that they have two different modes (and probably two different sets of pins): One for CSI-2 and One for CSI-2/CSI-1 legacy. It is interesting that a company would choose to inlcude a dying technology in a newer processor, but my guess is that they have a number of other CSI-1 devices they are trying to sell before they can't be used anywhere and nobody wants them. if the customer is looking for a parallel camera interface to CSI-2 converter IC, may I recommend the Toshiba TC358746 device. I have not used it specifically, but I have worked with a Toshiba rep on an HDMI to MIPI CSI-2 project that input into the i.MX6 processor. Once all the correct parameters were determined, it worked very well. Much higher data rate flow.

Question: The following contradicting information regarding the UART clock tree has been seen in the Rev. 1.0  version of the reference manual: Page 813: PLL3_PFD1 -> divide by 6 -> adjustable post divider -> UART Page 839: PLL3 -> divide by 6 -> UART In the old Rev D I found: Page 803: PLL3 -> divide by 6  ... and something about 80MHz The assumption is that correct path would be: PLL3 -> divide by 6 -> post divider -> UART. Answer: The designer said that UART _CLK_ROOT comes from PLL3 (not PLL3:PFD1) and is divided by 6 to produce 80 MHz. I'm waiting for him to confirm that the divider he mentions is CSCDR1[UART_CLK_PODF].

In many cases (test certain modules, first boot-ups, DDR is not available), writing bare-metal (SDK) code with runs on iRAM (OCRAM) is the only possible scenario. The first (attached) patch creates a new linker file with proper sections and the second includes a tiny app (it should be tiny, by definition) using the previous file. These are the steps to have the setup ready: 1. Dowload latest i.MX6 SDK (v1.1.0 is the latest when writing this document). 2. Let GIT take the control (git init; git add .; git commit -m '1st commit') 3. Apply patches (git am < patch1; git am < patch2 ) 4. Compile             # This example is intended for a mx6q sabreSD, revision C             $ ./tools/build_sdk -target=mx6dq \                                 -board=smart_device \                                 -board_rev=c \                                 -app=iram     5. SD Card Flashing & Running: 5.1. ELF file & U-boot:    # Output image is located on:                 #   elf=output/mx6dq/minimal/smart_device_rev_c/minimal.elf                 $ dd if=$elf \                      of=/dev/sdb \                      seek=2048 bs=512; sync                 # Boot your board with your favorite u-boot version, just make                 # sure the bootelf command is presnet                 > mmc dev Y                 > mmc read 0x10800000 0x800 XXX                 > bootelf 0x10800000                where Y is the SD device and XXX are the records seen when dd flashing.             5.2  BIN file:    # Output image is located on:                 #   bin=output/mx6dq/minimal/smart_device_rev_c/minimal.bin                 $ dd if=$bin \                      of=/dev/sdb \                      seek=2 skip=2 bs=512; sync                 # Place the SD into your board and power-on. NOTES: + The first patch was taken from the internal discussion MX6 SDK (PLATLIB): has anyone created a stripped down version that will run from internal RAM?

Question: Using Linux SDK 4.1.0, with CAAM drivers enabled, there is little noticeable difference in the performance of openssd compared to a kernel without the CAAM drivers. Tests were done using openssd. Test image AES-128 8192 byte block (M Bytes/sec) “openssl speed –evp aes-128-cbc” AES-128 8192 byte block (M Bytes/sec) With /dev/crypto “openssl speed –evp aes-128-cbc -engine cryptodev”  Ubuntu 11.04 Image 19.010 N/A Timesys 20.518 N/A SDK 4.1.0 LTIB 22.013 21.984 (errors reported) One can see that with SDK 4.1.0, performance is worse with crypto enabled.  This is probably due to the overhead of a faulty driver or incorrect implementation. The lowest number is for Ubuntu which could be attributed to the Unity GUI. Conclusion:  CAAM driver is not functional or I am using an improper testing procedure. Test Procedure: Board used is iMX6Q Sabre SDP Openssl was used for testing. Two command line commands were used, with and without the cryptodev engine. openssl speed –evp aes-128-cbc openssl speed –evp aes-128-cbc -engine cryptodev Openssl versions used in each build are slightly different: Ubuntu:              openssl 1.0.0e Timesys:              openssl  1.0.1e SDK 4.1.0:            openssl  1.0.1c Three versions of Linux were tested. Default kernel  4.0.0 with Ubuntu rootfs form image tarballs. Timesys kernel and root file system Kernel built with SDK 4.1.0 using LTIB with hardware crypto enabled Both 1 and 2 above did not have CRYPTODEV set in .config which contains the line “# CONFIG_CRYPTO_CRYPTODEV is not set” Option 3 had the line in .config as, “CONFIG_CRYPTO_CRYPTODEV=y” All three builds generate “/proc/crypto”  whose contents are attached.  A partial listing of /proc/crypto lists “caam” as a driver for all encryption methods supported.  Example printout for aes shown below: ame         : cbc(aes) driver       : cbc-aes-caam module       : kernel priority     : 3000 refcnt       : 1 selftest     : passed type         : ablkcipher async        : yes blocksize    : 16 min keysize  : 16 max keysize  : 32 ivsize       : 16 geniv        : eseqiv All three builds have “caam” and “enable_wait_mode=off” in the kernel command line in u-boot. Only option #3 contains both device file in “/dev/crypto” and an entry in “/proc/crypto” root@freescale ~$ cd / root@freescale /$ ls /proc/cr* /proc/crypto root@freescale /$ ls /dev/cr* /dev/crypto root@freescale /$ Test #1—Kernel build 4.1.0 openssl speed test without caam engine root@freescale ~$ openssl speed -evp aes-128-cbc                    Doing aes-128-cbc for 3s on 16 size blocks: 3471184 aes-128-cbc's in 2.94s Doing aes-128-cbc for 3s on 64 size blocks: 986286 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 249743 aes-128-cbc's in 2.93s Doing aes-128-cbc for 3s on 1024 size blocks: 64343 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 7954 aes-128-cbc's in 2.96s OpenSSL 1.0.1c 10 May 2012 built on: Sat Sep 7 18:47:34 PDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 18890.80k    21040.77k    21820.55k 21962.41k    22013.23k root@freescale ~$ Test #2—Timesys kernel build of openssd without /dev/crypto # openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 3361305 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 924423 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 236623 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 59967 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 7514 aes-128-cbc's in 3.00s OpenSSL 1.0.1e 11 Feb 2013 built on: Thu Sep 5 21:54:37 EDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: armv7l-timesys-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/here/workdir/factory/build_armv7l-times ys-linux-gnueabi/toolchain/usr/include -DL_ENDIAN -DTERMIO -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -Os -pipe -Wa,--noexecstack -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 17926.96k    19721.02k    20191.83k 20468.74k    20518.23k #  Test #3—Ubuntu rootfs and kernel image root@linaro-ubuntu-desktop:/# openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 3030128 aes-128-cbc's in 2.98s Doing aes-128-cbc for 3s on 64 size blocks: 852897 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 220572 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 55534 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 6846 aes-128-cbc's in 2.95s OpenSSL 1.0.0e 6 Sep 2011 built on: Wed Oct 5 01:45:02 UTC 2011 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall The 'numbers' are in 1000s of bytes per second processed. type             16 bytes     64 bytes 256 bytes   1024 bytes   8192 bytes aes-128-cbc 16269.14k    18195.14k    18822.14k 18955.61k    19010.99k root@linaro-ubuntu-desktop:/# Test #4—SDK 4.1.0 openssl speed test with “/dev/crypto” .  Note errors. root@freescale ~$ openssl speed -evp aes-128-cbc -engine cryptodev  invalid engine "cryptodev" 716715216:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(/usr/lib/engines/libcryptodev.so): /usr/lib/eng ines/libcryptodev.so: cannot open shared object file: No such file or directory 716715216:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 716715216:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: 716715216:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=cryptodev 716715216:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(libcryptodev.so): libcryptodev.so: cannot open shared object file: No such file or directory 716715216:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244: 716715216:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450: Doing aes-128-cbc for 3s on 16 size blocks: 3572980 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 966002 aes-128-cbc's in 2.94s Doing aes-128-cbc for 3s on 256 size blocks: 255307 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 62967 aes-128-cbc's in 2.93s Doing aes-128-cbc for 3s on 8192 size blocks: 7890 aes-128-cbc's in 2.94s OpenSSL 1.0.1c 10 May 2012 built on: Sat Sep 7 18:47:34 PDT 2013 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes     64 bytes    256 bytes 1024 bytes   8192 bytes aes-128-cbc 19055.89k    21028.61k    21786.20k 22006.21k    21984.65k root@freescale ~$ Answer: I do not know what is recent state of official Freescale BSP regarding CAAM, but to get OpenSSL working under CAAM support with reasonable acceleration  : https://community.freescale.com/message/318188#318188 The patches was used below : http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_3.0.35_4.0.0 Direct link to the patches: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.0.0&id=6068d7a77b2101c172fc2f003f90b1febbf99505 http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.0.0&id=b30237c79003223c6e8035d5be183cd4f0b469f9

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.