If Android device has Internet access, it can download and install TTS library automatically. However, sometimes in a developer environment, Internet may not be available. Download TTS library from Eyes-Free project, [1] Unzip all files into VFAT partition (of SDCard). It will create two directories: daiane@b19406:/media$ sudo ls disk-3/ -l total 231552 drwx------ 6 daiane root      4096 2010-05-24 15:46 espeak-data drwx------ 2 daiane root      4096 2010-05-24 15:46 svox daiane@b19406:/media$ mount /dev/sdd5 on /media/disk-1 type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd2 on /media/system type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd6 on /media/disk-2 type ext3 (rw,nosuid,nodev,uhelper=hal) /dev/sdd1 on /media/disk-3 type vfat (rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1001,utf8,umask=077,flush) /dev/sdd4 on /media/recovery type ext3 (rw,nosuid,nodev,uhelper=hal)

Contents 1 创建 i.MX8QXP Linux 4.14.98_ga 板级开发包编译环境 2 1.1 下载板级开发包 ...................................................... 2 1.2 创建yocto编译环境: ................................................ 3 2 Device Tree ............................................................. 15 2.1 恩智浦的device Tree结构 ..................................... 15 2.2 device Tree的由来(no updates) ............................ 18 2.3 device Tree的基础与语法(no updates) ................. 20 2.4 device Tree的代码分析(no updates) .................... 42 3 恩智浦i.MX8XBSP 包文件目录结构 ......................... 75 4 恩智浦i.MX8XBSP的编译(no updates) .................... 77 4.1 需要编译哪些文件 ................................................ 77 4.2 如何编译这些文件 ................................................ 78 4.3 如何链接为目标文件及链接顺序 ........................... 79 4.4 kernel Kconfig ...................................................... 81 5 恩智浦BSP的内核初始化过程(no updates) .............. 81 5.1 初始化的汇编代码 ................................................ 83 5.2 初始化的C代码 ..................................................... 87 5.3 init_machine ....................................................... 100 6 恩智浦BSP的内核定制 ........................................... 103 6.1 DDR修改 ............................................................ 103 6.2 IO管脚配置与Pinctrl驱动 .................................... 105 6.3 新板bringup ........................................................ 120 6.4 更改调试串口 ...................................................... 128 6.5 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 135 6.6 LVDS LCD 驱动定制 .......................................... 144 6.7 GPIO_Key 驱动定制 .......................................... 147 6.8 GPIO_LED 驱动定制 ......................................... 151 6.9 Fuse nvram驱动 ................................................. 154 6.10 SPI与SPI Slave驱动 ........................................... 155 6.11 USB 3.0 TypeC 改成 USB 3.0 TypeA(未验证) ... 162 6.12 汽车级以太网驱动定制 ....................................... 162 6.13 i.MX8DX MEK支持 ............................................. 180 6.14 NAND Flash支持与烧录 ..................................... 181

Few issues encountered trying to build L5.1.1_2.1.0 Android for i.MX6: (some of them can apply to Android M6 build also) Issue-1: OpenJDK-7 required to build L5.1.1_2.1.0 but not able to download/install in Ubuntu 16.04: solution: Ubuntu 16.04 and openjdk 7 - Ask Ubuntu =============================== sudo add-apt-repository ppa:openjdk-r/ppa sudo apt-get update sudo apt-get install openjdk-7-jdk =============================== Issue-2: without any modification, got error message like: "You have tried to change the API from what has been previously approved." during compilation. solution: follow the suggestion in the error message, do "make update-api" Issue-3: error messages like ========================================= external/libcxx/include/thread:149: error: unsupported reloc 43 clang: error: linker command failed with exit code 1 (use -v to see invocation) build/core/host_shared_library_internal.mk:44: recipe for target 'out/host/linux-x86/obj32/lib/libc++.so' failed make: *** [out/host/linux-x86/obj32/lib/libc++.so] Error 1 ========================================= related post on Internet: http://stackoverflow.com/questions/36048358/building-android-from-sources-unsupported-reloc-43 https://bbs.archlinux.org/viewtopic.php?id=209698 solution:(as mentioned in the link above) replaced "prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.6/x86_64-linux/bin/ld" with the symlink to "/usr/bin/ld.gold" so this should look like: ========================================= ~/myandroid/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/x86_64-linux/bin$ ls -l ld* lrwxrwxrwx 1 jimlin jimlin      16     May  6 14:48 ld -> /usr/bin/ld.gold -rwxrwxr-x 1 jimlin jimlin 1645584 May  6 11:24 ld.bfd -rwxrwxr-x 1 jimlin jimlin 3497448 May  6 11:24 ld.gold -rwxrwxr-x 1 jimlin jimlin 3497448 May  6 11:24 ld.org ========================================= to this point I can build L5.1.1_2.1.0 successfully.(on 2016, May, 12.) Issue-4: can't run the SD tool "fsl-sdcard-partition.sh" used to partition/format SD card in "~/myandroid/device/fsl/common/tools" root-cause: in Ubuntu 16.04, "sfdisk" tool doesn't support "-u" parameter: ================================== sfdisk from util-linux 2.27.1 -u, --unit S              deprecated, only sector unit is supported ================================== error message encountered when running the script: ================================== ~/myandroid/device/fsl/common/tools$ sudo ./fsl-sdcard-partition.sh /dev/sdc sfdisk: unsupported unit 'M' sfdisk: unsupported unit 'M' ================================== I've modified the script a bit to adapt the changes, as attached.

