[中文翻译版] 见附件   原文链接： Guide to flash an eMMC from SD Card on i.MX6Q SABRE-SD 

We are pleased to announce that Pins Tool for i.MX v4 is now available.   The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Documented and easy to understand source code CSV Report and Device Tree File   To download the installer for all platforms, please login to our download site via:  http://www.nxp.com/pinsimx   Please refer to Pins Tool Documentation  for installation and quick start guides.   Overview of Changes - version 4 Added ability to import configuration from existing MEX file (for selected tools) Added common Functions group toolbar across all tools Added option to not generate YAML Pins tool: multiselect in Routed pins view supported Syntax coloring supported in Sources view Export sources wizard simplified Several bug fixed and performance improved Quick start guide added   Community https://community.nxp.com/community/imx 

Q: Does VIN have to be valid before we can talk to the PMIC over i2c? Can a valid voltage on LICELL and VDDIO work instead? The PF0100 datasheet says: ---------------------------------------------- To communicate with I2C, VIN must be valid and VDDIO, to which SDA and SCL are pulled up, must be powered by a 1.7 to 3.6V supply. VIN, or the coin cell voltage must be valid to maintain the contents of the registers. -------------------------------- A: VIN and VDDIO must be valid for communicating to the I2C block. Having LICELL and VDDIO will not work since a portion of the digital circuitry needed for accessing the registers is powered through VIN. This document was generated from the following discussion: Programming PMIC over i2c

This is a generic script which flashes a Linux System (U-boot, uImage and root filesystem) into a SD card. Steps:     1. Download the script into a Linux system     2. Make the script executable (chmod +x mk_mx_sd)     3. Run it with '-H' to know its usage.     4. Run the script with real parameters, specifying the paths for U-boot, uImage and the root filesystem as seen above     5. Plug the SD into your target, boot the board and change the corresponding U-boot variables $ IMAGE=/data/BSP/L2.6.35_11.09.01_ER/L2.6.35_11.09.01_ER_images_MX5X $ ./mk_mx_sd  -d /dev/sdc \                       -u $IMAGE/u-boot-mx53-loco.bin \                       -k $IMAGE/uImage \                       -r $IMAGE/rootfs     6. In case you only want to flash a single binary (like U-boot), just specify the U-boot parameter (-u)

