Hi everybody, The attached document walks you through to build a Linux image for UDOO Quad board with QT5 support by using a Yocto Project build environment. The Kernel used in this process is 3.14.52. I hope you find it useful. Best regards, Carlos

In our document there is about how to fuse in the u-boot, as follows you can see: Here we can use the mfgtool and these command to download the fuse to u-boot. 1/ Set the BOOT_MODE[1:0] to 00 2/Use the mfgtool to download the u-boot to RAM Use the mfgtool to download only the u-boot, so you have to annotate the code not about u-boot. Only u-boot download code left. As follows:  …………    Loading uboot.  Jumping to OS image. 3/When the u-boot boot up, print and go to the u-boot command line. U-Boot contains a tool, imxotp, which is used for fusing. The commands imxotp read addr and imxotp blow --force addr value read the data of Efuse. The addr is the register address of eFUSE, and the base address of eFUSE is 0x021BC0000, details you can refer to the section 46 of the iMX6DQRM.pdf p4016. And the The exact configuration please refer to the section 5 of the iMX6DQRM.pdf p315. Take the Sabrelite as an example the value of burning : imxotp blow --force 0x5 0x18000030 imxotp blow --force 0x6 0x10 Hope this can do some hope for you. About the efuse you also can refer to : https://community.nxp.com/thread/316232 

