Instead to use gst-launch to play your audio/video media you can create an application do to that. This application was tested in iMX27ADS but should to work on iMX27PDK First execute LTIB (./ltib -c) and select these packages: all gstreamer plugin, alsa-utils and libmad. Create your file code (i.e.: playvideo.c): #include <gst/gst.h> #include <glib.h> #include <string.h> static GstElement *source, *demuxer, *vdqueue, *adqueue, *vdsink, *adsink, *decvd, *decad; void on_pad_added (GstElement *element, GstPad *pad) {         g_debug ("Signal: pad-added");         GstCaps *caps;         GstStructure *str;         caps = gst_pad_get_caps (pad);         g_assert (caps != NULL);         str = gst_caps_get_structure (caps, 0);         g_assert (str != NULL);         if (g_strrstr (gst_structure_get_name (str), "video")) {                 g_debug ("Linking video pad to dec_vd");                 // Link it actually                 GstPad *targetsink = gst_element_get_pad (decvd, "sink");                 g_assert (targetsink != NULL);                 gst_pad_link (pad, targetsink);                 gst_object_unref (targetsink);         }         if (g_strrstr (gst_structure_get_name (str), "audio")) {                 g_debug ("Linking audio pad to dec_ad");                 // Link it actually                 GstPad *targetsink = gst_element_get_pad (decad, "sink");                 g_assert (targetsink != NULL);                 gst_pad_link (pad, targetsink);                 gst_object_unref (targetsink);         }         gst_caps_unref (caps); } static gboolean bus_call (GstBus    *bus,           GstMessage *msg,           gpointer    data) {   GMainLoop *loop = (GMainLoop *) data;   switch (GST_MESSAGE_TYPE (msg)) {     case GST_MESSAGE_EOS:       g_print ("End of stream\n");       g_main_loop_quit (loop);       break;     case GST_MESSAGE_ERROR: {       gchar  *debug;       GError *error;       gst_message_parse_error (msg, &error, &debug);       g_free (debug);       g_printerr ("Error: %s\n", error->message);       g_error_free (error);       g_main_loop_quit (loop);       break;     }     default:       break;   }   return TRUE; } int main (int  argc,       char *argv[]) {   GMainLoop *loop;   GstElement *pipeline;   GstBus *bus;   /* Initialisation */   gst_init (&argc, &argv);   loop = g_main_loop_new (NULL, FALSE);   /* Check input arguments */   if (argc != 2) {     g_printerr ("Usage: %s <Video H264 filename>\n", argv[0]);     return -1;   }   /* Create gstreamer elements */   pipeline      = gst_pipeline_new ("media-player");   source        = gst_element_factory_make ("filesrc","file-source");   demuxer      = gst_element_factory_make ("mfw_mp4demuxer","avi-demuxer");   decvd        = gst_element_factory_make ("mfw_vpudecoder", "video-decoder");   decad        = gst_element_factory_make ("mad", "mp3-decoder");   vdsink        = gst_element_factory_make ("mfw_v4lsink",    "video-sink");   vdqueue      = gst_element_factory_make ("queue",            "video-queue");   adqueue      = gst_element_factory_make ("queue",            "audio-queue");   adsink        = gst_element_factory_make ("fakesink",        "audio-sink");   g_object_set (decvd, "codec-type", "std_avc", NULL);   if (!pipeline || !source || !demuxer || !decvd || !decad || !vdsink || !vdqueue || !adqueue || !adsink) {     g_printerr ("One element could not be created. Exiting.\n");     return -1;   }   /* Set up the pipeline */   /* we set the input filename to the source element */   g_object_set (G_OBJECT (source), "location", argv[1], NULL);   /* we add a message handler */   bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));   gst_bus_add_watch (bus, bus_call, loop);   gst_object_unref (bus);   /* we add all elements into the pipeline */   /* file-source | ogg-demuxer | vorbis-decoder | converter | alsa-output */   gst_bin_add_many (GST_BIN (pipeline),                     source, demuxer, decvd, decad, adqueue, vdqueue, vdsink, adsink,  NULL);   /* we link the elements together */   /* file-source -> ogg-demuxer ~> vorbis-decoder -> converter -> alsa-output */   gst_element_link (source, demuxer);   gst_element_link (decvd, vdqueue);   gst_element_link (vdqueue, vdsink);   //gst_element_link (decad, adqueue);   gst_element_link (adqueue, adsink);   g_signal_connect (demuxer, "pad-added", G_CALLBACK (on_pad_added), NULL);   /* note that the demuxer will be linked to the decoder dynamically.     The reason is that Ogg may contain various streams (for example     audio and video). The source pad(s) will be created at run time,     by the demuxer when it detects the amount and nature of streams.     Therefore we connect a callback function which will be executed     when the "pad-added" is emitted.*/   /* Set the pipeline to "playing" state*/   g_print ("Now playing: %s\n", argv[1]);   gst_element_set_state (pipeline, GST_STATE_PLAYING);   /* Iterate */   g_print ("Running...\n");   g_main_loop_run (loop);   /* Out of the main loop, clean up nicely */   g_print ("Returned, stopping playback\n");   gst_element_set_state (pipeline, GST_STATE_NULL);   g_print ("Deleting pipeline\n");   gst_object_unref (GST_OBJECT (pipeline));   return 0; } Create a directory inside your ltib directory to compile your source code: $ mkdir ~/your-ltib-dir/rpm/BUILD/gst Enter on LTIB shell mode: $ ./ltib -m shell Entering ltib shell mode, type 'exit' to quit LTIB> Enter in your application dir: LTIB> cd rpm/BUILD/gst/ Compile your application: LTIB> gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) playvideo.c -o playvideo If everything worked file you will get a "playvideo" arm binary: LTIB> file playvideo playvideo: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped Now just copy it to ~/your-ltib-dir/rootfs/home. Start your board using this rootfs and execute: root@freescale ~$ cd /home/ root@freescale /home$ ./playvideo your-file-h264-mp3.avi Now playing: your-file-h264-mp3.avi Running...

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

