i.MX8/8X/8XL在汽车中的应用 • 娱乐导航 • 虚拟仪表 • 电子座舱 • 360环视与ADAS • C-V2X Tbox

Introduction Even though we have provided MQX OS support for imx6SX M4 core, we don’t need such complex operation system running on M4 core in some cases. For users who want to simplify and accelerate their M4 application development, bare metal codes without OS support is also a good choice. This demo will show how to develop bare metal codes for i.MX SoloX. Verified Platform imx6sx sabresd Application Notes How to develop bare metal codes running on M4 core .pdf Demo files a9_launch_m4: Run at A9 core and launch M4 core m4_apps: Run at M4 core

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:

How to change Linux Kernel configuration file in Yocto Project metalayer Preparing the requirements Download the metalayer Git clone the Linux Kernel source code Customize the configuration Copy the configuration to the metalayer Install the patch in the Linux Kernel recipe Build the new image with the different Linux Kernel configuration How to change Linux Kernel configuration file in Yocto Project metalayer It is common that the metalayer providing a Linux Kernel recipe includes a default configuration file for the Linux Kernel source code (the defconfig file). There are several approaches to customize the Linux Kernel source code and defconfig file. This article presents the option to patch the defconfig from the Linux Kernel source code and is a good approach to be used with meta-fsl-bsp-release or meta-imx . Preparing the requirements The list of requirements: the target metalayer (in this example, it's meta-imx:imx-5.4.3-2.0.0 ) the same Linux Kernel source code, but git cloned Download the metalayer For example, take BSP release imx-5.4.3-2.0.0 for meta-imx $ mkdir <BSP_DIR> $ cd <BSP_DIR> $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-2.0.0.xml $ repo sync $ MACHINE=imx8mnevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Git clone the Linux Kernel source code Use the very same Linux Kernel source code from the metalayer. In this example, open the file sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb to get the git repository, and git commit. $ cd ~ $ git clone git://source.codeaurora.org/external/imx/linux-imx.git $ cd linux-imx $ git checkout fd263a3edd95dfe812397fabf1059b5f99bba2ab -b change_defconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Customize the configuration Using the default defconfig as a base, configure the Linux Kernel, and then use make menuconfig to change the configuration as desired. After the customization, generate a new defconfig file and replace the default one. The step by step with all the commands can be see in next snippet: $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- $ make defconfig $ make menuconfig $ make savedefconfig $ cp defconfig arch/arm64/configs/defconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The customization can be highlighted by git, in this example the result is show in next log: $ git status On branch change_defconfig Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: arch/arm64/configs/defconfig Untracked files: (use "git add <file>..." to include in what will be committed) defconfig no changes added to commit (use "git add" and/or "git commit -a")‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Review the change and create a commit, with that commit, create a patch. TIP: The defconfig file can also be directly changed. The make menuconfig can be skipped in that case. $ git add arch/arm64/configs/defconfig $ git commit -s -m "defconfig: Customize defconfig" $ git format-patch -1 0001-defconfig-Customize-defconfig.patch‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Copy the configuration to the metalayer Now that the Linux Kernel configuration is customized, and a patch to the kernel is created, copy over that patch to the metalayer, and install it to the Linux Kernel recipe file. $ mkdir <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/ $ cp 0001-defconfig-Customize-defconfig.patch <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/‍‍ Install the patch in the Linux Kernel recipe The Linux Kernel recipe for this example is linux-imx_5.4.bb . Edit the file to install the patch. $ gedit <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb‍ Add the following line: SRC_URI += "file://0001-defconfig-Customize-defconfig.patch "‍ The resultant change is show above: $ cd <BSP_DIR>/sources/meta-imx/ $ git diff diff --git a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb index 214647abb..3f926314c 100644 --- a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb +++ b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb @@ -16,6 +16,7 @@ KERNEL_BRANCH ?= "imx_5.4.3_2.0.0" LOCALVERSION = "-2.0.0" KERNEL_SRC ?= "git://source.codeaurora.org/external/imx/linux-imx.git;protocol=https" SRC_URI = "${KERNEL_SRC};branch=${KERNEL_BRANCH}" +SRC_URI += "file://0001-defconfig-Customize-defconfig.patch " SRCREV = "fd263a3edd95dfe812397fabf1059b5f99bba2ab"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Build the new image with the different Linux Kernel configuration Remember to change the current directory to the metalayer. Build the image again. The new image binary reflects the changes in Linux Kernel, and in case the change removes some kernel module, the rootfs also reflects the change. $ cd <BSP_DIR>/bld-xwayland $ bitbake‍ <image-name>‍‍‍‍‍‍‍‍‍‍

Description about VPU & IPU usage in Android R13.4 GA release for i.MX6DQ

Introduction There are four boot logos in kk4.4.3_2.0.0-beta  system at first: uboot logo\linux logo\android init logo\android animation. We plan to use uboot logo to cover linux logo and android init logo so that we  can combine first three logoes into one logo.This guide provides a step by step explanation of how to transfer uboot UI to  linux kernel and android init smoothly on board sasbresd_6dq sabresd_6dl. The core ideas of the patch: need to  keep display clock from uboot to kernel. When kernel boot up , we do not break the frambuffer for that it stores uboot logo data. need to disable show android init logo. what do the patch do in uboot 1、 can not shut down video after uboot is over.The patch delete releted code in function  arch_preboot_os() 2、 keep hsp clock (ipu clock) the same with linux 3.10 the below is the setting in sabrasd DQ board: osc(24MHz) -> pll2(528MHz) -> mmdc_ch0(528MHz) -> ipu1_hsp_clk(264MHz) the below is the setting in sabrasd DL board: osc(24MHz) -> pll3(480MHz) -> pll3_pdf1(540MHz) -> ipu1_hsp_clk(270MHz) 3、 keep pixel clock the same with linux 3.10 the below is the setting in sabrasd DQ board: osc(24MHz) -> pll2(528MHz) -> pll2_pfd0(452.57MHz) -> ldb_di1(64.65MHz) -> ipu1_di1(64.65MHz) -> ipu1_pixel(64.65MHz) the below is the setting in sabrasd DL board: osc(24MHz) -> pll2(528MHz) -> pll2_pfd0(452.57MHz) -> ldb_di1(64.65MHz) -> ipu1_di1(64.65MHz) -> ipu1_pixel(64.65MHz) 4、 keep pwm clock In kernel,there is a 100% duty pwm to drive lvds panel.So the patch set the pad SD1_DATA3 to a 100% duty pwm pin. 5、 add fbbase and fbmem to bootargs the fbbase is the uboot logo’s phy addr. So the patch pass the parament to kernel through cmdline.we should allocate address aligned 1M for linux 3.10 reserve address aligned by 1 M. what do the patch do in linux 3.10 1、 reserve the address which come from fbbase 2、 keep  ipu related clock when system init the clock in clk-imx6q.c The patch  enable ldb_di1_clk、ipu1_di1_clk、ipu1_clk、pwm1_clk.  Do not disable pll2 and pll3 related clock for the clock may be the source of  ipu clock. Although we enable ldb_di1_clk、ipu1_di1_clk and so on in register, we need to use the function clk_prepare_enable(). Because  the system may close some clocks for their user count is 0(if we use clk_prepare_enable(),it and it’s parent  user count will add 1 ) 3、 disable cabc which will light the panel according the content. Change cabc_enable in dts file. 4、 Move global alpha and color key setting in probe  after framebuffer is registered. Delay       register IPU interrupts used by framebuffer  until IPU hsp clock is enabled.Because global alpha and color key setting and register IPU interrupts may disable hsp clock. disable show android init logo android init logo is the text"android_". we need disable to show it so that the former three logos looks the same logo.The patch 92-system_core solve this problem. The environment of the patch: Hardware: SABRASD DQ&DL Soft ware: kk4.4.3_2.0.0-beta on linux 3.10 How to use the patch: $ cd my_android/kernel_imx/ $ patch -p1 < ./92-kernel_v2 $ cd my_android/bootable/bootloader/uboot-imx/ $ patch -p1 < ./92-uboot_v2     $ cd my_android/system/core $ patch -p1 < 92-system_core Note:      1、 If you want to have this feature on sabraSD dq&dl board,this patch is OK .After you use this patch, you want to change to  other board such as sx, you may meet this problem that the kernel logo penguin don’t appear. You may change this file: arch/arm/configs/imx_v7_android_defconfig                 CONFIG_LOGO=y                 CONFIG_FRAMEBUFFER_CONSOLE=y                 CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y                 #CONFIG_MX6_CLK_FOR_BOOTUI_TRANS=y                 #CONFIG_MX6_CLK_FOR_BOOTUI_TRANS_LVDS_IPU1_DI1=y

Hi all, Most of IoT customers request to enable/demo i.MX EVK with FSL Zigbee solution. In default i.MX Linux/Android BSP, Zigbee function is not enabled. Here we make a lighting demo setup through i.MX6Q SabreSD, KW20 USB dongle and Philips Hue light. KW20 is configured as Zigbee coordinator, connected with USB OTG in i.MX6Q, then i.MX6Q can issue On/Off, brightness and color control commands through KW20 to toggle Philips Hue light directly. Please find the attachment for details. Best regards, Carl

本文档主要包括两个部分： 1：如何将一首超过两声道的多声道音乐放到多个双声道声卡上播放，来模拟原音乐文件的多声道输出。 2：如何将多个双声道音乐文件同时放到一个8声道的声卡的不同channel上播放。 涉及的文件：etc/asound.conf 1：如何将一首超过两声道的多声道音乐放到多个双声道声卡上播放，来模拟原音乐文件的多声道输出。 1）：Sabresd板子 按设计来讲，sabresd板子最多只能播双声道的音乐，但是如果一个音乐文件是四声道，该如何用sabresd板子来播放呢？ 可以让前两个声道通过WM8962来播放，后两个声道通过HDMI来播放： 33 pcm.multi { 34         type multi 35 36         slaves.a.pcm "hw:0,0" 37         slaves.a.channels 2 38         slaves.b.pcm "hw:1,0" 39         slaves.b.channels 2 40 41         bindings.0.slave a 42         bindings.0.channel 0 43         bindings.1.slave a 44         bindings.1.channel 1 45         bindings.2.slave b 46         bindings.2.channel 0 47         bindings.3.slave b 48         bindings.3.channel 1 49 } 273 pcm.asymed{ 274 type asym 275 playback.pcm "multi" 276 capture.pcm "dsnoop_44100" 277 } 278 279 ctl.multi{ 280         type hw; 281         card 0; 282 } 289 pcm.!default{ 290 type plug 291 route_policy "average" 292 slave.pcm "asymed" 293 } 可以通过以下命令来测试： speaker-test -c 4 -t sine speaker-test -c 4 -t sine -D multi 2）：ARD板子 ARD板子，6声道的audio文件，用ESAI来播放前四个channel，后两个channel用HDMI来播放： 33 pcm.multi { 34         type multi 35 36         slaves.a.pcm "hw:0,0" 37         slaves.a.channels 4 38         slaves.b.pcm "hw:2,0" 39         slaves.b.channels 2 40 41         bindings.0.slave a 42         bindings.0.channel 0 43         bindings.1.slave a 44         bindings.1.channel 1 45         bindings.2.slave a 46         bindings.2.channel 2 47         bindings.3.slave a 48         bindings.3.channel 3 49         bindings.4.slave b 50         bindings.4.channel 0 51         bindings.5.slave b 52         bindings.5.channel 1 53 } 273 pcm.asymed{ 274 type asym 275 playback.pcm "multi" 276 capture.pcm "dsnoop_44100" 277 } 278 279 ctl.multi{ 280         type hw; 281         card 0; 282 } 289 pcm.!default{ 290 type plug 291 route_policy "average" 292 slave.pcm "asymed" 293 } 可以用下面命令来测试： 播源文件是6声道的音乐： aplay 48kHz16bit-six-channel.wav aplay -D multi 48kHz16bit-six-channel.wav speaker-test -c 6 -t sine speaker-test -c 6 -t sine -D multi 播源文件是双声道的音乐，ESAI的四个channel和HDMI的两个声道都是该音乐： aplay heart.wav 2：如何将多个双声道音乐文件同时放到一个8声道的声卡的不同channel上播放。 我们ARD的板子，ESAI是8声道的，大部分音乐都是双声道的，ESAI的6个channel会被浪费掉。如何将其余的6个声道也应用起来？ alsa lib有dshare这个plugin,可以将4个双声道的音乐文件当成一个8声道的音乐来处理。 28  pcm_slave.nforce { 29        pcm "hw:0,0” 30        channels 8 31        rate 48000        # fixed, because all dshare devices must use the same samplerate. 32        buffer_size 4096  # make these sizes smaller for lower latency 33        period_size 1024 34        periods 4 35        period_time 0 36    } 37 39  pcm.ch12 { 40        type dshare 41        ipc_key 47110815 42        slave nforce 43        bindings.0 0 44        bindings.1 1 45    } 46 47  pcm.ch34 { 48        type dshare 49        ipc_key 47110815 50        slave nforce 51        bindings.0 2 52        bindings.1 3 53    } 54 55   pcm.ch56 { 56        type dshare 57        ipc_key 47110815 58        slave nforce 59        bindings.0 4 60        bindings.1 5 61    } 62 63   pcm.ch78 { 64        type dshare 65        ipc_key 47110815 66        slave nforce 67        bindings.0 6 68        bindings.1 7 69    } 可以通过下面的命令来测试： (aplay -Dplug:ch12 XX.wav &) (aplay -Dplug:ch34 XXX.wav &) (aplay -Dplug:ch56 XXXX.wav &) (aplay -Dplug:ch78 XXXXX.wav &) 四首音乐会分配到ESAI的8个channel上。

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

It is one mandatory patch if you are in the case: The chip you are using is imx6sx TO1.3 and newer, and use the kobs-ng to flash your image to the Nand memory chip. If you are using MFG, you also need rebuild the kobs-ng, and update the binary into your MFG tool.  The patch have been integrated into the default release yocto_4.1.15, but if you are using the older version release before yocto_4.1.15, please make sure you have integrated the modification when you need to use kobs-ng to flash the image to Nand memory chip. commit 5ecf08703da489a3bd317341f630870a3d07dab9 Author: Han Xu <[email protected]> Date:   Thu Jan 28 14:40:14 2016 -0600     MMT-105: change the i.mx6sx revision check change the i.mx6sx revision check since v1.3 uses v1.2 boot config as well.     Signed-off-by: Han Xu <[email protected]>     (cherry picked from commit 1dac0c14d1e2016c2fa804f6628543d8d238c680) diff --git a/src/plat_boot_config.c b/src/plat_boot_config.c index 461675a..e1ef6f3 100644 --- a/src/plat_boot_config.c +++ b/src/plat_boot_config.c @@ -1,5 +1,5 @@ /* -* Copyright (C) 2010-2015 Freescale Semiconductor, Inc. All Rights Reserved. +* Copyright (C) 2010-2016 Freescale Semiconductor, Inc. All Rights Reserved. */ /* @@ -256,10 +256,12 @@ int discover_boot_rom_version(void)                                         }                                         fgets(line_buffer, sizeof(line_buffer), revision);                                         if (!strncmp(line_buffer, "1.0", strlen("1.0")) || -                                                       !strncmp(line_buffer, "1.1", strlen("1.1"))) +                                                       !strncmp(line_buffer, "1.1", strlen("1.1"))) {                                                 plat_config_data = &mx6sx_boot_config; -                                       if (!strncmp(line_buffer, "1.2", strlen("1.2"))) +                                       /* all other revisions should use the latest boot config */ +                                       } else {                                                 plat_config_data = &mx6sx_to_1_2_boot_config; +                                       }                                 }                                 if (!strncmp(line_buffer, plat_imx6ul, strlen(plat_imx6ul))) How to apply it to older version quickly:  Apply the patch and rebuild the kobs-ng in yocto_3.14_x environment: bitbake -c compile -v -f imx-kobs cd tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/5.0-r0/imx-kobs-5.0 git apply yocto_3_14_x.patch bitbake -c compile -v -f imx-kobs you can find the new binary “kobs-ng” under “tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/5.0-r0/build/src” Apply the patch and rebuild the kobs-ng in yocto_3.10_53 environment: . ./setup-environment build bitbake -c compile -v -f imx-kobs cd tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/3.10.53-1.1.0-r0/imx-kobs-3.10.53-1.1.0 git apply yocto_3_10_53patch bitbake -c compile -v -f imx-kobs you can find t he new binary “kobs-ng” under tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/3.10.53-1.1.0-r0/imx-kobs-3.10.53-1.1.0/src As one alternation method, you also can download the whole imx-kobs-5.4 package which yocto_4.1.15 is using to build. wget http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//imx-kobs-5.4.tar.gz

