Using Clock Out - i.MX31PDK i.MX31 has a clock out pin that can be used to output internal clock signals. On the i.MX31PDK the clock out pin is accessible on TP1. The clock out is controlled by register COSR (Clock Out Source Register) at address 0x53F8001C. There three fields on COSR: Field Description CLKOEN (bit 9) Clock output enable bit CLKOUTDIV (bits 8-6) Clock output divide factor CLKOSEL (bits 3-0) These bits select which clock is to be reflected on the clock output CKO. Here are the values each field may assume: CLKOEN Values CLKOUTDIV Values CLKOSEL Values 1 clock output IO pin is enabled 0 clock output IO pin disabled 000 => 1 001 => 2 010 => 4 011 => 8 100 => 16 0000 => mpl_dpdgck_clk 0001 => ipg_clk_ccm 0010 => upl_dpdgck_clk 0011 => pll_ref_clk 0100 => fpm_ckil512_clk 0101 => ipg_clk_ahb_arm 0110 => ipg_clk_arm 0111 => spl_dpdgck_clk 1000 => ckih 1001 => ipg_clk_ahb _emi_clk 1010 => ipg_clk_ipu_hsp 1011 => ipg_clk_nfc_20m 1100 => ipg_clk_perclk_uart1 1101 => ref_cir1 (ref_cir_gateload) 1110 => ref_cir2 (ref_cir_intrcload) 1111 => ref_cir3 (ref_cir_path) Based on the Clock Generation Scheme, we can play with COSR register using the Register Accessing application to test Clock out pin by checking some i.MX31 internal clocks. Testing First we can check the value of CKIH, it should be 26MHz as a 26MHz is connected to that pin. We can write 0x208 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = ckih] root@freescale /home$ ./io2 0x53f8001c w 0x208 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x208 Then we can check pll_ref_clock. We can write 0x203 to COSR. [CLKOEN = 1| CLKOUTDIV = 1| CLKOSEL = pll_ref_clk] root@freescale /home$ ./io2 0x53f8001c w 0x203 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x203 As expected, pll_ref_clock is equals to CKIH because CCMR[PCRS]=10. Reading CCMR to confirm CCMR[PCRS]=10: root@freescale /home$ ./io2 0x53f80000 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80000 (0x4001f000): 0x174B0D7D The pll_ref_clock inputs to MCU PLL and Serial PLL. We can check MCU PLL and Serial PLL configurations on MPCTL (0x53F80010) and SPCTL (0x53F80010) registers respectively. Reading MPCTL and SPCTL: root@freescale /home$ ./io2 0x53f80010 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80010 (0x4001f010): 0x33280C root@freescale /home$ ./io2 0x53f80018 /dev/mem opened. Memory mapped on address 0x4001f000. Address value 0x53F80018 (0x4001f018): 0x2072356 Determine the PLL multiplication factor from MPCTL and SPCTL: - MPCTL: PD = 1 (0000) | MFD = 52 (0000110011) | MFI = 10 (1010) | MFN = 12 (0000001100) - MCPTL Multiplication Factor: 20,46153 - mpl-dpdgck-clk = 20,46153 * 26MHz = 532 MHz - SPCTL: PD = 1 (0000) | MFD = 520 (1000000111) | MFI = 8 (1000) | MFN = -170 (1101010110) - SCPTL Multiplication Factor: 15,3461538 - spl-dpdgck-clk = 15,3461538 * 26MHz = 399 MHz Finally we can output mpl-dpdgck-clk and spl_dpdgck_clk values to check the calculations above. We can write 0x300 to COSR for mpl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = mpl_dpdgck_clk] And 0x307 for spl-dpdgck-clk. [CLKOEN = 1| CLKOUTDIV = 16| CLKOSEL = spl_dpdgck_clk] root@freescale /home$ ./io2 0x53f8001c w 0x300 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x300 root@freescale /home$ ./io2 0x53f8001c w 0x307 /dev/mem opened. Memory mapped on address 0x4001f000. Written: 0x307 By multiplying the results above by 16 to compensate for CLKOUTDIV we have the expected results.

1) Remove all "network" parameters from .../ltib-dir/rootfs/rc.d/rc.conf 2) Add the path of rootfs in the /etc/exports file eg : /home/user/ltib-dir/rootfs/rootfs *(rw,sync,no_root_squash) then execute :- #exportfs -ra 3) Execute NFS server /etc/init.d/nfs restart

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.

There are two format system image(ext4): raw and sparse. The raw image is  larger, you can mount it to ext4 directly(mount -t ext4 system.img system). The sparse image is supported lp5.0, it is a bit smaller. The below part will take IMX7D SDB board as example. You can change the setting according your platform hardware.   1 generate sparse image   In Lollipop 5.0 and 5.1, both raw image and sparse image will be generated by default. sparse system image is located in: out/target/product/sabresd_7d/system_sparse.img raw system image is located in:out/target/product/sabresd_7d/system.img Below are the steps used in android build system to generate system.img build out sparse image(-s means the building system image is sparse)           make_ext4fs -s -T -1 -S out/target/product/sabresd_7d/root/file_contexts -l 374476800 -a system           out/target/product/sabresd_7d/obj/PACKAGING/systemimage_intermediates/system.img out/target/product/sabresd_7d/system transform sparse image to raw image           simg2img out/target/product/sabresd_7d/system_sparse.img out/target/product/sabresd_7d/system.img   2 burn sparse image to sd/emmc      There are two ways to program the sparse image into android boot storage Transform the sparse image into raw image in host Linux PC. And use the commands dd commands to program the raw image into the boot storage. Program the sparse image with MFG Tool in i.MX Android release package.                Steps: copy system_sparse.img to files/android/sabresd/. copy simg2img binary (in simg2img.zip) to files/android/. You also need update mfgtools-without-rootfs.tar\mfgtools\Profiles\Linux\OS Firmware\ucl2.xml        diff --git a/Profiles/Linux/OS Firmware/ucl2.xml b/Profiles/Linux/OS Firmware/ucl2.xml      index 3b15ddd..3c3d2ae 100755      --- a/Profiles/Linux/OS Firmware/ucl2.xml      +++ b/Profiles/Linux/OS Firmware/ucl2.xml        @@ -621,8 +621,12 @@              <CMD state="Updater" type="push" body="$ mkfs.ext4 /dev/mmcblk%mmc%p6">Formatting cache partition</CMD>                <CMD state="Updater" type="push" body="$ mkfs.ext4 /dev/mmcblk%mmc%p7">Formatting device partition</CMD>      -       <CMD state="Updater" type="push" body="pipe dd of=/dev/mmcblk%mmc%p5 bs=512" file="files/android/sabresd/system.img">Sending and writting system.img</CMD>      -      +       <CMD state="Updater" type="push" body="send" file="files/android/simg2img" ifdev="MX7D">Sending simg2img</CMD>      +       <CMD state="Updater" type="push" body="$ cp $FILE /tmp/simg2img ">cp simg2img</CMD>      +       <CMD state="Updater" type="push" body="$ chmod  777 /tmp/simg2img ">chmod 777</CMD>      +       <CMD state="Updater" type="push" body="$  mount -o remount,size=512M rootfs /">change size of tmpfs</CMD>      +       <CMD state="Updater" type="push" body="send" file="files/android/sabresd/system_sparse.img" ifdev="MX7D">Sending system_sparse.img</CMD>      +       <CMD state="Updater" type="push" body="$ /tmp/simg2img $FILE /dev/mmcblk%mmc%p5">Sending and writting system_sparse.img</CMD>              <!-- Write userdata.img is optional, for some customer this is needed, but it's optional. -->              <!-- Also, userdata.img will have android unit test, you can use this to do some auto test. -->              <!--    <CMD state="Updater" type="push" onError="ignore" body="pipe dd of=/dev/mmcblk0p7" file="file/android/userdate.img"> Sending userdata.   3 Support sparse image in uboot(v2014.04)      Cheery-pick sparse image related patches. Use write_sparse_image to burn sparse system image.      For detail information, Please check the attached file(uboot(v2014.04)which support sparseimage.zip )        The step of apply these patches: cd myandroid/bootable/bootloader/uboot-imx/ copy uboot(v2014.04) which support sparseimage.zip to myandroid/bootable/bootloader/uboot-imx/         unzip uboot(v2014.04) which support sparseimage.zip git am 0001-add-header-for-Android-sparse-image-format.patch         git am 0002-add-code-to-handle-Android-sparse-image-format.patch         git am 0003-update-code-which-handles-Android-sparse-image-forma.patch         git am 0004-cleanup-code-which-handles-the-Android-sparse-image-.patch         git am 0005-implement-the-Android-sparse-image-format.patch         git am 0006-aboot-fix-block-addressing-for-don-t-care-chunk-type.patch         git am 0007-MA-6732-Add-sparse-image-flash-support-for-uboot-s-f.patch            The page will keep updating.   Reference：      How to enable userdata.img and cache.img in lollipop

