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.

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/

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

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

Q:How use USB as both gadget mode and host mode usb USB_OTG? A: Hardware: imx6 sabresd board usb otg diagram, as follow Software:   You can use USB OTG port for both host mode and device gadget mode. There are 2 signals you should care: - USB_OTG_ID - USB_OTG_MODE (control power for usb vbus in host mode, this is EIM_D22 pin)   In device tree: reg_usb_otg_vbus: regulator@0 {                         compatible = "regulator-fixed";                         reg = <0>;                         regulator-name = "usb_otg_vbus";                         regulator-min-microvolt = <5000000>;                         regulator-max-microvolt = <5000000>;                         gpio = <&gpio3 22 0>;                         enable-active-high;                 };   pinctrl_usbotg: usbotggrp {                         fsl,pins = <                                 MX6QDL_PAD_GPIO_1__USB_OTG_ID           0x17059                                 MX6QDL_PAD_EIM_D22__GPIO3_IO22           0x80000000                         >;                 };   &usbotg {         vbus-supply = <&reg_usb_otg_vbus>;         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_usbotg>;         disable-over-current;         srp-disable;         hnp-disable;         adp-disable;         dr_mode = "otg";                 status = "okay"; };  With above config, one can use OTG port for mouse, usb stick in host mode, and gadget mode for ADB...   https://community.nxp.com/message/943460 

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

Building Linux Kernel Building Linux Kernel Building Using LTIB Building Outside LTIB Downloading and installing GNU Toolchain and git Building Kernel from Freescale git repository Building Kernel Mainline About Linux Building Using LTIB Linux kernel can be easily built using Ltib. On Ltib menu, just select: [*] Configure the Kernel When you exit this menu, Ltib will show the Kernel Menuconfig as below: This is the Kernel Menuconfig, where it's possible to configure kernel options and drivers. After exit this menu, kernel will be built and stored at: <Ltib directory>/rootfs/boot Building Outside LTIB Downloading and installing GNU Toolchain and git When you install LTIB, a GNU toolchain is automatically installed on /opt/freescale/usr/local/ Kernel releases newer than 2.6.34 doesn't build on Toolchain 4.1.2, only on 4.4.1 or later Check on your host at /opt/freescale/usr/local/ the current installed Toolchain. Next step is to install GIT on host. For Ubuntu machines, use: sudo apt-get install git-core Building Kernel from Freescale git repository Freescale provides access to their own git kernel repository and can be viewed at: Freescale Public GIT To download the kernel source code, create a new folder and use the command: git clone git://git.freescale.com/imx/linux-2.6-imx.git OR git clone http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git After some minutes, a folder called linux-2.6-imx will be created containing the Linux kernel Create a local git branch from a remote branch you want to use. Let's use branch origin/imx_3.0.15 as example: cd linux-2.6-imx git checkout -b localbranch origin/imx_3.0.15 To check all available remote branches, use: git branch -r Export the cross compiler, architecture and the toolchain path: export ARCH=arm export CROSS_COMPILE=arm-none-linux-gnueabi- If using Toolchain 4.1.2: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" OR If using Toolchain 4.4.4: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/" Copy the config file for the wanted platform on linux folder as example: cp arch/arm/configs/imx6_defconfig .config All platform config files are located at <linux directory>/arch/arm/configs/ Call menuconfig and change configuration (if needed) make menuconfig Now it's ready to be built: make uImage The zImage and uImage will be located at /arch/arm/boot/ folder. Building Kernel Mainline Mainline Kernel can be viewed on this link: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git To download the kernel source code, create a new folder and use the command: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git OR git clone http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git OR git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git After some minutes, a folder called linux will be created containing the Linux kernel Create a local git branch from a remote branch you want to use. Let's use branch origin/linux-3.8.y as example: cd linux git checkout -b localbranch origin/linux-3.8.y To check all available remote branches, use: git branch -r Export the cross compiler, architecture and the toolchain path: export ARCH=arm export CROSS_COMPILE=arm-none-linux-gnueabi- If using Toolchain 4.4.4: export PATH="$PATH:/opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/" Configure to the platform you want to build kernel. For i.MX family, use imx_v6_v7_defconfig: make imx_v6_v7_defconfig All platform config files are located at <linux directory>/arch/arm/configs/ Call menuconfig and change configuration (only if needed, this is an optional step!) make menuconfig Now it's ready to be built: make -j4 uImage LOADADDR=0x70008000 - Use -j4 option to speed up your build in case or PC has 4 cores. It's optional. - IMPORTANT: Use the correct address for each processor. You can check the correct address value at linux/arch/arm/mach-imx/Makefile.boot. After build the uImage, build the dtb file (device tree binary). For i.MX53 QSB use: make imx53-qsb.dtb The uImage will be located at: linux/arch/arm/boot/ folder and dtb binary will be located at: linux/arch/arm/boot/dts About Linux For general Linux information, see About Linux