This PDF is training material for showing examples on video encoding, video decoding, video streaming on an i.MX53QSB board.

There are two optionsou 1. Remove all source code after building: You can indicate bitbake to remove all source code after a build adding this line INHERIT += "rm_work" our to your conf/local.conf file. Of course, when baking another image, ALL source code has to be fetched again and it can take a lot of time, specially on machines with low connections to the Internet. The smallest image you can build is core-image-minimal, containing the minimal set of packages to board a particular machine. The largest is fsl-image-gui (in fact, there is one bigger 'fsl-image-gui-sdk' used for developing purposes inside the target). Between these two, there are a lot of images you can choose. You can even create your own image using hob. In case you do not want to build anything, there are some pre-built images on this site, just download the sdcard file and flash it to an SD card. 2. Select only those  IMAGE_FSTYPES you need. There is a variable named IMAGE_FSTYPES  which indicates the output formats you want for the resulting root file system images, by default is has this value: IMAGE_FSTYPES ?= "tar.bz2 ext3 sdcard" and it is located on /sources/meta-fsl-arm/conf/machine/include/imx-base.inc machine's header file. If you want to change it, place this variable on the build/conf/local.conf file. In case you have NFS mounting, remove the 'sdcard' (and either 'ext3' or 'tar.bz2') string, resulting in IMAGE_FSTYPES = "tar.bz2"

