Based on example code provided in AN4466 I've written a simple memory calibration script for ARM DS-5 that runs same steps and prints out results for DQS, read and write calibration. This script can be run on new boards in order to find optimum calibration settings for the memory controller. Prior to running this script it is necessary to run standard memory initialization script! When bringing up new board: obtain default memory initialization script for memory type you're using (for example from DDR stress tester package) and modify the memory controller settings according to memory device you are going to use. run DDR stress tester with the given configuration on target frequency you're going to use to make memory works with given settings (default values for calibration are  fine in most cases unless there's issues with PCB and/or routing). run memory init script and then the attached script to obtain calibrated values. Re-test Vladan

imx8mm platform on 4.14.78/98 GA Android  LCD MIPI panel or HDMI display may appear some strange color stride .  This is  one patch for this issue. 

This tool is also for emmc user partition mirror. Just give this tool the emmc files. The typical use case is for emmc mass production by emmc offline programming. Ver 0.4.0 2/14/2017 Support Android 7 Nougat. AndroidSDCARDMirrorCreator_Version_0.4.0_02142017.tgz Ver 0.3.2: 6/13/2016 Using static link simg2img AndroidSDCARDMirrorCreator_Version_0.3.2_06132016.tgz Ver 0.3.1: 5/31/2016 Remove some redundent code   AndroidSDCARDMirrorCreator_Version_0.3.1_05312016.tgz Ver 0.3: 5/25/2016 Add Marshmallow partition layout AndroidSDCARDMirrorCreator_Version_0.3_05252016.tgz Ver 0.2: Add Lollipop partition layout 1. Directory AndroidSDCARDMirrorCreator |-- AndroidSDCARDMirrorCreator.sh        --- main script |-- CFG.INC                              --- configuration file |-- KitKat_LAYOUT.INC                    --- KitKat partition layout |-- LAYOUT.INC -> Lollipop_LAYOUT.INC    --- symbol link to partition layout |-- Lollipop_LAYOUT.INC                  --- Lollipop partition layout `-- readme.txt                           --- this file 2. Need "root" run or "sudo" to run 3. parted and kpartx must be installed    sudo apt-get instal parted kpartx 4. test pass under the debian 8.2 and ubuntu 12.04 5. The AndroidSDCARDMirrorCreator.sh will look for LAYOUT.INC.    please make symbol link to the correct partition layout.    The default symbol link has created for Lollipop_LAYOUT.INC (LAYOUT.INC -> Lollipop_LAYOUT.INC) 6. Command    AndroidSDCARDMirrorCreator.sh -c    AndroidSDCARDMirrorCreator.sh -p 7. Example:    Suppose    The AndroidSDCARDMirrorCreator directory is in    ~/AndroidSDCARDMirrorCreator       The Android Images are in    ~/SD and ~/eMMC       Sdcdard Mirror:    cd ~/SD    ~/AndroidSDCARDMirrorCreator/AndroidSDCARDMirrorCreator.sh -c    eMMC Mirror:    cd ~/eMMC    ~/AndroidSDCARDMirrorCreator/AndroidSDCARDMirrorCreator.sh -c    8. Once the Mirror has been created. Can be reused. Just use kpartx.

All, This document will help you to understand the " YOCTO PROJECT COMMUNITY LAYERS" and the "YOCTO PROJECT FREESCALE OFFICIAL RELEASE" differences and where the layer content is coming from.   Best Regards, Luis

I've recently done some digging into fstrim feature on sabresd-6q. Here list it below detailed: Background:      When Nexus 7 first came out, many users felt it was speedy and high-performance. But after months of installing applications and using the tablet, things began slowing down.This was a friction point that many hoped would be fixed in the new Nexus 7 (2013) model, which it was. There’s even more to the story though, it turns out Google has fixed that storage I/O aging problem on all Nexus devices with the Android 4.3 update which comes with a little-hyped feature that could be huge for performance in the future – TRIM support via fstrim. Why slowing down？      Remember that deleting a file in software isn't actually communicated to solid state storage (whether SSD or eMMC). The space is freed up from the user's perspective, but the eMMC controller in this case still treats the pages in NAND as having valid data. Let's say you copy a 3GB movie to your internal storage, watch the movie and later delete it. You'd have 3GB free to re-use, but until you re-write those blocks the eMMC controller would treat all 3GB as valid data. There's a data structure used by the eMMC controller that tracks mapping logical locations to physical locations in NAND. I won't go into great detail here but the more complex that mapping becomes, and the more locations that have to be tracked, the slower internal NAND management works. Why SSD has such issue? Root cause is "Flash memory is divided into blocks, which is further divided in pages. The minimum write unit is a page, but the smallest erase unit is a block" which will cause fragments as time goes. Why fstrim?      Fstrim is one mechanism of linux filesystem which derives from TRIM. TRIM is already introduced since linux2.6.33. It is the name of a command that the operating system can send to tell the SSD which blocks are free in the filesystem.The SSD uses this information to internally defragment the blocks and keep free pages available to be written quickly and efficiently. How framework triggers fstrim in android4.3?      Android4.3 introduces a new service IdleMaintenanceService to manage when and how trigger fstrim in right time. Once system satisfies the following conditions, it will send out one "ACTION_IDLE_MAINTENANCE_START" intent which the MountService listens for. Last time  "ACTION_IDLE_MAINTENANCE_START" intent has been sent before 24 hours. The device is either off-charger with 80% battery or on-charger with 30% battery The device can go idle state. User don't use it for 71 minutes. Test fstrim on Imx.6      In order to wait little time to trigger fstrim, I tried to change the following variables not to wait 71 minutes and 24 hours. After changing, it will trigger one time fstrim two minutes after system goes into idle state every 30 minutes. --- a/services/java/com/android/server/IdleMaintenanceService.java +++ b/services/java/com/android/server/IdleMaintenanceService.java -    private static final long MIN_IDLE_MAINTENANCE_INTERVAL_MILLIS = 24 * 60 * 60 * 1000; // 1 day +    private static final long MIN_IDLE_MAINTENANCE_INTERVAL_MILLIS = 30 * 60 * 1000; // 30 minute -    private static final long MIN_USER_INACTIVITY_IDLE_MAINTENANCE_START = 71 * 60 * 1000; // 71 min +    private static final long MIN_USER_INACTIVITY_IDLE_MAINTENANCE_START = 2 * 60 * 1000; // 2 min -    private static final long MAX_IDLE_MAINTENANCE_DURATION = 71 * 60 * 1000; // 71 min +    private static final long MAX_IDLE_MAINTENANCE_DURATION = 2 * 60 * 1000; // 2 min Firstly I  run Quadrant apk to see my I/O performance at beginning, Its score is 3544. During this 30 minutes, you can try to mess your system. Try your best to install most apks. Run monkey test in background. Then I  run Quadrant again to check my I/O performance, its score is only a little decline 3538. After that I run "logcat | busybox grep -i fstrim" in console to wait for the action of fstrim, here is my logcat: 130|root@sabresd_6dq:/ # logcat -d | busybox grep -i fstrim I/fstrim  ( 2344): Starting fstrim work... I/fstrim  ( 2344): Invoking FITRIM ioctl on /data I/fstrim  ( 2344): Trimmed 6367305728 bytes on /data I/fstrim  ( 2344): Invoking FITRIM ioctl on /cache I/fstrim  ( 2344): Trimmed 526355456 bytes on /cache I/fstrim  ( 2344): Finished fstrim work. OK, I checked the I/O information again, its score is restored to 3546: Conclusion      Good, fstrim takes effect. So on imx.6 using android4.3, fstrim will also work automatically. We will also enjoy good performance in I/O memory.Great!

Question: An alignement trap in Linux had been seen in an unaligned access of the WEIM (to an external FPGA) Alignment trap: testFPGA (1027) PC=0x000086dc Instr=0xe1d330b0 Address=0x08000001 FSR 0x011 The issue can be reproduced with the platform SDK EIM parallel Nor Test on the Sabre AI - When I access WEIM_BASE_ADDR +1 I get an exception. EIM test start: Flash size: 0x 2000000 Flash erase... . Oops, data abort occurred! Registers at point of exception: cpsr = nZCvqeAift Supervisor (0x60000113) r0 = 0x00000000    r8 =  0x00000000 r1 = 0x00000000    r9 =  0x00000000 r2 = 0x00000001    r10 = 0x00000000 r3 = 0x08000001    r11 = 0x10409770 r4 = 0xdeadfeed    r12 = 0x00000001 r5 = 0x10002458    sp =  0x10409734 r6 = 0x00000000    lr =  0x1000ef9c r7 = 0x00000094    pc =  0x1000bfd0 dfsr = 0x00000001 dfar = 0x08000001 Access type: read Fault status: 0x1 Is adress alligned access mandatory for EIM or AXI HW? or is it possible to support unaligned access? Answer: EIM should support unaligned access. Also ARM architecture supports unaligned access to data and address buses but only if the MMU co-processor is setup for that. Try checking cp15 sctlr[1]. Linux discourage the access to unaligned memory and some times that makes a bus error resulting in a kernel panic. So the drivers and the setup architecture files should support unaligned memory access. ARM Information Center /linux/Documentation/unaligned-memory-access.txt The EIM device is a AXI slave which should support unaligned access. Reference Manual and there's a sub-chapter in the EIM call AXI(Master) Bus cycles support. In that chapter there's a table AXI to Memory Burst Splits Number in that table states the increment burst access to a aligned or unaligned address. I expect those are for the EIM and not refer only to the AXI bus. At any case is not state clear if unaligned access should work only in burst mode (which doesn't make any sense to me) or if the RM information is incorrect. Also in the same chapter in signals not supported never list the alignment signals so unaligned access is supported. Link with some generic ARM information about that. http://forums.arm.com/index.php?/topic/8862-axi-narrowunaligned-read-transfers/ AXI4 - Aligned & unaligned address - ARM Community

Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.

This is the prototype demo to enable surround view demo on SabreSD.   The attached Files are HW&SW guides and demo video. Updating Notes: Add miniPCIE Surround View_Rev A design file (include schematic and layout) as attachement. Add Gerber file   i.MX6Q Surround view patch https://community.freescale.com/docs/DOC-95143 Original Attachment has been moved to: Gerber-file.zip Original Attachment has been moved to: miniPCIe-Surround-View_Rev-A.zip

After rework the board, enable two OTG controllers in Linux DTB file and disable VBUS valid comparator when in suspend mode by clear USB_OTGx_PHY_CTL2 bit 16.  Then we get the following power data on suspend mode  Suspend Mode     ****  The page is under internal check ****

Overview This purpose of this document is to introduce how to support recovery mode for POR reboot event based on MX6 Android R13.4.1. Background If you boot Android R13.4.1 on MX6 SabreSD board, the reboot reason is Watchdog. But if the reboot reason is changed from Watchdog to POR, the recovery mode is failed to enter after factory reset. In R13.4.1, the bit 8 of SRC_GPR10 is used as the persistent bit of recovery mode. This bit is expected to be kept after reboot so that U-boot can use this bit to distinguish what mode should enter. However all SRC registers will be reset on POR sequence according to i.MX6DQRM Section 59.4.1.2.3 IPP_RESET_B (POR). So when the reboot reason is POR, the persistent bit of recovery mode is cleared even if the software set it before reboot. It causes the bootloader won't enter recovery mode after reboot. Software Changes According to i.MX6DQRM, the SNVS_LP General Purpose Register provides a 32 bit read write register, which can be used by any application for retaining 32 bit data during a power-down mode. So to support recovery mode for POR event, the SNVS_LP register can be used to store the persistent bit of recovery mode. The following changes are reqiured to apply (See patches.tar.gz) Apply for Uboot patch bootable/bootloader/uboot-imx/0001-ENGR00235817-mx6-use-SNVS-LPGPR-register-to-store-bo.patch. diff --git a/cpu/arm_cortexa8/mx6/generic.c b/cpu/arm_cortexa8/mx6/generic.c index 257c930..bd47130 100644 --- a/cpu/arm_cortexa8/mx6/generic.c +++ b/cpu/arm_cortexa8/mx6/generic.c @@ -1146,14 +1146,14 @@ int check_and_clean_recovery_flag(void) {   int flag_set = 0;   u32 reg; - reg = readl(SRC_BASE_ADDR + SRC_GPR10); + reg = readl(SNVS_BASE_ADDR + SNVS_LPGPR);   flag_set = !!(reg & ANDROID_RECOVERY_BOOT);   /* clean it in case looping infinite here.... */   if (flag_set) {    reg &= ~ANDROID_RECOVERY_BOOT; -  writel(reg, SRC_BASE_ADDR + SRC_GPR10); +  writel(reg, SNVS_BASE_ADDR + SNVS_LPGPR);   }   return flag_set; @@ -1168,14 +1168,15 @@ int fastboot_check_and_clean_flag(void) {   int flag_set = 0;   u32 reg; - reg = readl(SRC_BASE_ADDR + SRC_GPR10); + + reg = readl(SNVS_BASE_ADDR + SNVS_LPGPR);   flag_set = !!(reg & ANDROID_FASTBOOT_BOOT);   /* clean it in case looping infinite here.... */   if (flag_set) {    reg &= ~ANDROID_FASTBOOT_BOOT; -  writel(reg, SRC_BASE_ADDR + SRC_GPR10); +  writel(reg, SNVS_BASE_ADDR + SNVS_LPGPR);   }   return flag_set; diff --git a/include/asm-arm/arch-mx6/mx6.h b/include/asm-arm/arch-mx6/mx6.h index efb90c2..45381e2 100644 --- a/include/asm-arm/arch-mx6/mx6.h +++ b/include/asm-arm/arch-mx6/mx6.h @@ -732,6 +732,8 @@ #define SRC_GPR9  0x40 #define SRC_GPR10  0x44 +#define SNVS_LPGPR              0x68 + /* Get Board ID */ #define board_is_rev(system_rev, rev) (((system_rev & 0x0F00) == rev) ? 1 : 0) #define chip_is_type(system_rev, rev) \ Apply for kernel patch kernel_imx/0001-ENGR00235817-mx6-use-SNVS-LPGPR-register-to-store-bo.patch diff --git a/arch/arm/mach-mx6/system.c b/arch/arm/mach-mx6/system.c index 6d24f22..61649c5 100644 --- a/arch/arm/mach-mx6/system.c +++ b/arch/arm/mach-mx6/system.c @@ -563,7 +563,7 @@ void mxc_clear_mfgmode(void) #endif #ifdef CONFIG_MXC_REBOOT_ANDROID_CMD -/* This function will set a bit on SRC_GPR10[7-8] bits to enter +/* This function will set a bit on SNVS_LPGPR[7-8] bits to enter   * special boot mode.  These bits will not clear by watchdog reset, so   * it can be checked by bootloader to choose enter different mode.*/ @@ -574,18 +574,18 @@ void do_switch_recovery(void) {   u32 reg; - reg = __raw_readl(SRC_BASE_ADDR + SRC_GPR10); + reg = __raw_readl(MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR);   reg |= ANDROID_RECOVERY_BOOT; - __raw_writel(reg, SRC_BASE_ADDR + SRC_GPR10); + __raw_writel(reg, MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR); } void do_switch_fastboot(void) {   u32 reg; - reg = __raw_readl(SRC_BASE_ADDR + SRC_GPR10); + reg = __raw_readl(MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR);   reg |= ANDROID_FASTBOOT_BOOT; - __raw_writel(reg, SRC_BASE_ADDR + SRC_GPR10); + __raw_writel(reg, MX6Q_SNVS_BASE_ADDR + SNVS_LPGPR); } #endif diff --git a/arch/arm/plat-mxc/include/mach/mx6.h b/arch/arm/plat-mxc/include/mach/mx6.h index 48b04b1..bb22de0 100644 --- a/arch/arm/plat-mxc/include/mach/mx6.h +++ b/arch/arm/plat-mxc/include/mach/mx6.h @@ -302,6 +302,8 @@ #define SRC_GPR9   0x40 #define SRC_GPR10   0x44 +#define SNVS_LPGPR   0x68 + /* GPC offsets */ #define MXC_GPC_CNTR_OFFSET  0x0

When you do long test (days or weeks) test on i.MX board and your test fails, you often wants to know what has happen with a JTAG probe. The problem is when you have 50 boards running in parallel, you don't have the budget to have 50 JTAG debug probe. If you do a "hot plug" of your JTAG probe, you have roughly one chance out 2 to reset your board... so you'll have to wait another couple of hour to resee the problem. Anyway to have a reliable JTAG plug with no reset, it is really simple... cut the RESET line on your cable! then you'll still be able to "attach" to your i.MX. On the MEK board, with a 10-pin JTAG connector, you have the cut the cable line 10 of the ribbon cable: On the cable, cut the reset line like this: With my Lauterbach JTAG  probe, when I do a "hot plug" I never have a reset of my i.MX. BR Vincent

1) Remove all "network" parameters from .../ltib-dir/rootfs/rc.d/rc.conf 2) Add the path of rootfs in the /etc/exports file eg : /home/user/ltib-dir/rootfs/rootfs *(rw,sync,no_root_squash) then execute :- #exportfs -ra 3) Execute NFS server /etc/init.d/nfs restart

This guide is about how to use EVIS to create user nodes and kernels in OpenVX to implement image processing on NPU(i.MX8MP)/GPU(i.MX8QM). Take gaussian filter as an example. It is tested on i.MX8QM and i.MX8MP. User Node Creation from User Kernel 1. Define a user node Register a user kernel by its ID or name For example, #define VX_KERNEL_NAME_GAUSSIAN "com.nxp.extension.gaussian" #define VX_KERNEL_ENUM_GAUSSIAN 100 Get the kernel reference by the ID or name For example, vx_kernel kernel = vxGetKernelByName(context, VX_KERNEL_NAME_GAUSSIAN); vx_kernel kernel = vxGetKernelByEnum(context, VX_KERNEL_ENUM_GAUSSIAN ); Create a user node vx_node node = vxCreateGenericNode(graph, kernel); Set input/output node parameters For example, vx_status status = vxSetParameterByIndex(node, index++, (vx_reference)in_image); status |= vxSetParameterByIndex(node, index++, (vx_reference)out_image); 2. Create InputValidator/OutputValidator functions for the node The validators are only used for graph verification. For example, static vx_status VX_CALLBACK vxGaussianInputValidator(vx_node node, vx_uint32 index) static vx_status VX_CALLBACK vxGaussianOutputValidator(vx_node node, vx_uint32 index, vx_meta_format metaObj) ToDo: a. InputValidator: Get the reference to the parameter object   vx_parameter paramObj = NULL; vx_image imgObj = NULL; paramObj=vxGetParameterByIndex(node, index); vxQueryParameter(paramObj, VX_PARAMETER_REF, &imgObj, sizeof(vx_image)); Check meta-data restriction vxQueryImage(imgObj, VX_IMAGE_FORMAT, &imgFmt, sizeof(imgFmt)); Check consistency with other parameters if (VX_DF_IMAGE_U8==imgFmt) status = VX_SUCCESS; else status = VX_ERROR_INVALID_VALUE; b. OutputValidator Set the meta_format object with expected meta-data for the output status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_FORMAT, &imgFmt, sizeof(imgFmt)); status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_WIDTH, &width, sizeof(width)); status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_HEIGHT, &height, sizeof(height)); 3. Create Initializer function for the node. The initializer is used to specify workdim, global work size and local work size for the user kernel. These parameters are similiar to that in OpenCL. For example,                                                                                    /* workdim, globel offset, globel scale, local size, globel size */ vx_kernel_execution_parameters_t shaderParam = {2,               {0, 0, 0},        {0, 0, 0},        {0, 0, 0},   {0, 0, 0}}; vx_status VX_CALLBACK vxGaussianInitializer(vx_node nodObj, const vx_reference *paramObj, vx_uint32 paraNum) Set attribute to the node vxSetNodeAttribute(nodObj, VX_NODE_ATTRIBUTE_KERNEL_EXECUTION_PARAMETERS, &shaderParam, sizeof(vx_kernel_execution_parameters_t)); Note: The links below are guides about OpenCL on GPU, which are helpful to understand OpenVX implemented on GPU/NPU. OpenCL Work Item Ids: Global/Group/Local OpenCL Programming Guide OpenCL Resources Introduction to OpenCL 4. Create Deinitializer function for the node (Optional) It is used to de-allocate memory allocated at initializer. User Kernel on NPU/GPU Creation 1. Create description of a user kernel For example, vx_kernel_description_t vxGaussianKernelVXCInfo = { VX_KERNEL_ENUM_GAUSSIAN, VX_KERNEL_NAME_GAUSSIAN, nullptr, vxGaussianKernelParam, (sizeof(vxGaussianKernelParam)/sizeof(vxGaussianKernelParam[0])), vxGaussianValidator, nullptr, nullptr, vxGaussianInitializer, nullptr }; 2. Register the new kernel For example, static vx_kernel_description_t* kernels[] = { &vxGaussianKernelVXCInfo, }; 3. Write kernel source implemented on NPU/GPU For example, char vxcKernelSource[] = { "#include \ \n\ \n\ \n\ __kernel void gaussian\n\ ( \n\ __read_only image2d_t in_image, \n\ __write_only image2d_t out_image \n\ ) \n\ { \n\ int2 coord = (int2)(get_global_id(0), get_global_id(1)); \n\ int2 coord_out = coord; \n\ vxc_uchar16 lineA, lineB, lineC, out;\n\ int2 coord_in1 = coord + (int2)(-1, -1);\n\ VXC_OP4(img_load, lineA, in_image, coord_in1, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in2 = coord + (int2)(-1, 0);\n\ VXC_OP4(img_load, lineB, in_image, coord_in2, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in3 = coord + (int2)(-1, 1);\n\ VXC_OP4(img_load, lineC, in_image, coord_in3, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int info = VXC_MODIFIER_FILTER(0, 13, 0, VXC_FM_Guassian, 0);\n\ VXC_OP4(filter, out, lineA, lineB, lineC, info); ;\n\ VXC_OP4_NoDest(img_store, out_image, coord_out, out, VXC_MODIFIER(0, 13, 0, VXC_RM_TowardZero, 0)); \n\ }\n\ " }; Note: the source is written by EVIS instructions with less latency. But the EVIS instructions are limited. These fucntions defination can be found in "cl_viv_vx_ext.h" located at "/usr/include/CL/cl_viv_vx_ext.h". Read back the processed data by GPU/NPU to check if the operations are correct. For example, status = vxCopyImagePatch(vx_out_image, &rect, 0, &addressing, data2, VX_READ_ONLY, VX_MEMORY_TYPE_HOST); 4. Build the NPU/GPU source code runtime For example, programObj = vxCreateProgramWithSource(ContextVX, 1, programSrc, &programLen); vxBuildProgram(programObj, "-cl-viv-vx-extension"); 5. Add kernel to the program For example, ... kernelObj = vxAddKernelInProgram(programObj, kernels[i]->name, kernels[i]->enumeration, kernels[i]->numParams, kernels[i]->validate, kernels[i]->initialize, kernels[i]->deinitialize ); ... for(vx_uint32 j=0; j < kernels[i]->numParams; j++) { status = vxAddParameterToKernel(kernelObj, j, kernels[i]->parameters[j].direction, kernels[i]->parameters[j].data_type, kernels[i]->parameters[j].state ); 6. Finalize the kernel creation For example, status = vxFinalizeKernel(kernelObj); Exercise The example is attached. You can build and test it on i.MX8QM or i.MX8MP. Results on i.MX8QM: References: Khronosdotorg/resources.md at master · KhronosGroup/Khronosdotorg · GitHub  Further Reading: OpenVX Vision Image Extension API Introduction - Basic API OpenVX Vision Image Extension API Introduction - DP Dot Products

Below is one implementation of i.MX as a USB Playback/Capture device on one OTG port. Design Block Diagram: Driver user space interface: As file /dev/gadget/g_audio file system : gadgetaudiofs_type usage: mount -t gadgetaudiofs path /dev/gadget /* if /dev/gadget is not exist, create it manually */ r/w interface open read write close ssize_t read(int fd, void *buf, size_t count); Notice: Attempts to read up to count bytes from file descriptor fd into the buffer starting at buf. On success, the number of bytes read is returned. This call may be blocked if device can't give enough data. Only if usb out pipe be broken(host stop audio player), return value is still positive and less than count. Error: Count must align with PCM audio frame size. If not -EFAULT as errorno. Notes: Audio frame size = audio sample size x audio channels. ssize_t write(int fd, void *buf, size_t count); Notice: Writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. On success, the number of bytes written is returned. This call will never be blocked, even if the internal ring buffer dose not have enough space to write. A successful return from write() that return value equal to count does not make any guarantee that data all have been put to internal ring buffer. For example, if ring buffer is empty and has 1K bytes space, while write count is 3K bytes, only the last 1K bytes will be put to the ring buffer! Key attribute for g_audio driver USB out pipe parameter: Sample width hard code to 16bits. static int out_sample_rate = 48000; static int out_channel = 2; #define OUT_EP_ALIGN (2 * out_channel) // 2 mean 2 bytes, sample width 16bits OUT_EP_ALIGN mean “read ring buffer” write/read align, if read/write length not align this value, throw out error. Read mean user space read system call, write mean driver internal copy req->buf to “read ring buffer”. #define OUT_EP_MAX_PACKET_SIZE (192) // out pipe max packet size, it based on out_sample_rate and out_channel. 192 = (48KHZ / 1000) * out_channel * sample_width(as bytes) 192 = (48000 / 1000 ) * 2 * 2; Hear 1000 based on: as_out_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int out_req_count = 256; /* out pipe queue count, this value dose not introduce extra audio latency ! */ #define AUDIO_READ_RINGBUF_LEN (23 * OUT_EP_MAX_PACKET_SIZE) /* 4416 bytes, max valid 23 * 192, about 23 ms at 48KHZ, this value determine out pipe max audio latency */ If “read ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } USB in pipe parameter: Sample width hard code to 16bits. static int in_sample_rate = 8000; static int in_channel = 2; #define IN_EP_ALIGN (2 * in_channel) // 2 mean 2 bytes, sample width 16bits IN_EP_ALIGN mean “write ring buffer” write/read align, if read/write length not align this value, throw out error. Write mean user space write system call, read mean driver internal copy “write ring buffer” to req->buf. #define IN_EP_MAX_PACKET_SIZE (32) // in pipe max packet size, it based on in_sample_rate and in_channel. 32 = (8KHZ / 1000) * in_channel * sample_width(as bytes) 32 = (8000 / 1000 ) * 2 * 2; Hear 1000 based on: as_in_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int in_req_count = 32; /* in pipe queue count, this value dose introduce extra audio latency ! Latency = 32ms */ #define AUDIO_WRITE_RINGBUF_LEN (32 * OUT_EP_MAX_PACKET_SIZE) /* 1024 bytes, max valid 32 * 32, about 32 ms at 8KHZ, this value and in_req_count determine in pipe max audio latency 32 + 32 = 64 ms*/ If “write ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } Test Environment. Ubuntu 10.0.4 LTS Kernel 3.0.0-15 64bit. Ubuntu 10.0.4 LTS Kernel 2.6.32-42 64bit. Test application. Test user space application based on http://www.rosoo.net/a/201107/14725.html I will attach modified code. Test procedure. /* I.MX28 EVK board audio ADC default input is MIC, so, set it to LINE IN */ amixer sset 'ADC Mux' 'LINE_IN'  /* insmod g_audio driver and create directory for gadgetaudiofs */ modprobe g_audio && mkdir /dev/gadget /* mount gadgetaudiofs */ mount -t gadgetaudiofs path /dev/gadget /* start read g_audio device application.   It read PCM data from g_audio_device and put it to alsa playback device.   It read from g_audio_device per read system call per period_size (300 bytes).   See alsa PCM playback configuration   stream : PLAYBACK access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 48000   exact rate : 48000 (48000/1)   msbits : 16   buffer_size : 1200 (frames) (buffer time is 1200 / 48000 = 25ms)   period_size : 300 (frames)   period_time : 6250 (ns) */ ./lplay /dev/gadget/g_audio /* start write g_audio device application. It read PCM data from alsa capture device and put it to g_audio_device. It write to g_audio_device per write system call per period_size (50 bytes). See alsa PCM capture configuration   stream : CAPTURE   access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 8000   exact rate : 8000 (8000/1)   msbits : 16   buffer_size : 200 (frames) (buffer time is 200 / 8000 = 25ms)   period_size : 50 (frames)   period_time : 6250 (ns) */ ./lrecord /dev/gadget/g_audio The two processes CPU utilization on I.MX28 EVK board is about 5~15%, if you change per g_audio_device read/write system call size more larger, the more smaller CPU utilization you will get, but at the same time the more audio latency you will get. Per read/write system call size should has relation will “read/write ring buffer” size in g_audio driver. For example, if per write system call size is larger than “write ring buffer” size, then every write system call will discard some part of write buffer data. During 15 hours lplay and lrecord long test, driver and application both use default configuration as upper description, summarily 271 times driver internal buffer full appear. In another test, driver keep default configuration, new test set microphone ALSA capture buffer to 250ms, ALSA capture read as unblock mode, other configuration as lrecord application, block read USB gadget device 200 x 192 bytes (waiting 200ms), then unblock read whole ALSA capture buffer, found about every 1.5s, ALSA buffer will less then 16bytes (4 sample) compare to 200 x 32 bytes. Clock Sync issue of echo cancellation based on this implementation: Note： USB clock domain different with play back and microphone, some buffer will be discard by USB audio driver. See this diagram: 1: Echo cancellation application will try best to read “USB Output Buffer”, so no buffer will be discarded from output. ( Application input and output based on the same clock). 2: “Host playback buffer” maybe overrun because:   A: Playback source unstable and host playback buffer not enough larger.   B: Clock(playback) quick than Clock(USB). 3: Echo cancellation application will try best to read “ALSA Buffer”, so no buffer will be discarded from “ALSA buffer”. (Application discard some samples of “ALSA Buffer”) 3: Echo cancellation application handle “USB Output Buffer” and “ALSA Buffer” based on “USB Output Buffer” that same time mean based on Clock(USB). We assume Echo cancellation application will insert or discard some samples of “ALSA Buffer” based on “USB Output Buffer”. 4: Echo cancellation application will send processed buffer to USB audio driver based on Clock(USB), so no buffer will be discard from “USB Input Buffer”. If Echo cancellation application said “ I don't have the ability to insert or discard some samples of “ALSA Buffer”, we need adjust the Clock(MIC) based the internal buffer level of Echo cancellation application. But I think the “internal buffer level” will be influenced by difference of the clocks, the buffer input and output task runtime loading, so it may not be reality to implement this, need do more test on this! Add USB get output/input buffer length interface Add USB SAIF(only for i.mx 28) set clock interface For i.MX28 SAIF clock based on 480MHz. The fraction divider is 16bit, that mean the mini step is 0x 0.0001. 0x 0.0001 * 480MHz = 7324.21875Hz. If master clock as 512x frame rate, the mini step of frame rate is 14.3Hz USB get output/input buffer length interface: IOCTL CMD: #define USBAUDIO_BUFFER_STATUS_GET \ _IOR('g', 200, struct usbaudio_buffer_status) structure: struct usbaudio_buffer_status{   /* all as bytes */   __u32 playbackBufferTotalLen;   __u32 playbackBufferCurrentLen;   __u32 microphoneBufferTotalLen;   __u32 microphoneBufferCurrentLen; }; usage: struct usbaudio_buffer_status bufferStatus; ioctl(fd, USBAUDIO_BUFFER_STATUS_GET, &bufferStatus); USB SAIF(only for i.mx 28) set clock interface. IOCTL CMD: #define USBAUDIO_SAIF_CLOCK_CONTROL \ _IOWR('g', 201, struct usbaudio_saif_clock_control) structure: struct usbaudio_saif_clock_control{   /* all as HZ -1 as invalid */   __u32 saifCurrentClock; /* read */   __u32 saifNextClock; /* write */ }; usage: struct usbaudio_saif_clock_control saifClkCtl; saifClkCtl.saifNextClock = -1; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); saifClkCtl.saifNextClock = saifClkCtl.saifCurrentClock + step; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); Compile sample: /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-linux-gcc -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/include/ -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/Kernel/linux-2.6.35.3/include -L /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/lib/ lrecord.c -o lrecord -lasound

Abstract This is a small tutorial about running a simple OpenCL application in an i.MX6Q. It covers a very small introduction to OpenCL, the explanation of the code and how to compile and run it.   Requirements   Any i.MX6Q board. Linux BSP with the gpu-viv-bin-mx6q package (for instructions on how to build the BSP, check the BSP Users Guide)   OpenCL overview   OpenCL allows any program to use the GPGPU features of the GC2000 (General-Purpose Computing on Graphics Processing Units) that means to use the i.MX6Q GPU processing power in any program.   OpenCL uses kernels which are functions that can be executed in the GPU. These functions must be written in a C99 like code. In our current GPU there is no scheduling so each kernel will execute in a FIFO fashion. iMx6Q GPU is OpenCL 1.1 EP conformant. The Code   The example provided here performs a simple addition of arrays in the GPU. The header needed to use openCL is cl.h and is under /usr/include/CL in your BSP rootfs when you install the gpu-viv-bin-mx6q package. The header is typically included like this: #include <CL/cl.h> The libraries needed to link the program are libGAL.so and libOpenCL.so those are under /usr/lib in your BSP rootfs.   For details on the OpenCL API check the khronos page: http://www.khronos.org/opencl/ Our kernel source is as follows: __kernel void VectorAdd(__global int* c, __global int* a,__global int* b) {      // Index of the elements to add      unsigned int n = get_global_id(0);      // Sum the nth element of vectors a and b and store in c      c[n] = a[n] + b[n]; } The kernel is declared with the signature     __kernel void VectorAdd(__global int* c, __global int* a,__global int* b).   This takes vectors a and b as arguments adds them and stores the result in the vector c. It looks like a normal C99 method except for the keywords kernel and global. kernel tells the compiler this function is a kernel, global tells the compiler this attributes are of global address space. get_global_id built-in function   This function will tell us to which index of the vector this kernel corresponds to. And in the last line the vectors are added. Below is the full source code commented. //************************************************************ // Demo OpenCL application to compute a simple vector addition // computation between 2 arrays on the GPU // ************************************************************ #include <stdio.h> #include <stdlib.h> #include <CL/cl.h> // // OpenCL source code const char* OpenCLSource[] = { "__kernel void VectorAdd(__global int* c, __global int* a,__global int* b)", "{", " // Index of the elements to add \n", " unsigned int n = get_global_id(0);", " // Sum the nth element of vectors a and b and store in c \n", " c[n] = a[n] + b[n];", "}" }; // Some interesting data for the vectors int InitialData1[20] = {37,50,54,50,56,0,43,43,74,71,32,36,16,43,56,100,50,25,15,17}; int InitialData2[20] = {35,51,54,58,55,32,36,69,27,39,35,40,16,44,55,14,58,75,18,15}; // Number of elements in the vectors to be added #define SIZE 100 // Main function // ************************************************************ int main(int argc, char **argv) {      // Two integer source vectors in Host memory      int HostVector1[SIZE], HostVector2[SIZE];      //Output Vector      int HostOutputVector[SIZE];      // Initialize with some interesting repeating data      for(int c = 0; c < SIZE; c++)      {           HostVector1[c] = InitialData1[c%20];           HostVector2[c] = InitialData2[c%20];           HostOutputVector[c] = 0;      }      //Get an OpenCL platform      cl_platform_id cpPlatform;      clGetPlatformIDs(1, &cpPlatform, NULL);      // Get a GPU device      cl_device_id cdDevice;      clGetDeviceIDs(cpPlatform, CL_DEVICE_TYPE_GPU, 1, &cdDevice, NULL);      char cBuffer[1024];      clGetDeviceInfo(cdDevice, CL_DEVICE_NAME, sizeof(cBuffer), &cBuffer, NULL);      printf("CL_DEVICE_NAME: %s\n", cBuffer);      clGetDeviceInfo(cdDevice, CL_DRIVER_VERSION, sizeof(cBuffer), &cBuffer, NULL);      printf("CL_DRIVER_VERSION: %s\n\n", cBuffer);      // Create a context to run OpenCL enabled GPU      cl_context GPUContext = clCreateContextFromType(0, CL_DEVICE_TYPE_GPU, NULL, NULL, NULL);      // Create a command-queue on the GPU device      cl_command_queue cqCommandQueue = clCreateCommandQueue(GPUContext, cdDevice, 0, NULL);      // Allocate GPU memory for source vectors AND initialize from CPU memory      cl_mem GPUVector1 = clCreateBuffer(GPUContext, CL_MEM_READ_ONLY |      CL_MEM_COPY_HOST_PTR, sizeof(int) * SIZE, HostVector1, NULL);      cl_mem GPUVector2 = clCreateBuffer(GPUContext, CL_MEM_READ_ONLY |      CL_MEM_COPY_HOST_PTR, sizeof(int) * SIZE, HostVector2, NULL);      // Allocate output memory on GPU      cl_mem GPUOutputVector = clCreateBuffer(GPUContext, CL_MEM_WRITE_ONLY,      sizeof(int) * SIZE, NULL, NULL);      // Create OpenCL program with source code      cl_program OpenCLProgram = clCreateProgramWithSource(GPUContext, 7, OpenCLSource, NULL, NULL);      // Build the program (OpenCL JIT compilation)      clBuildProgram(OpenCLProgram, 0, NULL, NULL, NULL, NULL);      // Create a handle to the compiled OpenCL function (Kernel)      cl_kernel OpenCLVectorAdd = clCreateKernel(OpenCLProgram, "VectorAdd", NULL);      // In the next step we associate the GPU memory with the Kernel arguments      clSetKernelArg(OpenCLVectorAdd, 0, sizeof(cl_mem), (void*)&GPUOutputVector);      clSetKernelArg(OpenCLVectorAdd, 1, sizeof(cl_mem), (void*)&GPUVector1);      clSetKernelArg(OpenCLVectorAdd, 2, sizeof(cl_mem), (void*)&GPUVector2);      // Launch the Kernel on the GPU      // This kernel only uses global data      size_t WorkSize[1] = {SIZE}; // one dimensional Range      clEnqueueNDRangeKernel(cqCommandQueue, OpenCLVectorAdd, 1, NULL,      WorkSize, NULL, 0, NULL, NULL);      // Copy the output in GPU memory back to CPU memory      clEnqueueReadBuffer(cqCommandQueue, GPUOutputVector, CL_TRUE, 0,      SIZE * sizeof(int), HostOutputVector, 0, NULL, NULL);      // Cleanup      clReleaseKernel(OpenCLVectorAdd);      clReleaseProgram(OpenCLProgram);      clReleaseCommandQueue(cqCommandQueue);      clReleaseContext(GPUContext);      clReleaseMemObject(GPUVector1);      clReleaseMemObject(GPUVector2);      clReleaseMemObject(GPUOutputVector);      for( int i =0 ; i < SIZE; i++)           printf("[%d + %d = %d]\n",HostVector1[i], HostVector2[i], HostOutputVector[i]);      return 0; } How to compile in Host   Get to your ltib folder and run $./ltib m shell This way you will be using the cross compiler ltib uses and the default include and lib directories will be the ones in your bsp. Then run LTIB> gcc cl_sample.c -lGAL -lOpenCL -o cl_sample. How to run in the i.MX6Q   Insert the GPU module root@freescale/home/user $ modprobe galcore Copy the compiled CL program and then run root@freescale /home/user$ ./cl_sample References   [1] ttp://www.khronos.org/opencl/ Original Attachment has been moved to: libOpenCL.so.zip Original Attachment has been moved to: libCLC_Android.so.zip Original Attachment has been moved to: libOpenCL_Android.so.zip Original Attachment has been moved to: libCLC.so.zip

It is based on 3.0.35 GA 4.1.0 BSP.   0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch It is the updated IPU code for MIPI ID and SMFC setting in ipu_capture.c. These setting should not be combined with MIPI virtual channel value, they shoule be fixed with ID 0.   0002-Use-virtual-channel-3-for-ov5640-mipi-camera-on-iMX6.patch The sample code to modify ov5640_mipi camera to use virtual channel 3 on SabreSD board.   The followed command can be used to verify the mipi camera function after booted into Linux: $ gst-launch mfw_v4lsrc capture-mode=1 device=/dev/video1 ! mfw_v4lsink     2014-09-30 update: Added the patch for 3.10.17_GA1.0.0 BSP. "L3.10.17_1.0.0_mipi_camera_virtual_channel_3.zip"  

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

Hello Android users Otto has posted on the Element14 community some clear tutorial (accessible following the link below) to build Android from source. RIoTboard: Building Android from Source | element14 I recommend you to start following those steps to properly setup the Android tools. Happy Source Programming Greg

MX7D_DDR3_压力测试应用手册_V1_201611108.doc