KSZ9031 is a very common PHY used with many ethernet design. This document will show you how to add it in u-boot and kernel. 1. Schematic The MODE[3:0] strap-in pins are sampled and latched at power-up/reset. MODE[3:0]=1111 is RGMII mode - Advertise all capabilities (10/100/1000 speed half-/full-duplex) The PHY address, PHYAD[2:0], is sampled and latched at power-up/reset. Here PHY address is set to 001. In this design example, the ENET_RESET_B is connected to GPIO pin GPIO1_IO03. 2. Source code modification In u-boot source code, add the following code in the <board_name>.c file. - IOMUX setup for the GPIO1_IO03 pin. static iomux_v3_cfg_t const phy_reset_pads[] = {      MX7D_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(NO_PAD_CTRL), }; - In the function setup_fec(int fec_id), add the code for phy reset. imx_iomux_v3_setup_multiple_pads(phy_reset_pads, ARRAY_SIZE(phy_reset_pads)); gpio_request(IMX_GPIO_NR(1, 3), "ENET PHY Reset"); gpio_direction_output(IMX_GPIO_NR(1, 3) , 0); mdelay(20); gpio_set_value(IMX_GPIO_NR(1, 3), 1); - There is a PHY config for the KSZ9031. int board_phy_config(struct phy_device *phydev) {    /*      * Default setting for GMII Clock Pad Skew Register 0x1EF:      * MMD Address 0x2h, Register 0x8h      *      * GTX_CLK Pad Skew 0xF -> 0.9 nsec skew      * RX_CLK Pad Skew 0xF -> 0.9 nsec skew      *      * Adjustment -> write 0x3FF:      * GTX_CLK Pad Skew 0x1F -> 1.8 nsec skew      * RX_CLK Pad Skew 0x1F -> 1.8 nsec skew      *      */     /* control data pad skew - devaddr = 0x02, register = 0x04 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);     /* rx data pad skew - devaddr = 0x02, register = 0x05 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);     /* tx data pad skew - devaddr = 0x02, register = 0x05 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);     /* gtx and rx clock pad skew - devaddr = 0x02, register = 0x08 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_CLOCK_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x03FF);     if (phydev->drv->config)         phydev->drv->config(phydev);     return 0; } The KSZ9031 driver (drivers/net/phy/micrel.c) had already supported in the u-boot source code. Add the following #define in the <board_name>.h file to enable the driver for building. #define CONFIG_PHY_MICREL As the PHY address on the board is 001, change the PHYADDR to 1 in the <board_name>.h file. #define CONFIG_FEC_MXC_PHYADDR          0x1 In the kernel source code, add/modify the PHY setting in dts file like this. &fec1 {     pinctrl-names = "default";     pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet_reset>;     assigned-clocks = <&clks IMX7D_ENET_PHY_REF_ROOT_SRC>,               <&clks IMX7D_ENET_AXI_ROOT_SRC>,               <&clks IMX7D_ENET1_TIME_ROOT_SRC>,               <&clks IMX7D_ENET1_TIME_ROOT_CLK>,               <&clks IMX7D_ENET_AXI_ROOT_CLK>;     assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_25M_CLK>,                  <&clks IMX7D_PLL_ENET_MAIN_250M_CLK>,                  <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;     assigned-clock-rates = <0>, <0>, <0>, <100000000>, <250000000>;     phy-mode = "rgmii";     phy-handle = <&ethphy0>;     phy-reset-gpios = <&gpio1 3 0>;     fsl,magic-packet;     status = "okay";     mdio {         #address-cells = <1>;         #size-cells = <0>;         ethphy0: ethernet-phy@1 {    //here '@1' is the PHY address             compatible = "ethernet-phy-ieee802.3-c22";             reg = <1>;         };     }; }; Add the GPIO pin for the ENET_RESET_B &iomuxc { ... ... pinctrl_enet_reset: enet_resetgrp {             fsl,pins = <                 MX7D_PAD_GPIO1_IO03__GPIO1_IO3      0x14     //ENET_RESET_B             >;         }; } There is a PHY fixup in the arch/arm/mach-imx/<imx_cpu>.c Here is the example in mach-imx7d.c #define PHY_ID_KSZ9031    0x00221620 #define MICREL_PHY_ID_MASK 0x00fffff0 static void mmd_write_reg(struct phy_device *dev, int device, int reg, int val) {     phy_write(dev, 0x0d, device);     phy_write(dev, 0x0e, reg);     phy_write(dev, 0x0d, (1 << 14) | device);     phy_write(dev, 0x0e, val); } static int ksz9031rn_phy_fixup(struct phy_device *dev) {     /*      * min rx data delay, max rx/tx clock delay,      * min rx/tx control delay      */     mmd_write_reg(dev, -1, 0x4, 0);     mmd_write_reg(dev, -1, 0x5, 0);     mmd_write_reg(dev, -1, 0x6, 0);     mmd_write_reg(dev, -1, 0x8, 0x003ff);     return 0; } static void __init imx7d_enet_phy_init(void) {     if (IS_BUILTIN(CONFIG_PHYLIB)) {         phy_register_fixup_for_uid(PHY_ID_AR8031, 0xffffffff,                        ar8031_phy_fixup);         phy_register_fixup_for_uid(PHY_ID_BCM54220, 0xffffffff,                        bcm54220_phy_fixup);         phy_register_fixup_for_uid(PHY_ID_KSZ9031, MICREL_PHY_ID_MASK,                 ksz9031rn_phy_fixup);     } } Now, the PHY is working on your board. Reference: 1.  Create an Ubuntu VM environment to build Yocto BSP  2.  i.MX Software | NXP 