Abstract: On the time otp driver initializes, it will check the mac bits of eFuse,  when the value is invalid, generate a random mac, and program  it to eFuse. Environment: i.mx6dl android-4.2.2 kernel-3.0.35 Changes: 1. kernel_imx/arch/arm/mach-mx6/mx6_fec.c ---------------------------------------------------------------- void __init imx6_init_fec(struct fec_platform_data fec_data) {   fec_get_mac_addr(fec_data.mac);   if (!is_valid_ether_addr(fec_data.mac))       fec_data.mac[0] = 0x10; // changed by xxx   if (cpu_is_mx6sl())   imx6sl_add_fec(&fec_data);   else   imx6q_add_fec(&fec_data); } 2. kernel_imx/drivers/char/fsl_otp.c ---------------------------------------------------------------- //add by xxx static void check_otp_mac(void) {   unsigned int index_mac0 = 34;   unsigned int index_mac1 = 35;   u32 value_mac0 = 0;   u32 value_mac1 = 0;   u32 value_random_mac0 = 0;   u32 value_random_mac1 = 0;   char otp_mac[6], random_mac[6];   memset(otp_mac, 0, sizeof(otp_mac));   memset(random_mac, 0, sizeof(random_mac));   mutex_lock(&otp_mutex);   //get   if (otp_read_prepare(otp_data)) {   mutex_unlock(&otp_mutex);   return 0;   }   value_mac0 = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUSTn(index_mac0));   value_mac1 = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUSTn(index_mac1));   otp_read_post(otp_data);   mutex_unlock(&otp_mutex);   if(value_mac0 != 0 && value_mac1 != 0)   {   otp_mac[5] = value_mac0 & 0xff;   otp_mac[4] = (value_mac0 >> 😎 & 0xff;   otp_mac[3] = (value_mac0 >> 16) & 0xff;   otp_mac[2] = (value_mac0 >> 24) & 0xff;   otp_mac[1] = value_mac1 & 0xff;   otp_mac[0] = (value_mac1 >> 😎 & 0xff;   }   printk("otp_mac=%pM\n", otp_mac);   //check   if (!is_valid_ether_addr(otp_mac))   {   random_ether_addr(random_mac);   printk("get random mac:%pM\n", random_mac);   //set   value_random_mac0 = 0;   value_random_mac0 = value_random_mac0 | random_mac[2];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[3];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[4];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[5];   value_random_mac1 = 0;   value_random_mac1 = value_random_mac1 | random_mac[0];   value_random_mac1 = (value_random_mac1 << 😎 | random_mac[1];   mutex_lock(&otp_mutex);   if (otp_write_prepare(otp_data)) {   mutex_unlock(&otp_mutex);   return 0;   }   otp_write_bits(index_mac0, value_random_mac0, 0x3e77);   otp_write_bits(index_mac1, value_random_mac1, 0x3e77);   otp_write_post(otp_data);   mutex_unlock(&otp_mutex);   } } //end 3.  kernel_imx/drivers/char/fsl_otp.c ---------------------------------------------------------------- static int __devinit fsl_otp_probe(struct platform_device *pdev) {   ...   retval = sysfs_create_group(otp_kobj, &attr_group);   if (retval)   goto error;   mutex_init(&otp_mutex);   //add by xxx   check_otp_mac();   //end

1) rtsp gst-launch-1.0 rtspsrc location=rtsp://192.168.0.105:10000 name=source ! queue ! rtph264depay ! vpudec ! overlaysink source. ! queue ! rtpmp4gdepay ! aacparse ! beepdec ! alsasink pc side: open vlc, choose media , then choose stream and rtsp, then choose the port to 10000 2)udp imx side: gstream 0.1 version: gst-launch udpsrc do-timestamp=false uri=udp://192.168.0.255:10000 caps="video/mpegts" ! aiurdemux streaming_latency=400 name=d d. ! queue ! vpudec low-latency=true ! queue ! mfw_v4lsink sync=true d. ! queue ! beepdec ! alsasink sync=true gstream 1.0 version: gst-launch-1.0 udpsrc do-timestamp=false uri=udp://192.168.0.255:10000 caps="video/mpegts" ! aiurdemux streaming-latency=400 name=d d. ! queue ! vpudec ! queue ! overlaysink sync=true d. ! queue ! beepdec ! pulsesink sync=true pc side: open vlc , then choose media, then choose stream and add the ts file, then choose dup(legacy) in the destinationsetup, then set the same broadcasting address as the gstreamer command set, then streaming.

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.

