The VAR-SOM-SOLO small form factor System-on-Module carries an advanced feature-set and broad connectivity options, making it an ideal solution for customers and products in the embedded market.   Staying on-trend with the market’s shift towards a cost-effective highly integrated off-the-shelf solution, the VAR-SOM-SOLO from Variscite levels the playing ground for a broad spectrum of embedded products. Bringing all the benefits of the widely successful VAR-SOM-MX6, the VAR-SOM-SOLO from Variscite carries much smaller dimensions and a slim lined price-point.  Features include Freescale’s i.MX6 1GHz Cortex-A9, SLC NAND, eMMC, dual band Wi-Fi/BT with MIMO, USB, Gigabit Ethernet, A/V interfaces and industrial operating temperatures. The VAR-SOM-SOLO utilizes a standard SO-DIMM 200pins interface to the carrier board, fully pin-to-pin compatible with the VAR-SOM-MX6.   Ohad Yaniv, Variscite’s CEO, explains the strategy behind the new System-on-Module: “In today’s market, we believe the compact VAR-SOM-SOLO presents a true synergy between an impressive feature set and an affordable price-point. We feel the newly introduced SoM reflects a constantly evolving embedded application concept that requires advanced multimedia features, in a compact and cost efficient solution.”   Key features include:   - Freescale i.MX6 1000MHz single Cortex-A9   - Up to 1GB DDR3, 512MB SLC NAND and 64GB eMMC   - Certified Wi-Fi 802.11 a/b/g/n 2.4/5GHz with optional 2x2 MIMO   - Bluetooth 4.0/BLE   - Full 1080p video encode/decode capability   - Vivante GPU 2D/3D graphics accelerator   - Display: 2x LVDS, HDMI1.4, MIPI DSI   - 10/100/1000 Mbps Ethernet   - USB 2.0: Host, OTG   - PCIe   - Audio In/Out   - Camera inputs: MIPI CSI, parallel   - Dual CAN, UART, I2C, SPI   - Industrial temperature -40 to 85°C   - Dimensions: 33mm x 68mm x 4mm   - OS: Linux Yocto & Ubuntu, Android, WEC 7 & 2013   Availability and Pricing: The VAR-SOM-SOLO is available now. Pricing starts at 42USD. Contact [email protected] or +972 9 9562910 for more information.   About Variscite: Variscite is a leading System on Modules (SoM) and Single-Board-Computer (SBC) design and manufacture company. A trusted provider of development and production services for a variety of embedded platforms, Variscite transforms clients’ visions into successful products.   Learn more about Variscite, visit www.variscite.com    

[中文翻译版] 见附件   原文链接： Add a new shared memory region on Android Auto P9.0.0_GA2.1.0 BSP 

Measuring only 20mm x 50mm, the DART-MX6 from Variscite is the smallest System-on-Module (SoM) supporting Freescale’s i.MX6 quad and dual core ARM Cortex-A9™ processor. The DART-MX6 offers impressive performance and scalability. Together with optimized power consumption this miniature sized SoM is ideal for portable and battery operated embedded systems. The DART-MX6 highly integrated connectivity includes dual band Wi-Fi/BT with optional MIMO, dual USB, Gigabit Ethernet, PCIe and A/V interfaces. Furthermore, the system supports industrial operating temperatures. Performing as the DART-MX6 carrier board, the VAR-DT6CustomBoard completes an attractive full reference kit, which can be used for customers’ evaluation, development and end-product mass production. Key features of the DART-MX6 include: - Miniature size: 20mm x 50mm x 4mm - Freescale i.MX6 800MHz Quad/Dual ARM Cortex-A9 - Up to 1GB LP-DDR2 and 32GB eMMC - Certified Wi-Fi 802.11 a/b/g/n 2.4/5GHz with optional 2x2 MIMO - Bluetooth 4.0/BLE - Full 1080p video encode/decode capability - Vivante GPU 2D/3D graphics accelerator - Display: 2x LVDS, HDMI1.4, MIPI DSI - 10/100/1000 Mbps Ethernet - USB 2.0: Host, OTG - PCIe - Audio In/Out - Camera inputs: MIPI CSI, parallel - Dual CAN, UART, I2C, SPI - Industrial temperature - OS: Linux Yocto, Android Availability and Pricing: The DART-MX6 SoM and development kits are available now. Email [email protected] or call +972 9 9562910 for more information About Variscite: Variscite is a leading System on Modules (SoM) and Single-Board-Computer (SBC) design and manufacture company. A trusted provider of development and production services for a variety of embedded platforms, Variscite transforms clients’ visions into successful products. Learn more about Variscite, visit www.variscite.com