This document is a simple guide on one of the ways in which 3D models can be loaded and displayed using OpenGL.   Requirements - Blender (open source) or a similar program that allows to export 3D models in the .obj format. We’ll be using Blender to export the .obj file with the essential information to draw the 3D model, without information on textures, for example. https://www.blender.org/   - i.MX6 Linux BSP image with X11 support – For this document we’ll use the L3.10.31 BSP, which is compiled using Yocto 1.6.You may use a newer BSP. We’ll use the fsl-image-gui. You may use a Qt5 image with X11 from newer BSPs. - GCC Toolchain -You may either cross compile on a Host or compile on the same board by providing the necessary libraries and toolchain. On the L3.10.31 you need to manually add GCC to your baked image. In newer releases this may not necessary. For adding the GCC package to a Yocto image and compiling within the board itself please add the following line to the conf/local.conf file inside your build directory. IMAGE_INSTALL_append += " gcc libgcc" If you wish to cross compile from your host and then run on your board you first will need to extract the toolchain from the BSP, which can be done by following the instructions of the next document: https://community.nxp.com/docs/DOC-95122  - FreeGLUT – FreeGLUT is an open source alternative to the OpenGL Utility Toolkit (GLUT), a window system independent toolkit for writing OpenGL programs. It implements a simple windowing application programming interface (API) for OpenGL. This is not necessary for drawing the model on the window but foes allow for functions such as rotating it. You may install it on your host with the following command: $ sudo apt-get install freeglut3-dev For additional information and downloads of FreeGLUT please refer to the projects website: http://freeglut.sourceforge.net/   - i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – We’ll use the GPU Test examples which are available at the following link. Source code for this document implementation is attached but for more examples of OpenGL ES please refer to this SDK. (Please note that you may need to login in order to download this file) https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product   - i.MX6Q Board – For this example we will be using the i.MX6Q SABRE Board, but you may run OpenGL ES on any i.MX6Q board provided that you provide the necessary packages to support OpenGL ES.   Brief introduction to OpenGL ES? OpenGL is a software interface to hardware accelerated graphics. The API of this interface consists of about 150 distinct commands that allow you to specify objects and perform operations on them in order to produce interactive three-dimensional applications. OpenGL ES is the OpenGL implementation for Embedded Systems. Somei.MX6 Processors like the i.MX6Q possess a Vivante GPU module that runs on OpenGL ES. When using OpenGL or OpenGL ES all 3D objects are descripted as a series of triangles. This is important to mention as it will make the instructions we will need for describing our model make more sense.   Step 1 - Exporting a model as .obj You may import a 3D model from other sources or make your own simple 3D model in blender. For this example we’ll make a simple 3D NXP logo and export it. Once you have your model ready, select the object in objet mode with a right click. Once selected select File > Export > Wavefront (.obj) You may now select where and with what name to export the object file. On the left panel you will have the export options. It’s important to leave all options unchecked except for: Write Normals Include UVs Triangulate Faces (You may change the scale of your model and it won’t negatively affect the process)     The .obj model may be opened with a text editor and we’ll see that it basically describes the object as a series of parameters that may include vertex data, free-form curve/surface attributes, elements, free-form curve/surface body statements, connectivity between free-form surfaces, grouping and display/render attribute information. For our example we’ll be using a simple file that just contains: - List of geometric vertices, with (x,y,z) coordinates v 0.292475 0.017345 -0.152653 - List of vertex normals in (x,y,z) form vn 0.0000 1.0000 -0.0000 - Polygonal face element f 3//1 113//1 4//1   Step 2- Converting .obj to OpenGL compatible information We’ll be using the following program that allows to convert from .obj format to a format compatible with OpenGL as the conversion from one format to the other is not part of the scope of this document. https://fr.jeffprod.com/obj-to-opengl.php This program does more than just changing the format on the file and do perform some operations to translate the parameters of the .obj file to the following OpenGL ES information: static GLfloat v_triangles[] static GLfloat vt_triangles[] static GLfloat vn_triangles[] We’ll be using these variables and also the number of triangles which for this example is 1440. This can be found at the end of the file on the following line which effectively draws the complete triangle array: glDrawArrays(GL_TRIANGLES, 0, 1440);   Step 3 – Loading the model arrays to the .C program. You will need to copy the three GLfloat arrays to your OpenGL ES .C code. (You may alternatively use an include to have it more neatly organized but this is outside the scope of this document) In our example we’ll copy them inside void render (). Inside this function we’ll find the Draw Array instruction in which we must specify the number of triangles in our array. You may just replace your model information AND also change the number of triangles, otherwise you will receive an error when running the program.   glDrawArrays(GL_TRIANGLES,0,1440); We are using a simple rotation using glRotate and incrementing the value of rotation with each flush of the screen.     glRotatef(rlogo, 2.0f, 1.0f, 1.0f); The variable rlogo gets increased each time the screen is drawn. Depending on your model you may need to change the view in order to be able to see your model. This example uses a very small model so we have a viewpoint just 1.25 units away from the screen (Z axis). Depending on your model you may need to be further away in order to see the model on the screen. glTranslatef(0.0f, 0.0f, -1.25f);    Step 4- Compiling the OpenGL example For this simple example we will be using the examples from the GPU  as base an add the information of the model we have just exported. We’ll use the two attached files for this: Makefile.x11 – A make file with the dependencies and attributes necessary to compile our C file. NXPlogo.c – C file with the information of the model and instructions on to draw it on the screen. You can compile using the following commands to first clean in case you built before and then compiling the code. make –f Makefile.x11 clean make Makefile.x11 Once the program has compiled you can run it from the command prompt by using: export DISPLAY=:0.0 ./NXPlogo The result will be as follows, where the 3D model is rotating,     Additional Resources 2D and 3D Graphics in NXP Devices http://www.nxp.com/files/training/doc/dwf/DWF13_AMF_CON_T1025.pdf   i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – Which provides the source code for the demo in which this example was built upon and also contains good documentation for those interested in OpenGL ES. https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product    OpenGL Redbook – Which is the most comprehensive book documenting and explaining the OpenGL API. http://www.opengl-redbook.com/

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

