In this doc will show how to adjust display brightness/contrast/saturation by using i.MX8  Display Controller (DC) Subsystem.   HW: i.MX8QXP MEK board SW: Linux 4.14.98_2.0.0 BSP release.   See i.MX 8DualXPlus/8QuadXPlus Applications Processor Reference Manual, Rev. 😧 This kind Matrix total number is 5 , that is 0/1/4/5/9. In this doc using Matrix0 to adjust whole display brightness/contrast/saturation. Matrix0 unit position is located between FramGen unit and Tcon unit, that means using Matrix0 will impact on the whole display contents. Note, this Matrix is applied on RGB color space.    The Matrix is consist of two parts: and  You can program any value into register of A11 to A44 and C1 to C4, Matrix will applied on input RGB data, then output RGB data will changed as you want. In this way, we can change the display brightness/contrast/saturation. The Matrix entry from A11 to A44, their register format is same as below: Each register entry of A11 to A44 , total 13 bit, bit 12 is symbol bit , bit 11 and bit 10 is integer bit, bit 9 to bit 0 is floating point bit. The Matrix entry from C1 to C4, their format is same as below: Each register entry of C1 to C4, total 13 bit, bit 12 is symbol bit, others are integer bit. Now let us choose the matrix that will be used for adjust brightness/contrast/saturation. See this link  https://docs.rainmeter.net/tips/colormatrix-guide/ So we can set matrix as below to change brightness/contrast/saturation   A11=c(sr+s)   A12=c(sg)    A13=c(sb)   A21=c(sb)     A22=c(sg+s)  A23=c(sb)   A31=c(sr)     A32=c(sg)    A33=c(sb+s)   C1=C2=C3=t+b   b as brightness , range[-1.0, 1.0], zero means no change , >0 will increases brightness, <0 will reduce brightness. c as contrast, range [0,2.0) , default is 1.0 , >1.0 is increase , <1.0 is reduce. s is saturation, range [0,1.0], default is 1.0.  Other matrix entry is related to alpha, in this doc not change it, just keep them as zero.     Note here sr,sb,sg value will depend on lumR/ lumG/ lumB constant value you choose, this value may depend on different color standard.   Due to each matrix value is floating point number, and in this doc , i.MX8X run Linux OS. So you can choose do floating point operation in user space program, then pass related register value into kernel space , let driver write them into register. But in this doc, to make Linux kernel driver more simple, I will convert floating point operation into integer operation , then user space app just pass brightness/contrast/saturation value into kernel space, then kernel driver to do left operation in kernel space. So 1024*c and 1024*s is integer number that user space app will passed into kernel space. And in kernel space could be do left integer number operation, then write register value. The kernel patch 8qxp_4.14.98_brightness_contrast_saturation.diff could be used on 4.14.98_2.0.0 BSP release. Test usage, need used one patch that for proptest which from libdrm test case, see 8qxp_prop_test.diff, recompile the proptest case. root@imx8qxpmek:~# ./proptest     //list current drm property CRTC 32         42 bringhtness:                 flags: range                 values: 0 131071                 value:0x0         43 contrast:                 flags: range                 values: 0 2048                 value:0x400         44 saturation:                 flags: range                 values: 0 1024                 value:0x400         45 update:                 flags: range                 values: 0 1                 value:0x0   I add four drm property , brightness, contrast, saturation, update. The “update property” should be set as 1 at last, otherwise kernel space will not update related property. Reference API usage ( in 8qxp_prop_test.diff) +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 42, b_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 43, c_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 44, s_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 45, 1);      //run cmd as below , will ask you input related brightness/contrast/saturation value , then will get result in display root@imx8qxpmek:~# ./proptest 32 crtc 45 1   input brightness [-1,1] 0.3 input contrast, >1.0 or <1.0 1.2 input saturation, [0,1] 0.3 brightness 0.300000  0x133 from [-1,1] percent contrast  1.200000  0x4cc >1.0 or <1.0 saturation 0.300000 0x133  from 0.0 to 1.0   Known Issue: For demo this feature , I need run proptest and weston at same time. Due to the set property drm ioctl default allowed by DRM master and DRM control client. But 4.14. kernel, removed the DRM control device node, so I changed to open drm render node fd, and allow DRM render client to using set property drm ioctl.  This is just a workaround, you may not use it. Reference: 1.https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf  2.https://docs.rainmeter.net/tips/colormatrix-guide/