Very often, customers need to disable the framebuffer auto blank. There are several ways to do so. Modify the code in drivers/tty/vt/vt.c or remove the  “CONFIG_VT_CONSOLE” from the kernel configuration. All these work, but inconvenient. Review the code following: static int vesa_blank_mode; /* 0:none 1:suspendV 2:suspendH 3:powerdown */ static int vesa_off_interval; static int blankinterval = 10*60; core_param(consoleblank, blankinterval, int, 0444); The blank is controlled by blankinterval, which can be set with the name consoleblank. And the consoleblank is a "core_param". core_param in linux can be recognized by kernel. Also can be passed to kernel command line from uboot with bootargs. we could add this to the bootargs that the framebuffer will not go blank: consoleblank=0 Example(verified with imx6 L3.0.35_4.1.0_130816): setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk1p1 rootfstype=ext4 rootwait video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 fbmem=28M consoleblank=0'

Wondering how to manage and install the various rpms generated under tmp/deploy/rpm? smart is the application you need on the target to replace apt-get Please set your local.conf with the following: # It is also recommended you use build history, which adds some sanity checks to package versions, in conjunction with the server that # is running the PR Service. To enable build history, add the following to each building system's # It is recommended to activate "buildhistory" for testing the PR service INHERIT += "buildhistory" BUILDHISTORY_COMMIT = "1" PRSERV_HOST = "localhost:0"  # This will set up your host computer as Package Revision Server // PACKAGE_FEED_URIS = "http://10.170.96.7/imx7rpm" #please place any server ip addr, this one is mine. add also the following to enable the package management (smart): EXTRA_IMAGE_FEATURES += "package-management" Setup your own http server, and link the server repository with your tmp/deploy/rpm repo (your are free to use your preferred http server). Since Morty (yocto 2.4), smart has been deprecated, and now the package management is done with dnf (from Debian). Please check dnf document to get more to know about dnf. The dependencies are still poorly controlled. After compiling a pkg the easiest remain: dnf install package.rpm example: root@imx8mmevk:~# dnf install libfuse2-2.9.7-r0.aarch64.rpm Failed to synchronize cache for repo 'oe-remote-repo-imx8m-imx8mqevk-arm', disabling. Dependencies resolved. ===============================================================================================================  Package                  Arch                    Version                   Repository                    Size =============================================================================================================== Installing:  libfuse2                 aarch64                 2.9.7-r0                  @commandline                  56 k Transaction Summary =============================================================================================================== Install  1 Package Total size: 56 k Installed size: 212 k Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction   Preparing        :                                                                                       1/1   Installing       : libfuse2-2.9.7-r0.aarch64                                                             1/1   Running scriptlet: libfuse2-2.9.7-r0.aarch64                                                             1/1 /sbin/ldconfig: /usr/lib/libOpenVG.so is not a symbolic link   Verifying        : libfuse2-2.9.7-r0.aarch64                                                             1/1 Installed:   libfuse2.aarch64 2.9.7-r0 Complete!

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.

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

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