Using the FEC on U-boot 1 - Start by programming U-boot into the SD or NAND, click here for SD or here for NAND. 2 - Boot the image programed on Step 1, for the SD Card: Personality Board settings:                   12345678 SW22 -> 00000000 SW21 -> 11000000  Debug Board settings:   SW5,6,7,8,9,10 -> OFF                    12345678   SW4 -> 10000001 For NAND:                              12345678   SW22 -> 00100000   SW21 -> 10011000  Debug Board settings:   SW5,6,7,8,9,10 -> OFF                      12345678     SW4 -> 10000001 Stop at u-boot prompt: MX25 U-Boot > 3 - Configure u-boot networking variables, replace the values according to your network configuration: MX25 U-Boot > setenv serverip 192.168.1.1 MX25 U-Boot > setenv ipaddr 192.168.1.2 MX25 U-Boot > setenv eth1addr 00:04:9f:00:3b:33 Update "ethact" var to enable the FEC. MX25 U-Boot > setenv ethact FEC0 4 - With the Ethernet cable connected, start a tftp transfer: MX25 U-Boot > tftpboot 0x80800000 uImage_mx25 FEC: enable RMII gasket Using FEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.1.2 Filename 'uImage_mx25'. Load address: 0x80800000 Loading: #################################################################              #################################################################              #################################################################              #################################################################              #################################################################              #################################################################              ##### done Bytes transferred = 2022396 (1edbfc hex) 5 - If you transfered the kernel image, you can boot it (Don't forget to update bootargs): MX25 U-Boot > bootm 0x80800000

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

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

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

Pre-Sales: i.MX8/8X applications in automotive(Chinese Version) https://community.nxp.com/docs/DOC-345825 i.MX8X website design resource guide: (Chinese Version) https://community.nxp.com/docs/DOC-345676 After-Sales: i.MX8X memory configuration&test application notes: (Chinese Version) https://community.nxp.com/docs/DOC-345803 i.MX8X hardware design guide: (Chinese Version) https://community.nxp.com/docs/DOC-346582 i.MX8X_4.19.35_bootloader customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-345713 i.MX8X_4.19.35_kernal customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-345714 i.MX8X_4.14.98_bootloader customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-342448 i.MX8X_4.14.98_kernal customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-344217 i.MX8X_5.4.24_bootloader customization application notes: (Chinese Version) https://community.nxp.com/docs/DOC-347131

It is suggested to create a layer when creating or modifying any metadata file (recipe, configuration file or class). The main reason is simple: modularity. Follow these steps 1. To have access to Yocto scripts, setup the enviroment from the BASE folder fsl-community-bsp $ . setup-environment build 2. Move to the place you want to create your layer and choose a name (e.g. `fsl-custom`) sources $ yocto-layer create fsl-custom # Answer the questions. Make sure the priority is set correctly (higher numbers, # higher priorities). Set the priority equal to the lowest already present, except # when you have introduce a new recipe with the same name as other and want to shadow # the original one. 3. Add any metadata content. Suggestion: Version the layer with Git and upload your local git repo to a server 4. Edit and add the layer to the `build/conf/bblayers.conf` file 5. To verify that your layer is *seen* by BitBake, run the following command under the build folder build $ bitbake-layers show-layers This document was generated from the following discussion: i.MX Yocto Proyect: How can I create a new Layer?

[中文翻译版] 见附件   原文链接： 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