Hello! Here's some CODE!!! #include <iostream> #include <stdio.h> #include <assert.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <math.h> #include <stdlib.h> //#define EGL_USE_GLES2 #include <GLES2/gl2.h> #include <EGL/egl.h> #include <GLES2/gl2ext.h> #include <EGL/eglext.h> #include <termios.h> #include <unistd.h> #include <fcntl.h> #ifdef EGL_USE_X11 #include <X11/X.h> #include <X11/Xlib.h> #endif EGLDisplay egldisplay; EGLConfig eglconfig; EGLSurface eglsurface; EGLContext eglcontext; EGLNativeWindowType eglNativeWindow; EGLNativeDisplayType eglNativeDisplayType; EGLNativeDisplayType fsl_getNativeDisplay() {   EGLNativeDisplayType eglNativeDisplayType = NULL; #if (defined EGL_USE_X11)   eglNativeDisplayType = XOpenDisplay(NULL);   assert(eglNativeDisplayType != NULL); #elif (defined EGL_API_FB)   eglNativeDisplayType = fbGetDisplayByIndex(0); //Pass the argument as required to show the framebuffer #else   display = EGL_DEFAULT_DISPLAY; #endif   return eglNativeDisplayType; } EGLNativeWindowType fsl_createwindow(EGLDisplay egldisplay, EGLNativeDisplayType eglNativeDisplayType) {   EGLNativeWindowType native_window = (EGLNativeWindowType)0; #if (defined EGL_USE_X11)   Window window, rootwindow;   int screen = DefaultScreen(eglNativeDisplayType);   rootwindow = RootWindow(eglNativeDisplayType,screen);   window = XCreateSimpleWindow(eglNativeDisplayType, rootwindow, 0, 0, 400, 533, 0, 0, WhitePixel (eglNativeDisplayType, screen));   XMapWindow(eglNativeDisplayType, window);   native_window = window; #else   const char *vendor = eglQueryString(egldisplay, EGL_VENDOR);   if (strstr(vendor, "Imagination Technologies"))   native_window = (EGLNativeWindowType)0;   else if (strstr(vendor, "AMD"))   native_window = (EGLNativeWindowType)  open("/dev/fb0", O_RDWR);   else if (strstr(vendor, "Vivante")) //NEEDS FIX - functs don't exist on other platforms   { #if (defined EGL_API_FB)   native_window = fbCreateWindow(eglNativeDisplayType, 0, 0, 0, 0); #endif   }   else   {   printf("Unknown vendor [%s]\n", vendor);   return 0;   } #endif   return native_window; } void fsl_destroywindow(EGLNativeWindowType eglNativeWindowType, EGLNativeDisplayType eglNativeDisplayType) {   (void) eglNativeWindowType; #if (defined EGL_USE_X11)   //close x display   XCloseDisplay(eglNativeDisplayType); #endif } void GLInit (void) {   static const EGLint s_configAttribs[] =   {   EGL_RED_SIZE, 5,   EGL_GREEN_SIZE, 6,   EGL_BLUE_SIZE, 5,   EGL_ALPHA_SIZE, 0,   EGL_SAMPLES, 0,   EGL_NONE   };   EGLint numconfigs;   printf("1");   eglNativeDisplayType = fsl_getNativeDisplay();   printf("2");   egldisplay = eglGetDisplay(eglNativeDisplayType);   printf("3");   eglInitialize(egldisplay, NULL, NULL);   printf("4");   assert(eglGetError() == EGL_SUCCESS);   printf("5");   eglBindAPI(EGL_OPENGL_ES_API);   printf("6");   eglChooseConfig(egldisplay, s_configAttribs, &eglconfig, 1, &numconfigs);   assert(eglGetError() == EGL_SUCCESS);   assert(numconfigs == 1);   printf("7");   eglNativeWindow = fsl_createwindow(egldisplay, eglNativeDisplayType);   assert(eglNativeWindow);   printf("8");   eglsurface = eglCreateWindowSurface(egldisplay, eglconfig, eglNativeWindow, NULL);   assert(eglGetError() == EGL_SUCCESS);   printf("9");   EGLint ContextAttribList[] = { EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE };   eglcontext = eglCreateContext( egldisplay, eglconfig, EGL_NO_CONTEXT, ContextAttribList );   assert(eglGetError() == EGL_SUCCESS);   printf("10");   eglMakeCurrent(egldisplay, eglsurface, eglsurface, eglcontext);   assert(eglGetError() == EGL_SUCCESS); } void GLEnd (void) {   printf("Cleaning up...\n");   eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);   assert(eglGetError() == EGL_SUCCESS);   eglDestroyContext(egldisplay, eglcontext);   eglDestroySurface(egldisplay, eglsurface);   fsl_destroywindow(eglNativeWindow, eglNativeDisplayType);   eglTerminate(egldisplay);   assert(eglGetError() == EGL_SUCCESS);   eglReleaseThread(); } int main (int argc, char **argv) {   GLInit();   for( int i = 0; i < 100000; ++i)   {   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);     // Clear The Screen And The Depth Buffer   glClearColor (.0f, .0f, 1.0f, 1.0f);   eglSwapBuffers (egldisplay, eglsurface);   }   GLEnd(); } Above code is stitched together from samples from GPU SDK. I've built an image using Yocto (dylan branch) and build the meta-toolchain-qt (and qte). Successfully managed to build above code ONLY FOR X11. Issues i am facing: 1) if build for X11 and run app on the board, window shows, but it stays white, when it should be BLUE...doesn't update no matter what color i glClear to. 2) when compiling with FB, fbCreateWindow and etc don't get recognized, i.e. undefined reference to `fbCreateWindow' .... WHAT header contains these functions???? 3) if even the basic samples don't work, how the hell is anybody supposed to build a GL application on this board?? --- more rhetorical than a real question, just frustrated here... what did i do wrong? 4) please show me a working tutorial or some code on how to get this EGL context initialized...i'm running at wit's end here...

Question: What exactly does the DTE/DCE interface in the i.MX6's UART module do and how are RTS and CTS affected by the UARTxUFCR[DTEDCE] bit? In i.MX6 RM, revision 1: Sections 64.2.1.2.1  (CTS) and 64.2.1.2.2 (RTS) both state that CTS and RTS change direction between DCE and DTE modes.  However, sections 64.4.3.1 (RTS_B) and 64.4.3.8 (CTS_B) state they do not change functions.  Is this a documentation error, or is there a difference between CTS/RTS and CTS_B/RTS_B? It appears that some of this is covered in the IOMUX daisy chain by switching which pins are connected to CTS and RTS. Answer: Example 1: UART1 in DTE mode. RTS is an output from the UART IP block so it must be routed to a CTS pin. Therefore, the SELECT_INPUT register could only use settings 00 or 10. Example 2: UART1 in DCE mode. RTS is an input to the UART IP block so it must be routed to an RTS pin. Therefore, the SELECT_INPUT register could only be set to 01 or 11. At this point, we have assumed that the internal signals connected to the UART block do not change direction.  We believe that DCEDTE from the UART block connects into the IOMUX logic and controls the direction of the PAD.  Then, the IOMUX INPUT_SELECT mux is used to choose one of four pads to connect to the UART inputs while the IMOUX MUX_CTRL connects the output path.  Further, we assume it is an error to connect the UART input to a pad configured as an output or a UART output to a pad configured as an input. The attached shows our assumptions For the Uart IP, the CTS_B is always an output and RTS_B always an input. But the RTS_B &CTS_B IO will be swapped  when UART operates in different DTE or DCE mode.  IO port DTE mode DCE mode direction Uart IP port(internal) direction Uart IP port(internal) UART_CTS_B O CTS_B I RTS_B UART_RTS_B I RTS_B O CTS_B UART_TXD O TXD I RXD UART_RXD I RXD O TXD Regarding how to configure the IOMUX, please see the attached PDF.

Question: In a single uImage to contain the compressed kernel and rootfs, if the uImage is greater than 16MB, the system will not boot and reports errors. Is there a size limitation on uImage?  If so, is there a work around? Answer: uImage should only contains kernel compressed. rootfs should be read through a linux partition after the kernel boots up. Regarding the uImage's size, there is no limitation. In the other hand, a single uImage with kernel and filesystem is needed; in other words, kernel (alias uImage) needs a filesystem to work, and these are two independent systems in that sense. If u-boot, kernel and filesystem are in a single device (SD Card), the filesystem must be mounted in the first partition (SD, eMMC, etc) starting somewhere > 16M/512 sectors. But in cases where: * A fast boot is needed with  very small rootfs * As a intermediate (temporal) rootfs  before switching  to the real rootfs. The usage (actually used when flashing with the MFG tool) of this intermediate system is to load heavy modules, keeping the uImage small. This mechanism is called initramfs and the uImage will contain the kernel and the this mini rootfs compressed as cpio archive. But there appears to be a 16MB limitation. See here:  http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/ It seems to be related to alignment suggesting that 24-bit addressing is used instead of 32-bit.  I did notice Thumb mode is used, which seems odd to me.

This patch is for i.MX6 ESPI controller slave mode (SPI timing mode 0 and 3) support. Hardware prepare:   Connect two i.MX6 Sabresd boards, remove U14 SPI nor device, connect two boards like:          MISO --- MISO          MOSI --- MOSI          SS     --- SS          CLK   --- CLK          GND  ---  GND Software prepare: 1>Apply patch spi_slave_2013_10_12.patch on 3.0.35_4.1.0 Linux BSP release.     Note two board all need choose CONFIG_IMX6_SDP_MISCSPI, CONFIG_SPI_SPIDEV of kernel Symbol: IMX6_SDP_MISCSPI [=y]                                                                                                              Location:   |     -> Device Drivers                                                                                                                      |       -> Misc devices (MISC_DEVICES [=y]) Symbol: SPI_SPIDEV [=y]  Location:                                                                                                                                            |     -> Device Drivers                           |       -> SPI support (SPI [=y])    Spi master board choose CONFIG_SPI_IMX_VER_2_3 Symbol: SPI_IMX_VER_2_3 [=y] Location:                                                                                                                                           |     -> Device Drivers                                                                                                                                 |       -> SPI support (SPI [=y])                                                                                                                       |         -> Choose IMX SPI work mode (<choice> [=y])    Spi slave board choose CONFIG_SPI_IMX_VER_2_3_SLAVE. Symbol: SPI_IMX_VER_2_3_SLAVE [=y] Location:                                                                                                                                           |     -> Device Drivers                                                                                                                                 |       -> SPI support (SPI [=y])                                                                                                                       |         -> Choose IMX SPI work mode (<choice> [=y]) 2>Compile test application  mxc_spi_test1.c to generate mxc_spi_test. 3> Test steps : First  spi slave board input cmd mxc-spi-test –D 0 –b 32 –L 32 Then spi master board input cmd mxc-spi-test –D 0 –b 32 –L 32           This tool will write its buffer ( the content is same in two side ) to the  other board  through  SPI bus , then read data from the other board , and compare with its write buffer.

Question: What does it means by depending on load? Is there a value? This is  related with i.MX6D Answer: The comment about the "load" means the total system load on the 2.5V rail. We understand that people design systems, not just MX6 devices. The documentation confusion stems from the design team changing from allowing customers to use the LDOs to power system devices back to just using the LDOs to power the MX6. Reasons - thermals, and also concern for uncontrolled system noise injection into the MX6 and causing failures.

Question: If the i.mx6’s internal real time clock is not used,  instead an external I2C device is used,  does this create a problem with using any of the i.mx6’s security features? Answer: iMX6 Secure features uses and internal real time counter (SRTC) which if enabled and reaches the maximum value it generates an interrupt informing a security violation. External RTC can't be used in security iMX6 context. I2C external RTC for applications is needed, but for security features SNVS uses the internal SRTC. Question: If I'm interpreting your comments correctly - The customers external RTC can't be used in the context of iMX6 security but can still used be used for their applications needs.  To utilize the security features of the SNVS Module (RM Chp. 60), it must use the internal SRTC.  Disabling or otherwise not implementing the requirements the SNVS module has a cascading effect on many other security features such as High-Assurance Boot (HAB) and CAAM operation.  So it seems that if the customer must have an external RTC, they should still implement the requirements of the internal SNVS/SRTC. Answer: That's the case if secure features are needed they will end up using the internal SRTC, actually I don't think is possible to be used in other scenario as is part of SNVS. Question: To better understand the implications of not having battery backup for the SNVS supply as it pertains to security, if it is normally powered all the time via either a local AC supply or POE+ and is never powered down except for service, and reboots are done with a pushbutton. Given this, can you list what types of security features cannot be implemented or will be problematic? Answer: ???

This is done with the 11.09 BSP for imx53 specifically. Attached is an amrnb.spec file, I put it in ltib/dist/lfs-5.1/amrnb. Then I extracted opencore-amr-0.1.3.tar.gz and put it in ltib/rpm/BUILD. I built with ltib ( ALl this could be added to the ltib menus as well 😞 ./ltib –m scbuild –p amrnb ./ltib –m scdeploy –p amrnb Then I applied the patch to .ltib for gst-plugins-ugly and built that with ltib. It will play a .3gp file with this pipeline: gst-launch filesrc location=/media/sd/test.3gp ! qtdemux name=demux demux.audio_00 ! queue ! amrnbdec ! alsasink demux.video_00 ! multiqueue ! mfw_vpudecoder ! mfw_isink Regards, Randy Krakora

Question: How to enable HAB on the MX28, following the recommendations of AN4555 to get the "get_hab_status()" function working, but has run into an issue. Question #1 They believe they have all the HAB components worked out that are inputs to the efltosb tool as they are able to successfully run U-boot to the interactive prompt.  However, at the point where they:     - call the rvt_report_status() function, their board says "### ERROR ### Please RESET the board ###".      - call the rvt_entry(), their board prints some garbage characters on the screen and then hangs. This suggests that there is something wrong with the clock that in turn affects the baudrate on the serial console causing the above behavior. Question #2 Is there a concept of a "Bound Signature" in HABv4 as there is in HABv3? Any chance the addresses for the rvt_ calls are incorrect? Can you provide the u-boot source? Either Bound signature verification or UID is never mentioned in the HABv4 Application Note. So I suppose it is not supported. We have made assumptions about the RVT function pointer offsets.  The HAB 4 API does not explicitly say the offsets but uses a rvt_base::function_name notation.  We have assumed that function pointers are placed in order, at every word offset beyond the RVT header.  We have confirmed the RVT header exists at the latest address in the reference manual based on a memory dump but we cannot be certain the function offsets we have setup are correct. As far as source code, we modeled our changes for our mx28 board off of the hab.c and hab.h files available from the mainline u-boot for the mx6 architecture. This is basically the same code get_hab_status code that is written in the AN4555 document.  We did HAB API function pointer addresses to match the updated RVT base address and assumed offsets. Answer: Here are the first 3 instructions from report_status(), could your customer check the instructions from the address which they called is correct? <report_status>: :   b087b570        addlt   fp, r7, r0, ror r5 :   1c0e1c05        stcne   12, cr1, [lr], {5} :   22182433        andscs  r2, r8, #855638016      ; 0x33000000

Question: How to enable touch functions on LVDS1/SabreAI base board? what should be soldered in order to connect the signals to i2c what to add in the Linux kernel (board-mx6q_sabreauto.c) BTW.: Why did we leave these disconnected? Is there any conflict on i2c? Answer: You can mount R305 and R306 to support touch on LVDS1, no code modification was needed. The only limitation is that the two LVDS's touch can't be connected to same I2C port, because they are using the same I2C address. Question: How is this working because the touch interrupt signal from LVDS1 called LCD1_TOUCH_INT_B is connected to pin21 on J44 on base board which is left floating (TP1) on CPU card P1A connector? Are both LVDS needed to work in the same time. Answer: That's the problem, the LVDS1 touch interrupt pin hasn't been connected to IMX6 CPU. Maybe you can use the SabreSD board, the two touch are ready on that board.

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