i.MX Processors Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Knowledge Base Articles

When to enable CONFIG_DEBUG_LL, choose the debug port and then CONFIG_EARLY_PRINTK on i.MX6, system will hang. There is no error information there as below, Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Initializing cgroup subsys cpu Initializing cgroup subsys cpuacct Linux version 4.1.15-00001-gd582989-dirty (jay@jay-ubuntu) (gcc version 4.9 20 150123 (prerelease) (GCC) ) #10 SMP PREEMPT Mon Jul 17 15:08:55 CST 2017 CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine model: Freescale i.MX6 Quad SABRE Smart Device Board bootconsole [earlycon0] enabled cma: Reserved 448 MiB at 0x2a000000 Memory policy: Data cache writealloc -------------- hang ----------------- ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ The patch fix it on android n7.1.1_1.0.0, kernel: 4.1.15.
View full article
Building Freescale U-boot The U-boot provided by Freescale can be downloaded in the following link: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/ 1 - Set the cross compiler environment variables. When using Yocto, it can be made by the following command (see more details at Yocto Trainning Yocto Training - HOME ) source /opt/poky/1.7/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi 2 - Download the source code using "git clone": git clone  http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git 3 - Create a local branch based on some remote branch. In this example, lets use branch origin/imx_v2014.04_3.14.28_1.0.0_ga cd uboot-imx git checkout -b imx_v2014.04_3.14.28_1.0.0_ga_local origin/imx_v2014.04_3.14.28_1.0.0_ga 4 - Configure the project with the board you want to build. All board are listed on file boards.cfg. Check the exactly name of the choosen board and add "_config" to build the project. In this example, lets use mx6qsabresd make mx6qsabresd_config make 5 - The binary file will be generated and will be located at project root folder. The generated file in this case will be u-boot.imx 6 - More details can be found on files doc/README.imx6 doc/README.imximage README Building Mainline U-boot The U-boot project is developed and maintained by Denx Computer Systems can be downloaded in the following link: http://git.denx.de/?p=u-boot.git;a=summary 1 - Set the cross compiler environment variables. When using Yocto, it can be made by the following command (see more details at Yocto Trainning Yocto Training - HOME ) source /opt/poky/1.7/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi 2 - Download the source code using "git clone": git clone http://git.denx.de/u-boot.git 3 - Check the name of the board on "configs" folder. In this case lets use mx6qsabresd_config make mx6qsabresd_config make 4 - The binary file will be generated and will be located at project root folder. The generated file in this case will be u-boot.imx
View full article
i.MX evaluation board can be a simple solution to program i.MX boards in a factory for instance. i.MX evaluation board are not for industrial usage, but you can find plenty of cheap i.MX insdustrial boards on the web. Here I am using an i.MX8QXP rev B0 MEK board and I will program an i.MX6Q SABRE SD board. The first step is to generate your image. Follow the documentation steps to generate the "validation" image. You will have to customize a little bit the local.conf file (in conf/local.conf) to have git, cmake, gcc and other missing package. edit local.conf and add the following lines at the end of the file: IMAGE_INSTALL_append = " git cmake htop packagegroup-core-buildessential xz p7zip rsync" ‍‍‍‍ ‍ I have added rsync package in local, it can replace cp (copy) but with the --progress option you can see the copy progression. P7zip replace unzip for our images archives avaialable on nxp.com as unzip as issues with big files. then rebake your image: bitbake - k fsl - image - validation - imx‍‍‍‍ ‍ When it is done, go in tmp/deploy/image/<your image generated> and use uuu to program your board (I use a sd card; thus I can increase the partition esily): sudo . / uuu - b sd_all imx - boot - imx8qxpmek - sd . bin - flash fsl - image - validation - imx - imx8qxpmek . sdcard . bz2 / * ‍‍‍‍ ‍ As the rootfs can be too small, use gparted under Linux for instance to increase the size of the partition. Put the SD card and start your board. Here here the dirty part... You may know archlinux|ARM websitesite (Arch Linux ARM ), you have a lots of precompiled packages. Thus on the board you can download it, and copy the file in /usr folder (you can use it to have the latest openSSL for  instance!). Plug an ethernet cable on the board and check if it is up: ifconfig - a ifconfig eth0 up‍‍‍‍‍‍‍‍ ‍ ‍ Now you should have access to the internet. On uuu webpage you can find all the packages you need (here I am using a 4.14.98_2.0.0 Linux): mkdir missinglibs cd missinglibs wget http : / / mirror . archlinuxarm . org / aarch64 / core / bzip2 -1.0 . 8 - 2 - aarch64 . pkg . tar . xz wget http : / / mirror . archlinuxarm . org / aarch64 / core / nettle -3.5 . 1 - 1 - aarch64 . pkg . tar . xz wget http : / / mirror . archlinuxarm . org / aarch64 / core / libusb -1.0 . 22 - 1 - aarch64 . pkg . tar . xz wget http : / / mirror . archlinuxarm . org / aarch64 / extra / libzip -1.5 . 2 - 2 - aarch64 . pkg . tar . xz wget http : / / mirror . archlinuxarm . org / aarch64 / core / zlib -1 : 1.2 . 11 - 3 - aarch64 . pkg . tar . xz wget http : / / mirror . archlinuxarm . org / aarch64 / extra / p7zip -16.02 - 5 - aarch64 . pkg . tar . xz cd . . ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Wait all the archives are downloaded (otherwise you'll decompress before the archive is downloaded) as wget is running in background! Now untar the archives and copy it in the rootfs (dirty): tar - xJf libzip -1.5 . 2 - 2 - aarch64 . pkg . tar . xz tar - xJf libusb -1.0 . 22 - 1 - aarch64 . pkg . tar . xz tar - xJf nettle -3.5 . 1 - 1 - aarch64 . pkg . tar . xz tar - xJf bzip2 -1.0 . 8 - 2 - aarch64 . pkg . tar . xz cp zlib -1 : 1.2 . 11 - 3 - aarch64 . pkg . tar . xz zlib tar - xJf zlib tar - xJf p7zip -16.02 - 5 - aarch64 . pkg . tar . xz cd usr sudo cp - R . / usr cd . . / . . / ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Download and compile uuu: git clone git : / / github . com / NXPmicro / mfgtools . git cd mfgtools / cmake . make‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ Download an image on nxp.com for instance. I have downloaded on the i.MX6 4.14.98_2.0.0 image and put it on a usb key. then unzip it in the uuu folder: 7z e L4 .14 . 98_2 .0 . 0_ga_images_MX6QPDLSOLOX . zip‍‍‍ ‍ As mentionned before unzip cannot hadle big files... so use 7z as me plug the i.MX6Q SABRE SD to the i.MX8X and program your i.MX6 board: . / uuu uuu . auto - imx6qsabresd‍ uuu ( Universal Update Utility ) for nxp imx chips -- libuuu_1 .3 . 74 - 0 - g64eeca1 Success 1 Failure 0 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍
View full article
This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary  core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.
View full article
Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind.   Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide.   Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido ‍ ‍  Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer.   BBLAYERS += " ${BSPDIR}/sources/meta-engicam " ‍   This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf   IMAGE_INSTALL_append += "wf111-driver" ‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work.   Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled:   CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default.   This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility   Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options.  Content of the config fragment:   CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍    Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory:   We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy:  <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg ‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment)   We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend   The linux-imx_3.14.52.bbappend file would contain the following:   SRC_URI += "file://WF111.cfg"  do_configure_append() {          #this is run from         #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git          cat ../*.cfg >> ${B}/.config  } ‍ ‍ ‍ ‍ ‍ ‍    After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍ ‍
View full article
A new version of the Pins Tool for i.MX Application Processors has been released and is available for download as desktop tool from Pins Tool for i.MX Application Processors|NXP. The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE What's New Added Label support to give signals a name Added ‘Log’ and ‘Problems’ view to report conflicts between settings Added support for templates to store user configurations as starting point for new configurations Added ability to download and share data for devices, especially for off-network host machines i. MX header files are now automatically part of the device data Import of legacy Processor Expert .pe files Export of register defines Various bug fixes and documentation improvements The release notes of the desktop application are attached to this article. Import Processor Expert Files A new importer has been added to import legacy Processor Expert for i.MX files: Labels Signals can now have user defined labels: Templates, Kits, Boards and Processors When creating a new configuration, it offers Templates, Boards and Processors. Custom configurations can be stored as templates and then used for new configurations. Board Specific Functions With the provided board and kit configurations, there are now pre-configured initialization functions for major blocks on the board: Export Data To simplify downloading the device specific data for the desktop tool, the 'Export' function can be used to download and export the data. The data can be copied that way to another machine or all data for a set of devices can be loaded. Export Registers With the Export command the registers can be exported as text/source: This is used to store the register values: /*FUNCTION********************************************************************** * * Function Name : init_audmux_pins * Description   : Configures pin routing and optionally pin electrical features. * *END**************************************************************************/ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT_VALUE            0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT_VALUE         0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT_VALUE          0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19 */ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ We hope you will find this new release useful. Thanks for designing with NXP! 
View full article
Q: How to program i.MX6 eFUSE? A: what about using the mfg tool? In the end only the supplies, USB OTG and the boot mode pins need to be connected. The customers Idea was to have all devices (i.MX6 eFUSE , Flash, PFUZE, etc) pre- programmed before mounting on the board. I presented the flows we support (MFG Tool, Platform SDK) for eFUSE programming last Friday when I was at the customer. KITPF0100SKTEVBE Product Summary Page MfgTools is the most convenient way to burn eFuse . Or the customer can burn the fuse on their jig/socket board by the u-boot: How to Fuse in U-Boot U-Boot contains a tool, imxotp , which is used for fusing. U-Boot > imxotp imxotp - One-Time Programable sub-system Usage: imxotp imxotp read <index> - read fuse at 'index' imxotp blow [--force] <index> <value> - blow fuse at 'index' with hex value 'value' Tips: ' addr ' to 'index': convert 'index' from 'address' index = ( addr - otp_base) / 0x10 eg , addr is 0x021bc410, otp_base is 0x021bc400, the index = 1 '-- force ' must be present in order to blow the fuse. Command will abort if '--force' is missing. index = ( addr - otp_base) / 0x10, where the addr is the address of the fuse you want to operate, the otp_base is the base address of the fuse block. ' value ' should correspond to fuse settings according to the fuse map and desired fuse configuration. ---------------------------------- FIrst of all thanks for your reply. However both flow assumes the i.MX6 is already soldered on the board. Please note the specific request was if it is possible (and we can support a programming house) to pre program the efuses BEFORE they are soldered on the PCB thus on a standard programmer. Take an FLASH programmer as an example.
View full article
i.MX6Q Automotive board has one ADV7180 analog video decoder with 2 video inputs. By default, only input 1 is used (connector J42).     To connect 2 analog video sources and switch the display between them, the following changes are needed:   1 - Create a new IOCTL on V4L2_capture and ADV7180 device drivers to receive the information from user space application on what input will be selected. 2 - In this new IOCTL, use the "Fast Switch Script" for ADV7180 described at Analog Devices site: ADV7180 Fast Switch Script | EngineerZone  3 - Create a user space application to call the IOCTL mentioned on step 1.   See attached:   1 -  0001-ADV7180-Adding-input-switch-IOCTL.patch.zip - Patch to be applied on NXP kernel 4.1.15_1.0.0_ga 2 - example2.c.zip - Source code example of user space application. It changes the video input in each 2 seconds. (See it working on attached video) 3 - example2.zip - U ser space application e xecutable file  4 - Makefile.zip - Makefile of user space application to be used as example 5 - adv7180_switch.mp4 - Video showing the application   In the application,  VIDIOC_S_CHIP_INPUT IOCTL is called to change the input:   int input = 0 ; if ( ioctl ( fd_capture_v4l , VIDIOC_S_CHIP_INPUT , & input ) < 0 ) { printf ( "VIDIOC_S_CHIP_INPUT failed\n" ) ; return TFAIL ; } ‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍   This IOCTL calls the ADV7180 Fast Switch Script, added on ADV7180 driver (see attached patch).
View full article
The following are a couple of recommendations for setting up a Host machine for building the Android Nougat 7.1.1_1.0.0 BSP. Some of these recommendations are not exclusive of the Nougat release and may help in other scenarios. These also apply to using Virtual Machines as Host. Installing Open JDK 8 on Ubuntu 14.04 As mentioned on the Android guide for Establishing a Build Environment (http://source.android.com/source/initializing.html) there are no available supported OpenJDK 8 packages for Ubuntu 14.04, which is the version recommended and tested on the Nougat Android BSP. An alternative is downloading the Ubuntu 15.04 Open JDK 8 packages and installing them manually, which can be done by following this procedure: Download the .deb packages for 64-bit architecture from archive.ubuntu.com: openjdk-8-jre-headless_8u45-b14-1_amd64.deb with SHA256 0f5aba8db39088283b51e00054813063173a4d8809f70033976f83e214ab56c0 http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jre-headless_8u45-b14-1_amd64.deb  openjdk-8-jre_8u45-b14-1_amd64.deb with SHA256 9ef76c4562d39432b69baf6c18f199707c5c56a5b4566847df908b7d74e15849 http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jre_8u45-b14-1_amd64.deb  openjdk-8-jdk_8u45-b14-1_amd64.deb with SHA256 6e47215cf6205aa829e6a0a64985075bd29d1f428a4006a80c9db371c2fc3c4c http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jdk_8u45-b14-1_amd64.deb  Once you have downloaded these three packages and checked the checksum for them install the packages (optional) install them by running: $ sudo apt-get update $ sudo dpkg -i openjdk-8-jre-headless_8u45-b14-1_amd64.deb $ sudo dpkg -i openjdk-8-jre_8u45-b14-1_amd64.deb $ sudo dpkg -i openjdk-8-jdk_8u45-b14-1_amd64.deb ‍ ‍ ‍ ‍   Increasing SWAP to compensate for the lack of RAM Having insufficient RAM especially on the linking part of the image build may cause a number of issues that are difficult to troubleshoot. In these cases it’s good to take a look at the resource monitor to see if indeed the RAM was depleted. One way to make up for the limited RAM is using a bigger swap. Google recommends at least 16GB of RAM/swap so it’s not uncommon to create a 10GB swap when working in VM, to do this please use the following commands.    $ sudo fallocate -l 10g /mnt/10GB.swap $ sudo chmod 600 /mnt/10GB.swap $ sudo mkswap /mnt/10GB.swap $ sudo swapon /mnt/10GB.swap ‍ ‍ ‍ ‍   Increasing heap size to avoid out of memory errors It is possible to encounter an out of memory error with the recommendation “try increasing heap size witj java option ‘-Xmx<size>’. If you encounter this error or would like to proactively avoid it you may run the following commands that will increase heap size to four gigabytes and then reset the Jack Server by killing it and starting it again. With the android environment initialized: $ cd my android $ export JACK_SERVER_VM_ARGUMENTS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g" $ jack-admin kill-server && jack-admin start-server‍‍‍ ‍ ‍ ‍  Fixing Jack Servers errors due to multiple users on the Host Android Nougat uses Jack Server as mono-user by default. If this is not the case for your host you would need to choose different port numbers for each user and adjust SERVER_NB_COMPILE accordingly. You can also disable the Jack server by setting SERVER=false in your $HOME/.jack. Alternatively, you may also use the patch available on the following link to myandroid/prebuilts/sdk. It will help to fix the mono-user build restriction. When installing the jack-server, it will detect if Jack server is running in the same build machine and then generate a random ports for my build instead of using the default one. https://groups.google.com/forum/#!topic/android-building/UWhJrXH8Vig
View full article
Before reading: only a personal works and sharing, not any form of "release". I didn't find any confidential information from the packages. So, I'm publishing it here. This is only for testing purpose. Do NOT use it for building a product. Use it at your own risk!! Yocto is flexible and powerful, and also, big and slow (when building). Sometimes we only need to build uboot or kernel or some piece of testing code. It's really a waste of time to build-up the whole Yocto environment which may cost over 50GB disk space and over 3 hours of building. I've made some scripts and sum them up to form a toolset for building uboot, kernel and some testing code out of Yocto environment. It's only a simple container and expect to use with uboot and kernel source code from formal Freescale release and a SDK built from Yocto project. GitHub source repo:       https://github.com/gopise/gopbuild What’s made off (a full package, not only the container): 1.    Some scripts and configurations files. 2.    SDK built from Yocto. 3.    Uboot/kernel from specific version. 4.    A hello-world to demonstrate how to build app in this environment. 5.    A slimmed rootfs binary from specific BSP pre-built as base. Will customize base on the source under “rootfs” folder. Only a placeholder in the container-only version. How to use it: Several common used board configurations have been included in the script: 6qsabresd/6qsabreai/6qpsabreai. You can add more into the “gopbuild” script easily. The “sabresd” has been set as default.      If you want to build all for sabresd (First of all, de-compress the package): cd < de - compressed - folder > source envsetup [ It will prompt for selecting board configuration to be built . Choose one by input corresponding number or click < ENTER > for default board . ] gmk ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍      If you want to build specific module for default board, such as uboot: gmk uboot ‍‍‍‍‍‍‍ ‍ ‍      Build kernel for sabreai board instead of default device: gmk kernel sabreai ‍‍‍‍‍‍‍ ‍ ‍      Clean everything? gmk all clean ‍‍‍‍‍‍‍ ‍ ‍ After a successfully full build, you will get everything under “output” folder, including a log folder contains full build log:      “u-boot.imx/zImage/rootfs.tar.bz2/*.dtb”, can be used with MFG or uuu.      “fsl-image.sdcard”, can be burn into SD card directly. "Ready-for-building" Package: The "gopbuild" itself is a "container-only" package which doesn't contain any source or SDK. I've also made some packages based on latest BSP release for i.MX6/i.MX7/i.MX8. These packages are "ready-for-build" package which you can de-compress and build it directly. -------------------------------------------------------------------------------------------------- URL:https://pan.baidu.com/s/1Xlh1OBGsTRXez_NQw-Rjxg Password: gdc9 -------------------------------------------------------------------------------------------------- Note: 1. To build for i.MX8 (8QM/8MQ/8QXP), you need L4.14.* or above. 2. To build for i.MX8, please download the SCFW from i.MX software page       i.MX Software and Development Tools | NXP      After download, decompress corresponding package for specific chip and put it under "/platform/scfw/". Take i.MX8QXP for example:             /platform/scfw/scfw_export_mx8qx/ All material (uboot/kernel/test code and SDK) are from official Yocto release. Thanks!
View full article
  This article uses i.MX Linux® User's Guide, Rev. L4.1.15_2.1.0-ga, 05/2017 as an example (it may be found as attachment), please refer to section 4.5.12 (How to build U-Boot and Kernel in standalone environment).   First, generate a development SDK, which includes the tools, toolchain, and small rootfs to compile against to put on the host machine.     • Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set <Target-Machine> to the machine you are building for.   <Target-Machine> may be one of the following :   • imx6qpsabreauto • imx6qpsabresd • imx6ulevk • imx6ull14x14evk • imx6ull9x9evk • imx6dlsabreauto • imx6dlsabresd • imx6qsabreauto • imx6qsabresd • imx6slevk • imx6sllevk • imx6solosabreauto • imx6solosabresd • imx6sxsabresd • imx6sxsabreauto • imx7dsabresd  The «populate_sdk» generates an script file that sets up environment without Yocto Project. This SDK should be updated for each release to pick up the latest headers, toolchain, and tools from the current release.   $ DISTRO=fsl-imx-fb MACHINE=<Target-Machine> source fsl-setup-release.sh -b build-fb   $ DISTRO=fsl-imx-fb MACHINE=<Target-Machine> bitbake core-image-minimal -c populate_sdk   or   $ bitbake meta-toolchain       • From the build directory, the bitbake was run in, copy the sh file in tmp/deploy/sdk to the host machine to build on and execute the script to install the SDK. The default location is in /opt but can be placed anywhere on the host machine.     Note. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.    $ . /opt/fsl-imx-fb/4.1.15-2.0.0/environment-setup-cortexa9hf-neon-poky-linux-gnueabi   or    $ source /opt/fsl-imx-fb/4.1.15-2.0.0/environment-setup-cortexa9hf-neon-poky-linux-gnueabi   From   Yocto Project Mega-Manual  Note By default, this toolchain does not build static binaries. If you want to use the toolchain to build these types of libraries, you need to be sure your image has the appropriate static development libraries. Use the   IMAGE_INSTALL   variable inside your   local.conf   file to install the appropriate library packages. Following is an example using   glibc   static development libraries:      IMAGE_INSTALL_append = " glibc-staticdev"   On the host machine, these are the steps to build U-Boot and Kernel:  • On the host machine, set the environment with the following command before building.   $ export CROSS_COMPILE=/opt/fsl-imx-fb/4.1.15/environment-setup-cortexa9hf-vfp-neon-pokylinux-gnueabi   $ export ARCH=arm • To build U-Boot, find the configuration for the target boot. In the following example,  i.MX 6ULL is the target.     Download source by cloning with   $ git clone  http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git  -b imx_v2016.03_4.1.15_2.0.0_ga   $ cd uboot-imx $ make clean $ make mx6ull_14x14_evk_defconfig $ make u-boot.imx   • To build the kernel, execute the following commands:   Download source by cloning with   $ git clone http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git -b imx_4.1.15_2.0.0_ga   $ cd linux-imx $ make defconfig $ make   • To build an application (Hello World) as test.c:   $ source /opt/fsl-imx-fb/4.1.15-2.0.0/environment-setup-cortexa9hf-neon-poky-linux-gnueabi $ cd ~/test/ $ arm-poky-linux-gnueabi-gcc --sysroot=/opt/fsl-imx-fb/4.1.15-2.0.0/sysroots/cortexa9hf-neon-poky-linux-gnueabi -mfloat-abi=hard test.c To check if the the compiled code (a.out) is ARM executable   $ file ./a.out   ./a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=0e5c22dcf021748ead2c0bd51a4553cb7d38f6f2, not stripped   Copy file a.out to target Linux filesystem and before run it check again :   root@imx6ul7d:/unit_tests/1# file a.out   a.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=0e5c22dcf021748ead2c0bd51a4553cb7d38f6f2, not stripped   To define what Linux libs are needed to run our application :   root@imx6ul7d:/unit_tests/1# ldd a.out     linux-vdso.so.1 (0x7ee93000)   libc.so.6 => /lib/libc.so.6 (0x76e64000)   /lib/ld-linux-armhf.so.3 (0x76f9d000)   If some libs are not located in the filesystem you can observe the following message :   -sh: root@imx6ul7d:/unit_tests/1#./a.out: No such file or directory   Finally - run a.out:   root@imx6ul7d:/unit_tests/1# ./a.out Hello World root@imx6ul7d:/unit_tests/1#
View full article
Using a RAW NAND is more difficult compared to eMMC, but for lower capacity it is still cheaper. Even with the ONFI (Open NAND Flash Interface) you can face initialization issue you can find by measure performance. I will take example of a non-well supported flash, I have installed on my evaluation board (SABRE AI). I wanted to do a simple performance test, to check roughly the MB/s I can expected with this NAND. One of a simplest test is to use the dd command: root@imx6qdlsolo : ~ # time dd if = / dev / mtd4 of = / dev / null 851968 + 0 records in 851968 + 0 records out 436207616 bytes ( 436 MB , 416 MiB ) copied , 131.8884 s , 3.3 MB / s ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ As my RAW was supposed to work in EDO Mode 5, I could expect more than 20MB/s. To check what was wrong, read you kernel startup log: Booting Linux on physical CPU 0x0 Linux version 4.1 . 15 - 2.0 . 0 + gb63f3f5 ( bamboo@yb6 ) ( gcc version 5.3 . 0 ( GCC ) ) # 1 SMP PREEMPT Fri Sep 16 15 : 02 : 15 CDT 2016 CPU : ARMv7 Processor [ 412fc09a ] revision 10 ( ARMv7 ) , cr = 10c53c7d CPU : PIPT / VIPT nonaliasing data cache , VIPT aliasing instruction cache Machine model : Freescale i . MX6 DualLite / Solo SABRE Automotive Board [ . . . ] Amd / Fujitsu Extended Query Table at 0x0040 Amd / Fujitsu Extended Query version 1.3 . number of CFI chips : 1 nand : device found , Manufacturer ID : 0xc2 , Chip ID : 0xdc nand : Macronix MX30LF4G18AC nand : 512 MiB , SLC , erase size : 128 KiB , page size : 2048 , OOB size : 64 gpmi - nand 112000 . gpmi - nand : mode : 5 , failed in set feature . Bad block table found at page 262080 , version 0x01 Bad block table found at page 262016 , version 0x01 nand_read_bbt : bad block at 0x00000a7e0000 nand_read_bbt : bad block at 0x00000dc80000 4 cmdlinepart partitions found on MTD device gpmi - nand Creating 4 MTD partitions on "gpmi-nand" : ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ On line 13 you can read "mode:5, failed in set feature", meaning you are not in mode 5... so you have the "relaxed" timing you have at boot. After debuging your code (I have just remove the NAND back reading security check), you can redo the test: root@imx6qdlsolo : ~ # time dd if = / dev / mtd4 of = / dev / null 851968 + 0 records in 851968 + 0 records out 436207616 bytes ( 436 MB , 416 MiB ) copied , 32.9721 s , 13.2 MB / s‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ So you multiplied the performances by 4! Anyway, you have a better tool to measure your NAND performance, it is mtd_speedtest, but you have to rebuild your kernel. In Yocto, reconfigure your kernel (on your PC of couse!): bitbake virtual / kernel - c menuconfig‍‍ ‍ Choose in the menu "Device Drivers" -> "Memory Technology Device (MTD) support" -> "MTD tests support" , even it it not recommended! bitbake virtual / kernel - f - c compile bitbake virtual / kernel - f - c build bitbake virtual / kernel - f - c deploy‍‍‍‍‍‍ ‍ ‍ ‍ Then reflash you board (kernel + rootfs as tests are .ko files): Then you can do more accurate performance test: insmod / lib / modules / 4.1 . 29 - fslc + g59b38c3 / kernel / drivers / mtd / tests / mtd_speedtest . ko dev = 2 == == == == == == == == == == == == == == == == == == == == == == == == = mtd_speedtest : MTD device : 2 mtd_speedtest : MTD device size 16777216 , eraseblock size 131072 , page size 2048 , count of eraseblocks 128 , pages per eraseblock 64 , OOB size 64 mtd_test : scanning for bad eraseblocks mtd_test : scanned 128 eraseblocks , 0 are bad mtd_speedtest : testing eraseblock write speed mtd_speedtest : eraseblock write speed is 4537 KiB / s mtd_speedtest : testing eraseblock read speed mtd_speedtest : eraseblock read speed is 16384 KiB / s mtd_speedtest : testing page write speed mtd_speedtest : page write speed is 4250 KiB / s mtd_speedtest : testing page read speed mtd_speedtest : page read speed is 15784 KiB / s mtd_speedtest : testing 2 page write speed mtd_speedtest : 2 page write speed is 4426 KiB / s mtd_speedtest : testing 2 page read speed mtd_speedtest : 2 page read speed is 16047 KiB / s mtd_speedtest : Testing erase speed mtd_speedtest : erase speed is 244537 KiB / s mtd_speedtest : Testing 2x multi - block erase speed mtd_speedtest : 2x multi - block erase speed is 252061 KiB / s mtd_speedtest : Testing 4x multi - block erase speed mtd_speedtest : 4x multi - block erase speed is 256000 KiB / s mtd_speedtest : Testing 8x multi - block erase speed mtd_speedtest : 8x multi - block erase speed is 260063 KiB / s mtd_speedtest : Testing 16x multi - block erase speed mtd_speedtest : 16x multi - block erase speed is 260063 KiB / s mtd_speedtest : Testing 32x multi - block erase speed mtd_speedtest : 32x multi - block erase speed is 256000 KiB / s mtd_speedtest : Testing 64x multi - block erase speed mtd_speedtest : 64x multi - block erase speed is 260063 KiB / s mtd_speedtest : finished == == == == == == == == == == == == == == == == == == == == == == == == = ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ You can now achieve almost 16MB/s, better than the dd test. Of course you cannot achieve more than 20MB/s, but you are not that far, and the NAND driver need optimizations. To redo the test: rmmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko insmod /lib/modules/4.1.29-fslc+g59b38c3/kernel/drivers/mtd/tests/mtd_speedtest.ko dev=2 To check your NAND is in EDO mode 5, you can check your clock tree: / unit_tests / dump - clocks . sh clock          parent   flags    en_cnt pre_cnt      rate [ . . . ] gpmi_bch_apb   -- -       00000005    0        0        198000000 gpmi_bch       -- -       00000005    0        0        198000000 gpmi_io        -- -       00000005    0        0         99000000 gpmi_apb       -- -       00000005    0        0        198000000 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ The IO are clocked now at 99MHz, thus you can read at 49.5MHz (20ns in EDO mode 5 definition).
View full article
///////////////////////////create device node /dev/galcore///////////////////////////// $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/Kbuild MODULE_NAME ?= galcore /* define node name*/ $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h define DEVICE_NAME "galcore" $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_probe.c drv_init call ret = register_chrdev(major, DEVICE_NAME, &driver_fops); ///////////////////////////////opengles2 functios/////////////////////////////////////////// myandroid/device/fsl-proprietary/gpu-viv/lib/egl/libGLESv2_VIVANTE.so glActiveTexture glBindBuffer ... ... ... //those glxxxxxx call into sub_D40C int __fastcall sub_D40C(int a1, int a2, int a3) //address 0x0000D40C { int result; // r0@1 int v4; int v5; v4 = a2;   v5 = a3;   gcoOS_GetTLS(&v4);  //------------> goto libGAL.so   result = v4;   if ( v4 )     result = *(_DWORD *)(v4 + 36);   return result; } and $home/myandroid/device/fsl-proprietary/gpu-viv/lib/libGAL.so //export function signed int __fastcall gcoOS_GetTLS(void **a1) { ... ... gcoOS_GetTLS v4 = open("/dev/galcore", 2); ... ... } and device node /dev/galcore pass command into module galcore $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c gckKERNEL_Dispatch This document was generated from the following discussion: Share Vivante 3d gc2000 work flow
View full article
1.- Set SW602 Boot mode pin settings to Serial Downloader mode 2.-Connect JTAG debug probe and turn on the board 3.-Run script to bring-up DRAM In Lauterbach this script is called 'mcimx6ul_sieve_dram.cmm' under the mcimx6ul folder, the scripts can be found here and are also attached (download the imx6ultralite package). If you are not using Lauterbach please ask your probe vendor for a similar script. NOTE: this u-boot image has been built to run off DRAM if your bootloader runs from OCRAM you might not need a script. While running the script you might be prompted with and error telling you there is a syntax error in the script system.cpu IMX6ULL simply edit the script and change the CPU name to IMX6ULTRALITE 4.- Load u-boot.srec to DRAM and start executing it The srec is being used in this case because it contains the addresses where the binary needs to be loaded and the entry point for the application is automatically recognised and set by Lauterbach. To load it simply issue 'data.load.S3record u-boot.srec' and then click on go to let it run. You should now be able to see the output from u-boot on the console hit any key on the console to stop the boot process. 5.- Load QuadSPI configuration to DRAM and flash it to the memory The Boot ROM on the i.MX6UL requires the configuration data for the QuadSPI memory to be stored at address 0x400 of the QuadSPI memory, the length of this configuration data is 512 bytes. Attached is a configuration binary that can be used for the NOR flash memory used in the i.MX6UL EVK. For more details on the configuration parameters please refer to chapter '8.6.3 QuadSPI Configuration Parameters' of the i.MX6UL Reference Manual. Stop the execution on T32 (Lauterbach's environment) and load the configuration to DRAM by issuing 'data.load.binary QSPI_cfg2.bin 0x90000000' and resume execution. On u-boot execute the 'sf probe' command (sf stands for Serial Flash) to detect the memory. You should see an output like the following: => sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB Now issue the sf erase command to erase the first sector (remember our erase size is of 4KiB): => sf erase 0x0 0x1000 SF: 4096 bytes @ 0x0 Erased: OK Now we are ready to write our configuration to address 0x400 => sf write 0x90000000 0x400 0x200 SF: 512 bytes @ 0x400 Written: OK 6.- Load u-boot.imx to DRAM and download it to memory. We will follow the same procedure to download the u-boot image to the memory. Stop execution on Lauterbach and load u-boot.imx to DRAM using 'data.load.binary u-boot_SPI.imx 0x90000000' and resume execution (u-boot.imx contains the IVT header which basically stores all the information the device needs to boot u-boot.bin and u-boot.imx). The boot ROM expects to find the IVT header at address 0x1000 of the SPI NOR Flash memory. We will load u-boot.imx to this address by issuing ' sf update 0x90000000 0x1000 0x57830 '(the size of u-boot.imx is 358448 bytes) this will erase and write the memory. => sf update 0x90000000 0x1000 0x57830 358448 bytes written, 0 bytes skipped in 23.741s, speed 15458 B/s If you want to verify that the image was flashed correctly you can read from QuadSPI to DRAM by issuing 'sf read 0x90000000 0x1000 0x57830 ' and verify the data. 7.- Now we can end our debug session and turn off our board Set SW602 to Internal boot mode (ON/OFF) and SW601 to select boot from QuadSPI (all OFF) Turn on the board again and you should be able to see u-boot's output on your terminal. This procedure can be used with other boards/i.MX6 derivatives, I am just posting the setup in which I tested it.
View full article
Important:  If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the   i.MX community.  Please note that any private messages or direct emails are not monitored and will not receive a response. i.MX 6/7 Family DDR Stress Test   i.MX6/7 DDR Stress Test Tool is a PC-based software to fine-tune DDR parameters and verify the DDR performance on a non-OS, single-task environment(it is a light-weight test tool to test DDR performance). It performs write leveling, DQS gating and read/write delay calibration features.   There are three options to run the DDR Stress test. Each of these options are provided in the attached zip files. The following is a high-level overview of each option along with the naming convention of the associated zip file:   Option 1 GUI based: Run the GUI executable and connect your board to the host PC via USB Archive file: ddr_stress_tester_vX.xx.zip The tool will first need to run a DDR initialization script for the specified i.MX SoC (refer to Load Init Script in the GUI tool).  Example initialization scripts based on NXP's development boards can be found in this zip file under the script folder.  Note, these scripts may need to be modified for your custom board and memory.   Option 2 DDR Stress Tester: JTAG Interface A hardware debugger connected to the board via the JTAG interface is used to download an elf file into the i.MX SoC OCRAM (internal RAM) and then begin execution. Results are shown on the UART serial port (115200-8-n-1). Archive file: ddr_stress_tester_jtag_vX.xx.zip As with the GUI tool, the JTAG/debugger option will first need to run a DDR initialization script for the specified i.MX SoC. Refer to the GUI tool description above for the location of the example scripts (which are found in the ddr_stress_tester_vX.xx.zip file). Note that the scripts are available either in the RealView ICE format (.inc file) or the DS-5 DSTERAM format (.ds). For other debuggers, the user will have to modify the script's command syntax for their specific debugger. This is also true if converting from a RealView Ice (.inc) format to a DS-5 DSTREAM (.ds) format and vice versa. The DDR Stress Tester executable (starting with V2.20) has an auto UART detection feature. If a different UART port for the serial console has been chosen than used on the NXP development tool (EVK, SABRE) specific commands can be added to the DDR initialization script that allows you to configure for the specific UART and then load and run the elf executable. Refer to the FAQ section of this community post and the txt file found in the JTAG archive file for instructions.   Option 3 U-Boot: The boot loader u-boot is running and commands in u-boot are used to download the bin file into SoC OCRAM and begin execution. Results are shown on the UART serial port (115200-8-n-1) Archive file: ddr_stress_tester_uboot_vX.xx.zip When downloading the DDR Stress Tool by u-boot, please copy the ddr-test-uboot-jtag-mxxxx.bin to SD card and load it to IRAM using the 'fatload' u-boot command. For i.MX6, please load the binary to 0x00907000. For i.MX7D, please load the binary to 0x00910000.  It is imperative to first disable the I and D cache in u-boot as shown below as the DDR Stress Test re-configures and re-enables the cache and MMU page table. The following is an example of downloading and running the DDR stress test from u-boot: u-boot> dcache off u-boot> icache off u-boot> fatload mmc 0:1 0x00907000 ddr-test-uboot-jtag-mx6ul.bin u-boot> go 0x00907000   Stress Test Revision Features Comments 3.00 Add i.MX 7ULP support in the GUI version Known issues: USB connection is unstable when under USB HUB or some PC environments 2.92 Minor correction with write leveling calibration code error check to avoid a corner case of flagging an error when none have occurred.  2.91 Resolved issue with write leveling calibration code where a race condition in the code may result in the calibration routine not being able to find any delay values.   Only applies to MX6 series SoCs that support DDR3.   2.90 Reserve write delay line register (MMDC_MPWRDLCTL) configuration as DDR script does when do write calibration. In previous releases, MMDC_MPWRDLCTL would be changed to 0x40404040 by default.  * Further details available in the release notes  _________________________________________________________________________________________________________________________________________    FAQ   Q. I see an error message that states "ERROR: DCD addr is out of valid range.", why is this and how do I resolve? A. Sometimes, when using the register programming aid, there are registers writes that are not supported in the DCD range.  Try looking for the following items and comment them out from the DDR initialization script: wait = on setmem /16 0x020bc000 = 0x30 // disable watchdog (note the address for this may be different between i.MX6x devices)  Q. How do I select the "DDR Density" pull-down menu and what is the purpose of this? A. The DDR Density pull-down menu gives the user the option of testing a DDR density smaller than what they actually have on their board.  The advantage of doing this is to speed up test time to allow the user to perform a "quick test" of their system.  IMPORTANT: it is imperative that the user not set this value higher than the supported density on their board, doing so will cause the stress test to fail and/or lock up. The DDR Density has a different meaning depending on the memory type being tested (DDR3 or LPDDR2): For DDR3, this is the density per CHIP SELECT.  So if your board has two chip selects, and each chip select has 512MB, you would simply select 512MB or lower.  The default setting will simply set this to the detected density per chip select. For LPDDR2, this is the density per CHANNEL.  This is only relevant for MX6 devices that support 2 channel LPDDR2 memories (MX6DQ, MX6DL).  For other MX6 devices that support only one LPDDR2 channel, then this is the total density (for the maximum setting) for that channel. Note that for LPDDR2, the number of chip selects (per channel) is irrelevant when selecting the density to test as the stress test combines both chip-selects into one combined density per channel.  For example, lets say you have a 2GB LPDDR2 device, which 2 channels and 2 chip-selects per channel.  That means you have 512MB per chip select, per channel.  Or, it also means you have 1GB per channel when combining both chip selects per channel.  In this case, you would choose (a maximum setting of) 1GB in the DDR Density drop down menu.  However, this is also the same setting as the default setting (which you are welcome to still choose 1GB to convince yourself that 1GB per channel is indeed being tested). Now let's assume you have only one channel (LPDDR2) and one chip select, with a density of 128MB; in this case, the maximum DDR Density you can select is 128MB. Let's assume you have one channel and two chip selects, each chip select is 128MB;  in this case, the maximum DDR Density you can select is 256MB (a combination of both chip selects).   Note, for the MX7D, an actual density needs to be entered. For the MX6x series, simply leaving this field as Default will cause the DDR stress test to ascertain the supported density from the DDR init script. As the MX7D DDR controller is different, this feature is not supported, hence it is required for the user to enter an actual density (for more details regarding MX7D usage of density and number of chip-selects, see the next FAQ on the DDR CS setting).   Q.  What is the purpose of the "DDR CS" pull-down option? A.  The answer depends on which processor you are testing:   For the i.MX 6x series: This pull down menu gives you the option of testing one chip select (CS0) or ALL (both) chip selects *IF* you have a two-chip select configuration.  If you have a two-chip select configuration, then this allows you to test only one chip select for faster test time; else you can choose to test both chip selects.  Note that if you have a one-chip select configuration and you choose "ALL", the stress test will return an error.   For the iMX 7D: Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next. For example, let’s assume you are using two chip selects, with each chip select being 512MB. In this case, you would enter 1GB for the DDR Density field ensuring that both chip selects will be tested. The user is allowed to enter a density less than the density found on their board (for quicker testing), but keeping in mind both chip selects may not be tested in this case.   Q. I run DDR calibration using the DDR Stress Test Tool to obtain the calibration results.  Are these calibration parameters are written to the uboot flash_header.S automatically or manually? A. The calibration values obtained from the DDR Stress Test Tool will need to be manually updated in the flash_header.S file or any other DDR initialization script.   Q. When running the DDR stress test on MX7D and I try to perform calibration, I get an error stating that calibration is not supported, is this expected? A. Yes, calibration is not supported or needed when using MX7.  The reason is, MX7 uses a different memory controller than the MX6 series.  The MX6 series memory controller has built-in support for calibration where the MX7 memory controller does not.   Q. When running the GUI version of the DDR stress test, on MX7 and I leave DDR Density as default, I get an error in the tool stating I must supply a density.  Why is this? A. This is due to the fact that MX7 uses a different memory controller than the MX6 series.  In the MX6 series, it was possible to calculate the memory density from the memory controller register settings.  The MX7 memory controller is different and does not lend itself to easily calculate the supported density based on the register settings.  Instead, the user should verify the density on their board and selected this value in the DDR Density pull-down menu.    Q. I noticed that when I run write-leveling calibration I sometimes see a note that due to the write-leveling calibration value being greater than 1/8 clock cycle that WALAT must be set to 1.  What does this mean? A. In the MMDC chapter of the reference manual for the specific i.MX 6 device, the need to set WALAT is described in the MDMISC register as follows: " The purpose of WALAT is to add time delay at the end of a burst write operation to ensure that the JEDEC time specification for Write Post Amble Delay (tWPST) is met (DQS strobe is held low at the end of a write burst for > 30% a clock cycle before it is released). If the value of any of the WL_DL_ABS_OFFSETn register fields are greater than ‘1F’, WALAT should be set to ‘1’ (cycle additional delay). WALAT should be further increased for any full-cycle delays added by the WL_CYC_DELn register fields. " Therefore, if the write-leveling calibration routine detects any write-leveling delay value greater than 0x1F, it will note to the user that WALAT must be set and the user should update their DDR3 init script to ensure WALAT is set.  Sometimes, a user may find that the write-leveling delay value may fluctuate from one run to the next, which is quite normal.  If it is found that this delay is "borderline" meaning sometimes it is greater than 0x1F and sometimes it might be slightly less, then it is ok to go ahead and set WALAT permanently in your init script as there is no harm in doing so and will ensure you will stay within JEDEC's tWPST.   Q. I sometimes see that after running write-leveling calibration that delay values being reported back are zero'd out (0x00), and then at times I see a non-zero value being reported, why is this? A. It is quite normal to see slight variations in the delay value between write-leveling calibration runs.  The write-leveling calibration routine assumes a majority of users have designed their board such that the DDR3 memories are placed close to the i.MX 6 SoC. There’s a mechanism in NXP’s DDR Stress test write leveling calibration code that checks the returned write leveling value. If the write-leveling calibration routine detects that the returned delay value is greater than ¾ of a clock cycle, it will "zero out" the delay value. It does this because it assumes that such a large delay result is due to the fact that the DQS signal is already delayed relative to the SDCLK, and to align DQS with SDCLK requires the calibration routine to delay DQS even further to align it to the next SDCLK edge, something we ideally would like to avoid.  JEDEC specs that the DQS edge must be within 25% of a SDCLK cycle with respect to the SDCLK edge, so having DQS initially slightly delayed from SDCLK is actually ok, hence why the calibration routine “zero’s” this out when the returned value exceeds ¾ of a clock cycle.  In cases like this, the DQS edge and SDCLK edge are so close together that in some calibration runs, the DQS edge may slightly precede SDCLK (resulting in a very small write-leveling delay value) and other runs, it may be slightly delayed relative to the SDCLK (resulting in a very large write-leveling delay value that will try to align DQS to the next SDCLK edge, hence needs to be zero’d out).   Q. When using the JTAG version of the DDR stress test, how can I select a different UART port for my serial port? A. Under the folder ddr_stress_tester_jtag_v2.52, there's a text file that describes how to add a different UART port by adding a few additional commands to your DDR init script.  The following is an outline of these commands: 1. Ungate UART module clocks (most NXP scripts ungate all of the peripheral clocks at the beginning of the script, so this part is already done) 2. Configure the IOMUX options for the pins you wish the UART to use (normally an IOMUX option for UART_TX and UART_RX, and a daisy chain option for the UART_RX input) 3. Enable the desired UART module via the register UCR1, bit UART_EN 4. Disable other UART modules (UCR1[UART_EN] = 0).  Normally disabling UART1 should be sufficient, but it doesn't hurt to disable all of the other un-used UART options for the purpose of the stress test.   Here's an example in the .ds file vernacular of a set up as follows: MX6DQ, UART4 on KEY_COL0 and KEY_ROW0 (assume clock is ungated to all peripherals): mem set 0x020E01F8 32 0x00000004   #// config_pad_mode(KEY_COL0, ALT4) mem set 0x020E01FC 32 0x00000004   #// config_pad_mode(KEY_ROW0, ALT4); mem set 0x020E0938 32 0x00000001   #// Pad KEY_ROW0 is involved in Daisy Chain. mem set 0x02020080 32 0x00000000   #//disable UART1 in UART1_UCR1 (Note, you can disable other UART modules as well) mem set 0x021F0080 32 0x00000001   #//enable UART4 in UART4_UCR1   Here's another example in the .inc file vernacular of a set up as follows: MX6SX, UART5 on SD4_DATA4 abd SD4_DATA5 (assume clock is ungated to all peripherals): setmem /32 0x020E0294 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA5, ALT2; UART5_TX_DATA setmem /32 0x020E0290 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA4, ALT2; UART5_RX_DATA setmem /32 0x020E0850 = 0x00000000 // IOMUXC_UART5_IPP_UART_RXD_MUX_SELECT_INPUT, daisy chain for UART5_RX input to use SD4_DATA4 setmem /32 0x021F4080 = 0x00000001 // Enable UART_EN in UCR1 of UART5 // Disable UART_EN in UCR1 of UART1, UART2, UART3, and UART4 setmem /32 0x02020080 = 0x00000000 // UART1 setmem /32 0x021F0080 = 0x00000000 // UART2 setmem /32 0x021EC080 = 0x00000000 // UART3 setmem /32 0x021E8080 = 0x00000000 // UART4   Related Resources Links: iMX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 8M Family DDR Tool Release 
View full article
INTRODUCTION REQUIREMENTS KERNEL DRIVER DEVICE NODE NFC LIBRARY TESTING NFC READER REFERENCES 1. INTRODUCTION This document is a step by step guide of the AN11697 PN7120 Linux Software Stack Integration Guidelines application note that can be downloaded from http://www.nxp.com/documents/application_note/AN11697.pdf . It explains how to add the PN7120 driver and NFC libraries to a Linux OS running in the i.MX6Q. 2. REQUIREMENTS The board used in this document is the Udoo Board thanks to the easy pin access. More information about this board can be found at Ultimate Single Board Mini PC for Android and Linux - UDOO A modified FSL L3.14.28 BSP. The modifications can be found in these 2 documents Basic Device Tree for the Udoo Board and  U-Boot Migration Example . If you have followed the previous documents, you already have a working yocto image and toolchain (meta-toolchain), if not you must follow this awesome training first Yocto Training - HOME . The OM5577/PN7120S demonstration kit. You can find more details of this board at http://www.nxp.com/documents/user_manual/UM10878.pdf 3. KERNEL DRIVER According to the AN11697.pdf we must follow the below steps: From the Linux source directory: $ cd drivers/misc $ git clone https://github.com/NXPNFCLinux/nxp-pn5xx.git Add the below line in the Makefile of the current directory obj-y += nxp-pn5xx/ Include the driver config in the drivers/misc/Kconfig file source "drivers/misc/nxp-pn5xx/Kconfig" Export the environment variables $ source source /opt/poky/1.7/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi $ export ARCH=arm $ export CROSS_COMPILE=$TARGET_PREFIX $ make imx_v7_defconfig Using menuconfig include the driver as module (<M>).  Compile the modules and install the .ko files into the target rootfs. $ make  modules You can send the .ko files with scp $ make  INSTALL_MOD_PATH=~/Desktop/modules modules_install $ cd ~/Desktop/modules $ sudo scp -r lib/modules/3.14.28+g91cf351/kernel root@<board_ip>:/lib/modules/3.14.28+g91cf351/ 4. DEVICE NODE The PN7120 interfaces with an MCU or MPU via I2C interface, therefore the device must be described into a i2c node. The signals used in the PN7120 are shown below: As you can see besides power, ground and I2C lines, an IRQ and Reset pins are needed. These pins must be configured as GPIO and one must generate an interrupt to the iMX6Q. The chosen connection is shown below: To achieve the above configuration, the device tree must be changed. The changes consist on adding a device node in the corresponding I2C bus, describing the PN7120. &i2c1 {         clock-frequency = <100000>;         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_i2c1>;         status = "okay";         pn547: pn547@28 {                 compatible = "nxp,pn547";                 reg = <0x28>;                 clock-frequency = <400000>;                 interrupt-parent = <&gpio6>;                 interrupt-gpios = <&gpio6 2 0>;                 enable-gpios = <&gpio5 22 0>;         }; }; The pinctrl_i2c1 phandle contains the I2C pins configuration. Make sure that the PADs connected to the PN7120 are not used in other device node. &iomuxc {         imx6q-udoo {                       ...                 pinctrl_i2c1: i2c1grp {                         fsl,pins = <                         MX6QDL_PAD_GPIO_5__I2C3_SCL             0x4001b8b1                         MX6QDL_PAD_GPIO_6__I2C3_SDA             0x4001b8b1                         >;                 };         }; }; After this you can generate the dtb file and send it with scp make dtbs sudo scp arch/arm/boot/dts/imx6q-udoo.dtb root@<board_ip>:/run/media/mmcblk0p1/imx6q-udoo.dtb NOTE: Attached you can find the complete dts and dtsi files used in this document. 5. NFC LIBRARY     To work with the PN7120 in Linux the libnfc-nci stack is needed. You can find more details in http://www.nxp.com/documents/application_note/AN11697.pdf​ . This sections explains how to cross-compile the libray and install the required files in the target (The below steps must be performed in the host). Get the library $  git clone https://github.com/NXPNFCLinux/linux_libnfc-nci.git Generate the configuration script $ ./bootstrap Mount the target rootfs to /mnt in the host. $ sudo mount /dev/sdX2 /mnt Generate the Makefile $ ./configure --host=arm-none-linux --prefix=/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr --sysconfdir=/mnt/etc Build and install the source code $ make $ make install After a succesful bulding the libraries and a application demo are built in .libs directory. Copy the libaries to /usr/lib directory of the target and nfcDemoApp to /usr/sbin $ cd linux_libnfc-nci/.libs $ sudo cp * /mnt/usr/lib/ 6. TESTING NFC READER     To test the application you have to follow the below steps on the target: Install the .ko file $ insmod /lib/modules/3.14.28+g91cf351/kernel/drivers/misc/nxp-pn5xx/pn5xx_i2c.ko Run the nfcDemoApp $  nfcDemoApp poll You should get a console output like the shown below when placing a NFC tag next to the NFC reader. 7. REFERENCES     Integrating NFC Controller library with KSDK http://www.nxp.com/documents/application_note/AN11697.pdf http://www.nxp.com/documents/user_manual/UM10878.pdf
View full article
Introduction The "smart" package management system is available in  Yocto Project for managing  packages on a target machine. A host is configured as a server for the packages and on the target the "package-management" feature is enabled for working with the packages. The steps for setup and usage are described below. Resources The Yocto Project package management system will work with many hosts and targets. The following were used for creating this document: Host: Ubuntu 14.04 64-bit Target: MCIMX6Q-SDP Freescale Yocto Project Release Documentation: Linux 3.14.38_6ul BSP & Multimedia Codecs Documentation (fsl-yocto-L3.14.38_6ul-ga.tar.gz) Host You have successfully installed a Freescale Yocto Project release. (Refer to Freescale Yocto Project Release Documentation). There are two steps for adding package management and then building: 1. Modify conf/local.conf EXTRA_IMAGE_FEATURES = "debug-tweaks package-management" ‍ 2. Build the image: bitbake core - image - minimal ‍ The core-image-minimal recipe provides an image enabling the target board to boot and support a serial console. 3. Create SDCARD: $ cd < build > / tmp / deploy / images / imx6qsabresd $ sudo dd if = core - image - minimal - imx6qsabresd . sdcard of = / dev / sdb bs = 4M & & sync ‍ ‍ Note - verify location of SDCARD on your host, /dev/sdb in this example. Examine 'cat /proc/partitions' 4. Setup web server and add link to rpm packages A web server, lighttpd, is installed. $ sudo apt - get install lighttpd ‍ Provide user write capability in /var/www $ sudo chmod 777 / var / www ‍ Create a soft link in the default web server directory to the rpm directory from the build. Note: Please update $HOME/<build> to your actual location: $ ln - s $HOME / < build > / tmp / deploy / rpm / var / www / imx6qsd ‍ ‍ ‍ Target Insert the SDCARD created from step 3 above, connect power and console cable  and power on the MCIMX6Q-SDP. Login using the "root" id, no password required. The /usr/bin/smart application is now used to setup the channels and perform package commands. For all smart options: smart - - help ‍ 1. Add channels To add the packages from the host to your target, the smart  channel --add is used: Please enter the IP adress of your server, replacing SERVERIP below: smart channel - - add all type = rpm - md name = all baseurl = http : // SERVERIP / imx6qsd / all smart channel - - add cortexa9hf_vfp_neon type = rpm - md name = cortexa9hf_vfp_neon baseurl = http : // SERVERIP / imx6qsd / cortexa9hf_vfp_neon smart channel - - add imx6qsabresd type = rpm - md name = imx6qsabresd baseurl = http : // SERVERIP / imx6qsd / imx6qsabresd ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Check  the added channels: root@imx6qsabresd : ~ # smart channel --list all imx6qsabresd rpmsys cortexa9hf_vfp_neon ‍ ‍ ‍ ‍ ‍ 2. Update  local package cache Once the chanels have been added, the local package cache is updated. Note  SERVERIP below will be the host IP address in your network. root@imx6qsabresd:~# smart update Loading cache... Updating cache...               ######################################## [100%] Fetching information for 'all'...                                           -> http://SERVERIP/imx6qsd/all/repodata/repomd.xml                           repomd.xml                      ######################################## [ 16%]                                                                             Fetching information for 'imx6qsabresd'... -> http://SERVERIP/imx6qsd/imx6qsabresd/repodata/repomd.xml                  repomd.xml                      ######################################## [ 41%]                                                                             Fetching information for 'cortexa9hf_vfp_neon'... -> http://SERVERIP/imx6qsd/cortexa9hf_vfp_neon/repodata/repomd.xml           repomd.xml                      ######################################## [ 66%] Updating cache...               ######################################## [100%] Channels have no new packages. 3. Searching for packages Let us look at all packages containing the string client root@imx6qsabresd : ~ # smart search client* Loading cache . . . Updating cache . . .                ######################################## [100%] libice - dbg - ICE : Inter - Client Exchange library - Debugging files libice - dev - ICE : Inter - Client Exchange library - Development files libice - doc - ICE : Inter - Client Exchange library - Documentation files libice - staticdev - ICE : Inter - Client Exchange library - Development files ( Static Libraries ) libice6 - ICE : Inter - Client Exchange library libsm - dbg - SM : Session Management library - Debugging files libsm - dev - SM : Session Management library - Development files libsm - doc - SM : Session Management library - Documentation files libsm - staticdev - SM : Session Management library - Development files ( Static Libraries ) libsm6 - SM : Session Management library libx11 -6 - Xlib : C Language X Interface library libx11 - dbg - Xlib : C Language X Interface library - Debugging files libx11 - dev - Xlib : C Language X Interface library - Development files libx11 - doc - Xlib : C Language X Interface library - Documentation files libx11 - locale - Xlib : C Language X Interface library libx11 - staticdev - Xlib : C Language X Interface library - Development files ( Static Libraries ) libx11 - xcb1 - Xlib : C Language X Interface library libxau - dbg - Xau : X Authority Database library - Debugging files libxau - dev - Xau : X Authority Database library - Development files libxau - doc - Xau : X Authority Database library - Documentation files libxau - staticdev - Xau : X Authority Database library - Development files ( Static Libraries ) libxau6 - Xau : X Authority Database library python - netclient - Python Internet Protocol clients xtrans - dbg - XTrans : X Transport library - Debugging files xtrans - dev - XTrans : X Transport library - Development files xtrans - doc - XTrans : X Transport library - Documentation files ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Adding openssh client to core-image minimal The core-image-minimal does not provide openssh client applications like ssh or scp. Let's add them on the host then update the target cache of packages and then install. Host Run bitbake to exercise all the tasks for packagegroup-core-ssh-openssh $ bitbake packagegroup - core - ssh - openssh ‍ After building a package individually, always update the package-index $ bitbake package - index ‍ Target Run smart to update the local cache which will pickup the new packages from the bake above. root@imx6qsabresd : ~ # smart update Loading cache . . . Updating cache . . .                ######################################## [100%] Fetching information for 'all' . . .                                               - > http : // SERVERIP / imx6qsd / all / repodata / repomd . xml                           repomd . xml                      ######################################## [ 16%] - > http : // SERVERIP / imx6qsd / all / repodata / primary . xml . gz                       primary . xml . gz                  ######################################## [ 25%] - > http : // SERVERIP / imx6qsd / all / repodata / filelists . xml . gz                     filelists . xml . gz                ######################################## [ 33%]                                                                                Fetching information for 'imx6qsabresd' . . . - > http : // SERVERIP / imx6qsd / imx6qsabresd / repodata / repomd . xml                  repomd . xml                      ######################################## [ 50%] - > http : // SERVERIP / imx6qsd / imx6qsabresd / repodata / primary . xml . gz              - > http : // SERVERIP / imx6qsd / imx6qsabresd / repodata / filelists . xml . gz            filelists . xml . gz                ######################################## [ 58%] primary . xml . gz                  ######################################## [ 66%]                                                                                Fetching information for 'cortexa9hf_vfp_neon' . . . - > http : // SERVERIP / imx6qsd / cortexa9hf_vfp_neon / repodata / repomd . xml           repomd . xml                      ######################################## [ 83%] - > http : // SERVERIP / imx6qsd / cortexa9hf_vfp_neon / repodata / primary . xml . gz       primary . xml . gz                  ######################################## [ 91%] - > http : // SERVERIP / imx6qsd / cortexa9hf_vfp_neon / repodata / filelists . xml . gz     filelists . xml . gz                ######################################## [100%] Updating cache . . .                ######################################## [100%] Channels have 15 new packages . Saving cache . . . ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Examine information about local cache: root@imx6qsabresd : ~ # smart stats Loading cache . . . Updating cache . . .                ######################################## [100%] Installed Packages : 80 Total Packages : 3586 Total Provides : 6580 Total Requires : 1611 Total Upgrades : 3565 Total Conflicts : 25 ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ See what ssh packages are now available: root@imx6qsabresd : ~ # smart search *ssh* Loading cache . . . Updating cache . . .                ######################################## [100%] openssh - Secure rlogin / rsh / rcp / telnet replacement openssh - dbg - Secure rlogin / rsh / rcp / telnet replacement - Debugging files openssh - dev - Secure rlogin / rsh / rcp / telnet replacement - Development files openssh - doc - Secure rlogin / rsh / rcp / telnet replacement - Documentation files openssh - keygen - Secure rlogin / rsh / rcp / telnet replacement openssh - misc - Secure rlogin / rsh / rcp / telnet replacement openssh - ptest - Secure rlogin / rsh / rcp / telnet replacement - Package test files openssh - scp - Secure rlogin / rsh / rcp / telnet replacement openssh - sftp - Secure rlogin / rsh / rcp / telnet replacement openssh - sftp - server - Secure rlogin / rsh / rcp / telnet replacement openssh - ssh - Secure rlogin / rsh / rcp / telnet replacement openssh - sshd - Secure rlogin / rsh / rcp / telnet replacement packagegroup - core - ssh - openssh - OpenSSH SSH client / server packagegroup - core - ssh - openssh - dbg - OpenSSH SSH client / server - Debugging files packagegroup - core - ssh - openssh - dev - OpenSSH SSH client / server - Development files ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Install openssh root@imx6qsabresd : ~ # smart install openssh Loading cache . . . Updating cache . . .                ######################################## [100%] Computing transaction . . . Installing packages ( 9 ) :   openssh -6. 7p1 - r0@cortexa9hf_vfp_neon                                            openssh - keygen -6. 7p1 - r0@cortexa9hf_vfp_neon                                     openssh - scp -6. 7p1 - r0@cortexa9hf_vfp_neon                                        openssh - ssh -6. 7p1 - r0@cortexa9hf_vfp_neon                                        openssh - sshd -6. 7p1 - r0@cortexa9hf_vfp_neon                                       shadow -4.2 . 1 - r0@cortexa9hf_vfp_neon                                             shadow - base -4.2 . 1 - r0@cortexa9hf_vfp_neon                                        shadow - securetty -4.2 . 1 - r3@imx6qsabresd                                          util - linux - sulogin -2.25 . 2 - r1@cortexa9hf_vfp_neon                              1. 4MB of package files are needed . 3. 2MB will be used . Confirm changes? ( Y / n ) : y Fetching packages . . .                                                            - > http : // SERVERIP / imx6qsd / . . . / openssh -6. 7p1 - r0 . cortexa9hf_vfp_neon . rpm      - > http : // SERVERIP / imx6qsd / . . . / shadow - securetty -4.2 . 1 - r3 . imx6qsabresd . rpm    shadow - securetty -4.2 . 1 - r3 . imx . . ######################################## [ 11%] - > http : // SERVERIP / imx6qsd / . . . / openssh - scp -6. 7p1 - r0 . cortexa9hf_vfp_neon . rpm openssh - scp -6. 7p1 - r0 . cortexa9 . . ######################################## [ 22%] openssh -6. 7p1 - r0 . cortexa9hf_v . . ######################################## [ 33%] - > http : // SERVERIP / imx6qsd / . . . / openssh - sshd -6. 7p1 - r0 . cortexa9hf_vfp_neon . rpm openssh - sshd -6. 7p1 - r0 . cortexa . . ######################################## [ 44%] - > http : // SERVERIP / imx6qsd / . . . / shadow -4.2 . 1 - r0 . cortexa9hf_vfp_neon . rpm       - > http : // SERVERIP / imx6qsd / . . . / openssh - ssh -6. 7p1 - r0 . cortexa9hf_vfp_neon . rpm openssh - ssh -6. 7p1 - r0 . cortexa9 . . ######################################## [ 55%] - > http : // SERVERIP / imx6qsd / . . . / shadow - base -4.2 . 1 - r0 . cortexa9hf_vfp_neon . rpm shadow - base -4.2 . 1 - r0 . cortexa9 . . ######################################## [ 66%] shadow -4.2 . 1 - r0 . cortexa9hf_vf . . ######################################## [ 77%] - > http : // SERVERIP / . . . / util - linux - sulogin -2.25 . 2 - r1 . cortexa9hf_vfp_neon . rpm util - linux - sulogin -2.25 . 2 - r1 . . . ######################################## [ 88%] - > http : // SERVERIP / . . . / openssh - keygen -6. 7p1 - r0 . cortexa9hf_vfp_neon . rpm       openssh - keygen -6. 7p1 - r0 . corte . . ######################################## [100%]                                                                                Committing transaction . . . Preparing . . .                     ######################################## [  0%]    1 : Installing openssh - ssh     ######################################## [ 11%] Output from openssh - ssh -6. 7p1 - r0@cortexa9hf_vfp_neon :                           update - alternatives : Linking / usr / bin / ssh to / usr / bin / ssh . openssh                 2 : Installing openssh - scp     ######################################## [ 22%] Output from openssh - scp -6. 7p1 - r0@cortexa9hf_vfp_neon :                           update - alternatives : Linking / usr / bin / scp to / usr / bin / scp . openssh                 3 : Installing shadow - secure . . ######################################## [ 33%]    4 : Installing shadow - base     ######################################## [ 44%] Output from shadow - base -4.2 . 1 - r0@cortexa9hf_vfp_neon :                           update - alternatives : Linking / usr / bin / newgrp to / usr / bin / newgrp . shadow         update - alternatives : Linking / usr / bin / groups to / usr / bin / groups . shadow update - alternatives : Linking / bin / login to / bin / login . shadow update - alternatives : Linking / bin / su to / bin / su . shadow    5 : Installing util - linux - su . . ######################################## [ 55%] Output from util - linux - sulogin -2.25 . 2 - r1@cortexa9hf_vfp_neon :                   update - alternatives : Linking / sbin / sulogin to / sbin / sulogin . util - linux            6 : Installing openssh - keygen  ######################################## [ 66%]    7 : Installing shadow          ######################################## [ 77%] Output from shadow -4.2 . 1 - r0@cortexa9hf_vfp_neon :                                update - alternatives : Linking / usr / bin / passwd to / usr / bin / passwd . shadow         update - alternatives : Linking / usr / bin / chfn to / usr / bin / chfn . shadow update - alternatives : Linking / usr / bin / chsh to / usr / bin / chsh . shadow update - alternatives : Linking / usr / sbin / chpasswd to / usr / sbin / chpasswd . shadow update - alternatives : Linking / sbin / vipw to / sbin / vipw . shadow update - alternatives : Linking / sbin / vigr to / sbin / vigr . shadow Output from openssh - sshd -6. 7p1 - r0@cortexa9hf_vfp_neon :                          Removing any system startup links for sshd . . .                                 Running useradd commands . . . NOTE : Performing useradd with [ - - system - - no - create - home - - home - dir / var / run / sshd - - shell / bin / false - - user - group sshd ] and 10 times of retry    8 : Installing openssh - sshd    ######################################## [ 88%] Adding system startup for / etc / init . d / sshd .                                    Starting OpenBSD Secure Shell server : sshd   generating ssh RSA key . . .   generating ssh ECDSA key . . .   generating ssh DSA key . . .   generating ssh ED25519 key . . . done .    9 : Installing openssh         ######################################## [100%] ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Check for the scp command: root@imx6qsabresd : ~ # which scp / usr / bin / scp ‍ ‍ Summary To add a new package on the server host, run bitbake <recipe> then bitbake package-index to update the rpm tracking information. On the target board, run smart update and then smart install <package>. Use smart search <regular expression string> to hunt for a package to install.
View full article
NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. This page documents the triple-range "smart" current sensor that's part of a larger system for profiling power on application boards. The smart sensor features a Kinetis KL05Z with three current sense amplifiers. It allows measurement currents in three ranges. Four assembly options allow measurement of rail voltages 0-3.3V (two overall current ranges), 0-6.6V, and 12V. It connects to an aggregator, which powers, controls and aggregates data from a number of smart sensor boards. One of the biggest improvements over the older dual-range measurement system is that the on-sensor microcontroller allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler can only make one measurement at a time.  These are intended to be used with a microncontroller board to act as a trigger and data aggregator. This aggregator could also be used to reprogram the sensors.  The series resistance added by the smart sensor when in run mode (highest current range) is under 11 milliOhms as measured with 4-point probes and a Keysight B2902B SMU.  A "power oscilloscope" can be made by triggering measurements at regular intervals and presenting the results graphically.... Schematic: Board Layout, Top: Board Layout, Bottom: Here's a photo of two with a nickel is included to show scale. The board measures about 0.5 by 1.3 inches. Connections: The smart sensor header connections are: 5V: powers the 3.3V regulator, which in turn powers everything else on the sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX: I2C clock line  SDA/RX:  I2C data line  SWD_CLK:  line for triggering smart sensors to make measurements RESET_B:  line for resetting the smart sensor board SWD_IO: select line for the smart sensor Theory of operation: Three shunts and current sense amplifiers are used to measure current in three ranges. One shunt/sense amp pair has a 0.002 Ω shunt integrated into the IC package (U1, INA250). The other two sense amps (U2 and U3, INA212) require an external shunt.  FETs Q1, Q2,  and Q3 are used to switch the two lower range shunt/sense amp pairs in and out of circuit. In normal run operation (highest current range), Q1 (FDMC012N03, with Rds(on) under 1.5m Ω ) is turned on, which shorts leaves only U1 in circuit. FETs Q4, Q5 and Q6 translate the voltages to 3.3V so that GPIO on U4 (MCU KL05Z) can control them.  Rail voltage measurement is facilitated via resistors R3, R4, and R12 and Q7. Not all of these are populated in every assembly option. For measuring rail voltages 0-3.3V, R12 is populated. To measure 0-6.6V, R3, R4,and Q7 are populated. When turned on Q7 enables the voltage divider. All of the assembly option population info can be found in the schematic (attached). Regulator U5 (AP2210N) provides the 3.3V supply for all of the components on the board. This 1% tolerance regulator is used to provide a good reference for the ADC in U4.  Microcontroller U4 detects the assembly population option of the board via resistors R9, R10, and R11 so that the same application code can be used across all variations of the sensor boards. GPIO control the FETs and four ADC channels are used to measure the sense amplifier outputs and the rail voltage. Having a microcontroller on the sensor board allows the user to do extra credit things like count coulombs as well as allowing all similarly instrumented rails to measure at the same time via trigger line SWD_CLK. Data communication can be via I2C or UART, since these two pins can do both.  But if multiple sensor boards are to be used with an aggregator, communication needs to be over I2C. Application Code: The latest application code for the KL05Z on the smart sensor resides here: https://os.mbed.com/users/r14793/code/30847-SMRTSNSR-KL05Z/. The latest binary is attached below. In order to re-flash a smart sensor, the modification detailed in the aggregator page needs to be made. Once the modification is completed, leave the aggregator unpowered while pluging the SWD debugger into J5 and the smart sensor to be programmed into JP15. Very old UART-based application code for the KL05Z, built in the on-line MBED compiler (note that it requires the modified mbed library for internal oscillator). This code was used while testing the first smart sensor prototypes. It has since been abandoned. It's published here in the event that a user wants to use a single sensor plugged into JP15 with UART breakout connector J6. /****************************************************************************** * * MIT License (https://spdx.org/licenses/MIT.html) * Copyright 2017-2018 NXP * * MBED code for KL05Z-based "smart" current sensor board, basic testing * of functions via UART (connected via FRDM board and OpenSDA USB virtual * COM port). * * Eventual goal is to have each smart sensor communicate over I2C to an * aggregator board (FRDM board with a custom shield), allowing 1-10 power * supply rails to be instrumented. Extra credit effort is to support * sensors and aggregator with sigrok... * * Because there is no crystal on the board, need to edit source mbed-dev library * to use internal oscillator with pound-define: * change to "#define CLOCK_SETUP 0" in file: * mbed-dev/targets/TARGET_Freescale/TARGET_KLXX/TARGET_KL05Z/device/system_MKL05Z4.c * ******************************************************************************/ #include "mbed.h" // These will be GPIO for programming I2C address... // not yet implemented, using as test pins... DigitalOut addr0 ( PTA3 ) ; DigitalOut addr1 ( PTA4 ) ; DigitalOut addr2 ( PTA5 ) ; DigitalOut addr3 ( PTA6 ) ; // configure pins for measurements... // analog inputs from sense amps and rail voltage divider... AnalogIn HIGH_ADC ( PTB10 ) ; AnalogIn VRAIL_ADC ( PTB11 ) ; AnalogIn LOW1_ADC ( PTA9 ) ; AnalogIn LOW2_ADC ( PTA8 ) ; // outputs which control switching FETs... DigitalOut VRAIL_MEAS ( PTA7 ) ; // turns on Q7, connecting voltage divider DigitalOut LOW_ENABLE ( PTB0 ) ; // turns on Q4, turning off Q1, enabling low measurement DigitalOut LOW1 ( PTB2 ) ; // turns on Q5, turning off Q2, disconnecting shunt R1 DigitalOut LOW2 ( PTB1 ) ; // turns on Q6, turning off Q3, disconnecting shunt R2 // input used for triggering measurement... // will eventually need to be set up as an interrupt so it minimizes delay before measurement InterruptIn trigger ( PTA0 ) ; // use as a trigger to make measurement... // PTB3/4 can be used as UART or I2C... // For easier development with one smart sensor, we are using UART here... Serial uart ( PTB3 , PTB4 ) ; // tx, rx long int count = 0 ; int n = 25 ; // global number of averages for each measurement int i , temp ; bool repeat = true ; // flag indicating whether measurements should repeat or not const float vref = 3.3 ; // set vref for use in calculations... float delay = 0.25 ; // default delay between measurement bool gui = false ; // flag for controlling human vs machine readable output bool statistics = false ; // flag for outputting min and max along with average (GUI mode only) void enableHighRange ( ) { LOW_ENABLE = 0 ; // short both low current shunts, close Q1 wait_us ( 5 ) ; // delay for FET to settle... (make before break) LOW1 = 0 ; LOW2 = 0 ; // connect both shunts to make lower series resistance VRAIL_MEAS = 0 ; // disconnect rail voltage divider wait_us ( 250 ) ; // wait for B2902A settling... } void enableLow1Range ( ) { LOW1 = 0 ; LOW2 = 1 ; // disconnect LOW2 shunt so LOW1 can measure wait_us ( 5 ) ; // delay for FET to settle... (make before break) LOW_ENABLE = 1 ; // unshort low current shunts, open Q1 VRAIL_MEAS = 0 ; // disconnect rail voltage divider wait_us ( 250 ) ; // wait for B2902A settling... } void enableLow2Range ( ) { LOW1 = 1 ; LOW2 = 0 ; // disconnect LOW1 shunt so LOW2 can measure wait_us ( 5 ) ; // delay for FET to settle... (make before break) LOW_ENABLE = 1 ; // unshort low current shunts, open Q1 VRAIL_MEAS = 0 ; // disconnect rail voltage divider wait_us ( 500 ) ; // wait for B2902A settling... } void enableRailV ( ) { VRAIL_MEAS = 1 ; // turn on Q7, to enable R3-R4 voltage divider wait_us ( 125 ) ; // wait for divider to settle... // Compensation cap can be used to make // voltage at ADC a "square wave" but it is // rail voltage and FET dependent. Cap will // need tuning if this wait time is to be // removed/reduced. // // So, as it turns out, this settling time and // compensation capacitance are voltage dependent // because of the depletion region changes in the // FET. Reminiscent of grad school and DLTS. // Gotta love device physics... } void disableRailV ( ) { VRAIL_MEAS = 0 ; // turn off Q7, disabling R3-R4 voltage divider } // this function measures current, autoranging as necessary // to get the best measurement... void measureAuto ( ) { Timer t ; float itemp ; float tempI = 0 ; float imin = 1.0 ; // used to keep track of the minimum... float imax = 0 ; // used to keep track of the maximum... t . start ( ) ; // use timer to see how long things take... enableHighRange ( ) ; // this should already be the case, but do it anyway... for ( i = 0 ; i < n ; i ++ ) { itemp = HIGH_ADC ; // read HIGH range sense amp output if ( statistics && itemp > imax ) imax = itemp ; // update max if necessary if ( statistics && itemp < imin ) imin = itemp ; // update min if necessary tempI + = itemp ; // add current sample to running sum } tempI = tempI / n * vref / 0.8 ; // compute average we just took... if ( gui ) uart . printf ( "=> %5.3f " , tempI ) ; if ( statistics && gui ) uart . printf ( "[%5.3f/%5.3f] " , imin * vref / 0.8 , imax * vref / 0.8 ) ; // if current is below this threshold, use LOW1 to measure... if ( tempI < 0.060 ) { if ( ! gui ) uart . printf ( "... too Low: %f A, switching to low1 ==>\r\n" , tempI ) ; tempI = 0 ; enableLow1Range ( ) ; // change FETs to enable LOW1 measurement... imin = 1.0 ; imax = 0 ; for ( i = 0 ; i < n ; i ++ ) { itemp = LOW1_ADC ; // read LOW1 sense amp output if ( statistics && itemp > imax ) imax = itemp ; // update max if necessary if ( statistics && itemp < imin ) imin = itemp ; // update min if necessary tempI + = itemp ; // add current sample to running sum } tempI = tempI / n * vref / 0.05 / 1000 ; // compute average we just took... if ( gui ) uart . printf ( "%6.4f " , tempI ) ; if ( statistics && gui ) uart . printf ( "[%6.4f/%6.4f] " , imin * vref / 0.05 / 1000 , imax * vref / 0.05 / 1000 ) ; // if current is below this threshold, use LOW2 to measure... if ( tempI < 0.0009 ) { if ( ! gui ) uart . printf ( "... too Low: %f A, switching to low2 ==>\r\n" , tempI ) ; tempI = 0 ; enableLow2Range ( ) ; // change FETs to enable LOW1 measurement... imin = 1.0 ; imax = 0 ; for ( i = 0 ; i < n ; i ++ ) { itemp = LOW2_ADC ; // read LOW2 sense amp output if ( statistics && itemp > imax ) imax = itemp ; // update max if necessary if ( statistics && itemp < imin ) imin = itemp ; // update min if necessary tempI + = itemp ; // add current sample to running sum } tempI = tempI / n * vref / 2 / 1000 ; // compute average we just took... if ( gui ) uart . printf ( "%8.6f " , tempI ) ; if ( statistics && gui ) uart . printf ( "[%8.6f/%8.6f] " , imin * vref / 2 / 1000 , imax * vref / 2 / 1000 ) ; } } t . stop ( ) ; // stop the timer to see how long it took do do this... enableHighRange ( ) ; if ( ! gui ) uart . printf ( "\r\nCurrent = %f A Current Measure Time = %f sec\r\n" , tempI , t . read ( ) ) ; } // the autoranging should really be done with functions that return values, as should the // functions below... This would make for shorter and more elegant code, but the author // is a bit of a pasta programmer... void measureHigh ( ) { float highI = 0 ; enableHighRange ( ) ; for ( i = 0 ; i < n ; i ++ ) { highI + = HIGH_ADC ; } highI = highI / n ; uart . printf ( "HIghI = %f A\r\n" , vref * highI / 0.8 ) ; } void measureLow1 ( ) { float low1I = 0 ; enableLow1Range ( ) ; for ( i = 0 ; i < n ; i ++ ) { low1I + = LOW1_ADC ; } enableHighRange ( ) ; low1I = low1I / n ; uart . printf ( "low1I = %f A\r\n" , vref * low1I / 0.05 / 1000 ) ; } void measureLow2 ( ) { float low2I = 0 ; enableLow2Range ( ) ; for ( i = 0 ; i < n ; i ++ ) { low2I + = LOW2_ADC ; } enableHighRange ( ) ; low2I = low2I / n ; uart . printf ( "low2I = %f A\r\n" , vref * low2I / 2 / 1000 ) ; } // measure the rail voltage, default being with // a divide by 2 resistor divider // It has to be switched out when not in use or it will // add to the measured current, at least in the low ranges... void measureRailV ( ) { float railv = 0 ; float mult = vref * 2 ; // since divide by 2, we can measure up to 6.6V... float vmin = 5 ; float vmax = 0 ; float vtemp ; enableRailV ( ) ; // switch FETs so divider is connected... for ( i = 0 ; i < n ; i ++ ) { vtemp = VRAIL_ADC ; // read voltage at divider output... if ( statistics && vtemp > vmax ) vmax = vtemp ; // update max if necessary if ( statistics && vtemp < vmin ) vmin = vtemp ; // update min if necessary railv + = vtemp ; // add current sample to running sum } disableRailV ( ) ; // now disconnect the voltage divider railv = railv / n ; // compute average (note this is in normalized ADC [0..1]) // Convert to voltage by multiplying by "mult" if ( ! gui ) uart . printf ( "RailV = %5.3f V " , mult * railv ) ; if ( gui ) uart . printf ( "%5.3f " , mult * railv ) ; if ( statistics && gui ) uart . printf ( "[%5.3f/%5.3f] " , mult * vmin , mult * vmax ) ; uart . printf ( "\r\n" ) ; } // not sure how useful this function is... void measureAll ( ) { measureHigh ( ) ; measureLow1 ( ) ; measureLow2 ( ) ; measureRailV ( ) ; } // test function to see if trigger pin is being hit... // intended for use later to do timed triggering of measurements... void triggerIn ( ) { uart . printf ( "You're triggering me! \r\n" ) ; measureAll ( ) ; } // main... int main ( ) { // set up basic conditions... Timer m ; uart . baud ( 115200 ) ; enableHighRange ( ) ; // default state - only HIGH sense amp in circuit, no divider // signal that we're alive... uart . printf ( "Hello World!\r\n" ) ; // configure the trigger interrupt... trigger . rise ( & triggerIn ) ; while ( true ) { count ++ ; wait ( delay ) ; if ( repeat ) { // if repeat flag is set, keep making measurements... m . reset ( ) ; // reset and start timer... m . start ( ) ; measureAuto ( ) ; // measuring current using auto-ranging... measureRailV ( ) ; // measure rail voltage... m . stop ( ) ; // stop the timer. if ( ! gui ) uart . printf ( " Total Measure Time = %f sec" , m . read ( ) ) ; if ( ! gui ) uart . printf ( "\r\n\r\n" ) ; } // see if there are any characters in the receive buffer... // this is how we change things on the fly... // Commands (single keystroke... it's easier) // t = one shot automeasure // v = measure volt // h = one shot high measure // k = one shot LOW1 measure // l = one shot LOW2 measure (letter l) // r = toggle repeat // R = turn off repeat // + = faster repeat rate // - = slower repeat rate // = = set repeat rate to 0.25 sec // g = use human readable text output // G = use compressed text format for GUI // s = turn statistics output off // S = turn statistics output on (only in GUI mode) // n = decrease number of averages for each measurement // N = increase number of averages for each measurement // // these were for testing FET switching... // 1 = LOW_ENABLE = 0 (the number 1) // 2 = LOW1 = 0 // 3 = LOW2 = 0 // 4 = VRAIL_MEAS = 0 // ! = LOW_ENABLE = 1 // @ = LOW1 = 1 // # = LOW2 = 1 // $ = VRAIL_MEAS = 1 if ( uart . readable ( ) ) { temp = uart . getc ( ) ; if ( temp == ( int ) 't' ) { if ( ! gui ) uart . printf ( "Keyboard trigger: " ) ; measureAuto ( ) ; measureRailV ( ) ; //measureAll(); } if ( temp == ( int ) 'v' ) { uart . printf ( "Keyboard trigger: " ) ; measureRailV ( ) ; } if ( temp == ( int ) 'h' ) { uart . printf ( "Keyboard trigger: " ) ; measureHigh ( ) ; } if ( temp == ( int ) 'k' ) { uart . printf ( "Keyboard trigger: " ) ; measureLow1 ( ) ; } if ( temp == ( int ) 'l' ) { uart . printf ( "Keyboard trigger: " ) ; measureLow2 ( ) ; } if ( temp == ( int ) '1' ) { LOW_ENABLE = 0 ; uart . printf ( "Keyboard trigger: LowEnable = %d\r\n" , 0 ) ; } if ( temp == ( int ) '2' ) { LOW1 = 0 ; uart . printf ( "Keyboard trigger: LOW1 = %d\r\n" , 0 ) ; } if ( temp == ( int ) '3' ) { LOW2 = 0 ; uart . printf ( "Keyboard trigger: LOW2 = %d\r\n" , 0 ) ; } if ( temp == ( int ) '4' ) { VRAIL_MEAS = 0 ; uart . printf ( "Keyboard trigger: VRAILMEAS = %d\r\n" , 0 ) ; } if ( temp == ( int ) '!' ) { LOW_ENABLE = 1 ; uart . printf ( "Keyboard trigger: LowEnable = %d\r\n" , 1 ) ; } if ( temp == ( int ) '@' ) { LOW1 = 1 ; uart . printf ( "Keyboard trigger: LOW1 = %d\r\n" , 1 ) ; } if ( temp == ( int ) '#' ) { LOW2 = 1 ; uart . printf ( "Keyboard trigger: LOW2 = %d\r\n" , 1 ) ; } if ( temp == ( int ) '$' ) { VRAIL_MEAS = 1 ; uart . printf ( "Keyboard trigger: VRAILMEAS = %d\r\n" , 1 ) ; } if ( temp == ( int ) 'r' ) { repeat = ! repeat ; uart . printf ( "Keyboard trigger: repeat toggle: %s \r\n" , repeat ? "true" : "false" ) ; } if ( temp == ( int ) 'R' ) repeat = false ; if ( temp == ( int ) '+' ) { delay - = 0.05 ; if ( delay < 0.05 ) delay = 0.05 ; } if ( temp == ( int ) '-' ) { delay + = 0.05 ; if ( delay > 1 ) delay = 1 ; } if ( temp == ( int ) '=' ) delay = 0.25 ; if ( temp == ( int ) 'g' ) gui = false ; if ( temp == ( int ) 'G' ) gui = true ; if ( temp == ( int ) 's' ) statistics = false ; if ( temp == ( int ) 'S' ) statistics = true ; if ( temp == ( int ) 'n' ) { n - = 25 ; if ( n < 25 ) n = 25 ; } if ( temp == ( int ) 'N' ) { n + = 25 ; if ( n > 1000 ) n = 1000 ; } if ( temp == ( int ) 'N' || temp == ( int ) 'n' ) uart . printf ( "/r/n/r/n Averages = %d \r\n\r\b" , n ) ; } } } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
View full article
Inside IPU there are two block where color space conversion can be made: IC (Image Converter) and DP (Display processor). On Linux, the CSC parameters are located at IPU (IC and DP) drivers, linux/drivers/mxc/ipu3 folder. All negative coefficients are represented using two's complement. Linux Image Converter driver: The parameters are set on function _init_csc: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_ic.c?h=imx_3.14.28_1.0.0_ga static void _init_csc ( struct ipu_soc * ipu , uint8_t ic_task , ipu_color_space_t in_format , ipu_color_space_t out_format , int csc_index ) { /* * Y = 0.257 * R + 0.504 * G + 0.098 * B + 16; * U = -0.148 * R - 0.291 * G + 0.439 * B + 128; * V = 0.439 * R - 0.368 * G - 0.071 * B + 128; */ static const uint32_t rgb2ycbcr_coeff [ 4 ] [ 3 ] = { { 0x0042 , 0x0081 , 0x0019 } , { 0x01DA , 0x01B6 , 0x0070 } , { 0x0070 , 0x01A2 , 0x01EE } , { 0x0040 , 0x0200 , 0x0200 } , /* A0, A1, A2 */ } ; /* transparent RGB->RGB matrix for combining */ static const uint32_t rgb2rgb_coeff [ 4 ] [ 3 ] = { { 0x0080 , 0x0000 , 0x0000 } , { 0x0000 , 0x0080 , 0x0000 } , { 0x0000 , 0x0000 , 0x0080 } , { 0x0000 , 0x0000 , 0x0000 } , /* A0, A1, A2 */ } ; /* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));   G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));   B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128); */ static const uint32_t ycbcr2rgb_coeff [ 4 ] [ 3 ] = { { 149 , 0 , 204 } , { 149 , 462 , 408 } , { 149 , 255 , 0 } , { 8192 - 446 , 266 , 8192 - 554 } , /* A0, A1, A2 */ } ; ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Linux Display Processor driver: The parameters are set on constants (rgb2ycbcr_coeff and ycbcr2rgb_coeff): http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/mxc/ipu3/ipu_disp.c?h=imx_3.14.28_1.0.0_ga /* Y = R * 1.200 + G * 2.343 + B * .453 + 0.250;   U = R * -.672 + G * -1.328 + B * 2.000 + 512.250.;   V = R * 2.000 + G * -1.672 + B * -.328 + 512.250.;*/ static const int rgb2ycbcr_coeff [ 5 ] [ 3 ] = { { 0x4D , 0x96 , 0x1D } , { - 0x2B , - 0x55 , 0x80 } , { 0x80 , - 0x6B , - 0x15 } , { 0x0000 , 0x0200 , 0x0200 } , /* B0, B1, B2 */ { 0x2 , 0x2 , 0x2 } , /* S0, S1, S2 */ } ; /* R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));   G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));   B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128); */ static const int ycbcr2rgb_coeff [ 5 ] [ 3 ] = { { 0x095 , 0x000 , 0x0CC } , { 0x095 , 0x3CE , 0x398 } , { 0x095 , 0x0FF , 0x000 } , { 0x3E42 , 0x010A , 0x3DD6 } , /*B0,B1,B2 */ { 0x1 , 0x1 , 0x1 } , /*S0,S1,S2 */ } ; ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
View full article
BlueZ5 provides support for the core Bluetooth layers and protocols. It is flexible, efficient and uses a modular implementation. BlueZ5 has implemented the Bluetooth low level host stack for Bluetooth core specification 4.0 and 3.0+HS which includes GAP, L2CAP, RFCOMM, and SDP. Besides the host stack, BlueZ5 has also supported the following profiles itself or via a third party software. Profiles p rovided by BlueZ: A2DP 1.3 AVRCP 1.5 DI 1.3 HDP 1.0 HID 1.0 PAN 1.0 SPP 1.1 GATT (LE) profiles: PXP 1.0 HTP 1.0 HoG 1.0 TIP 1.0 CSCP 1.0 OBEX based profiles (by obexd): FTP 1.1 OPP 1.1 PBAP 1.1 MAP 1.0 Provided by the oFono project: HFP 1.6 (AG & HF)Supported Profiles BlueZ5 has been supported in the latest Freescale Linux BSP release, so it would be pretty easy to generate the binaries for Bluetooth core stack and its profiles. In order to support A2DP sink on a SabreSD board, the following software should be downloaded and installed onto the target rootfs too. sbc decoder version 1.3 (http://www.kernel.org/pub/linux/bluetooth/sbc-1.3.tar.gz) PulseAudio 5.0 (http://www.freedesktop.org/software/pulseaudio/releases/pulseaudio-5.0.tar.xz) PulseAudio package has some dependencies with bluetooth and sbc packages, and pulseaudio will detect if the two packages have been built and then decide which pulse plugin modules to be generated. So the building order will be 1) bluez5_utils or bluez_utils   2) sbc   3) pulseaudio. After compile and install the above software onto the target rootfs, you should be able to see the following executable under the directory /usr/bin From BlueZ5: bluetoothctl, hciconfig, hciattach (Needed by operating a UART bluetooth module) From PulseAudio: pulseaudio, pactl, paplay If the building dependency has been setup correctly, the following pulse plugin modules should be located under the directory /usr/lib/pulse-5.0/modules module-bluetooth-discover.so      module-bluetooth-policy.so        module-bluez5-device.so   module-bluez5-discover.so Edit the file /etc/dbus-1/system.d/pulseaudio-system.conf, and add the following lines in red: <policy user="pulse">     <allow own="org.pulseaudio.Server"/>    < allow send_destination="org.bluez"/>     <allow send_interface="org.freedesktop.DBus.ObjectManager"/> </policy> Edit the file /etc/dbus-1/system.d/bluetooth.conf, and add the following lines: <policy user="pulse">      <allow send_destination="org.bluez"/>      <allow send_interface="org.freedesktop.DBus.ObjectManager"/> </policy> Adding the following settings at the bottom of the pulseaudio system configuration file which locates in /etc/pulse/system.pa ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif load-module module-switch-on-connect load-module module-alsa-sink device_id=0 tsched=true tsched_buffer_size=1048576 tsched_buffer_watermark=262144 On the system that can automatically detect the alsa cards, the above line #13 should be removed.  Also make sure "auth-anonymous=1" is added to the following line, which can resolve the issue: "Denied access to client with invalid authorization data". load-module module-native-protocol-unix auth-anonymous=1 Selecting a audio re-sampling algorithm and configuring the audio output by adding the following settings to the file daemon.conf locating in /etc/pulse resample-method = trivial enable-remixing = no enable-lfe-remixing = no default-sample-format = s16le default-sample-rate = 48000 alternate-sample-rate = 24000 default-sample-channels = 2 Pulseaudio can be started as a daemon or as a system-wide instance. To run PulseAudio in system-wide mode, the program will automatically drop privileges from "root" and change to the "pulse" user and group. In this case, before launching the program, the "pulse" user and group needs to be created on the target system.  In the example below, "/var/run/pulse" is the home directory for "pulse" user. adduser -h /var/run/pulse pulse addgroup pulse-access adduser pulse pulse-access Because PulseAudio needs to access the sound devices, add the user "pulse" to the "audio" group too. adduser pulse audio Starting bluetoothd and pulseaudio: /usr/libexec/bluetooth/bluetoothd -d & pulseaudio --system --realtime & To verify if the pulseaudio has been set up correctly, you can play a local wave file by using the following command. If you can hear the sound, the system should have been configured correctly. paplay -vvv audio8k16S.wav After setting up the pulseaudio, launch bluetoothctl to pair and connect to a mobile phone. After connecting to a mobile phone, you should be able to see the following information in bluetoothctl console: [bluetooth]# show Controller 12:60:41:7F:03:00         Name: BlueZ 5.21         Alias: BlueZ 5.21         Class: 0x1c0000         Powered: yes         Discoverable: no         Pairable: yes         UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)         UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)         UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)         UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)         UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)         UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)         UUID: Message Access Server     (00001132-0000-1000-8000-00805f9b34fb)         UUID: Phonebook Access Server   (0000112f-0000-1000-8000-00805f9b34fb)         UUID: IrMC Sync                 (00001104-0000-1000-8000-00805f9b34fb)         UUID: OBEX File Transfer        (00001106-0000-1000-8000-00805f9b34fb)         UUID: OBEX Object Push          (00001105-0000-1000-8000-00805f9b34fb)         UUID: Vendor specific           (00005005-0000-1000-8000-0002ee000001)         UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)         UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)         Modalias: usb:v1D6Bp0246d0515         Discovering: no If you can see the audio sink UUID, you are ready to enjoy the bluetooth music now.
View full article