This doc describe the steps to enable HAB on i.MX7D EVK board with plugin boot mode. The BSP version is L3.14.52_ga_1.1.0 or L4.1.15_ga_1.2.0, the CST tool version is cst-2.3.2. Since fast authentication is supported after HAB 4.1.2, and the HAB version of i.MX7D is 4.2, we use fast authentication here. The PC to run the CST tool is Ubuntu 10.04, x86 version. 1. Generate HAB4 Keys and Certificates 1.1. Unpack the CST package, there are seven folders: ca, code, crts, docs, keys, linux32 and linux64     In "keys" folder, create "serial" file, openSSL uses the contents of this file for the certificate serial numbers.     In "keys" folder, create "key_pass.txt" file, this file contains your passphrase that will protect the HAB code signing private keys.     In this example, the content in "serial" file is         $ cat serial         12345678       The content in "key_pass.txt" file is         $ cat key_pass.txt         nxp_imx7d         nxp_imx7d   1.2 Prior to running the hab4_pki_tree.sh, ensure that OpenSSL is included in your search path by running         $ openssl version         OpenSSL 0.9.8k 25 Mar 2009   1.3 Run the hab4_pki_tree.sh script to generate hab4 keys and certificates         $ cd keys         $ ./hab4_pki_tree.sh         Do you want to use an existing CA key (y/n)?: n         Do you want to use Elliptic Curve Cryptography (y/n)?: n         Enter key length in bits for PKI tree: 2048         Enter PKI tree duration (years): 10         How many Super Root Keys should be generated? 4         Do you want the SRK certificates to have the CA flag set? (y/n)?: n     Since we are verifying fast authentication, answer 'n' here.   1.4 Generating HAB4 SRK tables and efuse Hash         $ cd ../crts         $ ../linux32/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c        SRK1_sha256_2048_65537_v3_usr_crt.pem,SRK2_sha256_2048_65537_v3 _usr_crt.pem,SRK3_sha256_2048_65537_v3_usr_crt.pem,SRK4 _sha256_2048_65537_v3_usr_crt.pem     SRK_1_2_3_4_fuse.bin is SRK efuse binary file.     SRK_1_2_3_4_table.bin is SRK table binary file. 2. Program SRK_HASH fuse 2.1 Dump SRK_1_2_3_4_fuse.bin.         $ od -t x4  SRK_1_2_3_4_fuse.bin         0000000 ac7ab98f 8febd6b4 b6e15ce3 3e870783         0000020 6f06d6a9 e1107545 3e19d19c e79d1556   2.2 Boot up the board with Linux rootfs, after log in, program SRK_HASH fuse.         # echo 0xac7ab98f > /sys/fsl_otp/HW_OCOTP_SRK0         # echo 0x8febd6b4 > /sys/fsl_otp/HW_OCOTP_SRK1         # echo 0xb6e15ce3 > /sys/fsl_otp/HW_OCOTP_SRK2         # echo 0x3e870783 > /sys/fsl_otp/HW_OCOTP_SRK3         # echo 0x6f06d6a9 > /sys/fsl_otp/HW_OCOTP_SRK4         # echo 0xe1107545 > /sys/fsl_otp/HW_OCOTP_SRK5         # echo 0x3e19d19c > /sys/fsl_otp/HW_OCOTP_SRK6         # echo 0xe79d1556 > /sys/fsl_otp/HW_OCOTP_SRK7 3 Sign u-boot 3.1 Apply the HAB patch and build the u-boot.     Goto u-boot source code folder and apply the patch:     $ git apply 0001-iMX7D-SabreSD-enable-HAB-boot-for-plugin-mode.patch     Build u-boot.     $ make distclean     $ make mx7dsabresd_defconfig     $ make       The followed two defines should be enabled in "uboot-imx/include/configs/mx7dsabresd.h" for secure configure and plugin mode.         #define CONFIG_SECURE_BOOT         #define CONFIG_USE_PLUGIN   3.2 Create u-boot folder in cst-2.3.2 folder, copy u-boot.imx to u-boot folder. Dump u-boot.imx IVT structures.     Dump plugin IVT header:         $ cd u-boot         $ od -x -N 48 u-boot.imx         0000000 00d1 4020 042c 0091 0000 0000 0000 0000         0000020 0420 0091 0400 0091 2400 0091 0000 0000         0000040 0000 0091 8000 0000 0001 0000 401f e92d       Plugin IVT header layout is: Offset   Name                    Value 0           ivt.header              0x402000d1 4           ivt.entry                 0x0091042c 8           ivt.reserved1         0x00000000 12         ivt.dcd_ptr             0x00000000 16         ivt.boot_data_ptr   0x00910420 20         ivt.self                    0x00910400 24         ivt.csf                     0x00912400 28         ivt.reserved2          0x00000000 32         boot_data.start      0x00910000 36         boot_data.size       0x00008000 40         plugin                     0x00000001       IVT address:  ivt.self = 0x00910400     Image length: ivt.csf – ivt.self = 0x00912400 - 0x00910400 = 0x2000     So the [Authenticate Data] field of csf file "csf_u-boot_plugin_ivt1.txt" is         Verification index = 0         Blocks = 0x00910400 0x000 0x2000 "u-boot.imx"     Dump u-boot IVT header:         $ dd if=u-boot.imx of=u-boot-body.bin bs=1 skip=16384         $ od -x -N 48 u-boot-body.bin         0000000 00d1 4020 0000 8780 0000 0000 0000 0000         0000020 fff4 877f ffd4 877f 8bd4 8785 0000 0000         0000040 bbd4 877f f000 0005 0000 0000 00be ea00       U-boot IVT header layout is: Offset   Name                   Value 0          ivt.header              0x402000d1 4          ivt.entry                 0x87800000 8          ivt.reserved1         0x00000000 12        ivt.dcd_ptr             0x00000000 16        ivt.boot_data_ptr   0x877ffff4 20        ivt.self                    0x877fffd4 24        ivt.csf                    0x87858bd4 28        ivt.reserved2         0x00000000 32        boot_data.start     0x877fbbd4 36        boot_data.size      0x0005F000       IVT address:  ivt.self = 0x877fffd4     Image length: ivt.csf – ivt.self = 0x87858bd4 - 0x877fffd4 = 0x58c00     So the [Authenticate Data] field of csf file "csf_u-boot_plugin_ivt2.txt" is         Verification index = 0         Blocks = 0x877fffd4 0x0000 0x58c00 "u-boot-body-pad.bin"       When enable CONFIG_SECURE_BOOT, boot_data consists of uboot image and csf data, so it's larger than uboot Image length.     And the u-boot-body.bin should be padded to 0x58c00.   3.3 The command to sign u-boot         $ ../linux32/cst -o csf_plugin.bin -i csf_u-boot_plugin_ivt1.txt         $ objcopy -I binary -O binary --pad-to 0x58c00 --gap-fill=0x00 u-boot-body.bin u-boot-body-pad.bin         $ ../linux32/cst -o csf_u-boot.bin -i csf_u-boot_plugin_ivt2.txt         $ objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 csf_plugin.bin csf_plugin-pad.bin         $ objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 csf_u-boot.bin csf_u-boot-pad.bin         $ dd if=u-boot.imx of=plugin-body.bin bs=1 count=8192         $ cat plugin-body.bin csf_plugin-pad.bin u-boot-body-pad.bin csf_u-boot-pad.bin > u-boot-signed.imx   3.4 Download u-boot-signed.imx to SD         $ sudo dd if=u-boot-signed.imx of=/dev/sdx bs=1K seek=1   3.5 Bootup from SD card, check HAB status by uboot command         => hab_status     If see "No HAB Events Found",  the signature is verified successfully.  