How to load the camera driver modprobe ov3640_camera modprobe mxc_v4l2_capture How to encode audio gst-launch alsasrc ! mfw_mp3encoder ! filesink location= audio.mp3 Encoding an AVI audio only gst-launch alsasrc ! mfw_mp3encoder ! avimux ! filesink location=audio.avi You can use audiotestsrc instead of alsasrc Encoding Audio and Video (testsrc only) Raw video and Raw audio gst-launch videotestsrc num-buffers=250 ! 'video/x-raw-yuv,format=fourcc)I420,width=320,height=240,framerate=(fraction)25/1' ! queue ! mux. audiotestsrc num-buffers=440 ! audioconvert ! 'audio/x-raw-int,rate=44100,channels=2' ! queue ! mux. avimux name=mux ! filesink location=test.avi H.263 video and Raw audio gst-launch videotestsrc num-buffers=250 ! mfw_vpuencoder codec-type=1 ! queue ! mux. audiotestsrc num-buffers=440 ! audioconvert ! 'audio/x-raw-int,rate=44100,channels=2' ! queue ! mux. avimux name=mux ! filesink location=test.avi H.263 video and MP3 audio gst-launch videotestsrc num-buffers=250 ! mfw_vpuencoder codec-type=1 ! queue ! mux. audiotestsrc num-buffers=440 ! audioconvert ! mfw_mp3encoder ! queue ! mux. avimux name=mux ! filesink location=test.avi Real Source gst-launch-0.10 mfw_v4lsrc capture-mode=5 num-buffers=300 capture-width=320 capture-height=240 fps-n=15 blocksize=115200 ! queue2 max-size-buffers=1000 max-size-bytes=0 max-size-time=0 ! mfw_vpuencoder framerate=15 codec-type=2 name=venc  alsasrc num-buffers=300 ! audio/x-raw-int,rate=32000,channels=1,depth=16 ! audioconvert ! queue2 max-size-buffers=1000 max-size-bytes=0 max-size-time=0 ! mfw_mp3encoder name=aenc avimux name=mux ! filesink location=all_in_one.avi aenc. ! mux. venc. ! mux. The movie isn't that good, but you can improve that increasing num-buffers, width and heigh, and even framerate! STAMP If you face synchronization issues, you can try to use a non-standard plugin called stamp. Use the spec file gst-entrans.spec and this command line: gst-launch-0.10 mfw_v4lsrc capture-mode=5 num-buffers=160 capture-width=320 capture-height=240 fps-n=15 blocksize=115200 !  stamp sync-margin=1 sync-interval=1 ! queue2 max-size-buffers=1000 max-size-bytes=0 max-size-time=0  !  mfw_vpuencoder framerate=15 codec-type=2 name=venc  alsasrc num-buffers=160  !  audio/x-raw-int,rate=32000,channels=1,depth=16     !  audioconvert ! queue2 max-size-buffers=1000 max-size-bytes=0 max-size-time=0      !  mfw_mp3encoder name=aenc avimux name=mux ! filesink location=test_ALL.avi aenc. ! mux. venc. ! mux. Donwload the package from here: http://gentrans.sourceforge.net/ (source for stamp topic: http://blog.buberel.org/2008/03/using-a-usb-web.html)