The document will introduce all steps for poring WM8960 audio codec to freescale android4.2.2 BSP. Attachments include : (1)Document for porting (2)Codec driver : wm8960.c (3)Machine driver: imx-wm8960.c (4)wm8960 schematic for reference (5)Android Audio HAL: config_wm8960.h (6)schematic: MX6QDL-PIANO-CNFV1.DSN (7)i.MX6DL BSP files mx6dl_piano.c mx6dl_piano.h mx6dl_piano_pmic_pfuse100.c (8)i.MX6Q BSP files mx6q_piano.c mx6q_piano.h mx6q_piano_pmic_pfuse100.c   Freescale TICS Team Weidong.sun

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 )   ...

                                                                                         Watch the Freescale i.MX team boot up Android 5.0 Lollipop in i.mx6 application processors—在线播放—优酷网，视频高清在线观看 The Freescale i.MX Android team has booted up Android 5.0 Lollipop in the SABRE platform for i.mx6 series. Google pushed all of the latest source for its Android release to AOSP on Nov. 5, and the Freescale Android Team started their work. With the previous 6 days to boot Android Lollipop up, the Freescale i.MX Android team enabled the basic features like connectivity, audio/video playback, sensors, inputs and display on day 7! You can see the some changes in the demo video at the beginning of the post. The Freescale i.MX Android team has closely followed almost every version of Android since it is released by AOSP and has good experience on it. Below are some snapshots and pictures for the Android Lollipop.

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

Understanding and using the .sdcard format One very useful feature enabled by default in both the Yocto Communiy BSP and Release BSP is the option of generating the baked images in .sdcard format. If the .sdcard format is not selected by default it can be enabled on the conf/local.conf file by adding it with the IMAGE_FSTYPES as follow: IMAGE_FSTYPES="sdcard" It’s important to note that if this variable is specified only the file systems typed defined will be created. The default value used most often for this variable is: IMAGE_FSTYPES="tar.bz2 ext3 sdcard" The .sdcard format creates an image with all necessary partitions and loads the bootloader, kernel and rootfs to this image. You can just low level copy the data on this file to the SD card device using dd as on the following command example: $ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync Partitions used on the .sdcard file The .sdcard partitions looks as follow: IMAGE_ROOTFS_ALIGNMENT Unpartitioned space reserved for the bootloader BOOT_SPACE Kernerl and other data ROOTFS_SIZE The rootfs. Granting more free space on the RootFS partition The size of the .sdcard file will depend solely on the size of the rootfs. This means that the resulting file won’t partition all our SD Card capacity unless we add extra space to the rootfs partition. (Of course there is always the option of editing the partitions once loaded on the SD Card) In order to add more space you may use the IMAGE_ROOTFS_EXTRA_SPACE variable. You may add it to your local.conf file with the added free disk space in Kbytes. For example, if you would like to guarantee 1GB of extra space you may add the following line to your local.conf file. IMAGE_ROOTFS_EXTRA_SPACE = "1048576" It is important to note that this is space additional to the IMAGE_OVERHEAD_FACTOR variable which defines a multiplier that is applied to the initial image size. This is only applied when the multiplier times the By default, the build process uses a multiplier of 1.3 for this variable. This default value results in 30% free disk space added to the image when this method is used to determine the final generated image size. This would mean that there should be 30% of free disk space before post install scripts. If you wish for more space you may edit this variable as bellow: IMAGE_OVERHEAD_FACTOR = "1.5" Which would result in 50% free disk space added to the image, before post install scripts and without considering overhead that may come from the package management system. How the IMAGE_ROOTFS_SIZE is calculated This variable is also measured in Kbytes and it’s determined by the OpenEmbedded build system using an algorithm that considers the initial disk space used for the generated image, the requested size for the image (trough the overhead factor) and the additional free space to be added to the image (trough the extra space variable). The build system first runs a du (disk usage) command to determine the size of the rootfs directory tree. If the IMAGE_ROOTFS_SIZE current value is larger than the disk usage times the overhead factor only the extra space is added. If the IMAGE_ROOTFS_SIZE is smaller than the disk usage times the overhead factor then the disk usage is multiplied times the overhead factor prior to adding the extra space. IMAGE_ROOTFS_SIZE must be set on a default value which is usually very low as it’s just initialized and updated with the actual size requirements each time an image is baked. You may also use this variable directly in order to select the space you would like to allocate to the RootFS.For example setting the RootFS to 2GB would require the following addition to the local.conf file: IMAGE_ROOTFS_SIZE = “2097152” IMAGE_OVERHEAD_FACTOR = “1.0” In this example we would leave the overhead factor to 1 so no extra space is added since we’re specifying the rootfs size that we want.

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.     *

