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

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

This document shows the necessary steps to configure the Eclipse IDE for development of Yocto applications. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release or Freescale Community BSP. For this example we'll use the Freescale BSP Release L3.14.28 but you may use the FSL Community BSP. - Freescale Community BSP FSL Community BSP - Freescale BSP Release  Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… 3) Poky Meta Toolchain (Poky 1.7 / L3.14.28 for our example but you should use the toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document. Task #7 - Create the toolchain 4) Eclipse Luna. We’ll use the Luna SR2 (4.4.2) version of the Eclipse IDE. You may find it on the following website: http://www.eclipse.org/downloads/packages/release/luna/sr2 Look for the “Eclipse IDE for C/C++ Developers”, which contains the Eclipse Platform, the Java Development Tools (JDT), and the Plug-in Development Environment. Once you have downloaded the tarball extract it. The following command unpacks and installs the downloaded Eclipse IDE tarball into a clean directory using the default name eclipse:      $ cd ~      $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz Configuring the Eclipse IDE Once with Eclipse Luna installed you may run the Eclipse IDE with the following command: $ cd eclipse $ ./eclipse Select a new workspace. Chose "Install New Software" from the "Help" pull-down menu. Select the "Luna - http://download.eclipse.org/releases/luna" Find and expand the Linux Tools option and select: Linux Tools LTTng Tracer Control Linux Tools LTTng Userspace Analysis LTTng Kernel Analysis If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Find and expand the Mobile and Device Development and select the following:   C/C++ Remote Launch (Requires RSE Remote System Explorer)   Remote System Explorer End-user Runtime   Remote System Explorer User Actions   Target Management Terminal (Core SDK)   TCF Remote System Explorer add-in   TCF Target Explorer If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Expand Programming Languages and select:   C/C++ Autotools Support   C/C++ Development Tools Chose Next and accept the necessary EULA Clck on the Finish button. The selected packages will be downloaded and installed. You will be asked to restart Eclipse IDE to finish the installation. Adding the Yocto Plug-in to the Eclipse IDE Next step is to install the Eclipse Yocto Plug-in into the Eclipse IDE. We'll show how to install the pre-built plug in. Start the Eclipse IDE In Eclipse, select "Install new Software" from the "Help" menu Click the "Add..." button to add a repository and enter: Name: Any name, we will use Yocto Fio Location: http://downloads.yoctoproject.org/releases/eclipse-plugin/1.8/luna Click "Ok" and then chose this new repository on the "Work with" drop-down menu and select the following plug-ins from the list:   Yocto Project ADT Plug-in   Yocto Project Bitbake Commander Plug-in   Yocto Project Documentation plug-in Install these plug-ins and click "OK" when prompted about installing software that contains unsigned content. You may be asked to restart the Eclipse IDE. Configuring the Eclipse Yocto Plug-in With all the necessary packages installed we'll now configure the Eclipse Yocto Plug-in. In this steps we will configure the Cross Compiler options and the Target options. These will then be used as default for your projects from within your working workspace. Select "Preferences" from the "Window" menu. Click on Yocto Project ADT from the left options and then under Cross Compiler Options select the Standalone pre-built toolchain radio button. We need to point to the Toolchain Root location of our installed toolchain. This is covered on the following community document: Task #7 - Create the toolchain In this case we'll be using poky 1.7 tollchain which has the following default location: /opt/poky/1.7 As fo the Sysroot Location this would correspond to your build directory sysroot folder, which is located on the following path: <YOCTO_BSP_DIR>/<BUILD_DIR>/tmp/sysroots/<MACHINE> In our case our Tartget architecture would be the Cortex-A9, which correspond to the i.MX6 and which is also the only option installed on the chosen directory. For Target Options we would be using the actual HW in order to test our application so keep the External HW option selected. Creating a Hello World Project We are now ready to create our project. Just to test our configuration we'll create a Hello World project.We can do so by selecting File->New->C Project or C++ Project We must then select a Project name and in project type we can chose either an Empty project or as in our case a Hello World Project, all this under the Yocto Project ADT Autotools Project folder. We will have the GNU Autotools Tolchain selected. The next screen will show some of the Basic Properties for our project, including the GNU license. Fill these as required. You may clock on Finish at this point. We should see that the HelloWorld project was created. We should right-click on the project folder and then chose Reconfigure Project in order to fill the necessary libraries. After this is completed we can build our project either by choosing the hammer icon or in the Build Project option inside the Project menu. We can look for correct competition or any errors or warning on the Console tab. Further Application Development After this basic setup you may work on more complex examples like a GPU and a Gstreamer Application examples on the following nicely written document: Yocto Application Development Using Eclipse IDE

Test digital zoom with ipu for camera preview.   Board :sarbre-sd (imx6dq) BSP   : android 13.4ga In the above flow, one frame buffer is processed in four steps at camera preview. Add the step to change the frame buffer before step 4 , the added step which  zoom one preview frame.   The figure below shows the crop function of ipu lib, we use this function scale the frame.   Test result: preview zoom levle 0:   preview zoom level max:     When taking pictures with 5M pixels and the zoom is over level 1, the picture size is not 2592x1944 but 2016x1512. The underlying reason for it is that ipu crop function only supports the 2048x2048 maximum output .   Thumbnails of test result :  

I've done some research in Android boot optimization in the past months and have some getting. This page is for recording and sharing purpose only. It's target to provide some hints and directions for Android optimization. It's NOT a Freescale official document or patch release. The code/doc inside is only for reference. Background:      1. I've used SabreSD + Android KK 4.4.2 GA 1.0 as a reference platform.      2. I'm not doing some popular optimization way such as "hibernation", "suspend". I'm trying to "optimize" the boot process by re-arranging the boot process and make GUI related process run earlier and fine tune some boot code for running faster.      3. It's target to the Android IVI product. So, some features that will never be used in a IVI environment will be disabled or removed. Minor of them. I've come out with a patch package (latest is milestone 4 which is "_m4" in the version for short) and  a training document. I didn't find any confidential information from the patch or doc, so I'm open the sharing here. Updated on 2016/01/08 for new version (milestone m5): --------------------------------------------------------------------------------------- Change log against previous (milestone 4) version:      1. BSP base changed to Android KK 4.4.3 GA 2.0 which has a Linux kernel 3.10.53      2. Linux kernel and uboot optimization added. Kernel boot time (POR -> Android init entry) is less than 1.5s.      3. Some bug fixes.      4. Document updated accordingly. Total boot time tested on SabreSDP is about 8s.