The i.MX 6 D/Q/DL/S/SL  Android JB4.3_1.1.1 Patch release is now available on www.freescale.com ·         Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board This patch release is based on the i.MX 6 Android JB 4.3_1.1.0-GA BSP release. ·         Release Description o   To upgrade the GPU kernel and libraries to improve GPU stability o   To handle the Android SDK build failure o   To improve FSL OMX The table below describes the contents of this release.      Release Description Patches Contains the patches included in this release. The patches   are described in “Patch Description”. Documentation Contains the following document: • i.MX 6 Android JB 4.3_1.1.1 Patch Release Notes: This   document. ·         Patch Description Please consult the release notes.

In recent months, some i.MX6ULL users try to add google chromium to Linux BSP L4.1.15 managed by yocto project 2.1 (krogoth), but failed.  One of A customers project also encoutered the same issues, their engineers submitted case to us asking for help. Then a compilation test for the customer was done,  there really exist some errors during compilation. The follwing contents show how to compile it and handle issues. ---System Configurations Hardware: notebook, i7 4-cores, 16GB DDR4 Software: windows 7/10, VMware Player 14.0, USB3.1 SSD Step1: # cd ~/fsl-release-bsp # DISTRO=fsl-imx-x11 MACHINE=imx6ull14x14evk source fsl-setup-release.sh -b build-x11 # gedit ./conf/local.conf          Add lines below, just like descriptions of chromium in i.MX_Yocto_User’s_Guide.pdf …… CORE_IMAGE_EXTRA_INSTALL += "chromium libexif" LICENSE_FLAGS_WHITELIST="commercial" …… [Comment] Above methord has been described in i.MX_Yocto_User's_Guide.pdf. # bitbake chromium -c fetch           Begin to download chromium package：                    If you feel it’s the speed of download is too slow, you can copy the following link to explorer, and download the file directly: http://gsdview.appspot.com/chromium-browser-official/chromium-48.0.2548.0.tar.xz Then copy the file to ~/fsl-release-bsp/downloads. And create a.done file by touch command in the directory. # cd ~/fsl-release-bsp/downloads # touch chromium-48.0.2548.0.tar.xz.done          Empty file is OK, not need any contents in the file. Step 2          Begin to compile chromium: # cd ~/fsl-release-bsp/downloads/build-x11 # bitbake chromium -c compile          From the following picture, total tasks are 1636 Errors 1 during compilation Error : ERROR: cups-2.1.3-r0 do_fetch: Fetcher failure: Fetch command failed with exit code 4, output: failed: Connection timed out. Read error (Connection timed out) in headers.   ERROR: cups-2.1.3-r0 do_fetch: Function failed: Fetcher failure for URL: 'https://www.cups.org/software/2.1.3/cups-2.1.3-source.tar.bz2'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /home/weidong/fsl-release-bsp-415-200/build-x11/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/cups/2.1.3-r0/temp/log.do_fetch.33362 ERROR: Task 111 (/home/weidong/fsl-release-bsp-415-200/sources/poky/meta/recipes-extended/cups/cups_2.1.3.bb, do_fetch) failed with exit code '1' Handle it: Download the file through explorer: https://www.cups.org/software/2.1.3/cups-2.1.3-source.tar.bz2 Then copy it to ~/fsl-release-bsp/downloads, and create cups-2.1.3-source.tar.bz2.done Continue: # bitbake chromium -c compile Errors 2 during compilation Handle it : copy the fsimx6ul-chromium.patch to your main yocto directory (same directory were you can find yocto-download). Switch to this directory and apply the patch with the following command: patch -p1 < fsimx6ul-chromium.patch Compile your yocto rootfs again [Comment] The solution is from the link: https://forum.fs-net.de/index.php?thread/4352-yocto-build-chromium-browser/ fsimx6ul-chromium.patchis provided by F&S Support Team Continue: # bitbake chromium -c compile Successfully. Step 3 Compiling full image # bitbake fsl-image-gui          When chromium compilation is done, we can begin to comipile rootfs(fsl-image-gui)          Then no errors occurred. Compiled BSP successfully.   Then we check if chromium has been included in rootfs. # cd ~/fsl-release-bsp/build-x11/tmp/deploy/images/imx6ull14x14evk [Comment] (1) fsl-image-gui-imx6ull14x14evk-20200425220751.rootfs.tar.bz2          The file is rootfs without u-boot/device tree/linux kernel. (2) fsl-image-gui-imx6ull14x14evk-20200425220751.rootfs.sdcard          The file is full image including u-boot/device tree/kernel/rootfs Here is the links among files:          Now we check if rootfs have included chromium, create a temp directory in ~/ and copy rootffs to the temp directory # mkdir ~/temp # cp ./fsl-image-gui-imx6ull14x14evk-20200425220751.rootfs.tar.bz2 ~/temp          Then decompress it. # cd ~/temp # tar -jxvf fsl-image-gui-imx6ull14x14evk-20200425220751.rootfs.tar.bz2 # cd usr/bin/chromium/ # ls Successfully. NXP TIC team Weidog Sun 2020/05/01