Question: In a single uImage to contain the compressed kernel and rootfs, if the uImage is greater than 16MB, the system will not boot and reports errors. Is there a size limitation on uImage?  If so, is there a work around? Answer: uImage should only contains kernel compressed. rootfs should be read through a linux partition after the kernel boots up. Regarding the uImage's size, there is no limitation. In the other hand, a single uImage with kernel and filesystem is needed; in other words, kernel (alias uImage) needs a filesystem to work, and these are two independent systems in that sense. If u-boot, kernel and filesystem are in a single device (SD Card), the filesystem must be mounted in the first partition (SD, eMMC, etc) starting somewhere > 16M/512 sectors. But in cases where: * A fast boot is needed with  very small rootfs * As a intermediate (temporal) rootfs  before switching  to the real rootfs. The usage (actually used when flashing with the MFG tool) of this intermediate system is to load heavy modules, keeping the uImage small. This mechanism is called initramfs and the uImage will contain the kernel and the this mini rootfs compressed as cpio archive. But there appears to be a 16MB limitation. See here:  http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/ It seems to be related to alignment suggesting that 24-bit addressing is used instead of 32-bit.  I did notice Thumb mode is used, which seems odd to me.

THE CONTENTS •Background Knowledge −Kernel Introduction −Linux Kernel Directory Structure of the Source Code •Kernel Loading Procedure −Linux OS Boot Process −First Stage of Loading Sequence(Assembly Language) −Second Stage of Loading Sequence(C Language)

RedBoot is a bootloader, which contains support for some i.MX SoCs. Compiling RedBoot All Boards Compiling RedBoot Configuring RedBoot Configuring RedBoot All Boards Configuring RedBoot Loading Redboot Binary Directly to RAM Minicom Updating RedBoot Updating RedBoot Through RedBoot All Boards Updating RedBoot Through RedBoot IMX27 PDK NAND Flashing RedBoot i.MX31 PDK NAND Flashing RedBoot i.MX35 PDK NAND Flashing Kernel and Root File System Using RedBoot RedBoot Utilities All Boards Transfer Serial RedBoot Fixing Redboot RAM Bug Fixing Redboot RAM bug (CSD1 not activated)