This document provides the steps to patch and build a fastboot Linux System. This document assumes the BSP 3.0.35_1.1.0 and a  i.MX6Q platform. For more information about what the patches do, please check this link. Install LTIB and move to the ltib folder Download the ltib patch from this document and patch it (patch -p1 < 0001-set-imx6_ssd_lite_defconfig-as-default-kernel-config.patch) Go to the LTIB configuration menu (./ltib -m config), select mx6q platform and min profile Select mx6q_sabresd as u-boot board Fetch and Patch: u-boot: Prepare u-boot source code (./ltib -m prep -p u-boot) Move to u-boot folder (cd rpm/BUILD/u-boot-2009.08) Download u-boot attached patches Patch code (for p in *.patch; do patch -p1 < $p;done) kernel: Prepare kernel source code (./ltib -m prep -p kernel) Move to kernel folder (cd rpm/BUILD/linux) Download attached kernel patches Patch code (for p in *.patch; do patch -p1 < $p;done) Build  (./ltib) Add  an application to run first after boot in rootfs/etc/inittab (see example inittab file, it captures data from the MIPI Camera) Create necessary devices nodes under rootfs/dev. For example terminal: sudo mknod ttymxc0 c 207 16 video capture nodes: sudo mknod video0 c 81 5; sudo mknod video1 c 81 6 video display nodes: sudo mknod video16 c 81 0; sudo mknod video17 c 81 1 frame-buffers: for i in 0 1 2 3 4; do sudo mknod fb$i c 29 $i; done Package rootfs (cd rootfs; sudo tar --numeric-owner -cvfj ../rootfs.tar.bz2 *; cd ..) On a windows machine, download latest Manufacturing tool and uncompress it. Move rootfs.tar.bz2, rootfs/boot/uImage and rootfs/boot/u-boot.bin into the corresponding Manufacturing folder (Profiles\MX6Q Linux Update\OS Firmware\files) Choose a sabresd-eMMC profile and flash the board Boot the board using the eMMC

目录 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