From iMX 3.1x kernel, all kernel debug messages will be print to debug serial port after UART driver loaded, so if the kernel hang up before tty console driver ready, there will be no kernel boot up messages.   The attached patch can be used to enable the iMX serial debug console in early time, then kernel will not buffer the debug messages.   Note: the default patch is for UART1 (tty0) as the debug port, if you need use other debug port, please modify the code "early_console_setup()" with correct UART port base address.   L3.10.53-Add-early-console-for-debug-message.patch This patch is based on L3.10.53_GA1.1.0 release, it can support iMX6S/DL/D/Q.   L3.14.52-Add-early-console-for-debug-message.patch This patch is based on L3.14.52_GA1.1.0 release, it can support iMX6S/DL/D/Q, iMX6SL, iMX6SX, iMX6UL and iMX7.  

The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.1 patch release is now available in the Freescale git. The issue fixed is a GPU issue, for 2D GPU cores there is a potential need to manage the maximum number of outstanding return requests from the memory subsystem. The proper way to manage these for 2D cores with this configuration is to use a FLUSH. The patch does a FLUSH after every DRAW, the pipe will not overfill and the scenario which may lead to a stall will not occur. The instruction to get the patch are in the Readme on the git, under this link: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.17-1.0.1_ga

BSP version: 11.03 Multimedia Package version: 11.03 1. Install BSP and Multi Media package (11.03 release) 2. Avoid Display Timeout: append the following line to rootfs/etc/oprofile: echo -e -n '\033[9]' > /dev/tty0 3. Set VGA port as the primary display in the kernel command line: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga 4. Connect a VGA monitor and WVGA display to the MX53 Quick Start 5. Boot Linux on MX53 Quick Start board (NFS is used in this example) 6. Unblank WVGA display (fb1): $ echo 0 > /sys/class/graphics/fb1/blank 7. On the target enter into /dev/shm directory. If the following files are present: vss_lock vss_shmem ,delete them. 8. On your host, edit the ltib/rootfs/usr/share/vssconfig as following: vss device definition Master=VGA, Slave=WVGA master display [VGA] type = framebuffer format = RGBP fb_num = 2 main_fb_num = 0 vs_max = 4 slave display [WVGA] type = framebuffer format = RGBP fb_num = 1 vs_max = 4 9. Run the Gstreamer pipeline below: gst-launch filesrc location=file.mp4 ! qtdemux ! mfw_vpudecoder ! mfw_isink display=VGA display-1=WVGA Video is played on the VGA and WVGA panels. A 720p file can be played at the same time.