Question: The following contradicting information regarding the UART clock tree has been seen in the Rev. 1.0  version of the reference manual: Page 813: PLL3_PFD1 -> divide by 6 -> adjustable post divider -> UART Page 839: PLL3 -> divide by 6 -> UART In the old Rev D I found: Page 803: PLL3 -> divide by 6  ... and something about 80MHz The assumption is that correct path would be: PLL3 -> divide by 6 -> post divider -> UART. Answer: The designer said that UART _CLK_ROOT comes from PLL3 (not PLL3:PFD1) and is divided by 6 to produce 80 MHz. I'm waiting for him to confirm that the divider he mentions is CSCDR1[UART_CLK_PODF].

目录 1 i.MX8X 板级开发包镜像结构 ...................................... 3 2 创建 i.MX8QXP Linux 4.19.35 板级开发包编译环境 ... 3 2.1 下载板级开发包 ....................................................... 3 2.2 创建yocto编译环境: ................................................. 4 2.3 独立编译 ............................................................... 10 3 i.MX8X SC firmware ................................................. 16 3.1 SC firmware 目录结构 ........................................... 16 3.2 SC firmware 启动流程 ........................................... 17 3.3 SC firmware定制 ................................................... 17 4 i.MX8X ATF .............................................................. 28 5 FSL Uboot 定制 ........................................................ 30 5.1 FDT支持 ............................................................... 31 5.2 DM(driver model)支持 ........................................... 36 5.3 Uboot目录 结构 ..................................................... 50 5.4 Uboot编译 ............................................................. 52 5.5 Uboot初始化流程 .................................................. 53 5.6 uboot 定制 ............................................................ 63 5.7 uboot debug信息 ................................................... 78

Quick notes on testing audio on the i.MX 8QuadMax MEK board with 4.19.35-1.1.0 BSP. Hardware:   - Connect the MCIMX8QM-CPU to the MCIMX8-8X-BB.  - Connect the IMX-AUD-IO to the Audio Slot 1 on the MCIMX8-8X-BB.  - Short 2 and 3 on J47 on the MCIMX8-8X-BB  - Connect an external powered speaker to RCA connectors Audio OUT FR and/or Audio OUT FL on the IMX-AUD-IO  - Optionally, connect a headphone on J15 on the MCIMX8QM-CPU   Test: Power on the board. aplay -l shows the audio interface available. root@imx8qmmek:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: cs42888audio [cs42888-audio], device 0: HiFi cs42888-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: cs42888audio [cs42888-audio], device 1: HiFi-ASRC-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: imxaudmix [imx-audmix], device 0: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: imxaudmix [imx-audmix], device 1: HiFi-AUDMIX-FE (*) [] Subdevices: 1/1 Subdevice #0: subdevice #0 Play file on powered speaker via cs42888: root@imx8qmmek:~# aplay -Dhw:0,0 test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Play file on headphone via wm8960: root@imx8qmmek:~# aplay -Dhw:1,0 test.wav

This tutorial teaches how to flash bootloader using ATK. ATK (Advanced Toolkit) ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. Using ATK This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board.    Set S18 switch as below: Switch S18 -> 111100 3 - Run ATK by clicking Start -> Programs -> AdvancedToolKit -> AdvancedToolKit      Set the options:    Device memory -> DDR; Custom Initial File -> (keep it unmarked)    Communication Channel -> Serial Port (Usually COM1) 4 - Click Flash Tools to erase, program or dump the the flash memory and click GO Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program.    The bootloader binary image file can be found into your Board Support PackageSet Program, NOR Spansion, Bi Swap 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe

Question: Two boards are used and practically identical - one using the i.MX6Solo, the other is using a Dual. The sw settings in both cases are identical (except IOMUX addresses). On the i.MX6Solo they do not see any packet loss, on the i.MX6Dual they do. I recommended modifying the MTU size, but this also did not help. So here my two questions: 1)      is there still some hw difference between the Ethernet block on the Solo and the Dual/Quad? 2)      They run the AHB at only 100MHz. Could that be a problem? If not, why do the two chips behave so differently? To increase the AHB clock to 133 MHz.appears to solve the packet corruption issue. Is the 100 MHz AHB clock really the root cause. Answer: The DualLite/Solo and SoloLite contain different ethernet controllers. The DL/S has a 1000M controller which requires the AHB bus to be greater than 125MHz, while the SL has a 100M controller. As the question was about the Solo and the Dual and both use the Gigabit Ethernet block I assume that both will require a minimum AHB clock of 125MHz.

U-boot expects uImage format for the kernel image. In order for LTIB to 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