Network File System (NFS)      Setting the host          1 - Install NFS Service on host typing:        $sudo apt-get install nfs-kernel-server          2 - Create symbolic link to ltib/rootfs        $sudo ln -s <ltib instalation folder>/rootfs /tftpboot/rootfs          3 - Setup exports typing:        $sudo gedit /etc/exports          and add the following line:        /tftpboot/rootfs/ *(rw,no_root_squash,no_subtree_check,async)          4 - Restart the NFS server:        $sudo /etc/init.d/nfs-kernel-server restart          Now the host is ready to use NFS      Setting Target Linux Image to use NFS          1. Run LTIB configuration by typing: $cd <ltib instalation folder>          $./ltib -c          2 . On first page menu, go to "Target Image Generation -> Options"       3. Select the option NFS only and exit LTIB configuration to compile with the new configuration.          4. LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/zImage          5. Copy the created image on /<ltib instalation folder>/rootfs/boot/zImage to /tftpboot/zImage          6. The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/         

Synchronize your source code Create your local branch Why should I create a local branch? Choose your board Start to build Synchronize your source code Source code you have is one week old now. So, first step is synchronize it. $ repo sync‍‍‍ Create your local branch $ repo start <new branch name> --all‍‍‍ Why should I create a local branch? If you change *any* source code (for choosing another preferred kernel, for example) and want to sync again, or use master instead of dylan, you may be able to rebase or sync your source code, even with changes. Or you found a bug, fixed that, and want to send a patch to community. Example of a system with 2 branches: zeus and new_feature (the asterisk shows the current branch)    $ repo branches * new_feature | in all projects zeus | in all projects‍‍‍ Choose your board The following command display the usage, with a list of all supported machines, all supported community distros and examples of Poky's distro: $ source setup-environment build‍ Usage: MACHINE=<machine> DISTRO=<distro> source setup-environment <build-dir> Usage: source setup-environment <build-dir> <machine> machine name <distro> distro name <build-dir> build directory The first usage is for creating a new build directory. In this case, the script creates the build directory <build-dir>, configures it for the specified <machine> and <distro>, and prepares the calling shell for running bitbake on the build directory. The second usage is for using an existing build directory. In this case, the script prepares the calling shell for running bitbake on the build directory <build-dir>. The build directory configuration is unchanged. Supported machines: apalis-imx6 ccimx6ulsbcexpress ccimx6ulsbcpro cgtqmx6 cm-fx6 colibri-imx6 colibri-imx6ull colibri-imx7 colibri-vf cubox-i imx233-olinuxino-maxi imx233-olinuxino-micro imx233-olinuxino-mini imx233-olinuxino-nano imx6dl-riotboard imx6qdl-variscite-som imx6q-dms-ba16 imx6qsabrelite imx6sl-warp imx6ul-pico imx7d-pico imx7s-warp m28evk m53evk nitrogen6sx nitrogen6x nitrogen6x-lite nitrogen7 nitrogen8m pcm052 tx6q-10x0 tx6q-11x0 tx6s-8034 tx6s-8035 tx6u-8033 tx6u-80x0 tx6u-81x0 ventana wandboard imx23evk imx25pdk imx28evk imx51evk imx53ard imx53qsb imx6qdlsabreauto imx6qdlsabresd imx6slevk imx6sllevk imx6sxsabreauto imx6sxsabresd imx6ulevk imx6ullevk imx7dsabresd imx7ulpevk imx8mmevk imx8mqevk imx8qmmek imx8qxpmek ls1012afrwy ls1012ardb ls1021atwr ls1043ardb ls1046ardb ls1088ardb ls1088ardb-pb ls2080ardb ls2088ardb lx2160ardb mpc8548cds p1020rdb p2020rdb p2041rdb p3041ds p4080ds p5040ds-64b p5040ds t1024rdb-64b t1024rdb t1042d4rdb-64b t1042d4rdb t2080rdb-64b t2080rdb t4240rdb-64b t4240rdb Supported Freescale's distros: fslc-framebuffer fslc-wayland fslc-x11 fslc-xwayland Available Poky's distros: poky-altcfg poky-bleeding poky poky-tiny Examples: - To create a new Yocto build directory: $ MACHINE=imx6qdlsabresd DISTRO=fslc-framebuffer source setup-environment build - To use an existing Yocto build directory: $ source setup-environment build ERROR: You must set MACHINE when creating a new build directory. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ An example of command line to setup the build environment is (read and answer if you accept EULA or not): MACHINE=imx8mmevk DISTRO=fslc-wayland source setup-environment build‍ (...) Do you accept the EULA you just read? (y/n) y EULA has been accepted. Welcome to Freescale Community BSP The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You can now run 'bitbake <target>' Common targets are: core-image-minimal meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support Your build environment has been configured with: MACHINE=imx8mmevk SDKMACHINE=i686 DISTRO=fslc-wayland EULA= ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now, you are in new created build directory. Your default build/conf/local.conf file can looks like: MACHINE ??= 'imx8mmevk' DISTRO ?= 'fslc-wayland' PACKAGE_CLASSES ?= 'package_rpm' EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-system-native = " sdl" CONF_VERSION = "1" DL_DIR ?= "${BSPDIR}/downloads/" ACCEPT_FSL_EULA = "1"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ For the current list of supported board, take a look on FSL Community BSP Release Notes 2.4 (Draft document) documentation Or, see the FSL Community BSP  Release Notes Start to build There are a huge list of images available. Some images includes more packages than others, you can see a list of FSL Community BSP images with description here. The list of supported images from Yocto Project (with description) is here. When an image has more packages included, it takes longer to build. Another way to list all the images you have installed in your metadata is: $ find ../sources -name *image*‍‍   For the goal of this training, any image is good, but a suggestion is presented in next command line: (make sure you are still in build directory) $ cd build $ bitbake core-image-base‍‍‍‍‍‍‍‍ Note (Sept2019): Required disk space for build image is ~31GB Go to Yocto Training - HOME Go to Task #1 - Download the source code Go to Task #3 - The build result