LTIB Creating Uimage Uboot Configuration file for fw_(printenv/saveenv) utility Add new i.MX5x board on LTIB LTIB Creating Uimage Uboot U-boot expects uImage format for the kernel image. In order to LTIB generate a uImage file: $ export SYSCFG_KTARG=uImage $ ./ltib -p kernel Setup in U-Boot the kernel bootargs: u-boot> setenv bootargs noinitrd console=ttymxc0,115200 init=/linuxrc root=/dev/nfs nfsroot=10.29.244.27:/tftpboot/rootfs ip=dhcp Change 10.29.244.27 to your host IP. The procedure above is needed when default bootloader used by ltib was redboot. In some ltib releases (before 2010) default bootloader is u-boot. In this case, ltib will create uImage by default Configuration file for fw_(printenv/saveenv) utility # Configuration file for fw_(printenv/saveenv) utility. # Up to two entries are valid, in this case the redundant # environment sector is assumed present. # Notice, that the "Number of sectors" is ignored on NOR.               # MTD device name Device offset Env. size Flash sector size Number of sectors #/dev/mtd1 0x0000 0x4000 0x4000 #/dev/mtd2 0x0000 0x4000 0x4000 # NAND example /dev/mtd0 0x80000 0x40000 0x20000 2 Add new i.MX5x board on LTIB After porting u-boot to your i.MX5x board you might want add it on LTIB menu, "Choose your board for u-boot" section. For this, edit ltib/config/platform/imx/main.lkc to add your board: Enter board on menu: comment "Choose your board for u-boot" choice prompt "board" default BOARD_MX51_BBG depends on PLATFORM = "imx51" help This menu will let you choose the board you use. ... + config BOARD_MX53_MYBOARD + bool "mx53_myboard" ... endchoice Add the "mx53_myboard_config" that matches your board configuration on the u-boot Makefile to PKG_U_BOOT_CONFIG_TYPE: config PKG_U_BOOT_CONFIG_TYPE   string   ... + default "mx53_myboard_config" if ( PLATFORM = "imx51" && BOARD_MX53_MYBOARD && !PKG_KERNEL_UPDATER )   ...

Print caller stack may help you to analyze the program and find out the caller stack more easily. You can write your code like this: Java:      Exception e = new Exception();      Log.e(TAG,"xxx",e); C++ file:       #include <utils/Callstack.h>      android::CallStack stack;      stack.update(1,30);      stacn.dump("xxx"); Then you can see the function's caller stack in Android main log file. C file: #include <corkscrew/backtrace.h> #define MAX_DEPTH 31 #define MAX_BACKTRACE_LINE_LENGTH 800 static backtrace_frame_t mStack[MAX_DEPTH]; static size_t mCount; void csupdate(int32_t ignoreDepth, int32_t maxDepth) {     if (maxDepth > MAX_DEPTH) {         maxDepth = MAX_DEPTH;     }     ssize_t count = unwind_backtrace(mStack, ignoreDepth + 1, maxDepth);     mCount = count > 0 ? count : 0; } void csdump(const char* prefix)\ { size_t i = 0;     backtrace_symbol_t symbols[MAX_DEPTH];     get_backtrace_symbols(mStack, mCount, symbols);     for (i = 0; i < mCount; i++) {         char line[MAX_BACKTRACE_LINE_LENGTH];         format_backtrace_line(i, &mStack[i], &symbols[i],                 line, MAX_BACKTRACE_LINE_LENGTH);         ALOGE("%s%s", prefix, line);     }     free_backtrace_symbols(symbols, mCount); } void myFunc() {      csupdate(1, 30);      csdump("myprefix"); } In Android.mk, add libcorkscrew, as below LOCAL_SHARED_LIBRARIES := libxxx libyyy libcorkscrew