Two IPUs are supported in i.MX6Q SoC, each IPU supports 1920x1080 resolution, and 4 kinds of interfaces on i.MX6Q PADs can be used to connect display devices: HDMI, Digital RGB24, LVDS1+LVDS2, MIPI DSI. In the documents, we will discuss how to expand VGA port with digital RGB and realize dual-display via HDMI & VGA, The solution has been validated on Android4.2.2 and Android4.4.2 BSP released by NXP. 1.  Expanding VGA port based on digital RGB24 interface with ADV7125 Schematic is in attachments. 2. Configurations of envionment variables in u-boot The following settings are for booting via NFS, users can adjust them to boot via Flash on board. setenv ipaddr 192.168.1.103 setenv serverip 192.168.1.102 setenv gateway 192.168.1.1 setenv ethaddr 00:04:9f:00:ea:d3 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_android 'setenv bootargs ${bootargs} init=/init androidboot.console=ttymxc0 androidboot.hardware=freescale' setenv bootargs_nfs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gateway}:${netmask}::eth0 off root=/dev/nfs nfsroot=${serverip}:${nfsroot}' setenv bootargs_disp 'setenv bootargs ${bootargs} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb1:dev=lcd,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb2:off fbmem=32M vmalloc=400M' setenv bootcmd_net 'run bootargs_base bootargs_android bootargs_nfs bootargs_disp;tftpboot ${loadaddr} uImage;bootm' 3. Configurations in BSP file (1)IOMUX of DISP0 port (in header file)     MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,     MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15,        /* DE */     MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2,        /* HSync */     MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3,        /* VSync */     MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,     MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,     MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,     MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,     MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,     MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,     MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,     MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,     MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8,     MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9,     MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10,     MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11,     MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12,     MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13,     MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14,     MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15,     MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16,     MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17,     MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18,     MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19,     MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20,     MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21,     MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22,     MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23,     MX6Q_PAD_NANDF_D4__GPIO_2_4,        /* ADV7125 Power on / off (2) Frame buffer static struct ipuv3_fb_platform_data qcorein_fb_data[] = { /*    {     .disp_dev = "ldb",     .interface_pix_fmt = IPU_PIX_FMT_RGB666,     .mode_str = "LDB-WXGA",     .default_bpp = 16,     .int_clk = false,     .late_init = false,     }, */     {     .disp_dev = "hdmi",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080M@60",     .default_bpp = 32,     .int_clk = false,     .late_init = false,     },     {     .disp_dev = "lcd",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080",     .default_bpp = 32,     .int_clk = false,     }, }; (3) Settings about IPUs /* HDMI -- IPU1_DI0 */ static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {     .ipu_id = 1,     .disp_id = 1, }; /* RGB24 DISP0 LCD(Here is RGB24-->VGA via ADV7125 -- IPU0_DI0 */ static struct fsl_mxc_lcd_platform_data lcdif_data = {     .ipu_id = 0,     .disp_id = 0,     .default_ifmt = IPU_PIX_FMT_RGB24, }; (4) Adding LCD data in board_init() funtion static void __init mx6_qcorein_board_init(void) { .... imx6q_add_lcdif(&lcdif_data); ... } (5) Adding mxc_lcd.c driver to linux kernel When using make menuconfig to configure kernel, don't forget to add LCD driver to kernel.  Note: If users are using other version of android BSP, she can do porting according to above thinking. Weidong Sun NXP TIC team