System Memory Usage and Configuration Introduction This document describes i.MX android memory usage, layout and configuration for the entire system. Total DDR memory usage When i.MX Android is running, the DDR memory will be used by the following components: Linux Kernel reserved space, including: kernel text, data section and initrd kernel page tables       Normal zone space managed by kernel’s MM (high memory zone is also included) Used by application by brk() or malloc() in libc Used by kernel by mm api, like: kmalloc, dma_alloc, vmalloc       Reserved memory for GPU drivers, used by GPU libs, drivers Android surface view, normal surface buffers VPUs working buffer and bitstream (we allocate the VPU buffer from GPU driver to make a unify method of allocation) Reserved space for framebuffer BG triple buffers Framebuffer display are always required to have triple and large buffers       Memory layout The following diagram shows the default memory usage and layout on i.MX6Q/DL platform. Memory configuration According to different type of product and different hardware configurations (ddr size, screen resolution, camera), customer may do some configurations to the memory layout and usage to optimize their system. Some memory reservation can be configured by command line or modifying the code. The kernel reserved space cannot be adjusted. It is controlled by the kernel and the Normal zone size and it depends on the total DDR size and the reserved spaces. Reserved GPU memory size can be adjusted by adding "gpumem=" parameters in kernel commandline. It's size is highly depends on the screen resolution, the video stream decoding requirement and the camera resolution, fps. gpumem=<size>M Reserved memory size for BG (background) framebuffer can be configured by command line fbmem=<fb0 size>,<fb2 size>,<fb4 size>,<fb5 size> For example: If you have two display devices, one is XGA LVDS, the other is HDMI 1080p device (default 32bpp), you have to specify the BG buffer size for them: fbmem=10M,24M The size is calculated by xres*yres*bpp*3: 10M ~= 1024x768x4(32bpp)x3(triple buffer) 24M ~= 1920x1080x4(32bpp)x3(triple buffer)

1. To setup the Yocto environment, from the BASE folder run fsl-community-bsp $ . setup-environment build 2. Build the toolchain build $ bitbake meta-toolchain # Other toolchains: # Qt Embedded toolchain build: bitbake meta-toolchain-qte # Qt X11 toolchain build: bitbake meta-toolchain-qt 3. Install it on your PC build $ sudo sh \   tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-<version>.sh 4. Setup the toolchain environment build $ source \   /opt/poky/<version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi 5. Get the Linux Kernel's source code. $ git clone git://git.freescale.com/imx/linux-2.6-imx.git linux-imx $ cd linux-imx 6. Create a local branch linux-imx $ BRANCH=imx_3.0.35_4.0.0 # Change to any branch you want,   # Use 'git branch -a' to list all linux-imx $ git checkout -b ${BRANCH} origin/${BRANCH} 7. Export ARCH and CROSS_COMPILE linux-imx $ export ARCH=arm  linux-imx $ export CROSS_COMPILE=arm-poky-linux-gnueabi- linux-imx $ unset LDFLAGS 8. Choose configuration and compile linux-imx $ make imx6_defconfig  linux-imx $ make uImage  9. To Test your changes, copy the `uImage` into your SD Card linux-imx $ sudo cp arch/arm/boot/uImage /media/boot 10. If case you want your changes to be reflected on your Yocto Framework, create the patches following the document i.MX Yocto Project: How can I patch the kernel?

Low power demo on i.MX8MM.   9/28/2020: Attachments updated. 1. Fix a bug in 5.4.24 kernel that system can only wakeup once. 2. Remove 0x104 from atf patch. On 5.4.24, tested OK without PLL2.   9/8/2020: Attachments updated. Add patches for 5.4.24 kernel.   We use it to test power consumption on i.MX8MM EVK.   Usage: 1. Kernel: echo "mem" > /sys/power/state   2. M4: Select a power mode from menu and wait for wakeup. Default wakeup method is GPT.   Add more patches, which will add functions for the case: 1. M core RUN and A core in suspend with DDR OFF. 2. M core wakeup A core without DDR support.   Descriptions: freertos_lowpower.zip. A simple freertos example for M4 RUN when A core in DSM. Generally, we use MU_TriggerInterrupts(MUB, kMU_GenInt0InterruptTrigger); to do wakeup. low_power_demo.zip A simple baremetal example for M4 RUN when A core in DSM. Generally, we use MU_TriggerInterrupts(MUB, kMU_GenInt0InterruptTrigger); to do wakeup. Note that the freertos version will have more options in menu. atf patch: Allow A53 to enter fast-wakeup stop when M4 RUN. Also avoid bypass of some plls, which is important to make M4 RUN when A53 enters suspend. 0001-iMX8MM-GIR-wakeup.patch: GIR wakeup patch for kernel. Need kernel to use fsl-imx8mm-evk-m4.dtb. 0002-Don-t-keep-root-clks-when-M4-is-ON.patch. Don't keep root clocks when M4 is ON. 0001-plat-imx8mm-keep-the-necessary-clock-enabled-for-rdc.patch. There's a design issue that when wakeup from DSM, described in patch: "if NOC power down is enabled in DSM mode, when system resume back, RDC need to reload the memory regions config into the MRCs, so PCIE, DDR, GPU bus related clock must on to make sure RDC MRCs can be successfully reloaded." Note that this patch will keep PCIE, DDR and GPU clock on, which will increase the power. An optimization will be decrease PCIE, DDR and GPU clock before entering DSM.   Power measurement: Supply Domain Voltage(V) I(mA) P(mW) peak avg peak avg peak avg VDD_ARM(L6) 1.010029 1.009513 1.109 1.030 1.120 1.039 VDD_SOC(L5) 0.855199 0.854857 190.110 189.973 162.582 162.400 VDD_GPU_VPU_DRAM(L10) 0.977240 0.977050 19.865 19.800 19.413 19.346 NVCC_DRAM(L15) 1.094407 1.094168 2.059 1.984 2.253 2.171 Total         185.367 184.956   Notes: This power measurements is got by putting Cortex-A in DSM and Cortex-M in RUNNING. In other tests, if M core can be put to STOP mode, additional power can be saved (5 - 20mA in VDD_SOC). From the table, we can see that by putting DDR to retain, a lot of power can be saved in VDD_SOC and NVCC_DRAM.