Flash a full SD Card Android Image (4GB) using Linux on VMWare Flash a full SD card image (4GB) using Flashnul in Windows Flash a full SD Card Android Image (4GB) using Linux on VMWare Note: It is preferred that SanDisk 4G SD card be used rather then Kingston. Kingston seemed to enumerate slightly smaller then SanDisk which actually inhibited us from flashing the image onto Kingston.    Within VMWare player, go to places/filesystems/dev to see what the SD card is called. When plugging in or removing the SD card from an external reader, you should see within the dev folder files called sdx…etc. [x= some letter]. That will help you specify which card to program with your image. Make note of the file [which is really a drive] name. For example in my VMWare player, it turns out that my SD card that I want to program was sdb. Also, if windows asks to format the drive, allow it and use Fat32. And, if you notice the drive is only 1GB instead of 3-4GB its because you only formatted the windows structure of the disk, the Linux portion that might reside on it does not show up in Windows. For distribution, the entire image which includes the *.bin file {this is the one you are trying to get onto the SD card} can be downloadable from a Freescale FTP site or some other media. It is a large file which is between 1-2GB. In this Android example, the file is called MasterA.gz. GZ is a linux based zip application which runs circles around winzip or 7-zip. The Android image, MasterA.gz, was 1.08 GB. The file you want to see in this example is MasterA.bin. Open a terminal window in VMWare. Within VMWare, unzip the file. If you select the file, then right mouse click it it will give you the option to uncompress using GZ. Before moving forward, make sure the SD card is unmounted. To do this type sudo umount /dev/sdX {note: sdb was the SD card we previously found enumerated}.           If you don’t know if it is mounted, in places/filesystems/dev on the left side of the screen you will see names with shown next to it. That means it’s          mounted. To copy Android image to sd card, type sudo dd if=masterA.bin of=/dev/sdX bs=10M X is the sd card (like /sdb, /sdc etc.) This will take some time, so if you have to stop this process hit <ctrl C> or close the terminal window. This will take some time but that’s all that it takes. Use the bottom task bar of the VMware screen, to attach the USB removable drive to Linux. Flash a full SD card image (4GB) using Flashnul in Windows  The tool you will use to flash the content is FlashNul in windows. This is available at http://shounen.ru/soft/flashnul/flashnul-1rc1.zip Steps Insert your flash media Run flashnul -p (from the dir that has flashnul) Note the physical device number for flash media Run flashnul <number obtained in prior step> -L \path\to\downloaded.img Answer "yes" if the selected destination device is correct Remove your flash media when the command completes Be careful what drive you erase. There are warnings presented before you commit: Disk PhysicalDrive2 (UNC name: \\.\PhysicalDrive2)         ------------------------------------------------------------[Drive geometry]--         Cylinders/heads/sectors = 482/255/63         Bytes per sector = 512         CHS size = 3964584960 (3780 Mb)         ---------------------------------------------------------------[Device size]--         Device size = 3965190144 (3781 Mb)         delta to near power of 2 = 329777152 (314 Mb), 8%         Surplus size = 605184 (591 kb)         -----------------------------------------------[Adapter & Device properties]--         Bus type = (7) USB         Removable device = Yes         Command Queue = Unsupported         Device vendor = Generic         Device name = USB SD Reader         Revision = 0.00         --------------------------------------------------------------[Hotplug info]--         Device hotplug = Yes         Media hotplug = No Selected operation: load file content Selected drive: PhysicalDrive2, 3965190144b (3781 Mb)</pre>         THIS OPERATION IS DESTRUCTIVE!!!         Type 'yes' to confirm operation. All other text will stop it. Really destroy data on drive PhysicalDrive2? :yes         -----------------------------------------------------------------------[Log]-- Runing operation [load file content] for drive PhysicalDrive2 Writing 0x36110000 (865 Mb), 3362893 b/s      

Enter inside ~/ltibdir/rpm/BUILD and create a directory 'alpha': $ cd ltib/rpm/BUILD $ mkdir alpha Enter in 'alpha' dir and create setalpha.c file: $ cd alpha #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> #include <asm/arch/mxcfb.h>  int main(int argc, char **argv) {              int fb_fd;              struct mxcfb_gbl_alpha gbl_alpha;               if(argc != 2){                       printf("Usage: %s alpha_val[0-255]\n",argv[0]);                       return -1;              }               fb_fd = open("/dev/fb0",O_RDWR,0);              gbl_alpha.enable = 1;              gbl_alpha.alpha = atoi(argv[1]);              ioctl(fb_fd, MXCFB_SET_GBL_ALPHA, &gbl_alpha);              close(fb_fd);              return 0; } Compile it using this command: ./ltib -m shell LTIB> cd rpm/BUILD/alpha LTIB> gcc -I../linux/include setalpha.c -o setalpha In your board execute it: root@freescale /home$ /unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 480 -oh 640 -d 3 -r 4 -fr 5 qvga.yuv & While it is playing execute: root@freescale /home$ setalpha 128 root@freescale /home$ cat screen.raw > /dev/fb0 We used frame rate at 5 fps to have more time to execute next two commands.

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