Update 2 Nov 2016: The work begun with this current sensor board has been superseded by this 4-channel solution. The ribbon cables used below, although easier to solder, were very stiff and tended to lift the sensors off the double sticky foam tape, which endangered the target application board. This post remains for historical purposes. This little board set was put together quickly to measure run current as well as sleep current. The sensor board is intended to be affixed with double sided tape to the board under test. A flat ribbon cable connects to the connection board where the power and current sensor connections may be made. The holes accommodate banana jacks. The current range is selected via the dip switch on the connection board. Below is an image of the schematic. The attached PDF contains the schematic, layout and partial Digikey parts lists along with embedded source files (look for the thumb-tacks).   The DMN1019USN FETs have a Vgs of 8V, which limits the maximum current which may be measured (currents above will starve the output of the current sensor amplifiers since the output cannot swing high enough). With a supply of ~7.5V, a maximum high current of ~3A is possible with the 2V/A gain (A4) version of the INA250. With a 2 Ohm shunt for the low current range, the maximum current with an INA212 (1000V/V gain) is ~3mA. Two FETs in parallel were used to decrease the series resistance when shorting the low current shunt. [NOTE: The voltage applied to the gates of the FETs assumes that the ground on the both board under test and the current sense board combo are in common.  An isolated supply could have been used but was not for simplicity.] The high current range is intended for normal operation, i.e., measuring run currents.The low current range should only be selected once the board is configured for a low power mode. Once in that mode, the low power mode may be selected.  To use an instrumented target board without having to have the connection board hooked up and powered, jump the two vias (spaced 0.1", labeled "Jump" by the current input connections). These vias short the 2 Ohm low current shunt resistor. The target board is connected via the 3-pin header. The outer two points are the negative input connection; the center is the positive. Two negative connections are provided to avoid having to cross the connection wires. These wires should be kept as short as possible. The series resistance at the input in the high range (dip switch off) was under 25mOhms, so the connections wires only add to that. The board set may be used as-is before snapping apart since connections between the boars runs through the row of snap-vias. A ribbon cable needs be used after snapping them apart. Finer pitch ribbon could have been used but it'd be much less friendly for hand soldering. Board sets in multiples of 3 may be ordered here. Here are some photos of the prototype board (some silk screen errors and the banana jack holes were drilled too small). Before snapping apart on the left and after with the ribbon cable and connectors added on the right. Here is a photo of the i.MX6SL on the EVK instrumented for low-power sleep-mode current measurement on VDD_HIGH_IN: SENSOR CALIBRATION CHECK: The calibration of three sensor boards was checked by forcing an accurate, known current with a Keysight B2902A Source Measure Unit (SMU). The average sensor output was measured for each forced current in the high and low range. The data was plotted and best fit lines were applied: The data for each sensor was very linear. The coefficients and offsets of all 6 best fit lines were very similar as can be seen above. The data can be perused in the attached Excel file (HiLo-sensors-1-3-calib.xlsx). The three sets of coefficients for the high range sensor (the INA250A4) were averaged. For each sensor's output, the current was calculated using these averaged coefficients and tabulated next to the forced current (the brown data). All of the calculated currents were within at most 20mA of the actual current forced by the SMU. TO DO: Two outputs are somewhat cumbersome; it'd be handier to just switch which sensor is outputting to the measurement device. It'd also be really handy to have a 4 channel distribution board and 4 sensor boards, which would allow the use of a 4 channel oscilloscope. Some LEDs on the distribution board indicating which measurement range is in use would also be nice... UPDATE 7 OCT 2016: Working now on a Kinetis-based, data-logging capable, 4-channel power profiler for run and sleep. The Kinetis ADCs will be used to measure the sensor outputs and power supply rail voltages, which should be fine given the level of accuracy that is required. Data is sent up the line in real time via a USB serial port, which opens the possibility of the target board profiling it's own power consumption, including low power modes (a wake-up line for the target board is provided for just that purpose). For more information on current measurements in general, see this tutorial series: A Current Sensing Tutorial--Part 1: Fundamentals | EE Times  A Current Sensing Tutorial-Part II: Devices | EE Times  A Current Sensing Tutorial--Part III: Accuracy | EE Times  A Current Sensing Tutorial-Part IV: Layout and Troubleshooting Guidelines | EE Times 

Attached is an application note for iMX6 TVIN use case, some internal review was done. 2016-10-08, change it to pdf file.

The document is a master page for learning i.MX6Q SABRE. It contains several parts as following. The pdf files listed below(item 0, 1, 2) are contained in the NXP official website and others are in the community links. 0. i.MX6 SMART DEVICE SYSTEM(Schematics): SPF-27516_C5.pdf(in the iMX6Q_SABRE_SDB_DESIGNFILES) i.MX 6Quad SABRE Development Board|NXP  1. How to build an image for an i.MX NXP board by using a Yocto Project build environment: Freescale_Yocto_Project_User's_Guide.pdf(in the L4.1.15_1.1.0_LINUX_DOCS) i.MX 6Quad SABRE Development Board|NXP  2. How to build and install the NXP Linux OS BSP: i.MX_Linux_User's_Guide.pdf (in the L4.1.15_1.1.0_LINUX_DOCS) i.MX 6Quad SABRE Development Board|NXP  3. How to Use Trace32 to Run U-boot in the i.MX6Q SABRE Platform: How to Use Trace32 to Run U-boot in the i.MX6Q SABRE Platform  4. Bootloader Boot Procedure for linux OS in i.MX6Q: Bootloader Boot Procedure for linux OS in i.MX6Q  5. Kernel Loading Procedure for Linux OS in i.MX6Q: Kernel Loading Procedure for Linux OS in i.MX6Q 

THE CONTENTS •Background Knowledge −Kernel Introduction −Linux Kernel Directory Structure of the Source Code •Kernel Loading Procedure −Linux OS Boot Process −First Stage of Loading Sequence(Assembly Language) −Second Stage of Loading Sequence(C Language)

THE CONTENTS •Background Knowledge −Bootloader Introduction −U-boot Directory Structure of the Source Code •Bootloader Boot Procedure(e.g. U-boot) −i.MX6Q Introduction −Linux OS Boot Process −First Stage of Boot Sequence(Assembly Language) −Second Stage of Boot Sequence(Assembly + C Language)

The document in attachment describes how to learn System Boot Flow of Linux by code using Trace32. The hardware platform is i.MX6Q SABRE and the software in PC is Trace32. Contents 1. Introduction 2. Hardware Connection 3. Serial Connection Setup 4. U-boot Directory Setup 5. Trace32 Installation & U-boot Debugging

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:

Purpose:  Introduce how to debug M4 using trace32 and the difference with general debug case.If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool. Firmware: Here we using Freertos as the example, but not limited to this. There is one small difference with general debug case to M4 in 6sx, which when you attach M4 and break M4, it may impact the peripheral that A9 is using. You may have found when you break M4, A9 uart console also was frozen at the same time. This is caused by that when M4 enter debug mode, the debug_req will also assert in the peripherals which you are using on the A9 system. So,need configure the peripherals to keep running when the debug_req is assert when do the M4/A9 debug separately. Need configure the DBGEN (*) register in the related peripherals to allow the eripherals not going into debug mode and keep running even if debug_req is HIGH. The peripherals we need take care are: CAN, UART, EPIT,GPT, ENET, PWM. Note: For the CAN, the register bit is called FRZ Here is the details of uart dbgen in the RM: So if we want debug M4 separately,we should disable this bit, as A9 was using this peripheral. Here we take Freertos as the example to illuminate how to debug M4 step by step: Enable DBGEN case: Load M4 image into memory and kick off M4. (You can refer to  for the details)           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000               ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached): Note:  You can find the elf file at the same folder of binary: So now you can debug your code step by step.If you go back to A9 side uart console, you would find the console have been frozen. Disable DBGEN case at A9 side: Load M4 image into memory and kick off M4. (You can refer to  for imx6sx user guide  the details)           =>mm 0x20200b4                              020200b4:00000020 ? 0x820           =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000                ##Starting auxiliary core at 0x9FF00000                ... Attach M4 using the m4.cmm file(attached) In this case you will the A9 uart console still can work, after you break M4. Disable DBGEN case at M4 side: Load M4 image into memory and kick off M4.   =>fatload mmc 2:1 0x9ff00000 hello_world_ddr.bin                     reading hello_world_ddr.bin 18748 bytes read in 30 ms (609.4 KiB/s)           =>dcache flush           =>bootaux 0x9ff00000          ##Starting auxiliary core at 0x9FF00000 Attach M4 using the m4_disable_dbgen.cmm  file(attached) In this case you will the A9 uart console still can work, after you break M4.   Notes: For more trace32 usage, please refer to http://www.lauterbach.cn/           For more imx6sx information, please refer to i.MX 6SoloX Family of Applications Processors|NXP.