Product Family Features Freescale's i.MX family of applications processors has demonstrated leadership in the portable handheld market. The i.MX21 multimedia applications processor is the latest addition to this family and builds on its low-power, high-performance heritage. Freescale has shipped more than 60 million chips of our industry-founding applications processors. That means you can start smart by picking products with a technology pedigree to handle all the creativity you can pump into them. The i.MX21 features the advanced and power-efficient ARM926EJ-S core operating at speeds starting at 266 MHz and is part of a growing family of Smart Speed products that offer high performance processing optimized for lowest power consumption. ARM926EJ-S™ core (16 KB I-Cache, 16 KB D-Cache) Smart Speed Switch 16/18-bit color LCD controller up to SVGA USB On-The-Go (two-host port) MPEG-4 and H.263 encode/decode acceleration up to CIF 30 fps Additional Resources IMX21-ADS I.MX21 ADS Board Flashing IMX21-and-iMXL-Lite-Kit

Gamma correction Displays usually presents a nonlinear bright response. For example, a frame buffer value of 100 will almost never give half the brightness of a value of 200. Historically, this is due to the physics of CRT monitors, but newer display technologies emulate the behavior. This is not only for compatibility, but for solid reasons based in the science of human visual perception. A first-order approximation to the non-linearity of a CRT is: L = ν ^ γ where L is the radiance (light intensity) from the display, ν is the voltage applied to the CRT gun (normally proportional to the digital value in the frame buffer), and γ (Greek letter “gamma”) is a constant particular to the monitor; it's the unknown parameter that makes it all work. It usually ranges from about 2.0 to about 2.5. One useful fact is that the gamma curve is linear in log-log space (i.e. logL as a function of logν), and γ is just the slope of that line. Example of gamma correction The dotted line indicates a linear transfer function (γ=1), the framebuffer gamma; the solid line shows how a typical CRT behaves; the dashed line represents the inverse function, the corrected gamma. How to correct gamma on i.MX using DP (Display Processor)? Gamma correction can be performed by IC (Image Converter) or DP (Display Processor) sub-blocks inside IPU. Current Linux kernel (3.10) provided by Freescale has an IOCTL that changes the related gamma parameters registers DP_GAMMA_C_SYNC<i> and DP_GAMMA_S_SYNC<i> on Display Processor block. The steps below shows how to change the gamma using user space applications: 1 - Declare a variable as mxcfb_gamma: struct mxcfb_gamma fb_gamma; 2 - Enable the gama correction: fb_gamma.enable = 1; 3 - Set the constk and slopek values, where i = 0 to 15 and x and y are respectively the new constk and slopek constant values: fb_gamma.constk[i] = x; fb_gamma.slopek[i] = y; 4 - Open the framebuffer device and call MXCFB_SET_GAMMA: fd_fb = open("/dev/fb0", O_RDWR, 0) ioctl(fd_fb, MXCFB_SET_GAMMA, &fb_gamma) Running the code above will immediately change the gamma value.

