i.MXプロセッサナレッジベース

ディスカッション

GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API. GTK+ it is written in C, but has bindings to many other popular programming languages such as C++, Python and C# among others. GTK+ is licensed under the GNU LGPL 2.1 allowing development of both free and proprietary software with GTK+ without any license fees or royalties. [Source: gtk.org] As GTK+ is a graphical library, a program using GTK+ can be done in many languages like C, C++, Python, Perl, PHP, Ruby, and many others. Here a C example will be done. How to make a simple program with GTK An easier way to make a graphical interface (GUI) program using GTK+ is to use Glade as Graphical Editor. Glade3 Screenshot To install Glade on Ubuntu type: $sudo apt-get install glade-3 Old Glade versions used to generate C code. Currently version ONLY generates a .glade file that can be parsed in a .xml file which describes the hierachy of the widgets. Let's create, compile and test a sample program on host and after, cross-compile for iMX platform and check it running on a PDK i.MX31 Development kit. In order to develop on host PC, install libgtk2.0-dev typing: $sudo apt-get install libgtk2.0-dev

The System Controller Unit (SCU) is in charge of controlling several features related to power management of the whole system. The user gets access to the following features through the System Controller Firmware: Powering up/down the system,resources and partitions Configuring resource clocks Reset controls Configuring wake-up sources This document will cover the more commonly used features, for details on the full capabilities of the API please refer to the API document for your device. Resource Power Control The SCU is in charge of managing power control to the resources (peripherals) in the SoC. Attempting to access a resource on the OFF state will result in a bus error or a hang All resources are organized within several subsystems, subsystems group together resources with common functionality. Subsystems are independent of each other and have their own PLLs and power domains, this allows modular control of clocks and power to the resources. The System Controller Unit has a dedicated I2C channel to interact with the PMIC, this allows dynamic control of some power sources for resources like the GPUs and Cortex-A cores. The SCU can enable/disable the LDO that supplies power to the GPU for instance and also turn on/off the internal power domains. The mapping of PMIC supplies and resources happens on the board.c (included in the SCFW Porting kit) and it is part of the porting process of the SCFW to new boards. The function board_get_pmic_info is where the mapping of resources to supplies happen, see: /*--------------------------------------------------------------------------*/ /* Get the pmic ids and switchers connected to SS. */ /*--------------------------------------------------------------------------*/ static void board_get_pmic_info(sc_sub_t ss,pmic_id_t *pmic_id, uint32_t *pmic_reg, uint8_t *num_regs) { /* Map SS/PD to PMIC switch */ switch (ss) { case SC_SUBSYS_A53 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1U; } break; case SC_SUBSYS_A72 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_0_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; case SC_SUBSYS_GPU_0 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW1; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW2; *num_regs = 2U; } break; case SC_SUBSYS_GPU_1 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; default : ; /* Intentional empty default */ break; } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Only some subsystems have their own dedicated external power supplies, in the example above A cores and GPUs are the only ones with a dedicated external power supplies. Most of the other subsystems are powered from the main power supply and power gating happens internally, each subsystem contains different power domains that can be turned on/off to manage power consumption. The SCFW API used to power on/off resources is the following: sc_err_t sc_pm_set_resource_power_mode (sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_power_mode_t mode)‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the power mode change mode - is the power mode to change to The available power mode options are the following: Power mode Voltage Clocks SC_PM_PW_MODE_OFF OFF All clocks off SC_PM_PW_MODE_STBY ON All clocks off SC_PM_PW_MODE_LP ON PLLs off resource running from XTAL SC_PM_PW_MODE_ON ON PLLs on In order to be able to access a resource it must be at least on SC_PM_PW_MODE_LP mode, since that mode has the resource voltage on and the clock is supplied by the 24MHz crystal. For more details please refer to the SCFW API document. Clocks Configuration As in the power management case, clocks are also organized in a distributed manner within the device. Each subsystem has it's own PLLs and all of them are clocked by the 24MHz crystal. The number of PLLs in each subsystem varies between all subsystems. To see how many PLLs are within a subsystem please refer to the datasheet of the device you are interested on. For instance on the datasheet of the i.MX8QXP on table 16 in Chapter 4.3.1: It can be seen that the GPU subsystem contains two PLLs, the ADMA subsystem contains 4 PLLs, Display Controller 3, etc... The SCFW API used to configure a clock is the following: sc_err_t sc_pm_set_clock_rate ( sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_pm_clock_rate_t ∗ rate )‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the clock rate change clk - is the clock to set the rate to (each resource can have different clocks associated with it for instance the GPU resource has a clock associated for its shader and another for the GPU, this parameter is used to identify the clock) rate - this contains the desired clock rate, the SCFW will try to match the provided rate if not possible it will then set the closest possible value and return the value that was actually configured. To identify the clk that needs to be passed, please refer to the SCFW API chapter called "Clock List" That chapter contains a table with all the different clocks that are configurable by the SCFW, in the case of the GPUs for instance to select the rate for the Shader or GPU, either the SC_PM_CLK_MISC or SC_PM_CLK_PER options would have to be selected. Set=Y indicates the clock/PLL is not shared and the rate can be set via sc_pm_set_clock_rate(). Enable=Y indicates the clock is not auto gated and must be enabled via sc_pm_clock_enable(). As an example the following snippet configures the GPU_0 shader clock: sc_clock_rate_t shader_clk=700000000; // 700 MHz sc_pm_set_clock_rate(ipc, SC_R_GPU_0_PID0, SC_PM_CLK_MISC, &shader_clk);‍‍ System Controller Firmware 101