Default Ethernet feature is removed for Android Auto (both Android_Pie9.0 and Android10) Below are the patched to bring Ethernet feature back to Android Auto. Please try to apply the according patches if you want to enable Ethernet. For Android_Pie9.0_Auto(example with car2 build): --- a/arch/arm64/configs/android_car2_defconfig +++b/arch/arm64/configs/android_car2_defconfig @@ -245,7 +245,7 @@ CONFIG_DM_VERITY_FEC=y CONFIG_NETDEVICES=y CONFIG_MACVTAP=m CONFIG_TUN=y -# CONFIG_ETHERNET is not set +CONFIG_ETHERNET=y CONFIG_MDIO_BUS_MUX_MMIOREG=m CONFIG_AT803X_PHY=m CONFIG_MARVELL_PHY=m @@ -517,7 +517,7 @@ CONFIG_SQUASHFS=y CONFIG_SQUASHFS_DECOMP_MULTI=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_LZ4=y -# CONFIG_NETWORK_FILESYSTEMS is not set +CONFIG_NETWORK_FILESYSTEMS=y   --- a/imx8q/mek_8q/mek_8q.mk +++ b/imx8q/mek_8q/mek_8q.mk @@ -46,6 +46,7 @@ PRODUCT_COPY_FILES += \      $(IMX_DEVICE_PATH)/fstab.freescale.car:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.freescale \      $(IMX_DEVICE_PATH)/early.init_car.cfg:$(TARGET_COPY_OUT_VENDOR)/etc/early.init.cfg \      $(IMX_DEVICE_PATH)/required_hardware_auto.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/required_hardware.xml \ +    frameworks/native/data/etc/android.hardware.ethernet.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.ethernet.xml \      device/fsl/imx8q/init.recovery.freescale.car.rc:root/init.recovery.freescale.rc   For Android10_Auto,(example with car build): --- a/arch/arm64/configs/android_car_defconfig +++ b/arch/arm64/configs/android_car_defconfig @@ -23,6 +23,8 @@ CONFIG_SCHED_AUTOGROUP=y CONFIG_SCHED_TUNE=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y +CONFIG_FEC=y +CONFIG_AT803X_PHY=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set @@ -246,7 +248,6 @@ CONFIG_DM_VERITY=y CONFIG_DM_VERITY_FEC=y CONFIG_NETDEVICES=y CONFIG_TUN=y -# CONFIG_ETHERNET is not set   --- a/imx8q/mek_8q/mek_8q.mk +++ b/imx8q/mek_8q/mek_8q.mk @@ -46,6 +46,7 @@ PRODUCT_COPY_FILES += \      $(IMX_DEVICE_PATH)/fstab.freescale.car:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.freescale \      $(IMX_DEVICE_PATH)/early.init_car.cfg:$(TARGET_COPY_OUT_VENDOR)/etc/early.init.cfg \      $(IMX_DEVICE_PATH)/required_hardware_auto.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/required_hardware.xml \ +    frameworks/native/data/etc/android.hardware.ethernet.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.ethernet.xml \      device/fsl/imx8q/init.recovery.freescale.car.rc:root/init.recovery.freescale.rc   Note: Please also check for below file, if fec1 is disabled, please also apply below diff. --- a/arch/arm64/boot/dts/freescale/imx8qm-mek-car2.dts +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek-car2.dts @@ -147,10 +147,6 @@ status = "disabled"; }; -&fec1 { - status = "disabled"; -}; - &fec2 { status = "disabled"; };

What is a device tree? The device tree is a data structure that is passed to the Linux kernel to describe the physical devices in a system. Before device trees came into use, the bootloader (for example, U-Boot) had to tell the kernel what machine type it was booting. Moreover, it had to pass other information such as memory size and location, kernel command line, etc. Sometimes, the device tree is confused with the Linux Kernel configuration, but the device tree specifies what devices are available and how they are accessed, not whether the hardware is used. The device tree is a structure composed of nodes and properties: Nodes: The node name is a label used to identify the node. Properties: A node may contain multiple properties arranged with a name and a value. Phandle: Property in one node that contains a pointer to another node. Aliases: The aliases node is an index of other nodes. A device tree is defined in a human-readable device tree syntax text file such as .dts or .dtsi. The machine has one or several .dts files that correspond to different hardware configurations. With these .dts files we can compile them into a device tree binary (.dtb) blobs that can either be attached to the kernel binary (for legacy compatibility) or, as is more commonly done, passed to the kernel by a bootloader like U-Boot. What is Devshell? The Devshell is a terminal shell that runs in the same context as the BitBake task engine. It is possible to run Devshell directly or it may spawn automatically. The advantage of this tool is that is automatically included when you configure and build a platform project so, you can start using it by installing the packages and following the setup of i.MX Yocto Project User's Guide on section 3 “Host Setup”. Steps: Now, let’s see how to compile your device tree files of i.MX devices using Devshell. On host machine. Modify or make your device tree on the next path: - 64 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm64/boot/dts/freescale - 32 bits. ~/imx-yocto-bsp/<build directory>/tmp/work-shared/<machine>/kernel-source/arch/arm/boot/dts To compile, it is needed to prepare the environment as is mentioned on i.MX Yocto Project User's Guide on section 5.1 “Build Configurations”. $ cd ~/imx-yocto-bsp $ DISTRO=fsl-imx-xwayland MACHINE=<machine> source imx-setup-release.sh -b <build directory> $ bitbake -c devshell virtual/kernel (it will open a new window) On Devshell window. $ make dtbs (after finished, close the Devshell window) On host machine. $ bitbake -c compile -f virtual/kernel $ bitbake -c deploy -f virtual/kernel This process will compile all the device tree files linked to the machine declared on setup environment and your device tree files will be deployed on the next path: ~/imx-yocto-bsp/<build directory>/tmp/deploy/images/<machine> I hope this article will be helpful. Best regards. Jorge.

Hi all, I shared my test results and solutions in attachments. Best regards, Carl