Flash a full SD Card Android Image (4GB) using Linux on VMWare Flash a full SD card image (4GB) using Flashnul in Windows Flash a full SD Card Android Image (4GB) using Linux on VMWare Note: It is preferred that SanDisk 4G SD card be used rather then Kingston. Kingston seemed to enumerate slightly smaller then SanDisk which actually inhibited us from flashing the image onto Kingston.    Within VMWare player, go to places/filesystems/dev to see what the SD card is called. When plugging in or removing the SD card from an external reader, you should see within the dev folder files called sdx…etc. [x= some letter]. That will help you specify which card to program with your image. Make note of the file [which is really a drive] name. For example in my VMWare player, it turns out that my SD card that I want to program was sdb. Also, if windows asks to format the drive, allow it and use Fat32. And, if you notice the drive is only 1GB instead of 3-4GB its because you only formatted the windows structure of the disk, the Linux portion that might reside on it does not show up in Windows. For distribution, the entire image which includes the *.bin file {this is the one you are trying to get onto the SD card} can be downloadable from a Freescale FTP site or some other media. It is a large file which is between 1-2GB. In this Android example, the file is called MasterA.gz. GZ is a linux based zip application which runs circles around winzip or 7-zip. The Android image, MasterA.gz, was 1.08 GB. The file you want to see in this example is MasterA.bin. Open a terminal window in VMWare. Within VMWare, unzip the file. If you select the file, then right mouse click it it will give you the option to uncompress using GZ. Before moving forward, make sure the SD card is unmounted. To do this type sudo umount /dev/sdX {note: sdb was the SD card we previously found enumerated}.           If you don’t know if it is mounted, in places/filesystems/dev on the left side of the screen you will see names with shown next to it. That means it’s          mounted. To copy Android image to sd card, type sudo dd if=masterA.bin of=/dev/sdX bs=10M X is the sd card (like /sdb, /sdc etc.) This will take some time, so if you have to stop this process hit <ctrl C> or close the terminal window. This will take some time but that’s all that it takes. Use the bottom task bar of the VMware screen, to attach the USB removable drive to Linux. Flash a full SD card image (4GB) using Flashnul in Windows  The tool you will use to flash the content is FlashNul in windows. This is available at http://shounen.ru/soft/flashnul/flashnul-1rc1.zip Steps Insert your flash media Run flashnul -p (from the dir that has flashnul) Note the physical device number for flash media Run flashnul <number obtained in prior step> -L \path\to\downloaded.img Answer "yes" if the selected destination device is correct Remove your flash media when the command completes Be careful what drive you erase. There are warnings presented before you commit: Disk PhysicalDrive2 (UNC name: \\.\PhysicalDrive2)         ------------------------------------------------------------[Drive geometry]--         Cylinders/heads/sectors = 482/255/63         Bytes per sector = 512         CHS size = 3964584960 (3780 Mb)         ---------------------------------------------------------------[Device size]--         Device size = 3965190144 (3781 Mb)         delta to near power of 2 = 329777152 (314 Mb), 8%         Surplus size = 605184 (591 kb)         -----------------------------------------------[Adapter & Device properties]--         Bus type = (7) USB         Removable device = Yes         Command Queue = Unsupported         Device vendor = Generic         Device name = USB SD Reader         Revision = 0.00         --------------------------------------------------------------[Hotplug info]--         Device hotplug = Yes         Media hotplug = No Selected operation: load file content Selected drive: PhysicalDrive2, 3965190144b (3781 Mb)</pre>         THIS OPERATION IS DESTRUCTIVE!!!         Type 'yes' to confirm operation. All other text will stop it. Really destroy data on drive PhysicalDrive2? :yes         -----------------------------------------------------------------------[Log]-- Runing operation [load file content] for drive PhysicalDrive2 Writing 0x36110000 (865 Mb), 3362893 b/s      

i.MX6UL/ULL extend uart port and integrate SIP I2C device. Contents 1 硬件设计说明 ............................................................. 2 硬件框图 ........................................................................ 2 硬件模块设计 ................................................................. 4 IOMUX 表 ....................................................................... 8 2 编译环境搭建 ............................................................. 8 编译环境文档及镜像下载。 ............................................ 8 编译环境搭建 ............................................................... 11 3 移植BSP 到扩展串口板 ........................................... 15 Uboot 中支持新的DTB ................................................ 15 Uboot 中调试串口改成UART6 ..................................... 16 去除掉无用的驱动及其IOMUX .................................... 18 增加i.MX6UL/ULL 本身串口支持 ................................. 18 增加GPIO 输出支持（GPIO_LED） ............................ 26 增加GPIO 输入支持（GPIO_KEY） ........................... 30 增加PWM支持 ............................................................ 34 增加i.MX6UL 本身ADC 支持 ....................................... 38 修改网口驱动仅支持一个网口 ...................................... 41 增加NXP PCF8591 I2C 转ADC 芯片支持 ................... 44 增加NXP PCA9555A I2C 转GPIO 芯片支持(rework 支持) 47 增加NXP PCT2075 I2C 温度传感器芯片支持(rework 支持) 55 增加NXP PCF8563 I2C RTC 支持(rework 支持) ......... 58 增加NXP PCA9632 I2C LED控制器芯片支持(rework 支持) 65 增加CH438 EIM 转串口芯片支持(delay) ..................... 70

MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

All Boards Creating App MP3 OpenEmbedded