Download Linux kernel 2.6.29: $ wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 Extract this: $ tar jxvf linux-2.6.29.tar.bz2 Apply the patches: $ cd linux-2.6.29 Edit the file drivers/net/cs89x0.c adding: #include <mach/hardware.h> Export CROSS_COMPILE environmet: $ export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" $ export CROSS_COMPILE=arm-none-linux-gnueabi- Unselect all no essentials features: $ make ARCH=arm allnoconfig Start the configuration menu: $ make ARCH=arm menuconfig Change/Select the kernel options below. Select the MXC/iMX platform and iMX31ADS board: System Type -> ARM system type -> (X) Freescale MXC/iMX-based Freescale MXC Implementations -> MXC/iMX Base Type -> (X) MX3-based MX3 Options -> [*] Support MX31ADS platforms (NEW) Select ARM EABI standard to compile the kernel: Kernel Features ---> [*] Use the ARM EABI to compile the kernel Add support to Linux Binary Format ELF: Userspace binary formats -> [*] Kernel support for ELF binaries Add support to Network (TCP/IP): [*] Networking support -> Networking options -> [*] Packet socket [*] Unix domain sockets [*] PF_KEY sockets [*] TCP/IP networking [*] IP: kernel level autoconfiguration [*] IP: DHCP support Select network driver (CS89x0), serial driver and unselect VGA console: Device Drivers -> [*] Network device support ---> [*] Ethernet (10 or 100Mbit) ---> [*] CS89x0 support Character devices -> Serial drivers ---> [*] IMX serial port support [*] Console on IMX serial port Graphics support -> Console display driver support ---> [ ] VGA text console Add support to NFS and support to use it as root file system: File systems -> [*] Network File Systems (NEW) -> [*] NFS client support [*] Root file system on NFS Compile the kernel: $ make ARCH=arm Copy the created zImage to tftp directory: $ cp arch/arm/boot/zImage /tftpboot/ Configure your RedBoot to boots with this kernel: load -r -b 0x100000 /tftpboot/zImage exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.240.191:/tftpboot/rootfs ip=dhcp"

Hi All, The new i.MX 6 SL L3.0.35_2.1.0 release is now available on the http://www.freescale.com/site. · Files available # Name Description 1 L3.0.35_2.1.0_LINUX_DOCS i.MX 6SoloLite Linux BSP Documentation. Includes Release Notes, Reference Manual, User guide. API Documentation 2 L3.0.35_2.1.0_LINUX_MMDOCS i.MX 6SoloLite Linux Multimedia Codecs Documentation. Includes CODECs Release Notes and User's Guide 3 L3.0.35_2.1.0_ER_SOURCE i.MX 6SoloLite Linux BSP Source Code Files 4 L3.0.35_2.1.0_MM_CODECS i.MX 6SoloLite Linux Multimedia Codecs Sources 5 L3.0.35_2.1.0_AACP_CODECS i.MX 6SoloLite Linux AAC Plus Codec 6 L3.0.35_2.1.0_DEMO_IMAGE i.MX 6SoloLite Linux Binary Demo Files · Target HW boards o i.MX6SL-EVK · New features o Updated thermal equation for i.MX 6SoloLite o Added Fuse check for all the devices o Enabled DISPLAY power gating feature on TO1.2 · Known issues o For known issues and limitations please consult the release notes.