In this article, some experiments are done to verify the capability of i.MX6DQ on video playback under different VPU clocks. 1. Preparation Board: i.MX6DQ SD Bitstream: 1080p sunflower with 40Mbps, it is considered as the toughest H264 clip. The original clip is copied 20 times to generate a new raw video (repeat 20 times of sun-flower clip) and then encapsulate into a mp4 container. This is to remove and minimize the influence of startup workload of gstreamer compared to vpu unit test. Kernels: Generate different kernel with different VPU clock setting: 270MHz, 298MHz, 329MHz, 352MHz, 382MHz. test setting: 1080p content decoding and display with 1080p device. (no resize) 2. Test command for VPU unit test and Gstreamer The tiled format video playback is faster than NV12 format, so in below experiment, we choose tiled format during video playback. Unit test command: (we set the frame rate -a 70, higher than 1080p 60fps HDMI refresh rate)     /unit_tests/mxc_vpu_test.out -D "-i /media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.264 -f 2 -y 1 -a 70" Gstreamer command: (free run to get the highest playback speed)     gst-launch filesrc location=/media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.mp4 typefind=true ! aiurdemux ! vpudec framedrop=false ! queue max-size-buffers=3 ! mfw_v4lsink sync=false 3. Video playback framerate measurement During test, we enter command "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" to make sure the CPU always work at highest frequency, so that it can respond to any interrupt quickly. For each testing point with different VPU clock, we do 5 rounds of tests. The max and min values are removed, and the remaining 3 data are averaged to get the final playback framerate. #1 #2 #3 #4 #5 Min Max Avg Dec Playback Dec Playback Dec Playback Dec Playback Dec Playback Playback Playback Playback 270M unit test 57.8 57.3 57.81 57.04 57.78 57.3 57.87 56.15 57.91 55.4 55.4 57.3 56.83 GST 53.76 54.163 54.136 54.273 53.659 53.659 54.273 54.01967 298M unit test 60.97 58.37 60.98 58.55 60.97 57.8 60.94 58.07 60.98 58.65 57.8 58.65 58.33 GST 56.755 49.144 53.271 56.159 56.665 49.144 56.755 55.365 329M unit test 63.8 59.52 63.92 52.63 63.8 58.1 63.82 58.26 63.78 59.34 52.63 59.52 58.56667 GST 57.815 55.857 56.862 58.637 56.703 55.857 58.637 57.12667 352M unit test 65.79 59.63 65.78 59.68 65.78 59.65 66.16 49.21 65.93 57.67 49.21 59.68 58.98333 GST 58.668 59.103 56.419 58.08 58.312 56.419 59.103 58.35333 382M unit test 64.34 56.58 67.8 58.73 67.75 59.68 67.81 59.36 67.77 59.76 56.58 59.76 59.25667 GST 59.753 58.893 58.972 58.273 59.238 58.273 59.753 59.03433 Note: Dec column means the vpu decoding fps, while Playback column means overall playback fps. Some explanation: Why does the Gstreamer performance data still improve while unit test is more flat? On Gstreamer, there is a vpu wrapper which is used to make the vpu api more intuitive to be called. So at first, the overall GST playback performance is constrained by vpu (vpu dec 57.8 fps). And finally, as vpu decoding performance goes to higher than 60fps when vpu clock increases, the constraint becomes the display refresh rate 60fps. The video display overhead of Gstreamer is only about 1 fps, similar to unit test. Based on the test result, we can see that for 352MHz, the overall 1080p video playback on 1080p display can reach ~60fps. Or if time sharing by two pipelines with two displays, we can do 2 x 1080p @ 30fps video playback. However, this experiment is valid for 1080p video playback on 1080p display. If for interlaced clip and display with size not same as 1080p, the overall playback performance is limited by some postprocessing like de-interlacing and resize.

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