ADB is very well known as the tool to manually install APK’s, but there are some other useful commands. ADB is a command line tool that acts as the bridge between you and your android device. I want to show you some of them, but first, let’s make sure we have everything needed to use ADB. Requirements First, you need to have Java and the Android SDK installed on your PC, you can download it from here: Java SDK: Java SE - Downloads | Oracle Technology Network | Oracle Android SDK: http://developer.android.com/sdk/index.html Once it is installed, it is recommended to update the SDK Manager Once you have done this, flash the Freescale Android BSP onto your board… Once you have installed it, you need to enable USB Debugging in the Developer Options of your board.        Here's the steps to enable USB debugging: Go to Settings. Click on "about tablet" Scroll down to the last row (Build Number) and tap that row 7 times. Return to the previous screen and click on "developer options" Confirm that "usb debugging" is checked. Once you enable it, your OS (assuming you are using Windows) will look for the Android ADB Interface driver. Windows systems are the only ones that need this ADB driver. After this procedure, you can now start using ADB. Open a terminal window and go to the platform-tools directory of your SDK installation to find the ADB program. The usual path to find it would be: adt-bundle-windows-x86 >> sdk >>platform-tools adb start-server                              ::  Starts the ADB server in case it is not running already adb kill-server                   :: Terminates de ADB server adb devices                        :: Checks  and prints the status of each device plugged to your PC  (If you don’t see your device, make sure USB debugging is enabled in your tablet.) adb install  'apk file'       :: It will install an apk to the tablet.   This apk must be located in the same folder where the adb is. adb uninstall 'apk file' :: It will uninstall an apk adb pull 'file'                                               :: It copies a file or directory (and sub-directories) from your device to the PC. adb push 'file'                          :: It copies a file of directory (and sub-directories) from your PC to the device. adb logcat                        :: Prints the logdata to the screen adb logcat –c                  :: Clears the buffer to remove any old log data. adb bugreport               :: Prints dumpsys, dumpstate and logcat. adb shell pm list packages –f    ::  List all installed packages adb shell input keyevent 26     :: Send the power button event to turn on/off the device adb shell screencap –p /sdcard/screen.png      :: Takes a screenshot of the android display adb shell screenrecord /sdcard/demo.mp4      :: Records any activity on the android display Using the window manager There is also a very useful tool to manage the display. This can be ran through a terminal connection to your board. You run this command from the following path /system/bin of your android BSP These are some of the commands available: wm density 'density number'              :: Changes the display density wm size 'display size'                                :: Changes your display’s resolution Using the activity manager In the same path is the activity manager which has several other commands for use: am start 'package'   :: Starts an activity am monitor                     :: Monitors activities am bug-report               :: Requests a bug report am restart                        :: Restarts the OS

This section for all Freescale i.MX users ranging from customers to designers to help provide the best solution to the most frequently encountered questions related to Freescale i.MX products. Products Below are links to pages containing links to documentation related to that product. i.MX Family i.MX6 Multimedia Applications Processors i.MX53 Multimedia Applications Processors i.MX51 Multimedia Applications Processors i.MX35 Multimedia Applications Processors i.MX31 Multimedia Applications Processors i.MX28 Multimedia Applications Processors i.MX27 Multimedia Applications Processors i.MX25 Multimedia Applications Processors i.MX21 Multimedia Applications Processors Topics Below are links to pages containing links to documentation related to that topic. 19-iMX_Serial_Download_Protocol.py All Boards 2D/3D Graphics All Boards Accessing Registers All Boards Audio All Boards Bluetooth Dongle All Boards Compiling RedBoot All Boards Configuring RedBoot All Boards Creating App Video All Boards Deploy NFS All Boards DirectFB All Boards FlexCAN All Boards Hardware Software All Boards How To Convert RVICE CP15 To OpenOCD All Boards How To Understand JTAG BSDL All Boards I2C-tools All Boards Java All Boards JTAG All Boards LTIB All Boards LTIB Config Ubuntu All Boards LTIB Creating Uimage Uboot All Boards NFS on Fedora All Boards NFS on Slackware All Boards NFS on Ubuntu All Boards OpenEmbedded All Boards Pdfreader All Boards PMIC Registers All Boards Qtopia All Boards Qtopia on Ubuntu All Boards Qt v2 All Boards RedBoot All Boards Serial Console All Boards TCP All Boards Tethering All Boards TFTP All Boards TFTP Fedora All Boards TFTP on OpenSuse All Boards TFTP on Ubuntu All Boards Theora Encoder All Boards Transfer Serial RedBoot All Boards U-boot All Boards Updating RedBoot Through RedBoot All Boards Video All Boards Video Host All Boards VMWare All Boards Wi-Fi All Boards X11 Android Demonstration Platform Exercising the i.MX Serial Download Protocol with a Python Script Gstreamer GTK How to Enable Second Display Showing Different Things on JB4.2.2 SabreSD How to Measure Signal Frequency by Using the Camera Sensor Interface of an i.MX i.MX as a USB Playback/Capture Device on One OTG Port i.MX Bootlets (i.MX233 EVK) i.MX USB Loader i.MXS Development Kit InternalI2C Linux Kernel Mxuart patch New Release of the i.MX OTP Tools V1.3.3 NFS OpenEmbedded Redboot Running ATK on Linux Script to Flash a Linux System into a SD card U-Boot Yoctoproject