Dear All, Our board is designed based on both EVK and HEG (Adeneo Embedded Home Energy Gateway), the ENET_FEC_RESET_B on EVK is replaced by LCD_D11 as it on HEG. We have re-config all pins based on i.mx28 BSP and successfully built by ltib. However, eth0 is not working due to "PHY is not found"! and we are still trying to figure it out. The changes we apply on the BSP are(in mx28evk_pins.c): in static struct pin_desc mx28evk_fixed_pins[]: the definition of LCD_D11 change to { .name = "LCD_D11", .id = PINID_LCD_D11, /* PHY reset pin*/ .fun = PIN_GPIO, .voltage = PAD_3_3V, .strength = PAD_8MA, .output = 0, }, and replace all "PINID_ENET0_RX_CLK" in mx28evk_pins.c by "PINID_LCD_D11" To prevent any possible interrupt, we also disable all LCD pins in both mx28_pins.h and mx28evk_pins.c since we don't have LCD. Any comment/suggestion is highly appreciate! BR, TF

IMX6 S/DL for consumer has both PXP and IPU. Automotive and Industrial versions doesn't have PXP. As IMX6 also has IPU, the Linux framebuffer driver uses IPU and not PXP. Note : “pxp_v4l2_test.out” from unit_tests was made for processors (i.MX6 SL), that have only PXP and its framebuffer driver applies PXP to accelerate image processing. “pxp_v4l2_test.out” should not be used with i.MX6 S/DL. To test PXP device with i.MX6 S/DL users have to try “pxp_test.out”.

Computer On Module • Processor Freescale i.MX 6Quad, 1GHz • RAM 1GB DDR3 SDRAM 64-bit • ROM 4GB NAND Flash UP to 16GB • ROM 2M SPI Nor Flash ! • Power supply Single 5V • Size 40mm SO-DIMM • Temp.-Range 0 to + 95C (Consumer) -20 to + 105C (Extended Consumer) -40 to +105C (Industrial) -40 to + 125C (Automotive) Key Features • 10/100Mbps Ethernet • One High Speed USB 2.0 ports • Full HD LCD controller, 24bpp • OpenGL ES 2.0 and OpenVG 1.1 hardware accelerators • Multi-format HD 1080p60 video decoder and 1080p30 encoder hardware engine • Two Camera Interfaces • NEON MPE coprocessor — SIMD Media Processing Architecture — dual, single-precision floating point execute pipeline • Unified 1MB L2 cache • Several interfaces: 5x UART, 2x SDIO, 1x SSI/AC97/I2S, 3x I2C, 2xCSPI • 3.3V I/O • 2x Controller Area Network (FlexCAN) • PCIe 2.0 (1-lane) OS Support • Linux 3.0 • Android 4.2 Application:Media Tablet,Education Tablet PC,EBook,Automotive Infotainment,Aviation Infotainment,HMI,Portable Medical Instruments,IPTV,IP Phone,Smart Energy Systems,Intelligent industrial control systems For more information, please see Attachment We can provide a complete solution