The document in attachment describes how to learn System Boot Flow of Linux by code using Trace32. The hardware platform is i.MX6Q SABRE and the software in PC is Trace32. Contents 1. Introduction 2. Hardware Connection 3. Serial Connection Setup 4. U-boot Directory Setup 5. Trace32 Installation & U-boot Debugging

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.

DEVREGS - Is a tool to display and modify a device's registers at runtime. Under Linux, you can access registers, or any area of physical memory through the /dev/mem pseudo-device and the wonders of the mmap system call. To use it, you open the /dev/mem device, mmap the page in which a register is located, then use the pointer returned to read and/or write the data. Boundary Devices, developed a tool known as " devregs  " that allows you to put a little structure around this facility. It allows you to give names to particular physical memory areas and to describe the bits within a register in the text file /etc/devregs.dat. How to read from register : To read one or more registers, use devregs with a single parameter that’s either an address or a register name. Ex : $  devregs 0x73f88000 :0x73f88000    =0x803dffaf If a register address matches a register in /etc/devregs.dat , you’ll see the register name: Ex : $ devregs 0x73f88000 GPIO2_DR:0x73f88000    =0x803dffaf If used with a register name, any bitfields defined will be shown: Ex: devregs UART1_UFCR UART1_UFCR: 0x73fc0090   =0x0801 UART1_UFCR:0x73fc0090    =0x0801       TXTL                      10-15     =0x2       RFDIV                    7 - 9      =0x0       DCEDTE                 6 - 6     = 0x0       RXTL                       0 - 5     = 0x1 How to write to register : Ex : $ devregs GPIO2_GDIR GPIO2_GDIR:0x73f88004    =0x0002c0a4 Ex: $ devregs GPIO2_GDIR 0x2c0a0 GPIO2_GDIR:0x73f88004    =0x0002c0a4 GPIO2_GDIR:0x73f88004 == 0x0002c0a4...0x0002c0a0 Ex: $ devregs GPIO2_GDIR GPIO2_GDIR:0x73f88004    =0x0002c0a0 For more detailed information please go through the following below links : http://boundarydevices.com/i-mx5x-device-register-access/ http://boundarydevices.com/configuring-i-mx6-machines-different-screens-nitrogen6x-sabre-lite/

This patch adds DDR3 support for i.MX6SL, it is functionally tested with L3.0.35_2.1.0 release.

Video in Host Side Converting images (png, jpg, etc) to YUV format ffmpeg -f image2 -i test.png -pix_fmt yuv420p test.yuv Converting AVI files to YUV format To convert AVI to YUV you can use the lav2yuv program. In Ubuntu Linux this program is in mjpegtools package. This is the way to convert: lav2yuv myfile.avi > myfile.yuv Converting YUV video files to AVI (DivX) Use the ffmpeg tool: ffmpeg -s 176x144 -i kuuba_maisema_25fps_qcif.yuv -vcodec mpeg4 -sameq -aspect 4:3 ~/kuuba.avi You need to specify the video dimensions (176 × 144), the video codec (mpeg4), and the aspect ratio (4:3). Converting MP4 to AVI Use the mencoder tool: mencoder Bike1.mp4 -ovc lavc -oac lavc -o NewBike1.avi