Enter inside ~/ltibdir/rpm/BUILD and create a directory 'alpha': $ cd ltib/rpm/BUILD $ mkdir alpha Enter in 'alpha' dir and create setalpha.c file: $ cd alpha #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> #include <asm/arch/mxcfb.h>  int main(int argc, char **argv) {              int fb_fd;              struct mxcfb_gbl_alpha gbl_alpha;               if(argc != 2){                       printf("Usage: %s alpha_val[0-255]\n",argv[0]);                       return -1;              }               fb_fd = open("/dev/fb0",O_RDWR,0);              gbl_alpha.enable = 1;              gbl_alpha.alpha = atoi(argv[1]);              ioctl(fb_fd, MXCFB_SET_GBL_ALPHA, &gbl_alpha);              close(fb_fd);              return 0; } Compile it using this command: ./ltib -m shell LTIB> cd rpm/BUILD/alpha LTIB> gcc -I../linux/include setalpha.c -o setalpha In your board execute it: root@freescale /home$ /unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 480 -oh 640 -d 3 -r 4 -fr 5 qvga.yuv & While it is playing execute: root@freescale /home$ setalpha 128 root@freescale /home$ cat screen.raw > /dev/fb0 We used frame rate at 5 fps to have more time to execute next two commands.

This document is aimed to introduce seamless switch on rear view camera function in android P9 auto, and this can also be referenced for sharing dpu(display process unit) between A core and m4 core on imx8qxp/qm platform. OS: Android p9 auto beta. (linux needs some modifies). SDK_2.5.1_MEK-MIMX8QX for m4 core. Hardware platform: imx8qxp/qm mek board IT6263 lvds to hdmi cable. max9286 deserializer board. ov16035 camera. Hardware block：     Imx8qxp dpu block, for imx8qm there are two dpus:     Android/Linux and M4 shared dpu path:     The switch function is done by framegen0 unit in dpu, framegen unit can select 7 modes: primary src only second src only primary on second second on primary .....etc. for more details, please refer to the kernel codes at include/video/dpu.h, fgdm_t type. Seamless switch booting flow: Patches contain three main parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core, add ui ready rpmsg pipe. M4 code: modify dpu pipes, add ui ready rpmsg handle. AOSP init.rc scripts: add sending ui ready message scripts.

Support SSI Master function based on 0001_SSI_ASRC_P2P.patch

Configuring U-Boot LTIB Creating Uimage Uboot U-boot FW Printenv FW Env File Add New i.MX5x Board on LTIB i.MX25 PDK I.MX25 PDK U-boot SplashScreen I.MX25 PDK U-boot SDCard i.MX27 ADS Board Compiling U-Boot for i.MX27ADS Installing U-Boot on iMX27ADS i.MX31 ADS Board i.MX31ADS Compiling Uboot I.MX31ADS Installing Uboot i.MX31 PDK Board i.MX 31 PDK Board Screenshot I.MX31 PDK Board Flashing i.MX31 PDK Board DirectFB i.MX51 EVK Board i.MX51 EVK U-boot I.MX51EVK Install U-Boot i.MX51 EVK Compiling U-boot i.MX51 EVK Changing Env

