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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ディスカッション

ソート順:
Copy Redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND or MMC flash media for Redboot. In this case, NAND is beeing used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate Copy redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND, or MMC flash media for Redboot. In this case, NAND is being used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate
記事全体を表示
Features Additional Information Features The i.MX31 PDK, with Smart Speed™ technology, is a completely integrated hardware and software solution that simplifies product development so you can focus on your critical differentiation needed for market success. Reduce development time, and design products that have power to spare, even when running multiple applications simultaneously. Receive stellar image and graphic performance in a system design that dramatically reduces power consumption. The i.MX31 PDK provides: Modular hardware enabling multiple connectivity technologies Optimized development software for Linux®, Windows® CE 5.0 and Windows Embedded CE 6.0 operating systems Out-of-box experience, complete with demonstration software and performance data Maximum performance and power savings Complete "Design. Debug. Demo." capability as simple as 1,2,3 i.MX31 Applications Processor Module i.MX31 Applications Processor - ARM11™ 128 MB DDR SDRAM 256 MB NAND FLASH Power Management (PMIC MC13783) + Power Circuitry Audio HS USB PHY Touch Controller Connector Debug Module (Software Development) Debug Ethernet Port Debug Serial Port JTAG Reset, Interrupt, Boot Switches Debug LEDs CodeTest Interface Power Source Current/Power Monitoring Personality Module (Demo-ready) Acceleromater MMA7450L (Freescale) User I/O Connectivity (FM, 802.11, Bluetooth, USB OTG, USB HS) Button 2.7"TFT Display 2MP Camera Module SDcard, ATA HDD External Connectors (dock, headphones, TV out, GPS) Microphone Speaker Additional Information i.MX31 PDK Contents If you are new to i.MX31PDK development we suggest checking out:Not authorized to view the specified document 1673 To flash BootLoader: i.MX31 PDK Board Flashing Miscellaneous Tutorials Blink i.MX 31PDK LEDs Using U-Boot i.MX31 Testing RNGA I.MX31 Testing TvOut I.MX31 Using CLKO
記事全体を表示
This is ov5645 driver and tested with i.MX6 L3.0.35 BSP .  It is modified based on ov5640.c. P.S. The power down function for OV5645 is different from the OV5640. So modify the function in your_board.c like this: static void mx6q_mipi_powerdown(int powerdown) {     if (!powerdown)         gpio_set_value(MIPI_PWDN, 1);     else         gpio_set_value(MIPI_PWDN, 0);     msleep(5); }
記事全体を表示
For Fedora Users: Open a terminal as root Edit tftp file -> #gedit /etc/xinetd.d/tftp Add these lines: service tftp     {   socket_type = dgram   protocol = udp   wait = yes   user = root   server = /usr/sbin/in.tftpd   server_args = /tftpboot   disable = no   per_source = 100 2   flags = IPv4 } Restart the service: # /etc/init.d/xinetd restart OR # service xinetd restart
記事全体を表示
Q: What is latency figures for the VPU to decode Device: i.MX6Q OS: Linux Resolution:                         1920x1080(HD) Frame rate:                        30 FPS Function:                             Overlay messages. Input/Output:                   8 bit / YUV 4:2:0 / NAL stream Profile level:                      4.1. Constrained Baseline. I and P frames support. A: It depend on the syntax in H.264, includes num_reorder_frames,max_dec_frame_buffering,num_ref_frames,MaxDpbSize,etc. for start latency: it cover vpu driver loading, allocate buffers, init, decoding the first frame less than 100ms on iMX6/Linux. This document was generated from the following discussion: VPU Latency i.MX6
記事全体を表示
Currently the default i.MX51 wince release doesn't support high capacity MMC card. Attached was the patch of how to enable high capacity MMC card in i.mx51. Original Attachment has been moved to: High-capacity-MMC-support.zip
記事全体を表示
In new iMX8QM and iMX8QXP BSP, it had implemented hardware partition to split the resource and memory regions. The default Android Auto BSP had given example for shared memory between M4 and A core, it is used for RPMSG. Here is an example to add a new shared memory for iMX8QXP MEK board with Android Auto P9.0.0_GA2.1.0 BSP, which can be accessed in both M4, Uboot and Linux Kernel. The new shared memory region is from 0xF6000000 to 0xFDFFFFFF, total 128MB, it covers the RPMSG region too. RPMSG shared memory is moved to 0xF6000000 ~ 0xF6BFFFFF, total 12MB. vendor_nxp_fsl-proprietary_uboot-firmware.patch SCFW patch for board file to change the old shared memory region (0x90000000~0x90BFFFFF) to new shared memory region (0xF6000000~0xFDFFFFFF). This patch is applied to android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/board-imx8qxp.c, after patched, copy this file to SCFW porting kit and build out a new SCFW image, put it to "android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/mx8qx-scfw-tcm.bin". vendor_nxp-opensource_uboot-imx.patch This is the Uboot patch to map the shared memory region, if Uboot doesn't need access these memory, this patch is not needed. vendor_nxp-opensource_kernel_imx.patch This is the kernel patch to map the shared memory region. Note: VPU reserved memory address shouldn't be changed, otherwise it will impact the VPU function. So the new reserved memory region had been moved to 0xF600000~0xFDFFFFFF. vendor_nxp_mcu-sdk-auto_SDK_MEK-MIMX8QX.patch M4 patch for RPMSG address changed from 0x90000000 to 0xF6000000. Note: 1. In this example, we put the two shared memory regions together, then it will not split the memory region used in Linux. Another reason for such modification is the limitation of memory region counts in SCFW. 2. Since the RPMSG shared memory had been moved from 0x90000000 to 0xF6000000, the M4 code who used shared memory should also be changed. 2019-07-29 Update: When "#define PHYS_SDRAM_2_SIZE  0x0" in Uboot, it will create a 0 size memory region, this will impact the Uboot shared memory patch. Added the "uboot_imx8_cpu.patch" to avoid such issue.
記事全体を表示
This is a series of documents that intend to help you grasp he concept of the System Controller Unit (SCU) / System Controller Firmware (SCFW).    Getting started Power management service  Resource management service Pad configuration service Timer service Miscellaneous service   Other Useful resources: https://community.nxp.com/docs/DOC-344684 (2019) i.MX 8 System Controller Unit and System Controller Firmware Overview (2018) Clusters & Infotainment: Introduction to the i.MX 8 System Controller Unit (2017 Slightly outdated, for correct boot sequence go to Chapter 5 System Boot of the Reference Manual) System Controller Firmware command line utility for QNX and Linux You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: The porting kit contains documentation and allows you to build the SCFW from source and do modifications to the board dependent parts: The API documents explain the System Controller Firmware API syntax and it has a section for introduction and general overview of the system. The port document contains information on what each board component function does and the overall process of porting the SCFW.
記事全体を表示
[中文翻译版] 见附件   原文链接: https://community.nxp.com/docs/DOC-343344 
記事全体を表示
This document shows the steps for the creation of Archlinux and kernel 4.18.5 on the UDOO board. Required material: UDOO board, Ubuntu 16.04 and SD card. Firts we need u-boot (universal bootloader), for that reason we need update the host. $ sudo apt-get update Then we need the file *.img and SPL for the file system $ wget http://os.archlinuxarm.org/os/imx6/boot/udoo/SPL $ wget http://os.archlinuxarm.org/os/imx6/boot/udoo/u-boot.img Kernel 4.18.5 and file system: $ sudo mkdir archlinux $ wget http://os.archlinuxarm.org/os/ArchLinuxARM-armv7-latest.tar.gz $ sudo tar -xzvf  ArchLinuxARM-armv7-latest.tar.gz $ sudo rm -rf *.tar.gz You must have the following files Now  We are going to burn the memory, we need a 16Gb of space: We need to make sure it is empty Then partitions: $ sudo fdisk /dev/sdc O, P, N, P, 1 space, 8192 default, W At the end the sdc is partition, then create the filesystem partition $ sudo mkfs.ext4 /dev/sdc1 The working directory $ sudo mkdir mnt mount the partition 1 $ sudo mount /devsdc1 mtn/ Now we where the kernel and filesystem are and copy all the file in mnt: $ sudo cp -vr * ~/mnt/ Once it finish we execute $ sync then unmount the partition of sdc1: $ sudo umount mnt/ Now is moment to load the SPL and u-boot: and $ sync we retire the sd and turn on the board. Now you are on ArchLinux. user: alarm                  root: Root Pass: alarm                 pass: root Now the firts thing we must do it is upgrade the keys: $ pacman -key --init $ pacman -key --populate archlinuxarm $ pacman -Syyuu We can add another user: $ useradd - m -g user  -s /bin/bash user_name $ passwd user_name $ paman -S sudo $ visudo Root ALL= (ALL) ALL user_name ALL=(ALL) ALL $ exit For the graphic we are going to install the xorg: $ sudo pacman -S xorg-server $ sudo pacman -S xorg-apps Now we can execute startx and observe the windows of xorg $ startx To have a windows gestor: $ sudo pacman -S sddm $ sudo pacman -S plasma kde-applications $ sudo systemctl enable sddm Reboot and you are ArchLinux graphics windows
記事全体を表示
This document explains the pad implementation and its relationship with the System Controller Firmware pad configuration service. There are two components to pad configuration in the SCFW, there are the modules that generate the signals that will ultimately appear on the physical pad, let's say GPIO/Ethernet/I2C/UART etc... and then there is the part that configures the muxing of the pad (what signal is going to be outputted through the specific pad), the drive strength of the pad, pull selection, etc, this is the part that the SCFW pad service configures. Introduction‌ The i.MX8 has three types of I/Os: 1.8V only I/Os 3.3V only I/Os 1.8V / 3.3V I/Os Dual Voltage I/Os Note: USB High Speed Inter-Chip (HSIC) and Ethernet interfaces have specific integration schemes with dedicated features. They are a modified versions of the above I/O types. HSIC are a special kind of I/O modified to sustain 480Mbps data rates ENET I/Os are modified versions of Dual Voltage I/Os to support 2.5V operations All of these I/Os have "common features" and "technology specific features" which depend on the type of I/O and the chip manufacturing process (FDSOI in the i.MX8QM case) I/O common features Muxing capability of up to 4 signals Each Pad can have up to 4 signals, only one signal can be present in the pad. To select the signal that will output on the pad simply look at the Pinmux spreadsheet and use the desired alternative, for instance in the following image SCU_GPIO0_00 has 3 options, SCU_GPIO (ALT0 - GPIO controlled directly by the SCU), SCU_UART0_RX (ALT1 - SCU UART receiver) or LSIO_GPIO0_IO28 (ALT3 - Low speed I/O GPIO).   Pads without GPIO functionality (i.e. without the GPIO option in the pinmux spreadsheet) are implemented for one purpose only, these pins are connected directly to the module that drives them and they feature their own physical interface. Examples are XTAL pins, DDR pins and SCU PMIC interface (shown above). Mode of operation All GPIO types support four modes of operation: Normal mode Data is being driven directly to the pad (an internal signal of 1 shows in the pad as a 1 and vice-versa) and the pad works either as an output or as an input but not both at the same time. The output buffer while on this mode looks like this: Open drain Data is being driven through an open drain configuration, the output on the pad switches between 0 and high-z. The pad works either as an output or as an input but not both at the same time, e.g. if the Output Buffer is enabled the Input Buffer is disabled. This is how the output buffer looks like on Open drain mode: Open drain and input Output buffer acts as in open drain mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to simultaneously read the signal at the pad while driving it. Output and input Output buffer acts as in normal mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to read the signal at the pad while driving it. Wake-up capability Each I/O can be configured to wake-up the device, the following configuration options are available: OFF I/O cannot wake-up the system Low detect Generate wake-up event when the pad remains in low-level High detect Generate wake-up event when the pad remains in high-level Rising edge Generate wake-up event on rising edge detection Falling edge Generate wake-up event on falling edge detection Technology specific features Some of the available features for each pad depend on two factors: Chip manufacturing process (FDSOI or LPP) I/O type (1.8V, 3.3V or Dual Voltage) The i.MX8QM is manufactured using FDSOI technology and it features all of the three available I/O types. Drive strength Drive strength options vary within I/O types and chip manufacturing options. The available options for a FDSOI chip are: 1.8V Drive strength options 3.3V Drive strength options Dual Voltage drive strength options Drive strength of 1mA Drive strength of 2mA Low drive strength (50 ohms) Drive strength of 2mA Drive strength of 4mA High drive strength (33 ohms) Drive strength of 4mA Drive strength of 8mA Drive strength of 6mA Drive strength of 12mA Drive strength of 8mA Drive strength of 10mA Drive strength of 12mA High-speed drive strength Pull Select The pull select available options are almost the same for all I/O types (1.8V being the exception) and they also depend on chip manufacturing process. The available options for a FDSOI chip are: Pull select options for FDSOI Bus-keeper (only available for 1.8V) Pull-up Pull-down No Pull (Disabled) A bus-keeper or bus-holder is used to keep the last state on the bus. In normal operation it makes no difference, but once the bus is tri-stated it keeps the last logic level in the bus to prevent the bus from floating. Compensation The compensation feature is only available on Dual Voltage I/Os. Dual Voltage I/Os have a different implementation, they require: Voltage reference generator - which provides a voltage reference to the supply detector and compensation cell Supply detector - detects automatically whether the I/O is being supplied with 1.8V or 3.3V and broadcasts this information to compensation cell and I/O  Compensation cell - adjusts drive strength of dual voltage I/Os depending on Process Voltage and Temperature (PVT) conditions. The default configuration takes care of adjusting this parameters and no further modifications are required. Pad configuration service SCFW API Mux selection The very first function that needs to be called to configure a pad is: sc_err_t sc_pad_set_mux(sc_ipc_t ipc, sc_pad_t pad, uint8_t mux, sc_pad_config_t config, sc_pad_iso_t iso);‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the muxing alternative and setting the common features, its parameters are: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. mux - The mux setting that you require, basically Alt0 -> 0, Alt1 -> 1, Alt2 -> 2 and Alt3-> 3, the pinmux spreadsheet contains the required information (take a look at I/O common features above). config - Used to select the desired mode of operation (take a look at I/O common features above), the available options are declared under sc_pad_config_t Normal mode - SC_PAD_CONFIG_NORMAL Open Drain mode - SC_PAD_CONFIG_OD Open Drain and input - SC_PAD_CONFIG_OD_IN Output and input - SC_PAD_CONFIG_OUT_IN iso - This is the low-power isolation configuration (take a look at I/O common features above). The available options are declared under sc_pad_iso_t ISO_OFF - SC_PAD_ISO_OFF ISO_EARLY - SC_PAD_ISO_EARLY ISO_LATE - SC_PAD_ISO_LATE ISO_ON - SC_PAD_ISO_ON For instance to configure M40_I2C0_SCL with its UART alternative in normal mode with low-power isolation off, the call would look like this: sc_pad_set_mux(ipc, SC_P_M40_I2C0_SCL, 1, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);‍‍‍‍‍‍‍‍‍‍ Pad configuration To configure drive strength and pull select options the technology specific functions need to be used (FDSOI for i.MX8QM): sc_pad_set_gp is being used by our Linux team because it admits the passing of the configuration parameters as a single value and this eases the handling on the device tree, but you should aim to use the technology specific functions. sc_err_t sc_pad_set_gp_28fdsoi(sc_ipc_t ipc, sc_pad_t pad, sc_pad_28fdsoi_dse_t dse, sc_pad_28fdsoi_ps_t ps);‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the drive strength (DSE) and pull select settings (PS) for the specified pad, here is a break down of the parameters it uses: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. dse - The desired drive strength configuration (see Technology specific features above). DSE settings depend on the I/O type being used, the available options for each I/O type are defined under sc_pad_28fdsoi_dse_t: ENET pads capable of operating at 2.5V are a subset of dual voltage I/Os, the dse options available for these pads are the same as normal dual voltage I/Os. i.e. High drive and low drive. ps - The desired pull select configuration (see Technology specific features above). The available options are defined under sc_pad_28fdsoi_ps_t: To determine whether a GPIO pad is 1.8V, 3.3V or Dual Voltage one can look at the pinmux spread sheet, the supply for the pad will indicate what implementation of the GPIO is used. For instance: pads under VDD_SIM_1P8_3P3 are Dual voltage I/Os pads under VDD_SCU_1P8 are 1.8V I/Os pads under VDD_ADC_3P3 are 3.3V I/Os taking the same example as above we could configure the M40_I2C0_SCL as follows: sc_pad_set_gp_28fdsoi(ipc, SC_P_M40_I2C0_SCL, SC_PAD_28FDSOI_DSE_DV_LOW, SC_PAD_28FDSOI_PS_NONE);‍‍‍‍‍‍‍‍‍‍‍‍‍ Configuration under Linux Linux configures pads through the device tree, the full documentation of the binding is under Documentation/devicetree/bindings/pinctrl/fsl,imx8qxp-pinctrl.txt. but here is an extract: * Freescale i.MX8QXP IOMUX Controller Required properties: - compatible: "fsl,imx8qxp-iomuxc" - fsl,pins: each entry consists of 2 integers. Its format is <pin_id pin_config>. pin_config definition: - i.MX8QXP have different pad types, please refer to below pad register definitions, the pinctrl driver will just write the pin_config into the hardware register.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The driver uses the following API: sc_err_t sc_pad_set_gp (sc_ipc_t ipc, sc_pad_t pad, uint32_t ctrl) ‍‍‍ Instead of configuring each parameter individually as done with sc_pad_set_gp_28fdsoi it configures the pad as if writing to a register, the bitfield format is under the binding documentation but it is as follows: struct _hw_pad_iomux_bitfields0 { uint32_t GP : 19; /*!< [18:0] GP controls. */ uint32_t WAKEUP : 3; /*!< [21:19] Wakeup controls. */ uint32_t WAKEUP_ENB : 1; /*!< [22] Wakeup write enable. */ uint32_t LPCONFIG : 2; /*!< [24:23] Low-power config. */ uint32_t CONFIG : 2; /*!< [26:25] Config. */ uint32_t IFMUX : 3; /*!< [29:27] Mux. */ uint32_t GP_ENB : 1; /*!< [30] GP write enable. */ uint32_t IFMUX_ENB : 1; /*!< [31] Mux write enable. */ } B; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ All the configurations mentioned above can be configured, but they are done in a single pass, e.g. Muxing, Configuration (Norma, Open Drive, etc...), Wakeup control, and GP controls are for Pull Select Drive Strenght etc... Check the Reference Manual Chapter for IOMUXD for the register definition for each pad. References For more details refer to the sc_fw_api.pdf document: Chapter 1.3.3 Pad Configuration Service Chapter 6 Pad List Chapter 9.3 (SVC) Pad Service System Controller Firmware 101 
記事全体を表示
gst-inspect is a tool to to get documentation about GStreamer elements. Pipeline Check installed GST elements gst-inspect | tail -1 Check installed FSL GST elements gst-inspect | grep imx Element documentation gst-inspect <gst element>
記事全体を表示
UUU is an evolution of MFGTools. The introduction of UUU detail you can see the uuu.pdf file.. Please download uuu.exe and follow the UUU introduction. Here are some running examples. If you are not familiar with uuu, you can refer to them firstly. Under Windows (should be as admin): • For SD card:  Linux:  .\uuu -b sd_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard • For EMMC:  Linux:  .\uuu -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard  or  .\uuu.exe uuu.auto  Android:  .\uuu_imx_android_flash.bat -f imx8mm -u trusty Under Linux: • For EMMC  Linux:  sudo .\uuu uuu.auto If you download BSP release from nxp.com, you could find a file uuu.auto in the package. This is a preset script that can be executed directly (default for EMMC). You could change the script based on your requirement. Copy the uuu.exe under the release package, then execute the instructions. For UUU tool the prebuilt image and document are here: • https://github.com/NXPmicro/mfgtools/releases • UUU.pdf is snapshot of wiki   Environment PC: Window 10 64bit Board: i.MX8MMLPDDR4 EVK BSP: Q10.0.0_2.0.0 Demo images Screen: MX8-DSI-OLED1 Downloading android images to i.MX 8M Mini EVK LPDDR4 via UUU Tool 1\Hardware Preparations (1) Make the board enter serial download mode. For Rev. B boards, change the first two bits of board's sw1101 to 10 (from 1-2 bit) to enter serial download mode. For Rev. C boards, change the first four bits of board's sw1101 to 1010 (from 1-4 bit) to enter serial download mode. (2) Connecting J901to PC USB by a USB OTG cable. (3) Connecting J301(usb type c) to PC USB. (4) Plugging adapter into Power Jack (J302) (5) Power on i.MX 8M Mini EVK LPDDR4 board via SW101 Switch When first connect the board to PC, windows 10 64bit can’t automatically install FT2232D  driver from official website of manufacture, you need to Install the usb to uart driver manually: https://www.ftdichip.com/Drivers/D2XX.htm Download the setup executable and then install it. When installed success you can see the usb serial port can be used. 2\Downloading UUU Tool For the UUU binary file, download it from github: uuu release page on github. For the Q10.0.0_2.0.0 version use the UUU 1.3.124 version. For Linux OS, download the file named "uuu". For Windows OS, download the file named "uuu.exe". Here I use win10 system, so I download the uuu.exe file.   3\Download the Q10.0.0_2.0.0 Demo images for i.MX8MM   Now all the android os for i.MX products are here: Android OS for i.MX Applications Processors. Decompress release_package/android-10.0.0_2.0.0_image_8mmevk.tar.gz for LPDDR4 board. The package contains the image files and uuu_imx_android_flash tool. Copy uuu.exe to the directory of Q10.0.0_2.0.0 Demo images. 4\ Execute the uuu_imx_android_flash to flash image Power on the board. Open the serial port terminal and setting as following: Open a command line window. For the use and the Options for uuu_imx_android_flash tool details can see the Table 2 in the Android_Quick_Start_Guide. Here I use the OLED screen, to test MIPI panel output, need execute the tool with "-d mipi-panel". So here I use the .\uuu_imx_android_flash.bat -f imx8mm -e -d mipi-panel . When I use the download I meet the follow question: C:\Work\Products\Android BSP\New folder\Q10.0.0_2.0.0 Demo images\android-10.0.0_2.0.0_image_8mmevk>.\uuu_imx_android_flash.bat -f imx8mm -e -d mipi-panel This script is validated with uuu 1.3.124 version, it is recommended to align with this version. dtbo is supported dual slot is supported dynamic partition is supported You do not have sufficient privilege to perform this operation.   So here can change to use the Windows PowerShell, it works well and finished download.   Power off the board. 5\Boot up the board from emmc Set boot mode For Rev. C boards: Change sw1101 to 0110110010 and change sw1102 to 0001101000 if you want to boot from SD card. Change sw1101 to 0110110001 and change sw1102 to 0001010100 if you want to boot from eMMC. Set the U-Boot environment variables for the MIPI panel display U-Boot > setenv bootargs console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200 init=/init androidboot.console=ttymxc1 androidboot.hardware=freescale cma=800M@0x400M-0xb80M androidboot.primary_display=imx-drm firmware_class.path=/vendor/firmware transparent_hugepage=never androidboot.wificountrycode=CN androidboot.lcd_density=240 U-Boot > saveenv Then use the boot to boot up and then display on OLED screen.   Hope this can do help for some users. Best Regards Rita
記事全体を表示
  When considering EIM bursts (performance, burst length, etc) we should take into account, that some parameters (maximum burst length, which defines length in clocks of back-to-back EIM access) depend on master, which performs the access (EIM always service as slave). The EIM can split a master burst in order to meet own settings, but the EIM cannot join two master accesses. So, the maximum  burst length is defined by master.  Usually three options are applied for EIM burst accesses : - ARM block copy instructions (LDM / STM) ; - ARM NEON copy instructions (VLDM / VSTM) ; - i.MX SDMA.   Below are some details regarding these options.   1. ARM. ARM provide recommendations below about the fastest way to copy memory on a Cortex-A8. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html   According to section 8.1.2 (Supported AXI transfers) of ARM Cortex-A9 Technical Reference Manual, it is possible to get maximum 64 bytes (16 beats x 4 bytes) burst for read and 8 bytes burst for write. “INCR N (N:1-16) 32-bit read transfers INCR N (N:1-2) for 32-bit write transfers” http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388i/DDI0388I_cortex_a9_r4p1_trm.pdf 2. SDMA.   According to section 55.4.3.1 (Burst DMA Unit) of the i.MX6 DQ RM : “Perform up to 8-beat read and write bursts to the ARM platform memory, which optimizes throughput when accessing SDRAM-type devices because of an internal, 36-byte FIFO”. This means, that burst length of the SDMA cannot be greater than 32 bytes (8 beat x 4 bytes). As for performance and implementation of SDMA approach, please look at the following : “Measure SDMA Memory To Memory Copy Performance on i.MX6Q” https://community.freescale.com/docs/DOC-103127