i.MX Family Processor The i.MX family is designed for use in smartphones, wireless PDAs, gaming and many other mobile wireless applications, Freescale's i.MX Family of applications processors are a leading solution in today's smartphone environment. Based on ARM® core technology, the i.MX1, i. MXL, i.MX21, i.MX27 and i.MX31 are designed to offer low power consumption with real-world power performance and a high degree of integration to reduce your design time significantly. The i.MX Family supports a broad range of industry-leading platforms such as those based on the Microsoft® Window® CE operating systems, Palm® OS, Linux® OS, and Symbian™ operating systems. The i.MX portfolio is a leading solution in today's smartphone environment and is a central feature of Freescale's i.Smart smartphone reference design, providing power performance to our Innovative Convergence™ platforms. We are committed to continually expanding our Innovative Convergence platforms to support new technologies and new services as they emerge into the marketplace, such as advanced display technologies including smart panels; streaming video; multiple operating systems; and the far-reaching capabilities of the personal server. Processor CPU Speed FPU DMA Channels Embedded SRAM Flash Boot Video Acceleration 2D/3D Graphics i.MXS ARM920T 100MHz No 11 No NOR No No i.MXL ARM920T 200MHz No 11 No NOR DCT/iDCT Hardware Acceleration 2D/3D Graphics Through Software i.MX21S ARM926EJ-S 266MHz No 16 6KB NAND or NOR No No i.MX21 ARM926EJ-S 350MHz No 16 6KB NAND or NOR MPEG4 CIF 30 fps encoder and decoder 2D/3D Graphics with external accelerator i.MX27 ARM926EJ-S 400MHz No 16 45KB NAND or NOR H.264, MPEG-4, H.263 HW Enc/Dec; 24 fps VGA Full Duplex No i.MX31L ARM1136JF-S 532MHz Yes 32 16KB NAND or NOR MPEG4 VGA 30 fps Encode No i.MX31 ARM1136JF-S 532MHz Yes 32 16KB NAND or NOR MPEG4 VGA 30 fps Encode Integrated 2-D/3-D Processing Unit with OpenGL® Support i.MX35 ARM1136JF-S 532MHz Yes 32 128KB NAND, NOR, MMC/SD MPEG-4, H.264, ... Integrated 2D Processing Unit (Z160 @133MHz) with OpenVG® 1.1 Support i.MX51 ARM Cortex-A8 800MHz Yes 32 128kB NAND, NOR, MMC/SD MJPEG, MPEG-2, MPEG-4, H.263/264, VC-1, DivX, RV10 Integrated 2D (Z160 core @166MHz) and 3D (Z430 core @166MHz) Processing Unit with OpenVG® 1.1 and OpenGL ES® 2.0 / Direct3D Mobile Support i.MX53 ARM Cortex-A8 1GHz Yes 32 144kB NAND, NOR, MMC/SD MJPEG, MPEG-2, MPEG-4, H.263/264, VC-1, DivX, RV10 Integrated 2D and 3D (Z430 core @200MHz) Processing Unit with OpenVG® 1.1 and OpenGL ES® 2.0 / Direct3D Mobile Support For complete comparison click here. For more information about i.MX Family click here.

Question: To eliminate the need for pull-ups AND pull-downs on the gpio boot override pins to save board space, does anyone know when in the boot rom that the GPIO pins are sampled and whether the internal Pull Downs are already enabled? Is this true for all the GPIO override pins? To just be able to provide an external Pull-up to specify boot options and NOT both pull-up and pull-down option. Can this be done? Answer: The pull-ups and pull-downs are active while POR_B is low (as defined in the datasheet). The pins are sampled on the 2 nd rising edge of RTC_XTALO before the rising edge of POR_B. As a caution, on-chip pull-up/downs are very weak and are primarily intended for controlling the pin (keeping it from logically wiggling) if the pin is not connected at all. If a pin is connected out to a trace, relaying on the on-chip PU/PD alone could be a little risky. Since the PU/PD is weak, it's possible to have noise coupled onto the pin. [Similar to Brett's comment above].