Q: i.Mx53 and a kernel based on our latest Linux BSP (Kernel Version 2.6.35) – They do see problems when mounting SATA Disk which is used for their rootfs. Has anyone seen this before? I am just wondering if the upcoming release might address and fix this? From the MCU i MX Product Update Call_May 2013.ppt presentation i.MX53  external release June 30 th 2013, freescale.com •       There will be patches/features for i.MX53 including Yocto for this kernel  L2.6.35 BSP release •       Validation testing Where can I check which patches / features are in this release? Is there already a Release Note? this is the kernel for the legacy release: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain The main proposal for the next legacy release is not upgrade kernel, is only make a yocto release. And if you take meta-fsl-arm on master you will find everything from legacy release. I upstreamed every change I made internaly A: Rootwait is in the command line. Please note they can boot with Kernel version 3.2 - but customer requires 2.6.35 Kernel for other reasons. Please find attached the log files I received. A text bootlog (note sometimes booting works) but it is not stable and reliable on 2.6.35 - same HW seems stable on 3.2 Kernel Regarding to the failed messages contained in customer's log, it's a random issue. SATA driver reports that there is an " SError: { DevExch }" on the PHY connection. It seems that the SATA PHY connection is not stable enough. Can you make a double check on the cable connection and the power supply? You can disable the following configuration when build the 2.6.35 kernel image config SATA_AHCI_FSL_NO_HOTPLUG_MODE         bool "Freescale i.MX SATA AHCI NO HOTPLUG mode"         depends on SATA_AHCI_PLATFORM != n         default n         help           In order to decrease the pwr consumption, release the CLK resources such as usb_phy1_clk, when there is no SATA device adaptored into the AHCI SATA port. The HOTPLUG feature can't be enabled in this situation. Please disable this option if the HOTPLUG is mandatory required.           If unsure, say N. ============================ BTW, I just verified the RFS on SATA on i.MX53 LOCO. It's ok. Here is the log: Starting kernel ... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.35.3-01275-ge6b3f3b (r65037@shlinux1) (gcc version 4.7.3 20121001 (prerelease) (crosstool-NG hg+-946d6d133a90) ) #52 PREEMPT Tue Jul 30 11:27:17 CST 2013 CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7d CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Freescale MX53 LOCO Board Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 250880 Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/sda1 rootwait rw ... mxc_rtc mxc_rtc.0: setting system clock to 1970-01-01 00:00:01 UTC (1) Waiting for root device /dev/sda1... ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-8: SanDisk SSD P4 32GB, SSD 8.00, max UDMA/133 ata1.00: 62533296 sectors, multi 1: LBA48 ata1.00: configured for UDMA/133 ata1: EH complete scsi 0:0:0:0: Direct-Access     ATA      SanDisk SSD P4 3 SSD  PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk VFS: Mounted root (ext2 filesystem) on device 8:1. Is there a possibility to tweak timing parameters? Maybe that could help to get it more robust? Are there other parameters we can try to play with and could explain failing Sata RFS on some i.Mx53 boards? I got more info from customers and also "hints" to other forum entries realted to that problem. http://lists.debian.org/debian-arm/2012/03/msg00059.html http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html """ Linux version 2.6.35.3-mx53qsb (mike@ubuntu) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #3 PREEMPT Sat Mar 17 15:34:48 PDT 2012 CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Freescale MX53 LOCO Board ... ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 28 ... ata1: SATA link down (SStatus 1 SControl 300) ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen t4 ata1: irq_stat 0x00000040, connection status changed ata1: SError: { DevExch } ata1: hard resetting link ata1: SATA link down (SStatus 1 SControl 300) ata1: EH complete """ http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9&t=4256&start=175 As mentioned custoemr sees simlar problems with our test image. Maybe one way to check, can you provide me our u-boot and uImae you did the test with? Customer confirmed their HW is compatible with MX53 LOCO Board so I would like to make sure they use correct SW and use what you tested. A bit strange is also that this Problem shows never up on a 3.2 based kernel. However the end customer requires to stay on 2.6.35 for other reasons. - kernel 3.2 which is able to initialize always. - protocol logs for good and bad case trans -p uImage.mx5.35 File keyword is ngbl7927a Data transfer to Austin Transcend repository started.   File size is 2.94 MB. Transfer Method:  Serial with no encryption. File 'uImage.mx5.35' (size 2.94 MB) transcended. Retrieve the file with the keyword:  ngbl7927a TransWeb URL:  http://transweb.freescale.net/index.cgi?go=KEYWORD&KEYWORD=ngbl7927a This file will be deleted in three working days. Local Deletion Time:  Thu Aug 15 23:51:16 2013 CST Greenwich Mean Time:  Fri Aug 16 04:51:16 2013 GMT I know that i.MX53 SATA doesn't have the adjust-window like the adjust window contained by i.MX6Q SATA. As I know that we didn‘t release 3.2 kernel version BSP, right? Regarding to the experience of ”http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html”, it seems that the updates of the SATA stack of Linux level up the timing-compatibility of SATA. Derived from the URL listed above. ”I did trace the problems I having to the ahci code in the kernel not properly handling an ahci CONINIT event generated by my WD5000BEVT drive.  Seems this drive has extra SATA features implemented so that it can be used in hot-plug arrays and these features aren't recognized by the kernel driver so it just seems to shut down the drive and ignore it.  The other SATA drive that I do have working with the kernel doesn't implement the extra features so the kernel is happy.  Presumably these problems were fixed in later kernels and the patches didn't make it into Freescales 2.6.35.3 branch. On the other hand, the kernel might be fine and the firmware in the drive isn't conforming to the ahci specs, but I think that wold cause problems with the drive on other systems. ” This document was generated from the following discussion: i.MX53 Sata rootfs problem

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

I.MX6 CoreBoard Computer On Module • Processor Freescale i.MX 6Quad, 1GHz • RAM 1GB DDR3 SDRAM 64-bit • ROM 4GB NAND Flash    UP to 16GB • ROM 2M SPI Nor Flash • Power supply Single 5V • Size 40mm SO-DIMM • Temp.-Range     0 to + 95C (Consumer)               -20 to + 105C (Extended Consumer)               -40 to +105C (Industrial)               -40 to + 125C (Automotive) Key Features • 10/100Mbps Ethernet • One High Speed USB 2.0 ports • Full HD LCD controller, 24bpp • OpenGL ES 2.0 and OpenVG 1.1        hardware accelerators • Multi-format HD 1080p60 video decoder and 1080p30 encoder hardware engine • Two Camera Interfaces • NEON MPE coprocessor — SIMD Media Processing Architecture — dual, single-precision floating point execute pipeline • Unified 1MB L2 cache • Several interfaces: 5x UART, 2x SDIO, 1x SSI/AC97/I2S, 3x I2C, 2xCSPI • 3.3V I/O • 2x Controller Area Network (FlexCAN) • PCIe 2.0 (1-lane) LVDS Option only: • Dual LVDS display port • SATA OS Support • Linux • Android