Purpose: Introduce how to debug M4 using trace 32 and the difference with regular debug mode for imx6sx. If you are using other jtag debug tools, maybe you need to do the similar configuration. Debug tools: Trace32 – you can refer to http://www.lauterbach.cn/ for more information about this tool.

In our reference design board the eMMC IC is Sandisk SDIN5C2-8 (4.41), and in i.MX6 Reference manual and datasheet we can known that it compatible with the MMC System Specification version 4.2/4.3/4.4, and details in datasheet declare that the uSDHC module is "fully compliant with the MMC command/response sets and Physical Layer as defined in the Multimedia Card System Specification, v4.2/4.3/4.4/4.41, including high-capacity (> 2 GB) HC MMC cards." EMMC4.4/4.41 of cause can work in our released BSP. But eMMC 4.4 has been discontinued and there is a possibility eMMC 4.41 will be discontinued.  And many of our customers will choose the eMMC 4.5 or high verison EMMC 5.0 and EMMC 5.1. And how to make the eMMC 4.5 , EMMC 5.0 and EMMC 5.1 work on i.MX6 ? The EMMC 4.5 or EMMC 5.0 /5.1 is backward-compatible with eMMC4.4, we can use it in eMMC4.4 mode to enable eMMC4.4 functionality and performance on the i.MX6 platform. Booting from a eMMC 4.5 device or high version is not supported,  boot ROM will fall back to the eMMC4.4 standard when a eMMC4.5 or high version capable device is detected. In BSP it is possible to bypass eMMC version checking, so that eMMC v4.5 or high version can work as eMMC v4.4 cards, no specific v4.5 feature supported. Only basic read/write operations are supported. In the source code we can change check value of card->ext_csd.rev. Take the eMMC 4.5 work as example, the current i.MX6 Linux BSP (L3.0.35_4.1.0) has added code to interface with an eMMC4.5 card to operate as an eMMC4.4 card. Change the value of card->ext_csd.rev 5 to 6, now eMMC 5.0 can work as an eMMC 4.4. The code drivers/mmc/core/mmc.c: And for the EMMC 5.0 and EMMC5.1, modify the kernel to support eMMC 5.0 and 5.1 extended CSD revisions, as shown below: /drivers/mmc/core/mmc.c : if (card->ext_csd.rev > 6) {              // The '6' has to be replaced with '7' For EMMC5.0                                                         //  The '6' has to be replaced with '8'  For EMMC5.1 pr_err("%s: unrecognised EXT_CSD revision %d\n", mmc_hostname(card->host), card->ext_csd.rev); err = -EINVAL; goto out;          } After modifying the code we need to rebuild the the firmware uImage used for MfgTool . Update the uImage in Mfgtool , and it can flash successful. Then the eMMC version 5.0 and 5.1 can be used with IMX6 based boards.

since we have already released the patch for 3.10, this patch is for kernel 3.14

This example makes use of a U-Boot image as a bootloader. U-Boot is commonly used as a bootloader for Linux devices and is provide by the Freescale Linux BSP. The default memory layout of the Freescale U-Boot port can be modified to meet the encrypted boot requirements. This is shown in figure 5. As it can be seen, this layout is similar to any other U-Boot port, with the addition of the security mechanisms appended at the end of the image.                          Figure  Chosen memory layout of the encrypted u-boot 1)Assumptions In designing a U-Boot image as an encrypted boot solution, there are three assumptions which accelerate and simplify the construction process. . The U-boot image can be build for multiple board configuration, but for demonstration purposes this example uses i.MX6 Solo X . The user is familiar with the secure configuration for U-Boot and is able to properly sign and boot a U-Boot image. . The encrypted image will be constructed by an individual party, and there is no need to worry about provisioning the DEK. 2)Requirements The components required to build an encrypted image are shown below. Note that the majority of these components are the product of following the signing U-Boot image procedure.    a)Code Signing Tool in encryption mode o To build the CST in encryption mode, run the following command make OSTYPE=linux ENCRYPTION=yes HAB_RELEASE=~/hab/hab_release release o Note: that CST is not in encryption mode by default. This feature needs to be enabled before encrypting the bootloader image. The performance of the CST might be affected, due to its dependency on the host entropy. Refer to the CST User Guide for more details.   b) iMX6 Solo X device in secure mode   c) U-Boot image with secure boot support enabled. o To configure U-Boot to be built with secure boot support, CONFIG_SECURE_BOOT will need to be defined in the board header file (i.e. at include/configs/mx6q_arm2.h)   d) Signed U-Boot image o A U-Boot image with a CSF and digital signature attached. 3) Implementation Many different implementations for constructing a encrypted U-boot image are possible. The right implementation depends on the solution’s requirement. The presented implementation is intended to provide the foundation principles; it can be modified to meet different needs.