Q: How to get the CSI BT656 without HSYNC/VSYNC working. The problem, is that all implemented driver in the BSP are using the external HSYNC/VSYNC synchronization signal. The SW designer is actually struggling to find the right way to generate the end of field active interrupt (end of frame). > mxc_v4l2_still.out I get an: > ERROR: v4l2 capture: mxc_v4l_read timeout counter 0 > > When using mxc_v4l2_capture.out or mxc_v4l2_tvin.out I get an: > ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 > To help him implementing the driver, I need to get some insight on the IPUx_CSIn_CCIR_CODE_1/2/3 as it seems that the bit description 21 to 19 (CSI_STRT_FLD0_ACTV) is not described (same for all the multiple bit field in this register. Maybe it should match the ITU656, but here as well the driver examples does not match the bit description of the ITU standard. So my questions: IS it really possible to implement the BT656 with SAV / EAV and without external HSYNC/VSYNC? If yes, is it possible to review the IPUx_CSIn_CCIR_CODE_1/2/3 fields and communicate which parameter should be provided here? i.MX6Q A:      For no VSYNC and HSYNC case, in the sensor driver such as "linux-3.0.35\drivers\media\video\mxc\capture\adv7180.c", function ioctl_g_ifparm(), you should set p->u.bt656.bt_sync_correct to 0;      p->u.bt656.bt_sync_correct = 1; // It means external VSYNC and HSYNC will be used for SYNC.      p->u.bt656.bt_sync_correct = 0; // No external VSYNC and HSYNC, embedded EAV and SAV will be used for SYNC.      In iMX6 BSP, the CCIR related code is ready in "linux-3.0.35\drivers\mxc\ipu3\ipu_capture.c", function ipu_csi_init_interface(), no code modification was needed, that code was verified work.      For BT656 mode, your sensor driver such as adv7180, should also report correct parameters in function function ioctl_g_ifparm().      p->u.bt656.clock_curr = 0;  // This will tell linux-3.0.35\drivers\media\video\mxc\capture\mxc_v4l2_capture.c to use "IPU_CSI_CLK_MODE_CCIR656_INTERLACED" in function mxc_v4l2_s_param().      The current iMX6 BSP mxc_v4l2_capture.c driver doesn't support BT656 progressive mode, it only supports BT656 interlace mode. To support BT656 progressive mode, the customer should modify the code in mxc_v4l2_s_param(), let csi_param.clk_mode = IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE. This is exactly what they are doing, but still it doesn’t work. Actually, they see the code being executed following the right steps in the ipu_csi_init_interface() going through PAL 720x625 configuration. But still, they get the timeout! else if (cfg_param.clk_mode == IPU_CSI_CLK_MODE_CCIR656_INTERLACED) {       if (width == 720 && height == 625) {         /* PAL case */         /*         Field0BlankEnd = 0x6, Field0BlankStart = 0x2,         Field0ActiveEnd = 0x4, Field0ActiveStart = 0           */         ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_1);         /*         Field1BlankEnd = 0x7, Field1BlankStart = 0x3,         Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1           */         ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_2);         ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3); So, I believe the parameters are wrong. What could be missing. Can you review the driver? For me it looks like the adv example, except the bt_sync_correct=0, which is what we want. You can suggest the customer to capture the CSI data bus to check if there is correct output from sensor, such as EAV/SAV. For the "timeout" error, it always means there is no correct data on CSI data bus. This document was generated from the following discussion: CSI BT656

Note: All these gstreamer pipelines have been tested using a i.MX6Q board with a kernel version 3.0.35-2026-geaaf30e. Tools: gst-launch gst-inspect FSL Pipeline Examples: GStreamer i.MX6 Decoding GStreamer i.MX6 Encoding GStreamer Transcoding and Scaling GStreamer i.MX6 Multi-Display GStreamer i.MX6 Multi-Overlay GStreamer i.MX6 Camera Streaming GStreamer RTP Streaming Other plugins: GStreamer ffmpeg GStreamer i.MX6 Image Capture GStreamer i.MX6 Image Display Misc: Testing GStreamer Tracing GStreamer Pipelines GStreamer miscellaneous

It is based on 3.0.35 GA 4.1.0 BSP.   0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch It is the updated IPU code for MIPI ID and SMFC setting in ipu_capture.c. These setting should not be combined with MIPI virtual channel value, they shoule be fixed with ID 0.   0002-Use-virtual-channel-3-for-ov5640-mipi-camera-on-iMX6.patch The sample code to modify ov5640_mipi camera to use virtual channel 3 on SabreSD board.   The followed command can be used to verify the mipi camera function after booted into Linux: $ gst-launch mfw_v4lsrc capture-mode=1 device=/dev/video1 ! mfw_v4lsink     2014-09-30 update: Added the patch for 3.10.17_GA1.0.0 BSP. "L3.10.17_1.0.0_mipi_camera_virtual_channel_3.zip"  

Overview As more and more communication required between online and offline, the QR code is widely used in the mobile payment, mobile small apps, industry things identification and etc. The i.MX6UL/ULL has the IP of CSI and PXP for camera connection and image CSC/FLIP/ROTATION acceleration. A LCDIF IP is supporting the display, but no 3D IP support. This means this low power and low end AP is very suitable for the industry HMI segment, which does not require a cool 3D graphic display, but a simple and straightforward GUI for interaction. QR code scanner is one of the use cases in the industry segment, which more and more customer are focusing on. The i.MX6UL CPU freq of i.MX6UL is about 500Mhz, and it does not have GPU IP, so a lightweight GUI and window system is required. Here we recommend the QT with wayland backend (without X11), which would make the window system small and faster than traditional X11 UI. Why chose QT is because of it has open source version, rich components, platform independent, good performance for embedded system and strong development staffs like QtCreator for creating application. How to enable the QT development environment, check this: Enable QT developement for i.MX6UL (v2)  Here I made a QR code scanner demo based on QT5.6 + QZXing (QR/Bar code scan engine) running on the i.MX6UL EVK board with a UVC camera (at least 640x480 resolution is required) and 480x272px LCD. Source code is open here (License Apache2.0): https://github.com/muddog/QRScanner  Implementation To do camera preview and capture, you must think on the gstreamer first, which is easy use and has the acceleration pads which implemented by NXP for i.MX6UL. Yes, it's very easy for you to enable the preview in console like: $ gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw,format=YUY2,width=640,height=320 ! imxvideoconvert_pxp ! video/x-raw,format=RGB16 ! waylandsink It works under the i.MX6UL EVK, with PXP IP to do color space convert from YUY2 -> RGB16 acceleration, also the potential scaling of the image. The CPU loading of this is about 20-30%, but if you use the component of "videoconvert" to replace the "imxvideoconvert_pxp", we do CSC and scale by CPU, then the loading would increase to 50-60%. The "/dev/video1" is the device node for UVC camera, it may different in your environment. So our target is clear, create such pipeline (with PXP acceleration) in the QT application, and use a appsink to get preview images, do simple "sink" to one QWidget by drawing this image on the widget surface for preview (say every 50ms for 20fps). Then in other thread, we fetch the preview buffer in a fixed frequency (like every 0.5s), then feed it into the ZXing engine to decode the strings inside this image. Here are the class created inside the source code: ScannerQWidgetSink It act as a gstreamer sink for preview rendering. Init the pipeline, create a timer with timeout every 50ms. In the timer handler, we use appsink to copy the camera buffer from gstreamer, and tell the ViewfinderWidget to do update (re-draw event). ViewfinderWidget This class inherit from the QWidget, which draw the preview buffer as a QImage onto it's own surface by using QPainter. The QImage is created at the very begining with the image buffer created by the ScannerQWidgetSink. Because QImage itself does not maintain the image buffer, so the buffer must be alive during it's usage. So we keep this buffer during the ScannerQWidgetSink life cycle, copy the appsink buffer from pipeline to it for preview. MainWindow Create main window, which does not have title bar and border. Start any animation for the red line scan bar. Create instance of DecoderThread and ScannerQWidgetSink. Setup and start them. DecoderThread A infinite loop, to wait for a available buffer released by the ScannerQWidgetSink every 0.5s. Copy the buffer data to it's own buffer (imgData) to avoid any change to the buffer by sink when doing decoding. Then feed this copy of buffer into ZXing engine to get decoder result. Then show on the QLabel. Screenshot under wayland (weston) desktop: Customize Camera instance Now I use the UVC camera which pluged in the USB host, which device node is /dev/video1. If you want to use CSI or other device, please change the construction parameters for ScannerQWidgetSink(): sink = new ScannerQWidgetSink(ui->widget, QString("v4l2src device=/dev/video1")); Image resolution captured and review Change the static member value of ScannerQWidgetSink class: uint ScannerQWidgetSink::CAPTURE_HEIGHT = 480; uint ScannerQWidgetSink::CAPTURE_WIDTH = 640; Preview fps and decoding frequency Find the "framerate=20/1" strings in the ScannerQWidgetSink::GstPipelineInit(), change to your fps. You also have to change the renderTimer start timeout value in the ::StartRender(). The decoding frequency is determined by renderCnt, which determine after how many preview frames showed to feed the decoder. Main window size It's fixed size of main window, you have to change the mainwindow.ui. It's easy to do in the QtCreate Designer. FAQ Why not use CSI camera in demo? Honestly, I do not have CSI camera module, it's also DNP when you buying the board on NXP.com. So a widely used UVC camera is preferred, it's also easy for you to scan QR code on your phone, your display panel etc. Why not use QCamera to do preview and capture? The QCamera class in the Qtmultimedia component uses the camerabin2 gstreamer plugin, which create a very long pipeline for different usage of viewfinder, image capture and video encoder. Camerabin2 would eat too much CPU and memory resource, take picture and recording are very very slow. The preview of 30fps would eat about 70-80% CPU loading even I hacked it using imxvideoconvert_pxp instread of software videoconvert. Finally I give up to implement the QRScanner based on QCamera. How to make sure only one instance of QT app is running? We can use QSharedMemory to create a share memory with a unique KEY. When second instance of app is started, it would check if the share memory with this KEY is created or not. If the shm is there, it means there's already one instance running, it has to exit(). But as the QT mentioned, the QSharedMemory can not be destroyed correctly when app crashed, this means we have to handle each terminate signal, and do delete by ourselves: static QSharedMemory *gShm = NULL; static void terminate(int signum) {    if (gShm) {       delete gShm;       gShm = NULL;    }    qDebug() << "Terminate with signal:" << signum;    exit(128 + signum); } int main(int argc, char *argv[]) {    QApplication a(argc, argv);    // Handle any further termination signals to ensure the    // QSharedMemory block is deleted even if the process crashes    signal(SIGHUP, terminate ); // 1    signal(SIGINT, terminate ); // 2    signal(SIGQUIT, terminate ); // 3    signal(SIGILL, terminate ); // 4    signal(SIGABRT, terminate ); // 6    signal(SIGFPE, terminate ); // 8    signal(SIGBUS, terminate ); // 10    signal(SIGSEGV, terminate ); // 11    signal(SIGSYS, terminate ); // 12    signal(SIGPIPE, terminate ); // 13    signal(SIGALRM, terminate ); // 14    signal(SIGTERM, terminate ); // 15    signal(SIGXCPU, terminate ); // 24    signal(SIGXFSZ, terminate ); // 25    gShm = new QSharedMemory("QRScannerNXP");    if (!gShm->create(4, QSharedMemory::ReadWrite)) {       delete gShm;       qDebug() << "Only allow one instance of QRScanner";       exit(0);    } .....

One of the new feature of  the i.MX8 family is to support CAN FD. Fortunately the MEK board has a TJA1043 supporting CAN FD. The following document show you how to do simple CAN (FD) test under Linux. First of all let configure the CAN0 to be at 500kps in CAN, and 4Mbps in CAN FD: ip link set can0 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on ‍‍‍‍‍‍‍ Let's do the same for CAN1: ip link set can1 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on‍‍‍‍ Now you can do a bridge between CAN0 and CAN1 on the board. The easiest way is to put simple wires (pin 2 to pin 2 a,d pin 7 to pin 7), normally you have to twist your wires, but as it is on your desk, you can get rid of it): You can check the configurations of your FlexCAN: root@imx8qxpmek:~# ip -details link show can0 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 link/can promiscuity 0 can <FD> state ERROR-WARNING (berr-counter tx 0 rx 0) restart-ms 0 bitrate 500000 sample-point 0.750 tq 25 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 flexcan: tseg1 2..64 tseg2 1..32 sjw 1..32 brp 1..1024 brp-inc 1 dbitrate 4000000 dsample-point 0.800 dtq 25 dprop-seg 3 dphase-seg1 4 dphase-seg2 2 dsjw 1 flexcan: dtseg1 1..39 dtseg2 1..8 dsjw 1..8 dbrp 1..1024 dbrp-inc 1 clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 root@imx8qxpmek:~# ip -details link show can1 4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 link/can promiscuity 0 can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 bitrate 500000 sample-point 0.750 tq 25 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 flexcan: tseg1 2..64 tseg2 1..32 sjw 1..32 brp 1..1024 brp-inc 1 dbitrate 4000000 dsample-point 0.800 dtq 25 dprop-seg 3 dphase-seg1 4 dphase-seg2 2 dsjw 1 flexcan: dtseg1 1..39 dtseg2 1..8 dsjw 1..8 dbrp 1..1024 dbrp-inc 1 clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 root@imx8qxpmek:~#‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now a simple test can be to send random CAN FD messages, for that use "cangen" to send random CAN FD messages (read "cangen" documentation: https://manpages.debian.org/stretch-backports/can-utils/cangen.1.en.html 😞 root@imx8qxpmek:~# cangen can0 -v -b -g 20 can1 3E6 [00] can1 735 [20] F9 ED 40 53 AC CF 48 34 F9 ED 40 53 AC CF 48 34 F9 ED 40 53 can1 513 [20] 92 D2 E7 32 48 E6 EA 39 92 D2 E7 32 48 E6 EA 39 92 D2 E7 32 can1 03B [12] 6D 34 2F 11 52 8A 52 50 6D 34 2F 11 can1 47D [24] 72 08 88 0D E0 04 F7 09 72 08 88 0D E0 04 F7 09 72 08 88 0D E0 04 F7 09 can1 245 [00] can1 6F6 [48] B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 can1 1F4 [16] 03 5B 7C 00 DA E5 FA 03 03 5B 7C 00 DA E5 FA 03 can1 38A [48] 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 can1 4C9 [20] 6C 5A 98 54 DD D1 CB 09 6C 5A 98 54 DD D1 CB 09 6C 5A 98 54 can1 536 [48] 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 can1 308 [02] C3 57 can1 33E [05] 65 8C 7B 21 83 can1 3F5 [05] EA E0 07 63 EB can1 633 [03] 39 10 18 can1 25D [32] 01 4E 65 41 E8 4D 94 6F 01 4E 65 41 E8 4D 94 6F 01 4E 65 41 E8 4D 94 6F 01 4E 65 41 E8 4D 94 6F can1 2FB [03] A8 D8 E3 can1 0DE [04] A1 11 3F 32 can1 012 [06] 85 23 B2 07 1A 03 can1 658 [08] A0 8A 2D 67 97 79 A1 64 can1 37D [05] 1A 57 E8 4F 72 can1 70A [04] 5E 6A B8 0F can1 3A8 [07] 65 C5 48 76 05 B6 11 can1 5D4 [07] ED 03 A6 07 CF D8 DC can1 7DA [05] 94 18 50 09 B8 can1 7A9 [05] CC 5E 02 74 BC can1 3FC [01] D6 can1 599 [06] EB 23 02 61 16 D9 can1 47C [06] 88 20 F2 62 86 3B can1 30A [06] C4 98 57 61 B2 4E can1 57E [16] B8 04 86 5B 52 EB DF 45 B8 04 86 5B 52 EB DF 45 can1 191 [05] 22 C4 BC 26 6B can1 53B [06] 23 AA AA 00 E4 F4 can1 6EB [64] A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can check with a scope your CAN FD frame (here CAN High): And you can see the first part of the frame sent @500kps and the second part @4Mbps. If you unplug one wire, the messages will no longer be sent as no acknowlege will occurs. You can also send message without flexible datarate. In our case, we'll send long frame at 500kps (no more 4Mbps transfer for end of the frame): imx8qxpmek:~# cangen can0 -v -f -g 20 can0 6FE##0.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E can0 3E2##0.D4.9E.3D can0 1DE##0.D0.D8.33.50.7E.39 can0 7CE##0.FA.68.25.74.86.E7.E1.4A.FA.68.25.74.86.E7.E1.4A.FA.68.25.74 can0 7C3##0.58.E6.F2.1E.BD.7D.F8.7F can0 32A##0.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E can0 48B##0.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47 can0 3FC##0.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00 can0 4BE##0.7D.B0.E2.7E.A0.F0.DF.24.7D.B0.E2.7E can0 60C##0.0E can0 257##0.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65 can0 0BA##0.AB.B1.F8 can0 0FC##0.3A.7E.FB.34 can0 452##0.2F.4D.04.26.DE.80.EA can0 2C7##0.37.02.A4.4D.C3 can0 0B4##0.BE.39.AD.3B.73 can0 17E##0.13.66.44.6A.8A.8F.CE.7A.13.66.44.6A.8A.8F.CE.7A.13.66.44.6A‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can also force the CAN to only send CAN 2.0b frames (not FD, you'll have 8-byte data max frames): imx8qxpmek:~# cangen can0 -v -g 20 can0 7FF#8F.04.3F.31.EB can0 135#92.7C.46.5C.95.4E.6C.48 can0 0F8#E3.E4.7E.4D.92.2A.1D.69 can0 68F#C6.B7.BA.35.78.06 can0 4EC#D8.D9.86.19.40.BE.64.05 can0 09F#EE.E1.70.7D.13.C9.18.53 can0 7CE#BB.CD.FE.50.3E.B6.A4.4A can0 3C7#04 can0 1F6#B2.E4.4B.42 can0 080#C1.81.65.41 can0 14C#0B.B4.7E.5D can0 15A#53 can0 1CF#86.D4.ED.11.6E.BA.20.14 can0 257#82.83.39.67 can0 2C1#64.20.DF.0D.89.0E.14.55 can0 45E#50.72.44.76.55.4E.96.0F can0 6FC#80.81 can0 046#F6 can0 1E5#6D can0 0D2# can0 7EB#0F.3D.29.78.42.72.60.61 can0 480#68 can0 1CE#CB.05.12.74.2D.0E.F2.14 can0 634#82.5C.88.24.31.75.AF.03 can0 71D#AE.4C can0 144#F5.A8.17.70 can0 2A5#69.BE can0 222#18.C6.AA.4A.0D.5A.EC.48 can0 5FA#4F.CC.4C.2A.7B.BA.31 can0 3B9#BD.B1.2F.3C.87.D5.D1 can0 583#B4.E3.C3.4E.B8.D3.22.43‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Question: What exactly does the DTE/DCE interface in the i.MX6's UART module do and how are RTS and CTS affected by the UARTxUFCR[DTEDCE] bit? In i.MX6 RM, revision 1: Sections 64.2.1.2.1  (CTS) and 64.2.1.2.2 (RTS) both state that CTS and RTS change direction between DCE and DTE modes.  However, sections 64.4.3.1 (RTS_B) and 64.4.3.8 (CTS_B) state they do not change functions.  Is this a documentation error, or is there a difference between CTS/RTS and CTS_B/RTS_B? It appears that some of this is covered in the IOMUX daisy chain by switching which pins are connected to CTS and RTS. Answer: Example 1: UART1 in DTE mode. RTS is an output from the UART IP block so it must be routed to a CTS pin. Therefore, the SELECT_INPUT register could only use settings 00 or 10. Example 2: UART1 in DCE mode. RTS is an input to the UART IP block so it must be routed to an RTS pin. Therefore, the SELECT_INPUT register could only be set to 01 or 11. At this point, we have assumed that the internal signals connected to the UART block do not change direction.  We believe that DCEDTE from the UART block connects into the IOMUX logic and controls the direction of the PAD.  Then, the IOMUX INPUT_SELECT mux is used to choose one of four pads to connect to the UART inputs while the IMOUX MUX_CTRL connects the output path.  Further, we assume it is an error to connect the UART input to a pad configured as an output or a UART output to a pad configured as an input. The attached shows our assumptions For the Uart IP, the CTS_B is always an output and RTS_B always an input. But the RTS_B &CTS_B IO will be swapped  when UART operates in different DTE or DCE mode.  IO port DTE mode DCE mode direction Uart IP port(internal) direction Uart IP port(internal) UART_CTS_B O CTS_B I RTS_B UART_RTS_B I RTS_B O CTS_B UART_TXD O TXD I RXD UART_RXD I RXD O TXD Regarding how to configure the IOMUX, please see the attached PDF.

NFS and TFTP Boot 1  Introduction This document explains the required steps to boot Linux Kernel and mount a NFS on your target. 2 Requirements A functional Yocto environment (Images generated for your target). Your preferred target.  (SABRE-AI, SABRE-SD) 1 Ethernet Cable 1 Micro USB cable USB to Serial converter depending on your target features. 3 Yocto Folders When you develop your Linux kernel and Root File System with Yocto, different folders are created and each folder contains different information. {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  This directory contains the output images, like Kernel, U-Boot and the File System in a tar file. This directory will be used to fetch the kernel and device tree blob file only. {YOCTO_BUILD_DIR}/tmp/sysroot/{TARGET}/  This folder contains all the development files used to generate our Yocto images. Here we can find all the dynamic libraries and headers used for development. This folder is used as parameter for cross-compilation. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs This folder contains the uncompressed rootfs of our target. This folder will be used as entry in the host NFS server. 4 IP Address and Network Setup This section covers how to boot Linux that mounts the root file system (RFS) over the network. Remember that in this scenario, the RFS exists on the laptop hard drive, and the kernel that runs on the target board will mount the RFS over Ethernet. This setup is used for developing and debugging Linux applications. It allows for applications to be loaded and run without having to re-boot the kernel each time. First some packages on your host need to be installed: # apt-get install xinetd tftp tftpd isc-dhcp-server nfs-kernel-server portmap For development, it is best to have a static IP setup for the board and Linux environment. This way U-Boot options won’t change between reboots as you get a new IP address as you would using DHCP. 4.1 Linux Host Setup This section describes how to setup a static IP in your Linux host environment. This is not required but will allow the IP address of your virtual host system to remain unchanged. Because u-boot parameters use specific IP addresses, this step is recommended because u-boot parameters may need to be updated in the future to match your virtual IP address if it should ever change. You could take the existing IP address and make it static, but you would lose the Internet connection in your virtual machine. Instead we want to make use of the virtual environment and add a secondary Ethernet port that is tied to your wired Internet connection, while keeping the original Ethernet port which can use the wireless connection on your laptop. In the Linux virtual environment, type sudo ifconfig and note that you should have one Ethernet adapter (eth0). The other item listed (lo) is a virtual port for loopback mode. Shutdown the Linux virtual machine In VMware Player, go to Edit virtual machine settings. And add a Bridged Network Adapter, choosing only the wired Ethernet port. And click on OK.  See below for example: Start up the Linux VM. Open a terminal and type: sudo ifconfig You should have a new entry (eth1). This is the new Ethernet port you created in the virtual machine, and it is bridged to your wired Ethernet port. This is the port we want to make a static IP address. To set eth1 to a static IP, open /etc/nework/interfaces sudo gedit /etc/network/interfaces Add the following to set eth1 to your desired IP address. auto eth1 iface eth1 inet static address 192.168.0.100      <-- Your HOST IP netmask 255.255.255.0 gateway 192.168.0.1 Save the file Restart eth1 sudo ifdown eth1 sudo ifup eth1 4.2 Target Setup We need to setup the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters: setenv serverip 192.168.0.100 <-- This must be your Host IP address setenv ipaddr 192.168.1.102  <-- This must be your target IP addres setenv ip_dyn no The path where the rootfs is placed in our host has to be indicated in the U-Boot: setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs setenv image zImage setenv fdt_file uImage-imx6q-sabresd.dtb setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip={ipaddr} nfsroot=${serverip}:${nfsroot},v3,tcp' 4.3 TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. This is how U-Boot will download (via TFTP) the Linux kernel, and then the kernel will mount (via NFS) its root file system on the computer hard drive. 4.3.1 TFTP Setup Next setup the TFTP server. The following commands show that we are logged in as root (#). If you are not root ($) then precede each instruction with “sudo”. Edit /etc/xinetd.conf gedit /etc/xinetd.conf Add and save the following lines in the file service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  disable = no } Notice that {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/   has to be written as absolute path. Restart the xinetd service service xinetd restart Test that TFTP is working tftp localhost tftp> get {An Image found in the tftp folder} tftp> quit 4.3.2 NFS Setup Edit the /etc/exports file gedit /etc/exports Add the path where the rootfs is found in your host. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs *(rw,no_root_squash)                                                                 NOTE:      {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs may work most of the times,        but it is recommended to untar the {IMAGE}.bz2 in an exported           folder keeping using sudoand keeping the chmod of each file.     3. Restart the NFS service sudo service portmap stop sudo service nfs-kernel-server stop sudo service portmap start sudo service nfs-kernel-server start 5 Host Final Configuration and Booting Linux over NFS In your host, under the images folder {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/ create the below links ln -s zImage_imx_v7_defconfig zImage      2. In U-boot type the below command:                run netboot After a pair of minutes you should get a Linux working system on your target.

Introduction The NFC Reader Library is a feature complete software support library for NXP's NFC Frontend ICs. It is designed to give developers a faster and simpler way to deliver NFC-enabled products. This multi-layer library, written in C, makes it easy to create NFC based applications. The purpose of this document is to provide instructions on how to install the NFC Reader Library on imx7dsabresd and communicate with PN5180, a NFC frontend. It will describe all the steps required to connect the board to an OM25180TWR, the wire connections, the changes in the device tree, and the library configuration. Building the Linux image and the Bal kernel module This section describes how to build the Linux image using Yocto and how to compile the Bal kernel module. Informations specific for this library start from the next section. Requirements: a Linux host PC (ex. Ubuntu 14.04/16.04) and root permissions. To download the required host packages, use: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev Specific for Ubuntu: $ sudo apt-get install libsdl1.2-dev xterm sed cvs subversion coreutils texi2html docbook-utils python-pysqlite2 help2man make gcc g++ desktop-file-utils \ libgl1-mesa-dev libglu1-mesa-dev mercurial autoconf automake groff curl lzop asciidoc To setup the repo utility (a tool written on top of git), run the commands: $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo Then add the following line to .bashrc to ensure the ~/bin is in the PATH variable. export PATH=~/bin:$PATH To download the Freescale Yocto Project Community BSP: $ mkdir fsl-release-bsp $ cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth $ repo sync To build the image, in the fsl-release-bsp run the commands: $ mkdir buildDevSpi $ DISTRO=fsl-imx-xwayland MACHINE=imx7dsabresd source fsl-setup-release.sh -b buildDevSpi $ bitbake fsl-image-machine-test To build the toolchain, run: $ bitbake meta-toolchain $ cd buildDevSpi/tmp/deploy/sdk/ $ ./fsl-imx-xwayland-glibc-x86_64-meta-toolchain-cortexa7hf-neon-toolchain-4.1.15-2.1.0.sh Accept the default parameters. In order to deploy the image on an SD card use: $ sudo dd if=fsl-image-machine-test-imx7dsabresd.sdcard of=<sd card> bs=1M && sync The image is found in buildDevSpi/tmp/deploy/images/imx7dsabresd. For the kernel module compilation, setup the console environment: $ . /opt/fsl-imx-xwayland/4.1.14-2.1.0/environment-setup-cortexa7hf-neon-poky-linux-gnueabi Then, in the kernel module directory, replace the path with your linux build directory in the Makefile and run: $ make The bal.ko is the compiled module. To use the kernel menuconfig, run: $ bitbake -c menuconfig linux-imx Another useful command, for rebuilding the linux kernel image, is: $ bitbake -f -c compile linux-imx; bitbake -f -c deploy linux-imx; bitbake -f -c compile fsl-image-machine-test; bitbake -f fsl-image-machine-test Host interface The interface of the PN5180 to a host is based on a SPI interface, extended by the signal line BUSY. Only half-duplex data transfer is supported and no chaining is allowed, meaning that the whole instruction has to be sent, or the whole receiver buffer has to be read out. The module is connected to the i.MX7D board using the mikro bus expansion port in the following way: MK_BUS_CS, MK_BUS_SCK, MK_BUS_MOSI, MK_BUS_MISO are used for the SPI bus lines. MK_BUS_INT, MK_BUS_RX, MK_BUS_TX are used for the BUSY, RESET and IRQ lines. The pin configuration will be the following: GPIO6_IO22 will be the CS, GPIO6_IO14 will be BUSY, GPIO_IO12 will be RESET and GPIO_IO13 will be IRQ. The DWL pin, which can be used for firmware update, will be connected to GND. A common ground is also required. Connections table: Jumper Jumper Pins Description i.MX7D I/O Tower Edge J4 1 - 2 SPI Clk Selection ECSPI3_SCLK (SAI2_RX_DATA) B7 J20 1 - 2 PN5180 Reset GPIO6_IO12 (SAI1_RX_DATA) B8 J1 1 - 2 SPI SS0 GPIO6_IO22 (SAI2_TX_DATA) B9 J3 1 - 2 SPI MOSI ECSPI3_MOSI (SAI2_TX_BCLK) B10 J2 1 - 2 SPI MISO ECSPI3_MISO (SAI2_TX_SYNC) B11 J19 2 - 3 PN5180 BUSY GPIO6_IO14 (SAI1_TX_SYNC) B58 J5 1 - 2 PN5180 IRQ GPIO6_IO13 (SAI1_TX_BCLK) B62 X X PN5180 DWL GND B52 X X GND GND B2 Kernel Configuration In order to allow the library to manage the RESET, IRQ and BUSY pins, the options for Debug GPIO and Userspace I/O drivers must be enabled (in menuconfig, Device Drivers -> GPIO Support -> Debug GPIO and Device Drivers -> Userspace I/O -> Userspace I/O platform driver with generic IRQ). For controlling the SPI, there are two options: spidev or NXP bal. For spidev, it is necessary to select Device Drivers -> SPI support -> User mode SPI and apply the imx7d-sdb_spidev.patch (it also does the pinmuxing, it is attached to the document). When using NXP bal, it is necessary to compile the module, initialize it with insmod and apply the imx7d-sdb_bal.patch (it also does the pinmuxing, the patch and the module are attached to this document). Library Configuration For the library configuration, <lib-folder>/Platform/DAL/Board_Imx6ulevkPn5180.h must be replaced with Board_Imx7dsabresdPn5180_bal.h or Board_Imx7dsabresdPn5180_spidev.h (based on the selected spi interface). For compilation, the command is: $ ./build.sh yocto /opt/fsl-imx-xwayland/4.1.15-2.1.0/sysroots/ The last parameter is the location of the toolchain generated by yocto. A build folder is generated outside of the source code folder. The applications from the ComplianceApp can be deployed on the board in order to test the functionality provided. Other useful resources: – i.MX Yocto Project User's Guide: https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true – NFC Reader Library for Linux Installation: https://www.nxp.com/docs/en/application-note/AN11802.pdf – PN5180 component: https://www.nxp.com/docs/en/data-sheet/PN5180A0XX-C1-C2.pdf

Yes. The Yocto Project site hosts some of the MX machines here. NOTES: If the machine's folder is present but it is empty, a building error may have occurred. Check the build's status for the machine on the archives or send an email to the list. Due to limited resources, not all (Freescale) machines are (nightly) built, in case you need one of these, you need to bake it yourself. You can start building following these instructions.