Platform: Ubuntu 12.04 Board: Freescale MCIMX6Q-SDP  and  MCIMX-LVDS1 Screen BSP: L3.0.35_4.1.0_ER_SOURCE_BSP Other device: PC , One Router, 3 Network Cable and 2 usb-otg lines The  platform is as follow: Boot form NFS is very convenient in porting and debugging, and will value us much time. If the customers have modified the kernel and rebuild the kernel to generate the uImage running on board, he can directly download the uImage to the board by TFTP network. It is fast and can avoid the normal operation ,  first customers need to copy the images to the mfgtool specified directory and download the u-boot, uImage and file sytem again to the flash device in board, and then change to boot up mode to boot up the board. If customers are doing debug this operation will waste lot of time. So use the NFS is vey convenient. Beyond this, in the target board customers can also read the files and content in host machine. In a word, use NFS it will help save much time and also convenient. So the follows is introduce and show how to set NFS and then boot up the board. 1 Preparation (1)Build the BSP Build up the L3.0.35_4.1.0_ER_SOURCE_BSP use LTIB on the Ubuntu12.04, you can refer to our user guide document here no details. The u-boot, uImage and file system are all under the directory of litb. Boot up from NFS, so when build uImage some items are needed, here you can see the build details in the section of  Setting Target Linux Image to use NFS in this articel. (2)Download the u-boot to the target board Use the mfgtool Mfgtools-Rel-4.1.0_130816_MX6Q_UPDATER to download the u-boot to the SD card of MCIMX6Q-SDP board or use dd command to write the u-boot to SD card.( By the way, writing to the EMMC is also OK) 2 Setting the NFS Environment Set host machine 1 - Install NFS Service on host typing:     $sudo apt-get install nfs-kernel-server       2 - Create symbolic link to ltib/rootfs     $sudo ln -s <ltib instalation folder>/rootfs /tftpboot/rootfs       3 - Setup exports typing:     $sudo gedit /etc/exports       and add the following line:     /tftpboot/rootfs/ *(rw,no_root_squash,no_subtree_check,async) 4 - Restart the NFS server:     $sudo /etc/init.d/nfs-kernel-server restart       Now the host is ready to use NFS Setting Target Linux Image to use NFS       1. Run LTIB configuration by typing: $cd <ltib instalation folder>       $./ltib -c       2. On first page menu, go to "Target Image Generation -> Options"       3. Select the option NFS only and exit LTIB configuration to compile with the new configuration. 4. LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/uImage      5. Copy the created image on /<ltib instalation folder>/rootfs/boot/uImage to /tftpboot/uImage 6. The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/ 3 Setting the u-boot command line (1)Download the u-boot to the target board fist according to the section 1 (2) Download the u-boot to the target board. Then give the power to the board, boot up board, u-boot boot up. (2)Configuration the Network Configure the Network and IP , to make the target board and the host machine IP are in the local area network of Router. (3)Set the u-boot command line As follow is my setting for you to refer to : 4 Boot up the board Running the “run bootcmd” after setting the u-boot parameters then boot up the kernel and file system. We can see that the board download the uImage by the TFTP from host machine, then boot up the kernel and finally mount the NFS in the kernel. As follows is the details: Downloading the uImage success and boot up kernel: Input root and access the system. Test: Create a new file in the host machine directory, you can see in the next picture: Then open the target board, in the terminal go to the same directory  in the unit_test we can see the same name. So as we can see in the above operation we can see it is very convenient and fast use the NFS. It will help save time and speed the development time.