GTK+ is a highly usable, feature rich toolkit for creating graphical user interfaces which boasts cross platform compatibility and an easy to use API. GTK+ it is written in C, but has bindings to many other popular programming languages such as C++, Python and C# among others. GTK+ is licensed under the GNU LGPL 2.1 allowing development of both free and proprietary software with GTK+ without any license fees or royalties. [Source: gtk.org] As GTK+ is a graphical library, a program using GTK+ can be done in many languages like C, C++, Python, Perl, PHP, Ruby, and many others. Here a C example will be done. How to make a simple program with GTK An easier way to make a graphical interface (GUI) program using GTK+ is to use Glade as Graphical Editor. Glade3 Screenshot To install Glade on Ubuntu type: $sudo apt-get install glade-3 Old Glade versions used to generate C code. Currently version ONLY generates a .glade file that can be parsed in a .xml file which describes the hierachy of the widgets. Let's create, compile and test a sample program on host and after, cross-compile for iMX platform and check it running on a PDK i.MX31 Development kit. In order to develop on host PC, install libgtk2.0-dev typing: $sudo apt-get install libgtk2.0-dev

The System Controller Unit (SCU) is in charge of controlling several features related to power management of the whole system. The user gets access to the following features through the System Controller Firmware: Powering up/down the system,resources and partitions Configuring resource clocks Reset controls Configuring wake-up sources This document will cover the more commonly used features, for details on the full capabilities of the API please refer to the API document for your device. Resource Power Control The SCU is in charge of managing power control to the resources (peripherals) in the SoC. Attempting to access a resource on the OFF state will result in a bus error or a hang All resources are organized within several subsystems, subsystems group together resources with common functionality. Subsystems are independent of each other and have their own PLLs and power domains, this allows modular control of clocks and power to the resources. The System Controller Unit has a dedicated I2C channel to interact with the PMIC, this allows dynamic control of some power sources for resources like the GPUs and Cortex-A cores. The SCU can enable/disable the LDO that supplies power to the GPU for instance and also turn on/off the internal power domains. The mapping of PMIC supplies and resources happens on the board.c (included in the SCFW Porting kit) and it is part of the porting process of the SCFW to new boards. The function board_get_pmic_info is where the mapping of resources to supplies happen, see: /*--------------------------------------------------------------------------*/ /* Get the pmic ids and switchers connected to SS. */ /*--------------------------------------------------------------------------*/ static void board_get_pmic_info(sc_sub_t ss,pmic_id_t *pmic_id, uint32_t *pmic_reg, uint8_t *num_regs) { /* Map SS/PD to PMIC switch */ switch (ss) { case SC_SUBSYS_A53 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1U; } break; case SC_SUBSYS_A72 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_0_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; case SC_SUBSYS_GPU_0 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW1; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW2; *num_regs = 2U; } break; case SC_SUBSYS_GPU_1 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; default : ; /* Intentional empty default */ break; } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Only some subsystems have their own dedicated external power supplies, in the example above A cores and GPUs are the only ones with a dedicated external power supplies. Most of the other subsystems are powered from the main power supply and power gating happens internally, each subsystem contains different power domains that can be turned on/off to manage power consumption. The SCFW API used to power on/off resources is the following: sc_err_t sc_pm_set_resource_power_mode (sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_power_mode_t mode)‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the power mode change mode - is the power mode to change to The available power mode options are the following: Power mode Voltage Clocks SC_PM_PW_MODE_OFF OFF All clocks off SC_PM_PW_MODE_STBY ON All clocks off SC_PM_PW_MODE_LP ON PLLs off resource running from XTAL SC_PM_PW_MODE_ON ON PLLs on In order to be able to access a resource it must be at least on SC_PM_PW_MODE_LP mode, since that mode has the resource voltage on and the clock is supplied by the 24MHz crystal. For more details please refer to the SCFW API document. Clocks Configuration As in the power management case, clocks are also organized in a distributed manner within the device. Each subsystem has it's own PLLs and all of them are clocked by the 24MHz crystal. The number of PLLs in each subsystem varies between all subsystems. To see how many PLLs are within a subsystem please refer to the datasheet of the device you are interested on. For instance on the datasheet of the i.MX8QXP on table 16 in Chapter 4.3.1: It can be seen that the GPU subsystem contains two PLLs, the ADMA subsystem contains 4 PLLs, Display Controller 3, etc... The SCFW API used to configure a clock is the following: sc_err_t sc_pm_set_clock_rate ( sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_pm_clock_rate_t ∗ rate )‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the clock rate change clk - is the clock to set the rate to (each resource can have different clocks associated with it for instance the GPU resource has a clock associated for its shader and another for the GPU, this parameter is used to identify the clock) rate - this contains the desired clock rate, the SCFW will try to match the provided rate if not possible it will then set the closest possible value and return the value that was actually configured. To identify the clk that needs to be passed, please refer to the SCFW API chapter called "Clock List" That chapter contains a table with all the different clocks that are configurable by the SCFW, in the case of the GPUs for instance to select the rate for the Shader or GPU, either the SC_PM_CLK_MISC or SC_PM_CLK_PER options would have to be selected. Set=Y indicates the clock/PLL is not shared and the rate can be set via sc_pm_set_clock_rate(). Enable=Y indicates the clock is not auto gated and must be enabled via sc_pm_clock_enable(). As an example the following snippet configures the GPU_0 shader clock: sc_clock_rate_t shader_clk=700000000; // 700 MHz sc_pm_set_clock_rate(ipc, SC_R_GPU_0_PID0, SC_PM_CLK_MISC, &shader_clk);‍‍ System Controller Firmware 101 

Download Linux kernel 2.6.29: $ wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 Extract this: $ tar jxvf linux-2.6.29.tar.bz2 Apply the patches: $ cd linux-2.6.29 Edit the file drivers/net/cs89x0.c adding: #include <mach/hardware.h> Export CROSS_COMPILE environmet: $ export PATH="$PATH:/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/" $ export CROSS_COMPILE=arm-none-linux-gnueabi- Unselect all no essentials features: $ make ARCH=arm allnoconfig Start the configuration menu: $ make ARCH=arm menuconfig Change/Select the kernel options below. Select the MXC/iMX platform and iMX31ADS board: System Type ->             ARM system type -> (X) Freescale MXC/iMX-based             Freescale MXC Implementations  ->                            MXC/iMX Base Type -> (X) MX3-based                            MX3 Options  -> [*] Support MX31ADS platforms (NEW) Select ARM EABI standard to compile the kernel: Kernel Features  --->           [*] Use the ARM EABI to compile the kernel Add support to Linux Binary Format ELF: Userspace binary formats ->              [*] Kernel support for ELF binaries Add support to Network (TCP/IP): [*] Networking support  ->          Networking options  ->                          [*] Packet socket                          [*] Unix domain sockets                          [*] PF_KEY sockets                          [*] TCP/IP networking                                   [*] IP: kernel level autoconfiguration                                   [*]     IP: DHCP support Select network driver (CS89x0), serial driver and unselect VGA console: Device Drivers  ->                      [*] Network device support  --->                                      [*]   Ethernet (10 or 100Mbit)  --->                                             [*]   CS89x0 support                      Character devices  ->                              Serial drivers  --->                                       [*] IMX serial port support                                       [*]   Console on IMX serial port                      Graphics support  ->                             Console display driver support  --->                                        [ ] VGA text console Add support to NFS and support to use it as root file system: File systems  ->                            [*] Network File Systems (NEW)  ->                                        [*]   NFS client support                                        [*]     Root file system on NFS Compile the kernel: $ make ARCH=arm Copy the created zImage to tftp directory: $ cp arch/arm/boot/zImage /tftpboot/ Configure your RedBoot to boots with this kernel: load -r -b 0x100000 /tftpboot/zImage exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.240.191:/tftpboot/rootfs ip=dhcp"

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