Question: The i.MX6 documentation gives several different values for the maximum frequency of the IPU’s HSP_CLK clock. What are the correct HSP_CLK maximum frequency values for the i.MX6 Dual/Quad and Solo/DualLite? Can HSP_CLK run at 270 MHz on both the DQ and SDL CPUs, but it’s not clear from the documentation if this is permitted. Maximum HSP_CLK frequencies listed in the reference manual (DQ😞 264 MHz (Table 9-2 (IPU IP Parametric Table), Table 9-5 (IPU Clock Sources)) 266 MHz (Table 18-3 (System Clock Frequency Values)) Maximum HSP_CLK frequencies listed in the reference manual (SDL😞 270 MHz (Table 9-2 (IPU IP Parametric Table), Table 9-5 (IPU Clock Sources), Table 18-3 (System Clock Frequency Values)) Answer: Referring to Figure 18-2, IPU1_HSP_CLK_ROOT may be selected to have 1 of 4 sources. These sources are highlighted in yellow on the northwest corner of the page and the previous paragraph states these are max values. Possible sources are 540, 528, 396, and 480 MHz. The 480 MHz is divided by 4 before the selector, so winds up being 120 MHz. Per the diagram, these are all divided by 2 for IPU1_HSP_CLK_ROOT. The result is 270, 264, 198, and 60 MHz choices. Therefore, the max for IPU1_HSP_CLK_ROOT is 270 MHz for DQ. MX6D/Q and MX6S/DL are different with respect to max HSP_CLK frequency. MX6D/Q = 264 MHz max MX6S/DL = 270 MHz max

Random Number Generator - RNGA Download rng-tools: http://downloads.sourceforge.net/sourceforge/gkernel/rng-tools-2.tar.gz This tool tests the link between a random number generator hardware and the kernel's PRNG (pseudo-random number generator). ./ltib -m shell LTIB> cd rpm/BUILD/ LTIB> cp ~/hwrandom/rng-tools-2.tar.gz . LTIB> tar zxvf rng-tools-2.tar.gz LTIB> cd rng-tools-2 LTIB> ./configure --host=arm-linux LTIB> make LTIB> sudo cp rngtest /tftpboot/ltib/home/ Restart your board and execute this command in the board's console: $ cat /dev/hwrng | /home/rngtest -c 1000

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. These are detailed programming aids for the registers associated with DRAM initialization (LPDDR3 and LPDDR2). The last work sheet tab in the tool formats the register settings for use with the ARM DS5 debugger. It can also be used with the windows executable for the DDR Stress Test (note the removal of debugger specific commands in this tab). These programming aids were developed for internal NXP validation boards. This tool serves as an aid to assist with programming the DDR interface of the i.MX 7ULP and is based on the DDR initialization scripts developed for NXP boards and no guarantees are made by this tool. The following are some general notes regarding this tool: The default configuration for the tool is to enable bank interleaving. Refer to the "How To Use" tab in the tool as a starting point to use this tool. The tool can be configured for one of the two memory types supported by the i.MX 7ULP. Nevertheless, two separate programming aids are provided based on the DRAM type: LPDDR3 and LPDDR2. Therefore, you may use the tool pre-configured for your desired memory type as a starting point. Some of the CCM programming at the beginning of the DRAM initialization script (in the "DStream .ds file" tab) were automatically generated and in very few cases may involve writing to reserved bits, however, these writes to reserved bits are simply ignored. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements. There is no schedule for aforementioned maintenance. For questions or additional assistance using this tool, please contact your local sales or FAE.

Flashing Kernel and Root File System using RedBoot Creating an image A kernel image and a root file system can be created using All Boards LTIB or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs/ -e 0x20000 -n -p -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connections errors can be avoided by All Boards Configuring RedBoot. The process below uses TFTP to copy the files between host and target. See All Boards TFTP for detail in configurations. Copy the kernel image and the root file system image to the TFTP dir. For example, in LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: fis init Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel at the right address (0x200000, for IMX31PDK) fis create -f 0x200000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for IMX31PDK. fis create -f 0x600000 root Testing You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock2 /mnt ls /mnt List the /mnt contents. The output must be the right file system. Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=none" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the ethernet cable.

I was trying to implement an E-Ink solution using IMX7D. Unfortunately I only had a IMXEBOOKDC3 available, not the DC4 shown on the IMX7D E-Ink tutorials. After a couple of tries I found the right way of connecting the expansion board and the the definition of the arguments on U-boot to make the IMX7D and DC3 work together. I logged these considerations on the blog post below: http://bit.ly/IMX7D_IMXEBOOKDC3 Andres

i.MXプロセッサナレッジベース

i.MX Processors Knowledge Base

ディスカッション

All Boards GTK Glade

如何添加iMX8QXP PAD（GPIO）Wakeup

System Controller Firmware 101 - Power management service

IMX31ADS Compiling Linux kernel mainline

i.MX 6 SL L3.0.35_2.1.0 Release

Use LCD_D11 pin for enet reset in iMX28

IMX6 S/DL PXP module

xaa

i.MX6 D/Q L3.035_1.0.2 Patch Release

i.MX Android Introduction.pptx

How to quickly develop i.MX6 products

19-iMX_Serial_Download_Protocol.py

i.MX Family

Q&A: What is gpio configuration sampling in mx6 boot?

i.MX6 IPU CPMEM Tool

Q&A: What are the maximum HSP_CLK frequency values?

i.MX31 Testing RNGA

i.MX7ULP Register Programming Aids

i.MX31 PDK NAND Flashing RedBoot

IMX7D + IMXEBOOKDC3 use case considerations

i.MXプロセッサ ナレッジベース

i.MX Processors Knowledge Base

ディスカッション

i.MXプロセッサナレッジベース