目录 1    硬件资源，文档及工具下载... 2 1.1    硬件资源... 2 1.2    内存配置测试相关的文档... 3 1.3    内存压力测试工具. 3 1.4    内存配置工具. 4 2    内存设计要求... 4 3    LPDDR4基础... 4 4    硬件连接... 6 5    i.MX8QXP/DXP+LPDDR4内存配置与测试步骤... 8 5.1    生成LPDDR4初始化脚本... 8 5.2    使用内存测试工具测试内存... 13 5.3    编译内存测试工具所用的SCFW镜像... 17 5.4    其它尺寸的LPDDR4配置... 18 6    i.MX8DX+DDR3L内存配置... 23 7    测试失败的DEBUG.. 26 8    内存参数应用到SCFW中... 30

This document explains how to create a DS-5 project to compile and debug the SDK and OBDS for iMX6 and iMX28 respectively. Attached you can find the .ds file for the iMX28 needed to debug in DS-5.

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

Platform: i.mx8qm/qxp OS: imx-yocto-L4.14.98_2.0.0_ga Camera: max9286 deserializer <=> max96705 serializer  + ar0144 or: max9286 deserializer <=> max96705 serializer + ov9284 Note that currently only one camera is support and the serializer should be connected to the IN0 of max9286. Data format: ar0144: mono raw 12bit. ov9284: mono raw 10bit. On imx8qm/qxp the data will be recieved as raw 16bit and the valid data bit start from bit[13] to LSB. for mono raw 12bit the valid data bit is 0bxxdd_dddd_dddd_ddxx for mono raw 10bit the valid data bit is 0bxxdd_dddd_dddd_xxxx max9286 and max96705 configuration: dbl bws PXL_CRC/edc hven hibw lccen him should be the same on both sides, this can be achieved by pin or register configurations. The crossbar function of max96705 can be used to fix the reversed data bit. for example, reversed 12bit with dbl to 1. 0x20 0xb 0x21 0xa 0x22 0x9 ....... 0x2b 0x0 0x30 0xb 0x31 0xa .... 0x3b 0x0 0x20 to 0x2b and 0x30 to 0x3b are the registers of max96705. Patch apply: 1. push the kernel-patch to the kernel source and apply it. 2. reconfig the kernel setting, make sure there is only CONFIG_MAX9286_AR0144 or        CONFIG_MAX9286_WISSEN(ov9284) enabled, all other max9286 related are disabled. You can run menuconfig to achieve this. 3. For testing copy the vulkan-v4l2.tar to the board, and run vulkan-v4l2.     the source code is at https://github.com/sheeaza/vulkan-v4l2 branch ar0144 for ar0144, branch ov9284 for ov9284. =========== updated patch for data format.

The MMPF0100 and MMPF0200 are the newest in the family of Freescale Analog PMICs supporting the i.MX6 processor.  These devices are economical, quick turn programmable system power management solutions with fully programmable voltages, sequencing, and timings.  Why risk anything else?  These are optimized and validated to work seamlessly with our i.MX6 processors. 