記事全体を表示
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.   This is the detailed programming aid for the registers associated with DRAM initialization (DDR3 and LPDDR2) of the MX6UL/ULL/ULZ (consolidated RPA). The last work sheet tab in the tool formats the register settings for use with the ARM DS5/RealView debugger. It can be manually converted by the user to a DCD file format used by uboot or other bootloaders (note the removal of debugger specific commands in this tab). The programming aids were developed for internal NXP validation and development boards.   This tool serves as an aid to assist with programming the DDR interface of the MX6UL/ULL/ULZ and is based on the DDR initialization scripts developed by the R&D team and no guarantees are made by this tool.   The following are some general notes regarding this tool: Refer to the "How To Use" tab in the tool as a starting point to use this tool. 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.  
記事全体を表示
The i.MX27 PDK, with Smart Speed™ technology, is a completely integrated hardware and software solution designed to simplify product development so you can focus on the critical differentiation needed for market success. Reduce development time and design products that have power to spare, even when running multiple applications simultaneously. Receive stellar Ethernet and video performance in a system design that dramatically reduces power consumption. Features i.MX27 Applications Processor - ARM9™ 128 MB DDR SDRAM 256 MB NAND FLASH Power Management (PMIC MC13783) + Power Circuitry Audio HS USB PHY Touch Controller 10/100 Ethernet port Accelerometer MMA7450L (Freescale) User I/O Connectivity (FM, 802.11, Bluetooth, USB OTG, USB HS) Button 2.7" TFT Display 2MP Camera Module SD card, ATA HDD External Connectors (dock, headphones, TV out, GPS) Microphone Speaker Debug Ethernet Port Debug Serial Port JTAG Reset, Interrupt, Boot Switches Debug LEDs CodeTest Interface Power Source Current/Power Monitoring
記事全体を表示
As the Voice over IP (VoIP) market grows, the next evolution of the market is Video and Voice over IP (V2IP). iWave’s iW-RainboW-G15S is a Pico-ITX Single Board Computer (SBC) which has a Freescale’s i.MX6 DualLite ARM Cortex-A9 core based CPU which can operate up to 800MHz speed/core with 1GB (expandable) DDR3 RAM. iWave has provided V2IP on iWave’s Pico ITX i.MX6 which gives more quality in video and audio streaming. iWave has expertise in HD video streaming over V2IP. The SIP(Session Initiation Protocol) protocol for connection between i.MX6 PICO ITX board and host PC which is used in the application Linphone through network (Ethernet). Linphone is a comprehensive solution consisting of an extensive set of algorithms and codecs designed for Digital Voice and Video applications. Above design can be utilized for peer to peer communication between i.MX6 PICO ITX single board computer and PC with Android OS. The i.MX6 single board computer and PC are connected to an Ethernet. The Audio CODEC used on the iMX6 PICO ITX dev board is ALC5610 from Realtek with inbuilt Headphone amplifier and MIC which is used to provide a complete audio solution for portable products. The video pixel rates are typically from 25 MHz up to 297 MHz, but HDMI can support higher rates up to 340 MHz’s i.MX6 PICO ITX board supports LVDS connector to connect different LVDS LCDs. It also supports backlight connector with 15V 300mA output for LCD backlight. iWave's i.MX 6 PICO ITX SBC supports 8/10bit CMOS Camera Interface. External clock for camera is provided using on board Oscillator of frequency 26MHz. i.MX6 CPU supports MIPI CSI interface. The V2IP systems use some existing standard video codec and audio codec to reduce the program material to a bit stream and then use an Internet Protocol (IP) network to carry that bit stream encapsulated in stream of IP packets. This is typically accomplished using some variant of the RTP protocol. Freeescale i.MX6 multimedia applications processor provides sufficient power to provide high-quality audio through wideband audio, in-call audio and video recording on flash. Image: V2IP on iWave’s Android i.MX6 Pico ITX Single Board Computer Video Streaming Platform feature: Pico ITX board with i.MX6 dual lite CPU 320X240p camera OS: Android jelly-bean (4.3) MIC HDMI with 1920X1080p display Android NDK and SDK H264 video codec Freescale’s VPU     For further information or enquiries please write to [email protected] or visit www.iwavesystems.com
記事全体を表示
MX6UL_DDR3_调校_应用手册_V3_20160511.doc
記事全体を表示
i.MX8M_DDR3L_register_programming_aid is created for DDR3L validation board.
記事全体を表示