Here is a BDI3000 config file I used with a SABRE SD board sometimes ago that includes DDR initialization. I had several request on this in the past so I am placing it here in case anyone needs it. Please feel free to comment or update the document according to your own experience and results. Regards Sinan Akman

I've done some research in Android boot optimization in the past months and have some getting. This page is for recording and sharing purpose only. It's target to provide some hints and directions for Android optimization. It's NOT a Freescale official document or patch release. The code/doc inside is only for reference. Background:      1. I've used SabreSD + Android KK 4.4.2 GA 1.0 as a reference platform.      2. I'm not doing some popular optimization way such as "hibernation", "suspend". I'm trying to "optimize" the boot process by re-arranging the boot process and make GUI related process run earlier and fine tune some boot code for running faster.      3. It's target to the Android IVI product. So, some features that will never be used in a IVI environment will be disabled or removed. Minor of them. I've come out with a patch package (latest is milestone 4 which is "_m4" in the version for short) and  a training document. I didn't find any confidential information from the patch or doc, so I'm open the sharing here. Updated on 2016/01/08 for new version (milestone m5): --------------------------------------------------------------------------------------- Change log against previous (milestone 4) version:      1. BSP base changed to Android KK 4.4.3 GA 2.0 which has a Linux kernel 3.10.53      2. Linux kernel and uboot optimization added. Kernel boot time (POR -> Android init entry) is less than 1.5s.      3. Some bug fixes.      4. Document updated accordingly. Total boot time tested on SabreSDP is about 8s.

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.

In i.MX8MQ and i.MX8M Mini, the codec used is WM8524, which only supports audio playback. Although 8M Mini does have PDM microphone interface (MICFIL), there is no support for audio record via I2S. This guide will show you how to add audio recording driver in i.MX8MQ/8MM step by step.   Hardware: i.MX8MQ/8MM Evk, I2S output digital microphone OS: Android/Linux Kernel version: 4.14.78 For detailed steps, please see attachment.

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 