Introduction Disk encryption on Android is based on dm-crypt, which is a kernel feature that works at the block device layer. Therefore, it is not usable with YAFFS, which talks directly to a raw nand flash chip, but does work with emmc and similar flash devices which present themselves to the kernel as a block device. The current preferred filesystem to use on these devices is ext4, though that is independent of whether encryption is used or not. [1] Let's encrypt! I will show the whole process first, and then point out the issue I noticed on i.MX6. To use this feature, go to settings and security as below: Encrypted phones need to set the numeric PIN, so click Screen lock to set password: Choose PIN: After setting up PIN code, the Screen lock is showed "Secured with PIN" as below: We can then click Encrypt phone to start: Note the words on this page, it needs start with a charged battery and the charger needs to be on. Click Encrypt phone button and it will ask PIN code setup before: Enter the PIN code and then has the confirmed page: Click Encrypt phone, it will reset framework and starting to encrypt: After running 100%: It then reset the device. When it boots, it will ask you enter the PIN to enter system. Check Setting -> Security again: The status showed Encrypted under Encrypt phone. Errors While Doing Encryption on i.MX6 In the following, I list the error I met and the way to fix. Orig filesystem overlaps crypto footer region.  Cannot encrypt in place It needs to make sure the filesystem doesn't extend into the last 16 Kbytes of the partition where the crypto footer is kept. The encryption in place and get_fs_size() in system/vold/cryptfs.c will check it, so needs to re-make data partition. sudo mke2fs -t ext4 /dev/sde7 1034000 -Ldata The original size is larger than 103400, so I used this value to reserved 16 Kbytes for crypto footer. device-mapper: table: 254:0: crypt: Error creating IV E/Cryptfs ( 2221): Cannot load dm-crypt mapping table. The actual encryption used for the filesystem for first release is 128 AES with CBC and ESSIV:SHA256. The master key is encrypted with 128 bit AES via calls to the openssl library. This is done by enable CONFIG_CRYPTO_SHA256 in kernel. Enable post_fs_data_done Vold sets the property vold.post_fs_data_done to "0", and then sets vold.decrypt to "trigger_post_fs_dat". This causes init.rc to run the post-fs-data commands in init.rc and init..rc. They will create any necessary directories, links, et al, and then set vold.post_fs_data_done to "1". Vold waits until it sees the "1" in that property. Finally, vold sets the property vold.decrypt to "trigger_restart_framework" which causes init.rc to start services in class main again, and also start services in class late_start for the first time since boot. This is done by: diff --git a/imx6/etc/init.rc b/imx6/etc/init.rc index 17cbd4c..f2823f2 100644 --- a/imx6/etc/init.rc +++ b/imx6/etc/init.rc @@ -203,7 +203,7 @@ on post-fs-data      # must uncomment this line, otherwise encrypted filesystems      # won't work.      # Set indication (checked by vold) that we have finished this action -    #setprop vold.post_fs_data_done 1 +    setprop vold.post_fs_data_done 1 Don't unmount data partition when cryptfs_restart After the steps above, it can finish encryption. But I found Android will crash after encryption and reboot. When data partition is encrypted, Android's init to mount /data will fail. The cryptfs.c here to try unmount will fail since the data partition isn't mounted before. diff --git a/cryptfs.c b/cryptfs.c index 052c033..fd05259 100644 --- a/cryptfs.c +++ b/cryptfs.c @@ -694,7 +694,7 @@ int cryptfs_restart(void)      if (! get_orig_mount_parms(DATA_MNT_POINT, fs_type, real_blkdev, &mnt_flags, fs_options)) {          SLOGD("Just got orig mount parms\n"); -        if (! (rc = wait_and_unmount(DATA_MNT_POINT)) ) { +        //if (! (rc = wait_and_unmount(DATA_MNT_POINT)) ) {              /* If that succeeded, then mount the decrypted filesystem */              mount(crypto_blkdev, DATA_MNT_POINT, fs_type, mnt_flags, fs_options); @@ -710,7 +710,7 @@ int cryptfs_restart(void)              /* Give it a few moments to get started */              sleep(1); -        } +        //}      } References: [1]: Notes on the implementation of encryption in Android 3.0 | Android Open Source

This describes how to perform frequency measurements of an external signal by using the Camera Sensor Interface (CSI) of an i.MX21/25/35 processor. Principle: A way to measure the frequency of a digital signal is to count the number of received rising or falling edges during a known amount of time. The CSI embeds a 16-bit frame counter. When programmed in non-gated clock mode, this counter increases at any rising edge on the VSYNC signal. Other signals of this interface could be ignored such: MCLK, PIXEL_CLK, HSYNC, DATA. Software example for the i.MX25: void CSI_init(void){       unsigned int tmp_value = 0;       /* It assumes that the VSYNC I/O is set to CSI mode */       /* Disable IPG_PER_CSI to save power consumption */       *((unsigned int *) CCM_CGR0) &= ~(0x1<<0);       /* HCLK_CSI and IPG_CLK_CSI should be enabled. */       *((unsigned int *) CCM_CGR0) |= (0x1<<18);       *((unsigned int *) CCM_CGR1) |= (0x1<<4);       /* Configuration of CSI_CSICR1 in non-gated clock mode */       tmp_value = 0;       tmp_value |= (1<<8);    // sync FIFO clear       tmp_value |= (1<<30);   // ext vsync enable       *((unsigned int *) CSI_CSICR1) = tmp_value;       // Reset frame counter       *((unsigned int *) CSI_CSICR3) |= (1<<15); } Then, every T seconds, the software has to read the register CSI_CSICR3. The 16-bit size field from bit 16 shows the current value of the frame counter (FRMCNT). This regular or irregular read could be done based on a GPT to have a known time reference. It is easy to calculate the frequency of the signal: Frequency = FRMCNT / T (Hz). At any time, the frame counter can be reset thanks to the bit 15 of the register CSI_CSICR3. NOTES: MCLK does not need to be enabled. The input frequency should not be higher than what can electrically support the VSYNC input. Please, refer to each i.MX datasheet for more information.