This patch implements (or exposes) routines to poll the imx uarts. The KGDB drivers need these methods to be implemented or the ttymxc driver is not sufficient. The synthetic CONFIG_CONSOLE_POLL value activates these routines (or CONFIG_SERIAL_MXC_CONSOLE for the polled write). There is still no poll routines in -855-ge067785, which is the September 2010 Linux release from Freescale. Also not in Linux 2.6.36 drivers/serial/imx.c either. $ git diff drivers/serial/mxc_uart.c diff --git a/drivers/serial/mxc_uart.c b/drivers/serial/mxc_uart.c index ae6d2e1..728b607 100644 --- a/drivers/serial/mxc_uart.c +++ b/drivers/serial/mxc_uart.c @@ -1551,6 +1551,28 @@ mxcuart_pm(struct uart_port *port, unsigned int state, unsigned int oldstate)                             clk_enable(umxc->clk);    }  +#ifdef CONFIG_CONSOLE_POLL +/* + * Read a character from the UART. + */ +static inline int mxcuart_console_read_char(struct uart_port *port) +{ +       volatile unsigned int status; +    int ch; + +       do { +               status = readl(port->membase + MXC_UARTUSR2); +       } while ((status & MXC_UARTUSR2_RDR) == 0); +       ch = readl(port->membase + MXC_UARTURXD); +/* Ignore parity errors, etc. */ +/*  status = ch | UART_CREAD_BIT; */ +    ch &= 0xff; + +    return ch; +} +static void mxcuart_console_write_char(struct uart_port *port, char ch); +#endif +    /*!     * This structure contains the pointers to the control functions that are     * invoked by the core serial driver to access the UART hardware. The @@ -1575,14 +1597,18 @@ static struct uart_ops mxc_ops = {                 .config_port = mxcuart_config_port,                 .verify_port = mxcuart_verify_port,                 .send_xchar = mxcuart_send_xchar, +#ifdef CONFIG_CONSOLE_POLL +              .poll_put_char = mxcuart_console_write_char, +              .poll_get_char = mxcuart_console_read_char, +#endif };  -#ifdef CONFIG_SERIAL_MXC_CONSOLE +#if defined(CONFIG_SERIAL_MXC_CONSOLE) || defined (CONFIG_CONSOLE_POLL)     /*     * Write out a character once the UART is ready     */ -static inline void mxcuart_console_write_char(struct uart_port *port, char ch) +static void mxcuart_console_write_char(struct uart_port *port, char ch)    {            volatile unsigned int status;  @@ -1592,6 +1618,10 @@ static inline void mxcuart_console_write_char(struct uart_port *port, char ch)                writel(ch, port->membase + MXC_UARTUTXD);     }  +#endif + +#ifdef CONFIG_SERIAL_MXC_CONSOLE +    /*!     * This function is called to write the console messages through the UART port.     *

Question: How much control of the bitrate does the i.MX6's VPU provide? VPU API includes a bitrate setting in the EcnOpenParam, is this a maximum, minimum, or something else? To encode two 1280x1080 streams at 30fps with a bit rate of at least 20Mbps, from the information in the following thread, it looks like this isn't supported due to VPU bandwitdh, Is there any limit on bitrate due to the VPU's processing bandwidth?  I.e., if the stream is limited to one 1280x1080 channel, can we choose a maximum bit rate and if so, how do we determine what it is? Answer: The bitRate field in the EncOpenParam structure is the desired target bit rate in kbps. If 0, there is no rate control and frames are encoded based on the quantization parameter specified by the quantParam field in EncParam.structure. It seems upper limit is 20Mbps for 1280x1080@30fps. So you should specified bitrate=2000 in your use case. In general, the maximum bitrate is about 30Mbps. Vpu driver will return invalid parameter if the appointed bitrate reach out of the range (0, 32767kbps). Please refer to Q&A: MX6 VPU H.264 Dual Stream Encode Limits.

Q: ”We noticed that the specified risetime of this signal is max 5nS, while the Sable board schematic shows it driven from open collector/drain using only the 100k haulup provided in the chip. This will have risetimes of 10‘s (if not 100‘s!) of ns. The worrying thing is that the latest datasheet update specifically clarifies this rise time spec, so presumably it‘s considered important. Which is right? If the rise time spec needs to be met, we need a small haul up resistor or an active drive. In that case what rail should be used to haul/drive POR_B high?” It appears to be correct, and what is interesting I checked the PFUZE timing in the datasheet ”tr4 Rise time of RESETBMCU - 0.2 ms” Device: i.MX6Q OS: Linux Dev Board: i.MX6Q SDB A: The 5ns rise/fall time requirement does not apply to i.MX6. This was probably carried over from the i.MX53 where it was required. This will be removed from the datasheet but it will likely not be until the September time frame. We're not doing an update to any of the electrical parameters of the datasheet right now.

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