Hi,      Here share the hardfloat rootfs making document and related pkgs, please feel free for download best regards Jack

The Register Programming Aid (RPA) provides a default DRAM PLL setting (DRAM frequency) based on the default setting supported in u-boot.  It is highly recommended to use the default DRAM frequency settings in the RPA for ease of use and to align with u-boot.  Otherwise, in addition to updating the RPA for the new DRAM frequency, the u-boot SPL code itself will need to be manually updated with the new DRAM PLL setting.   Should the user wish to change the DRAM frequency, the following steps are required:   First, the user needs to update the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to the desired DRAM frequency       2. Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054”.  The address “0x30360054” is for the DRAM PLL register address and its setting needs to be updated to the desired frequency.        Note that there is another place where the DRAM frequency is also updated “freq0 set 0x30360054” but it is automatically updated based on the setting above.    Below is a table of various frequencies to choose from.  For frequencies not listed in the table below, it is up to the user to calculate a new register setting based on the formula:     (24MHz x m)/(p x 2^s)   Where “m” represents the PLL_MAIN_DIV, “p” represents the PLL_PRE_DIV, and “s” represents the PLL_POST_DIV.  NOTE:  The DRAM frequency is double the DRAM PLL frequency DRAM_freq = DRAM_PLL x 2   The DRAM PLL register and bit settings are shown below:          The following table provides examples of the various settings to create the desired frequency:       For example, in the i.MX 8M Mini LPDDR4 RPA where the default DRAM frequency is 1500MHz, let’s assume that the user instead wants 1200MHz.    First, the user changes the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to 1200.   Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054” and replace “0xFA080” (original setting from DRAM frequency 1500MHz) with “0x000C8022” (updated for DRAM frequency 1200MHz).  Note that for a DRAM frequency of 1200MHz, the DRAM PLL is configured for 600MHz, as the DRAM frequency is double the DRAM_PLL.   The steps outlined above are sufficient in order to create a DDR script for use with the DDR stress test tool to run the calibration and execute the DDR stress test.  However, to deploy the generated code in SPL, more steps are needed as the u-boot SPL DDR driver does not automatically change the DRAM PLL according to the generated code. Hence the user will need to manually modify related code in u-boot.  It is highly recommended to work with a software engineer familiar with u-boot when making the following modifications.    3. Modify DRAM PLL configuration in uboot-imx/drivers/ddr/imx8m.c, specifically the code highlighted below (function call dram_pll_init).  Note that the files and file paths in u-boot change frequently, so if this particular file (or file path) does not exist in the current u-boot, simply search for dram_pll_init or ddr_init.   void ddr_init(struct dram_timing_info *dram_timing) { ……    debug("DDRINFO: cfg clk\n");      if (is_imx8mq())           dram_pll_init(DRAM_PLL_OUT_800M);      else          dram_pll_init(DRAM_PLL_OUT_750M); ……  }   In the above code, the user should update the macro “DRAM_PLL_OUT_750M” with the new DRAM PLL value.  Note that the default DRAM_PLL_OUT_750M results in the DRAM frequency of 1500MHz, where the DRAM frequency is double the DRAM PLL (as previously stated above).   For example, if the user desires to run the DRAM at 1200MHz, they would change the above to: dram_pll_init(DRAM_PLL_OUT_600M);   Note that DRAM_PLL_OUT_600M is a supported macro in the dram_pll_init() API.  If the desired DRAM PLL configuration does not exist in dram_pll_init(), you will need to add support in uboot-imx/arch/arm/mach-imx/imx8m.c  (as stated above, if this file path does not exist in the current u-boot simply search for dram_pll_init):   void dram_pll_init(enum dram_pll_out_val pll_val) { …… }   Related Links i.MX8 MSCALE SERIES DDR Tool Release (V3.10) 

This is a tool can generate a DDR3 script easily for i.MX53 and only need input several parameters based on using DDR datasheet and system architecture. Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6SL LPDDR2 Script Aid through below link. i.Mx6SL LPDDR2 Script Aid Any questions are welcome!