This document shows how to run the multicore communication examples from MCUXpresso SDK while running the Android BSP on Cortex-A7 on i.MX 7ULP-EVK. Though this document is focused on the multicore demos, similar procedures can be applied to run any other demo in the SDK. 1. Source code This document is based on the following releases: Board Android BSP MCUXpresso SDK imx7ulp-evk Android O8.1.0 for i.MX 7ULP GA SDK2.4 for i.MX 7ULP GA Download releases at i.MX Software. 2. Building the Cortex-M4 SDK There are at least two multicore demos in the SDK package, rpmsg_lite_pingpong_rtos and rpmsg_lite_str_echo_rtos. They are located at: <SDK_2.4.0_EVK-MCIMX7ULP_dir>/boards/evkmcimx7ulp/multicore_examples/ Build the rpmsg_lite_str_echo_rtos demo according to the SDK Getting Started Guide. Remember to also follow the Chapter 6, Step 4 of the document to generate the ram bootable image (sdk20-app.img). 3. Building the Android BSP 3.1. RPMsg kernel module Before building the BSP, add the following line to the BoardConfig.mk file (<android_build_dir>/device/fsl/evk_7ulp/BoardConfig.mk): BOARD_VENDOR_KERNEL_MODULES += \    $(KERNEL_OUT)/drivers/net/wireless/qcacld-2.0/wlan.ko \ + $(KERNEL_OUT)/drivers/rpmsg/imx_rpmsg_tty.ko 3.2. Cortex-M4 image Copy the SDK image file (sdk20-app.img) to the following directory in the Android source code: $ cp <SDK_2.4.0_EVK-MCIMX7ULP_dir>/tools/imgutil/evkmcimx7ulp/sdk20-app.img \   <android_build_dir>/vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/sdk20-app.img Change the BoardConfig.mk file accordingly: # Copy prebuilt M4 demo image: PRODUCT_COPY_FILES += \ - vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/imx7ulp_m4_demo.img:imx7ulp_m4_demo.img + vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/sdk20-app.img:imx7ulp_m4_demo.img After these changes, build and flash Android as described in the BSP User's Guide. 4. Enabling the multicore communication While booting, the SoC automatically loads the Cortex-M4 image. After complete booting, install the imx_rpmsg_tty.ko module to create the multicore communication channel: $ su $ insmod vendor/lib/modules/imx_rpmsg_tty.ko To send messages from Cortex-A7 to Cortex-M4, use the /dev/ttyRPMSG* channel: $ echo "MESSAGE" > /dev/ttyRPMSG* /dev/ttyRPMSG* refers to the RPMsg device created on the board, so change the number accordingly. Cortex-M4 will echo all messages received from Cortex-A7. This is a simple example on how to communicate different cores on i.MX using Android but it can be used as a starting point for Android multicore applications.

Random Number Generator - RNGA Download rng-tools: http://downloads.sourceforge.net/sourceforge/gkernel/rng-tools-2.tar.gz This tool tests the link between a random number generator hardware and the kernel's PRNG (pseudo-random number generator). ./ltib -m shell LTIB> cd rpm/BUILD/ LTIB> cp ~/hwrandom/rng-tools-2.tar.gz . LTIB> tar zxvf rng-tools-2.tar.gz LTIB> cd rng-tools-2 LTIB> ./configure --host=arm-linux LTIB> make LTIB> sudo cp rngtest /tftpboot/ltib/home/ Restart your board and execute this command in the board's console: $ cat /dev/hwrng | /home/rngtest -c 1000

Flashing Kernel and Root File System using RedBoot Creating an image A kernel image and a root file system can be created using All Boards LTIB or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs/ -e 0x20000 -n -p -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connections errors can be avoided by All Boards Configuring RedBoot. The process below uses TFTP to copy the files between host and target. See All Boards TFTP for detail in configurations. Copy the kernel image and the root file system image to the TFTP dir. For example, in  LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: fis init Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel at the right address (0x200000, for IMX31PDK) fis create -f 0x200000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for IMX31PDK. fis create -f 0x600000 root Testing You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock2 /mnt ls /mnt List the /mnt contents. The output must be the right file system. Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=none" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the ethernet cable.

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

Debugging with Eclipse and GDB on Linux user space This is a good open-source choice to debug i.MX processors. The integration of popular tools like Eclipse and GDB offers a good and stable connection between host and target. The first step is to install the tools on host. Click here to get instructions of how to install the tools. Let's debug a ready hello world program into the ltib. To extract the hello world package, type on ltib directory: $./ltib -m prep -p helloworld Change the code of hello.c to: #include <stdio.h> int main(int argc, char** argv) {     int i;     for (i = 0; i < 100; ++ i)     {         printf(“Welcome to GDB ! %d /n”, i);     }     return 0; } Change the Makefile to add debug symbols Change the two following lines from: CFLAGS = -Wall CXXFLAGS = -Wall To: CFLAGS = -Wall -g CXXFLAGS = -Wall -g Build and deploy the new source-code: $./ltib –p helloworld –m scbuild $./ltib –p helloworld –m scdeploy Configuring the Target On target, gdbserver needs to be run to perform debug. The gdbserver command has the following structure: gdbserver ip_host:port /full/path/app/app_name If gdbserver is not installed on target, select gdb package on ltib configuration. In this example our host has the 192.168.16.35 IP address and our HelloWorld application is located at /usr/bin/hello on the target board. Execute the gdbserver: gdbserver 192.168.16.35:10000 /usr/bin/hello You can use other port number as long as you use the same number when configuring the Eclipse. Setting a GDB Debug Session on Eclipse Now we will configure Eclipse C/C++ to start a GDB session with our remote i.MX board. We will need to know which is the target board’s IP address. To get your target’s IP address: /sbin/ifconfig In our example the target board has the 192.168.16.36 IP address. Open-up Eclipse and choose the C/C++ perspective. We will import the HelloWorld executable built by LTIB. Go to the menu File -> Import You will see the “Import” screen. Select “C/C++ Executable” option. Hit the “Next” button. Eclipse automaticaly creates a new project when whe use the “Import” option. In the next screen, select the “Search Directory” option and hit the “Browse” button. This session is incomplete and is being edited...