The PICO-PI-IMX7 is a TechNexion board defined here. It is now supported in mainline U-Boot, mainline Kernel, FSL Community BSP and Buildroot. In mainline U-Boot it is supported since v2017.07. In mainline Linux Kernel it is supported since 4.13. To generate an image for PICO-PI-IMX7 using FSL Community BSP, please see: The imx7d-pico board is now supported in FSL Community BSP - i.MXDev Blog. To generate an image for PICO-PI-IMX7 using Buildroot, please see: The imx7d-pico board is now supported in Buildroot - i.MXDev Blog.

The i.MX6SX series of applications processors are powered by two asymmetrical cores: one ARM Cortex-A9 and one Cortex-M4. It allows the coexistence of real-time and non-real-time applications on the same processor (M4 core running an RTOS, and A9 core running Linux or Android). This document will explain how to compile and download a customized MQX application to the QSPI Flash of the IMX6SX-SDB board using a Ubuntu host. The example application will be connecting a 16x2 LCD to GPIO pins of the i.MX6SX. As the IMX6SX-SDB board doesn’t have GPIO header, we will use the pins from SD3 socket, so, it will be required to add the proper pin definitions to the MQX BSP. First of all, the Yocto image will be used as base to boot the A9 core (BSP L3.14.28_1.0.0), because it is the main core and the M4 core will be held on reset until the A9 removes the reset from it. The Yocto image includes many device tree files on the FAT partition, and the default DTB doesn’t consider the existence of the M4 core (only required when Linux applications would consider the M4 core as a resource), so, for changing the DTB file, launch the following command on U-Boot: => setenv fdt_file imx6sx-sdb-m4.dtb We are going to download and uncompress MQX 4.1 for i.MX6SX (Linux hosted) from the following link: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX In this example, GCC compiler for ARM will be used, so, download and uncompress gcc-arm-none-eabi-4_8-2014q1 from the link below: https://launchpad.net/gcc-arm-embedded/+download Additional Linux commands consider that MQX and GCC were uncompressed on /home/user folder. In order to avoid compiler error, it will be required to set a couple of environments variables: $ export TOOLCHAIN_ROOTDIR=/home/user/gcc-arm-none-eabi-4_8-2014q1 $ export PATH=$PATH:/home/user/gcc-arm-none-eabi-4_8-2014q1/bin/ Before building any MQX example applications, it is required to build MQX libraries (included BSP and PSP), so, navigate to the next folders and launch the build script in each of them: $ cd /home/user/ Freescale_MQX_4.1.0_i.MX_6SoloX /mqx/build/make/bsp_imx6sx_sdb_m4/ $ ./build_gcc_arm.sh $ cd /home/user/ Freescale_MQX_4.1.0_i.MX_6SoloX /mqx/build/make/psp_imx6sx_sdb_m4/ $ ./build_gcc_arm.sh Now we can compile the example applications like the GPIO demo (that will be used as base for our customized application): /home/user/Freescale_MQX_4.1.0_i.MX_6SoloX/mqx/examples/gpio/ Our example application will configure the 6 pins of the SD3 socket (LWGPIO_PIN_SD3_DATA0, LWGPIO_PIN_SD3_DATA1, LWGPIO_PIN_SD3_DATA2, LWGPIO_PIN_SD3_DATA3, LWGPIO_PIN_SD3_CMD, LWGPIO_PIN_SD3_CLK) for using them by the M4 core on MQX; so, it will be required to add the proper definitions on the board’s header file for each pin (in this case, “imx6sx_sdb_m4.h”). The following corresponds to the LWGPIO_PIN_SD3_DATA0 pin (we are naming them as “SD2GPIO0 – SD2GPIO5”): #define BSP_SD2GPIO0_PROMPT         "SD2GPIO0" #define BSP_SD2GPIO0                (LWGPIO_PIN_SD3_DATA0) #define BSP_SD2GPIO0_MUX_GPIO       (LWGPIO_MUX_SD3_DATA0_GPIO) #define BSP_SD2GPIO0_MUX_IRQ        (LWGPIO_MUX_SD3_DATA0_GPIO) As this file is part of the BSP, it will be required to recompile the BSP after applying these modifications. The modified header file could be found on the attachments of this document. Now, we are going to copy the entire folder of the “gpio” example to the same location, and we will rename it as “sd2gpio”. Inside such folder, we should also rename the “gpio.c” file to “sd2gpio.c”. Besides, it is required to edit the “Makefile” file in order to redirect the included paths to the new folder. It is basically done on the following two lines: NAME = sd2gpio SOURCES += $(MQX_ROOTDIR)/mqx/examples/sd2gpio/sd2gpio.c The modified “Makefile” file is also available on the attachments. The “sd2gpio.c” file includes the main MQX task that will initialize the LWGPIOs using the definitions declared on the board’s header file. It also includes the functions used by the 16x2 LCD driver. This file is also included on the attachments of this thread. With all the modifications done and the BSP recompiled, we can now compile our customized application by launching the command: $ ./build_gcc_arm.sh Located on the following path: /home/user/Freescale_MQX_4.1.0_i.MX_6SoloX/mqx/examples/gpio/build/make/ gpio_imx6sx_sdb_m4/ The output file (an ELF file) will be located at the following path: /home/user/Freescale_MQX_4.1.0_i.MX_6SoloX/mqx/examples/gpio/build/make/ gpio_imx6sx_sdb_m4/cd gcc_arm/extflash_debug/ Now, we are going to move to this folder, and launching the following command to convert the ELF file to a BIN file. It is required because we will flash the QSPI Flash using the A9 core, and the symbols data of the ELF file is not required (actually, the flashing applications looks for “m4_qspi.bin” file): $ arm-none-eabi-objcopy -O binary sd2gpio_imx6sx_sdb_m4.elf m4_qspi.bin Next, copy the BIN file to the FAT partition of the SD card (considering it is mounted over /media/ 😞 $ cp m4_qspi.bin /media/Boot\ imx6sx/ && sync Now we will place the SD card on the SDB board and boot it. Stop the boot process on U-Boot and launch the following command for flashing the QSPI Flash from the BIN file: => run update_m4_from_sd Finally, start the MQX application by releasing the reset of the M4 by launching the following command: => run m4boot The figure below shows the LCD with the application working: Additional tests: If you want to run the M4 application out of reset you could modify the environment variable ‘bootcmd’. For displaying the default variable value, launch the following command: => printenv bootcmd So, for just removing the reset from M4 core without booting Linux, launch the command below: => setenv bootcmd=‘run m4boot’ If you want to avoid the count-down delay (for a faster boot), you could try the following command: => setenv bootdelay 0 Finally, if Linux is also boots after the M4, it will change some clock settings, and also mounts the SD3 driver, so, the pin configurations will be overrode. In order to avoid clock issues on the M4, add to boot parameters ‘uart_from_osc' like command below: => setenv mmcargs 'setenv bootargs no_console_suspend clk_ignore_unused uart_from_osc console=${console},${baudrate} root=${mmcroot}' Don’t forget to save the environment after changing environments variables and then, reboot: => saveenv

I have imx53 quick sort board i downloaded u-boot-mx53.bin and uImage to loade that into the board and dowloaded rootfs.ext2.gz in the L2.6.35_11.09.01_ERimages and i did partitions on 1GB memory card and loaded that u-boot-mx53.bin,uImage images on to the 500mb of NTFS filesystem and loaded and rootfs.ext2.gz on to the othe 500mb of ext4 file system the i inserted memorycard in to the board but u-boot logs are not comming what will be the solution

In the default release the SSI1 doesn't suport double FIFO in audio driver. Attached was the code to support double FIFO with updated DMA script.