NFS and TFTP Boot 1  Introduction This document explains the required steps to boot Linux Kernel and mount a NFS on your target. 2 Requirements A functional Yocto environment (Images generated for your target). Your preferred target.  (SABRE-AI, SABRE-SD) 1 Ethernet Cable 1 Micro USB cable USB to Serial converter depending on your target features. 3 Yocto Folders When you develop your Linux kernel and Root File System with Yocto, different folders are created and each folder contains different information. {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  This directory contains the output images, like Kernel, U-Boot and the File System in a tar file. This directory will be used to fetch the kernel and device tree blob file only. {YOCTO_BUILD_DIR}/tmp/sysroot/{TARGET}/  This folder contains all the development files used to generate our Yocto images. Here we can find all the dynamic libraries and headers used for development. This folder is used as parameter for cross-compilation. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs This folder contains the uncompressed rootfs of our target. This folder will be used as entry in the host NFS server. 4 IP Address and Network Setup This section covers how to boot Linux that mounts the root file system (RFS) over the network. Remember that in this scenario, the RFS exists on the laptop hard drive, and the kernel that runs on the target board will mount the RFS over Ethernet. This setup is used for developing and debugging Linux applications. It allows for applications to be loaded and run without having to re-boot the kernel each time. First some packages on your host need to be installed: # apt-get install xinetd tftp tftpd isc-dhcp-server nfs-kernel-server portmap For development, it is best to have a static IP setup for the board and Linux environment. This way U-Boot options won’t change between reboots as you get a new IP address as you would using DHCP. 4.1 Linux Host Setup This section describes how to setup a static IP in your Linux host environment. This is not required but will allow the IP address of your virtual host system to remain unchanged. Because u-boot parameters use specific IP addresses, this step is recommended because u-boot parameters may need to be updated in the future to match your virtual IP address if it should ever change. You could take the existing IP address and make it static, but you would lose the Internet connection in your virtual machine. Instead we want to make use of the virtual environment and add a secondary Ethernet port that is tied to your wired Internet connection, while keeping the original Ethernet port which can use the wireless connection on your laptop. In the Linux virtual environment, type sudo ifconfig and note that you should have one Ethernet adapter (eth0). The other item listed (lo) is a virtual port for loopback mode. Shutdown the Linux virtual machine In VMware Player, go to Edit virtual machine settings. And add a Bridged Network Adapter, choosing only the wired Ethernet port. And click on OK.  See below for example: Start up the Linux VM. Open a terminal and type: sudo ifconfig You should have a new entry (eth1). This is the new Ethernet port you created in the virtual machine, and it is bridged to your wired Ethernet port. This is the port we want to make a static IP address. To set eth1 to a static IP, open /etc/nework/interfaces sudo gedit /etc/network/interfaces Add the following to set eth1 to your desired IP address. auto eth1 iface eth1 inet static address 192.168.0.100      <-- Your HOST IP netmask 255.255.255.0 gateway 192.168.0.1 Save the file Restart eth1 sudo ifdown eth1 sudo ifup eth1 4.2 Target Setup We need to setup the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters: setenv serverip 192.168.0.100 <-- This must be your Host IP address setenv ipaddr 192.168.1.102  <-- This must be your target IP addres setenv ip_dyn no The path where the rootfs is placed in our host has to be indicated in the U-Boot: setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs setenv image zImage setenv fdt_file uImage-imx6q-sabresd.dtb setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip={ipaddr} nfsroot=${serverip}:${nfsroot},v3,tcp' 4.3 TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. This is how U-Boot will download (via TFTP) the Linux kernel, and then the kernel will mount (via NFS) its root file system on the computer hard drive. 4.3.1 TFTP Setup Next setup the TFTP server. The following commands show that we are logged in as root (#). If you are not root ($) then precede each instruction with “sudo”. Edit /etc/xinetd.conf gedit /etc/xinetd.conf Add and save the following lines in the file service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  disable = no } Notice that {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/   has to be written as absolute path. Restart the xinetd service service xinetd restart Test that TFTP is working tftp localhost tftp> get {An Image found in the tftp folder} tftp> quit 4.3.2 NFS Setup Edit the /etc/exports file gedit /etc/exports Add the path where the rootfs is found in your host. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs *(rw,no_root_squash)                                                                 NOTE:      {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs may work most of the times,        but it is recommended to untar the {IMAGE}.bz2 in an exported           folder keeping using sudoand keeping the chmod of each file.     3. Restart the NFS service sudo service portmap stop sudo service nfs-kernel-server stop sudo service portmap start sudo service nfs-kernel-server start 5 Host Final Configuration and Booting Linux over NFS In your host, under the images folder {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/ create the below links ln -s zImage_imx_v7_defconfig zImage      2. In U-boot type the below command:                run netboot After a pair of minutes you should get a Linux working system on your target.

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