<analytics uacct="UA-5520491-1" /> How to enable WIFI support for i.MX53 QSB Android After applying every QSB patch, enable WiFi support according to your hardware. Android R4 can be downloaded from Adeneo´s website. AR6102  Change file device/fsl/imx53_loco/BoardConfig.mk -BOARD_WLAN_CHIP_AR6102  := false +BOARD_WLAN_CHIP_AR6102  := true AR6003  Change file device/fsl/imx53_loco/BoardConfig.mk -BOARD_WLAN_CHIP_AR6003  := false +BOARD_WLAN_CHIP_AR6003  := true After complete build ar6000.ko will be created under /system/etc/modules To turn WIFI on, go to Settings > Wireless & network s > Wi-Fi Error message case  In case logcat shows the following error message: E/WifiHW  ( 2086): Cannot access "/data/misc/wifi/wpa_supplicant.conf":Permission denied Reconfigure nfs server file /etc/default/nfs-kernel-server delete this line:   RPCMOUNTDOPT=--manage-gids

This post describes the setup detail for installing Ubuntu based distro in any i.Mx6x NXP Boards. Details are described on: 1. Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. 2. Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. 3. Modify rootfs and Installing needed packages 4. Setting with SD image. 5. Setting Ubuntu on target 6. Adding GPU acceleration 1: Select your board, Setting the host, Download and compile uboot , dtb and and the Kernel version on your board. Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board Install host dependences (version tested 14.04): $ sudo apt-get install gparted git build-essential libncurses5 wget u-boot-tools zlib1g-dev ncurses-dev \ cmake libc-dev-armhf-cross pkg-config-arm-linux-gnueabihf build-essential checkinstall cmake \ pkg-config lzop libc6 libstdc++6 debootstrap qemu-user-static binfmt-support Download the compiler toolchain and extract it: $ cd ~/ $ wget -c https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz $ tar xf gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz Create general variable environments: $ export target=mx6q (e.g. processor: mx6sx, mx6d, mx6dl,etc) $ export board=sabresd (e.g. sabresd, sabreauto) $ export ARCH=arm $ export CROSS_COMPILE=../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ unset LDFLAGS Download u-boot At the release of this document, latest uboot version was imx_3.14.52, it should work with other version as well, so please check the proper version for your board: $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/snapshot/uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar -xf uboot-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd uboot-imx-rel_imx_3.14.52_1.1.0_ga $ make $targetboard_config    # e.g. mx6qsabresd_config $ make Linux Kernel, Firmware, headers, modules and DTS files $ cd ~/ $ wget –c http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/snapshot/linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ tar xf linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga.tar.gz $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ make imx_v7_defconfig $ make menuconfig $ make -j4 zImage modules dtbs $ cd ~/ move your image to binary folder: $ sudo cp –v uboot-imx-rel_imx_3.14.52_1.1.0_ga/u-boot.imx binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/zImage binary/ $ sudo cp –v linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga/arch/arm/boot/dts/i$target-$board.dtb binary/ Now you have the bootloader, device tree and kernel image of your board ready, let’s create the rootfs. 2: Installing the Ubuntu core, Lubuntu graphics desktop version and/or Build your own Ubuntu rootfs with debootstrap. Installing ubuntu core: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget –c http://cdimage.ubuntu.com/ubuntu-core/releases/14.04/release/ubuntu-core-14.04.4-core-armhf.tar.gz $ sudo tar –xf ubuntu-core-14.04.4-core-armhf.tar.gz –C core $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing ubuntu Linaro LXDE: $ cd ~/ $ sudo mkdir –p core /media/rootfs /media/kernel $ wget https://releases.linaro.org/14.10/ubuntu/trusty-images/alip/linaro-trusty-alip-20141024-684.tar.gz $ sudo tar -xf linaro-trusty-alip-20141024-684.tar.gz –C core $ sudo mv core/binary/* core/ $ sudo rm –rf core/binary $ sudo cp -vr core/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/rootfs folder. and you can pass to part 3 of this post. Installing with debootstrap $ cd ~/ $ target=rootfs $ distro=trusty $ sudo debootstrap --arch=armhf --foreign --include=ubuntu-keyring,apt-transport-https,ca-certificates,openssl $distro "$target" http://ports.ubuntu.com $ sudo cp /usr/bin/qemu-arm-static $target/usr/bin $ sudo cp /etc/resolv.conf $target/etc Now have a minimal Ubuntu rootfs - chroot to it and perform the 2nd stage install: $ sudo chroot $target  //Now we are in chroot # distro=trusty # export LC_ALL=C LANGUAGE=C LANG=C # /debootstrap/debootstrap --second-stage Edit the sources.list repositories # cat <<EOT > /etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ $distro main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ $distro-security main restricted universe multiverse EOT # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 40976EAF437D05B5 # apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 3B4FE6ACC0B21F32 # apt-get update # apt -y -f install # apt-get upgrade # apt-get install nano Now you should be able to login without password, then use passwd command to set one. If you like to add custom users: # passwd root # adduser <myuser> # usermod -a -G tty myuser # usermod -a -G dialout, adm, sudo, dip, plugdev myuser # visudo Under the line that looks like: root ALL=(ALL:ALL) ALL add the following (change user with your actual username) <myuser> ALL=(ALL) ALL your rootfs is ready, exit chroot # exit $ sudo rm $target/etc/resolv.conf $ sudo rm $target/usr/bin/qemu-arm-static $ sudo mv rootfs/* /media/rootfs $ cd linux-2.6-imx-rel_imx_3.14.52_1.1.0_ga $ sudo make modules_install firmware_install INSTALL_MOD_PATH=/media/rootfs/ ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- $ sudo make ARCH=arm CROSS_COMPILE=../../gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- headers_install INSTALL_HDR_PATH=/media/rootfs/usr Now you should have your ubuntu rootfs on /media/root. 3: Modify Rootfs and Install needed packages Edit and verify the sources.list repositories $ cd /media/rootfs $ sudo cat <<EOT > etc/apt/sources.list deb http://ports.ubuntu.com/ubuntu-ports/ trusty main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main restricted universe multiverse deb http://ports.ubuntu.com/ubuntu-ports/ trusty-security main restricted universe multiverse EOT Edit networks interfaces and append in the existing file: $ sudo nano etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp If you require Serial Console, remove and include an additional line at the end of the file for  ttymxc0 output as below, $ sudo nano etc/init/tty1.conf exec /sbin/getty -8 38400 tty1 exec /sbin/getty -L 115200 ttymxc0 If you like to change the localhostname: $ sudo nano etc/hostname and change to “your name” e.g. imx6Q. Set the date and time clock and update $ sudo nano /etc/rc.local  Add this: if [ `date +"%Y"` -eq "1970" ]; then                     date --set="2016-04-01" fi exit 0 (optional for Linaro rootfs) Edit passwd and remove the x in root and linaro lines $ sudo nano etc/passwd root:x:0:0:root:/root:/bin/bash linaro:x:0:0.. and change like this:                                   root::0:0:root:/root:/bin/bash linaro:::0:.. Now you are ready to program your sd image. 4: Setup microSD/SD card For these instructions, we are assuming: DISK=/dev/sdg on your HOST, cat /proc/partitions is very useful for determining the device id. $ cd ~/ $ export DISK=/dev/sdg Erase microSD/SD card: $ sudo dd if=/dev/zero of=${DISK} bs=1M count=10 Install Bootloader $ cd binary/ $ sudo dd if=u-boot.imx of=${DISK} bs=512 seek=2 $ sync Create Partition layout: $ cd ~/ $ sudo fdisk ${DISK} steps:        d ///delete all partitions currently on sd n // create new partition p // Primary partition 1 // partition number 1 2048 //default +1G // n // created 2d parition p 2 default default 1 // firts B // to be fat32 W // write partiotions $ sudo mkfs.vfat ${DISK}1 $ sudo mkfs.ext3  ${DISK}2 Mount ext3 SD partition to /media/rootfs: $ sudo mount ${DISK1} /media/kernel_target $ sudo mount ${DISK}2 /media/rootfs_target Copy Files on the SD. $ cd ~/ $ sudo cp –v binary/ i$target-$board.dtb /media/kernel_target $ sudo cp –v binary/zImage /media/kernel_target $ sudo mv /media/rootfs/* /media/rootfs_target Remove SD: $ sync $ sudo umount /media/kernel_target $ sudo umount /media/rootfs_target Boot the target, in console you should be login as root. root@imx6QSabreSD:~# 5: Setting Ubuntu on target Note: If you have issues with sudo on user UID, need to logout and log as root: imx6Q login: root Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) root@imx6Q:~# chown root:root /usr/bin/sudo root@imx6Q:~# chmod 4755 /usr/bin/sudo root@imx6Q:~# exit Login with <user $> or root # # apt-get update # apt-get –f install # apt-get install locales dialog wget # dpkg-reconfigure locales # apt-get upgrade Optional – install some useful packages: # apt-get install openssh-server can-utils usbutils build-essential automake autoconf libtool Get and Install the BSP packages (EULA required) # cd /home/user # mkdir –p vpu_pack # cd vpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//firmware-imx-5.3.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-vpu-5.4.32.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//libfslcodec-4.0.8.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-lib-5.1.tar.gz # chmod +x * # ./firmware-imx-5.3.bin --auto-accept --force # mkdir –p /lib/firmware/vpu # cp -ravf firmware-imx-5.3/firmware/* /lib/firmware/ # ./imx-vpu-5.4.32.bin --auto-accept --force # cd imx-vpu-* # make PLATFORM=IMX6Q all # make install # tar -xf imx-lib-5.1.tar.gz # cd  imx-lib-5.1/ # make -j1 PLATFORM="IMX6Q" # make PLATFORM="IMX6Q" install # cd .. # ./libfslcodec-4.0.8 --auto-accept –force # cd libfslcodec-* # ./autogent.sh --prefix=/usr --enable-fhw --enable-vpu # make # make install # mv /usr/lib/imx-mm/video-codec/* /usr/lib # mv /usr/lib/imx-mm/audio-codec/* /usr/lib # rm –rf /usr/lib/imx-mm/ # cd .. # mkdir –p gpu_pack # cd gpu_pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-5.0.11.p7.4-hfp.bin # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # chmod +x * # ./imx-gpu-viv-5.0.11.p7.4-hfp –-auto-accept -–force # cd imx-gpu* # cp g2d/usr/include/* /usr/include/ # cp -d g2d/usr/lib/* /usr/lib/ # cp -Pr gpu-core/usr/* /usr # optional: install demos # cp -r gpu-demos/opt / # optional: install gpu tools # cp -axr gpu-tools/gmem-info/usr/bin/* /usr/bin/ # cd .. Installing gstreamer-imx, IPU, VPU and GPU support: Install build deps, gstreamer1.x, this step could take some time (~350MB): # apt-get install python pkg-config git gstreamer1.0-x gstreamer1.0-tools gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-alsa libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libgstreamer-plugins-good1.0-dev g++-multilib # git clone git://github.com/Freescale/gstreamer-imx.git # cd gstreamer-imx # ln –s /usr/lib/arm-linux-gnueabihf/gstreamer-1.0/ /usr/lib/gstreamer-1.0 # ./waf configure --prefix=/usr --kernel-headers=/include # ./waf # ./waf install # cd ../../ (optional) Install libimxvpuapi library: This library provides a community based open-source API to the NXP imx-vpu library (the low-level IMX6 VPU interface). # git clone git://github.com/Freescale/libimxvpuapi.git # cd libimxvpu* # ./waf configure –-prefix=/usr # ./waf # ./waf install # cd .. note './waf install' installs artifacts to its prefix + /lib/gstreamer-1.0 but they need to be installed to /usr/lib/arm-linux-gnueabihf/gstreamer-1.0 which is why we created a symlink above before installing note g2d lib required to build G2D note that x11 library is required to build EGL sink with Vivante direct textures (only needed for X11 support) note that libfslaudiocodec is required to build audio plugins Now you are ready to test gstreamer 6: Add GPU HW Acceleration for X11 NOTE: The original version of these build instructions can be found in the Gateworks wiki . Many thanks to them for writing this! IMX6 IPU, VPU, and GPU support via GStreamer and Gstreamer-imx plugins. Many of the pieces needed (firmware and source-code) are from NXP and not freely redistributable thus must be downloaded from their mirror and extracted from a shell script that forces you to read and agree to their End User License Agreement (EULA). The following instructions can be used on top of the debootstrap and should work on other sources of Ubuntu or other Linux distributions root filesystems as well You can easily add X11 support to a base image created with the debootstrap instructions above by adding a few package groups. You will need the following: X11 server - ie Xorg Display Manager - this controls the login to the X session Window Manager - manages window position, re-sizing, decorations, etc for X clients If in any case you have installed the Linaro LXDE rootfs, it includes the Xorg X11 server, the lxdm Display Manager, the openbox Window Manager, and others useful user applications including the Chromium browser, if you do not install linaro lxde and want to install it please do: this step could take some time (~650MB)   # apt-get install xinit lxde lxterminal lxappearance lxrandr lxshortcut lxinput xinit  xserver-xorg-dev mesa-utils mesa-utils-extra Notes: you will need to add a non-root user with adduser for Chromium browser to work. You may choose to set up auto-login for that user by editing /etc/lxdm/default.conf and setting the autologin property in the base section at the beginning of the config file. /etc/xdg/lubuntu/lxdm/lxdm.conf This document takes as based kernel version 3.14.52v, vivante 5.0.11p7.4 correspond to the kernel version used. you should check the BSP release notes in order to know which xserver and Vivante GPU files need to be downloaded from the NXP repos. $ sudo nano /etc/lxdm/default.conf    [base]    autologin=user To add hardware GPU acceleration to X11 you need to add some libraries and drivers provided by Freescale from the imx-gpu-viv package. This requires signing Freescales End User License Agreement (EULA). This package provides the following: libg2d - a documented low-level API to the GPU (used by things like libimxvpuapi for gstreamer-imx and the gpu-core drivers) gpu-core - provides all the various OpenGL libs (libGL, libGLESv1_CM, libGLESv1_CL, libGLESv2, libGLSLC, libCLC, libEGL, libGAL, libOpenCL, ls libOpenVG) typically provided by the mesa project. Note that several versions of libEGL/libGAL/libGLESv2/libVIVANTE are provided for different backend rendering systems: dfb, fb, wl, x11. # cd gpu_pack #cd imx-gpu-* # cp gpu-core/usr/lib/dri/vivante_dri.so /usr/lib/xorg/modules/drivers/ # chmod 644 /usr/lib/xorg/modules/drivers/vivante_dri.so # rm /usr/lib/arm-linux-gnueabihf/mesa/libGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libEGL.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libGLESv2.so* # rm /usr/lib/arm-linux-gnueabihf/mesa-egl/libOpenVG.so* # cd ../../ # cd gpu-pack # wget http://www.nxp.com/lgfiles/NMG/MAD/YOCTO//xserver-xorg-video-imx-viv-5.0.11.p7.4.tar.gz # tar –xf xserver* # cd xserver-org-video-imx* #looks lik have to made #git init # ./fastbuild.sh  BUILD_HARD_VFP=1 XSERVER_GREATER_THAN_13=1 # cd.. # cd kernel-modu* # make Switch to gpu-core x11 backend: # backend=x11 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1 # ln -sf libEGL-${backend}.so /usr/lib/libEGL.so.1.0 # ln -sf libGAL-${backend}.so /usr/lib/libGAL.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2 # ln -sf libGLESv2-${backend}.so /usr/lib/libGLESv2.so.2.0.0 # ln -sf libVIVANTE-${backend}.so /usr/lib/libVIVANTE.so # ln -sf libGAL_egl.dri.so /usr/lib/libGAL_egl.so # for i in egl glesv1_cm glesv2 vg; do         cp /usr/lib/pkgconfig/${i}_${backend}.pc/usr/lib/pkgconfig/${i}.pc     done #rm /usr/lib/*-dfb.so /usr/lib/*-fb.so /usr/lib/*-wl.so (Optional in case you deploy your kernel version with GPU as module) make vivante kernel module (GPU kernel driver) load on boot: # echo vivante >> /etc/modules # nano /etc/udev/rules.d/10-imx.rules KERNEL=="galcore",  MODE="0660", GROUP="video" KERNEL=="mxc_asrc",  MODE="0666" Create an xorg.conf configured for the Vivante fbdev driver: # nano /etc/X11/xorg.conf Section "Device"     Identifier "i.MX Accelerated Framebuffer Device"     Driver "vivante"     Option "fbdev" "/dev/fb0"     Option "vivante_fbdev" "/dev/fb0"     Option "HWcursor" "false" EndSection Section "ServerFlags"     Option "BlankTime"  "0"     Option "StandbyTime"  "0"     Option "SuspendTime"  "0"     Option "OffTime"  "0" EndSection # cd .. Make sure the files copied into the correct places. If all compiled and copied, you should now see a bunch of new libraries in /usr/lib! Congratulations! After you finish you can reboot your system and start playing. Testing Gstreamer examples: show gstreamer-imx plugins: # gst-inspect-1.0 | grep imx imxvpu:  imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder imxvpu:  imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder imxvpu:  imxvpuenc_h264: Freescale VPU h.264 video encoder imxvpu:  imxvpuenc_h263: Freescale VPU h.263 video encoder imxvpu:  imxvpudec: Freescale VPU video decoder imxv4l2videosrc:  imxv4l2videosrc: V4L2 CSI Video Source imxg2d:  imxg2dcompositor: Freescale G2D video compositor imxg2d:  imxg2dvideotransform: Freescale G2D video transform imxg2d:  imxg2dvideosink: Freescale G2D video sink imxipu:  imxipucompositor: Freescale IPU video compositor imxipu:  imxipuvideosink: Freescale IPU video sink imxipu:  imxipuvideotransform: Freescale IPU video transform imxpxp:  imxpxpvideotransform: Freescale PxP video transform imxpxp:  imxpxpvideosink: Freescale PxP video sink imxipuvideosink: # gst-launch-1.0 videotestsrc ! imxipuvideosink imxg2dvideosink: # gst-launch-1.0 videotestsrc ! imxg2dvideosink The imxeglvivsink allows hardware accelerated display to a window on the X11 host # export DISPLAY=:0.0 # gst-launch-1.0 videotestsrc ! imxeglvivsink To test if you have graphics support you can run any glmark2 and/or mesa-utils or can run example of the next route: # cd /opt/viv_samples/vdk/ # ./tutorial1                                                                      //any example root@imx6Q:~# glxgears -info GL_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation GL_EXTENSIONS = WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_EXT_swap_control GL_EXT_texture_env_add GL_ARB_multitexture GL_ARB_multisample GL_ARB_texture_env_add GL_ARB_texture_compression GL_ARB_texture_env_combine GL_ARB_depth_texture GL_ARB_window_pos …. 1606 frames in 5.0 seconds = 321.130 FPS 1650 frames in 5.0 seconds = 329.834 FPS L_RENDERER   = Vivante GC2000 GL_VERSION    = 2.1 2.0.1 GL_VENDOR     = Vivante Corporation1629 frames in 5.0 seconds = 325.644 FPS 1621 frames in 5.0 seconds = 324.072 FPS 1650 frames in 5.0 seconds = 329.806 FPS 1651 frames in 5.0 seconds = 330.079 FPS