From iMX 3.1x kernel, all kernel debug messages will be print to debug serial port after UART driver loaded, so if the kernel hang up before tty console driver ready, there will be no kernel boot up messages.   The attached patch can be used to enable the iMX serial debug console in early time, then kernel will not buffer the debug messages.   Note: the default patch is for UART1 (tty0) as the debug port, if you need use other debug port, please modify the code "early_console_setup()" with correct UART port base address.   L3.10.53-Add-early-console-for-debug-message.patch This patch is based on L3.10.53_GA1.1.0 release, it can support iMX6S/DL/D/Q.   L3.14.52-Add-early-console-for-debug-message.patch This patch is based on L3.14.52_GA1.1.0 release, it can support iMX6S/DL/D/Q, iMX6SL, iMX6SX, iMX6UL and iMX7.  

  IMX6 SL boot process is described in Chapter 8 (System Boot) of the Reference Manual. Shortly, the loading boot data from boot SD card is performed in two stages : first read IVT, DCD, then read executable code, using the Boot Data Structure.    At first, boot ROM copies 4K byte (containing IVT and DCD ) from sector 0 of the boot SD card to internal buffer in OCRAM, located in reserved area (0x00900000 - 0x00907000). This area must not be used by user application.   Then, “after checking the Image Vector Table header value (0xD1) from Program Image, the ROM code performs a DCD check. After successful DCD extraction, the ROM code extracts from Boot Data Structure the destination pointer and length of image to be copied to RAM device from where code execution occurs”.   The IVT contains field entry - absolute address of the first instruction to execute from the image.   Note : according to Figure 8-3 (Internal ROM and RAM memory map), only OCRAM Free Area (68KB) from 0x00907000 till 0x00918000 may be used by user’s application.   The attachment contains SD-bootable example.