Overview Resources Download Ubuntu 12.04.01 Download i.MX28EVK BSP and Documents Ubuntu Host Setup Host Package Update Ubuntu Configuration PDF Sudo Priviledges Default Shell CCACHE Directory Layout Extract SDK and Documents Install BSP Sources Ubuntu Software Packages for LTIB Patching LTIB Create SD Card Using Ubuntu Host Media Booting Selection Cable Connections   Overview Freescale's i.M28EVK development kit provides a platform for running software and evaluating features of the i.MX28 processor. This document provides the details for running the Linux Board Support Package (BSP) on the Ubuntu 12.04 64-bit Precise Pangolin Host on an Intel/AMD architecture computer. The 32-bit host is not covered in this document and does have different configuration steps than described here.   An Ubuntu Linux host is used to cross-compile the BSP creating ARM images. The BSP provides a build system named Linux Target Image Builder, (LTIB),  the GNU tool suite for compiling and debugging, U-Boot boot loader, Linux kernel, and a root file system. Resources i.M28EVK- i.MX28 Evaluation Kit Web Page MCIMX28EVKJ Product Summary Page- i.MX28 Download Collateral L2.6.36_MX28_SDK_10.12_Source- BSP Source Download Linux documentation - i.MX28EVK Documentation Ubuntu 12.04.1 LTS (Precise Pangolin)- Ubuntu 12.04 Release Download Ubuntu 12.04.01 A dedicated computer running Ubuntu or a Virtual Machine, (VMware or VirtualBox), can be used for running the Host Ubuntu software. The Ubuntu image is available for downloaded from the Ubuntu site: Ubuntu 12.04.1 LTS (Precise Pangolin).   This Ubuntu host ISO was used with the md5 checksum: ubuntu-12.04.1-desktop-amd64.iso  06472ddf11382c8da1f32e9487435c3d   One way to acquire the ISO is to use zsync to download: zsync http://releases.ubuntu.com/12.04/ubuntu-12.04.1-desktop-amd64.iso.zsync  Once downloaded, installing the ISO is user preference - either a dedicated Linux PC or in a Virtual Machine.   Download i.MX28EVK BSP and Documents The BSP download is from this site L2.6.36_MX28_SDK_10.12_Source and the documents from Linux documentation that requires a free registration to specify login credentials,   436e0b8e1c7976c657d530a45f9dbd0c L2.6.35_10.12.01_SDK_source_bundle.tar.gz de0274320a17c1e989d1ef5c088973e2 L2.6.35_10.12.01_SDK_docs.tar.gz   Ubuntu Host Setup Ubuntu login credentials of User: user Password: user are used for this documents. Host Package Update Once logged in to the Ubuntu host, the existing packages are brought up to date to the latest version before installing the BSP. The Ubuntu package manager used is apt-get. $ sudo apt-get update $ sudo apt-get upgrade  01. Check all installed packages for new revisions 02. all newer packages found are installed.   Addtional packages are required for the ltib build system. Ubuntu Configuration PDF evince is the default pdf reader, another option is zathura. $ sudo apt-get install zathura Sudo Priviledges LTIB requires super user priviledges for some operations. To enable a visudo entry is added to the sudo'ers file. For more information run 'man visudo'.   $ sudo visudo  The first word, user, is the login account 'user' This can be changed to whatever login you used, or if you have groups configured you can provide a group that developers are in - refer to the man page for sudo for details. Add this line:   user ALL =NOPASSWD: /usr/bin/rpm/ /opt/freescale/ltib/usr/bin/rpm   Default Shell Ubuntu uses the default shell 'dash'. This however causes failures on bash scripting which is part of the ltib system. Change the default shell from 'dash' to 'bash'   $ sudo update-alternatives --install /bin/sh sh /bin/bash 1  CCACHE ccache provides a fast C/C++ compiler cache which is supported in the ltib system. To configure once the ccache package has been installed: $ sudo apt-get install ccache $ ccache -M 50M $ ccache -c  02. Set the cache limit to 50 Meg 03. Clear the cache folder   Directory Layout The following directory structure is used: /home/user/freescale/imx28/ |-- archive |-- L2.6.35_10.12.01_ER_source |-- L2.6.35_10.12.01_SDK_docs |-- L2.6.35_10.12.01_SDK_scripts |-- ltib |-- ubuntu-imx28-ltib-patch   The archive directory is where the BSP and documents are stored; command to create the directory: $ mkdir -p ~/freescale/imx28/archive   Extract SDK and Documents The following instructions were used to extract the contents of the Software Development Kit:   $ cd ~/freescale/imx28/archive $ tar -zxf L2.6.35_10.12.01_SDK_source_bundle.tar.gz -C ..    01. Change into the directory containing the tar ball that is compressed. 02. Extract the contents into the directory above (-C ..) the current directory -z unzip -x extract -f L2.6.35_10.12.01_SDK_source_bundle.tar.gz   $ tar -zxf L2.6.35_10.12.01_SDK_docs.tar.gz  01. Extract the contents into the directory above (-C ..) the current directory     -z unzip     -x extract     -f L2.6.35_10.12.01_SDK_docs.tar.gz this file The contents of both tar files are now in the directory /home/user/freescale/imx28. Install BSP Sources After extracting the content from the L2.6.35_10.12.01_SDK_source_bundle.tar.gz the file L2.6.35_10.12.01_SDK.source.tar.gz contains all the sources and the build system. Extract the contents and install. This will create the ltib directory which is the build system. $ tar -zxf L2.6.35_10.12.01_SDK_source.tar.gz $ cd L2.6.35_10.12.01_ER_source $ ./install  Read the license information and accept by entering YES. An installation directory is then asked for, providing:  .. which is the parent directory. The installation script copies the packages and will inform you that 'Installation complete, your ltib installation has been placed in ../ltib, to complete the installation: cd .../ltib ./ltib  HOWEVER before doing this, there are packages and patches that need to be applied to run ltib on Ubuntu 12.04.01. Ubuntu Software Packages for LTIB The following packages are required. The script pkg-setup.sh attached below has these packages which can be downloaded and executed to install. $ sh pkg-setup.sh  sudo apt-get -y install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev sudo apt-get -y install libdbus-glib-1-dev liborbit2-dev intltool sudo apt-get -y install ccache zlib1g zlib1g-dev gcc g++ libtool sudo apt-get -y install uuid-dev liblzo2-dev tcl wget libncurses5-dev sudo apt-get -y install libncursesw5-dev lib32z1 libglib2.0-dev xsltproc sudo apt-get -y install ia32-libs libc6-dev-i386 The file pkg2-setup.sh contains optional packages for development. To install, download and execute: $ sh pkg2-setup.sh Please refer to the document ltib_build_host_setup.pdf for more information on host setup. Patching LTIB The location of files from the glibc-devel and zlib Ubuntu 12.04 packages has changed from 9.0.4 Ubuntu which the original ltib was released against. To update ltib operation the following patches are implemented from the directory ~/freescale/imx28/ltib 1. The file ltib is changed at line 2387 adding the '-v' option to the rpm call OLD:     system('rpm --force-debian 2>/dev/null') == 0? NEW:     system('rpm -v --force-debian 2>/dev/null') == 0? 2. The file bin/Ltibutils.pm is updated to support glibc-devel and zlib.   glibc-devel update: Line 563 add check for /usr/lib32/libm.so 'glibc-devel' => sub {-f 'usr/lib/libm.so' || -f '/usr/lib64/libz.so' || -f '/usr/lib32/libm.so'},   zlibc update: Line 584 add /lib/x86_64-linux-gnu/libz.so* zlib => sub{my @f = (glob('/usr/lib/libz.so*'),               glob('/lib/x86_64-linux-gnu/libz.so*'),               glob('/lib/libz.so*'),   The above patches are also in the attachment 0001-patches-for-12.04-ubuntu.patch.   LTIB packages also need adjustments to correctly build on Ubuntu. The tar file below, ubuntu-imx28-ltib-patch.tgz contains all the updates. Download and extract the contents at the same directory level as your ltib source directory. $ tar -zxf ubuntu-imx28-ltib-patch.tgz ├── ltib ├── ubuntu-imx28-ltib-patch └── ubuntu-imx28-ltib-patch.tgz Change directories to ubuntu-imx28-ltib-patch and then run the install-patches.sh script. $ cd ubuntu-imx28-ltib-patch $ ./install-patches.sh   The following packages are updated: lkc mtd-utils mux_server sparse Create SD Card Using Ubuntu Host The tar file L2.6.35_10.12.01_SDK_scripts.tar.gz contains scripts for writing the images from the ltib build to a SD card. Extract the content, copy the scripts to the ltib directory, and update the mk_mx28_sd script to work with the updated fdisk command.   $ tar -zxf L2.6.35_10.12.01_SDK_scripts.tar.gz $ cd L2.6.35_10.12.01_SDK_scripts $ cp mk_hdr.sh ~/freescale/imx28/ltib $ cp mk_mx28_sd ~/freescale/imx28/ltib $ cd ~/freescale/imx28/ltib  Edit mk_mx28_sd script and add the 'u' at line 177 then the o command after. This changes cylinders to sectors.   OLD: echo "o n   NEW: echo "u o n   Once updated to create the SD card which is at /dev/sdb: $ ./mk_mx28_sd /dev/sdb  NOTE: if mounted automatically, you need to unmount for the script to work $ sudo umount /dev/sdb*      Media Booting Selection The i.MX28EVK has a boot option to execute from the SD Card in Slot 0 which is located on the bottom of the EVK. On the top of the EVK there are switches that are read during the start up process to determine what boot media to use. The SD Card in slot 0 is used for this example which requires the settings: B3/DIP1 B2/DIP2 B1/DIP3 B0/DIP4 1 0 0 1 Refer to the user guide, i.MX28_Linux_BSP_UG.pdf section 3.2.1. Boot Modes for all options. The user guide is found in the Linux documentation bundle documentation.  Refer to the next section for a picture showing the boot switch location and the SD Card Slot 0 location. Cable Connections A computer serial port is connected to the i.MX28EVK serial port. The communication setting is 115200 baud, 8 data bits, No parity, and 1 stop bit. There is NO flow control set for this port. This is typically shown as 115200, 8N1. The power supply is connected  

Atlas PMIC i.MX Platforms uses Freescale Atlas chipset as power management IC (PMIC). PMIC is connected with i.MX processor through SPI port. Reading and Changing PMIC Registers pmic_reg is a simple program that allows to read and change PMIC registers through SPI. Click here to download the binary Click here to download the source package Click here to download the spec file pmic_reg Installation To use pmic_reg, you can simply download the binary file and move it to your system. To build the source code, download and mv the source package (in this case "pmic_reg-1.0.tar.gz") to /opt/freescale/pkgs: sudo mv pmic_reg-1.0.tar.gz /opt/freescale/pkgs Download the spec file to spec directory: mkdir <ltib directory>/dist/lfs-5.1/pmic_reg cp pmic_reg.spec <ltib directory>/dist/lfs-5.1/pmic_reg On <ltib directory>, extract, build and deploy pmic_reg: ./ltib -p pmic_reg.spec -m prep ./ltib -p pmic_reg.spec -m scbuild ./ltib -p pmic_reg.spec -m scdeploy Source files will be located at <ltib directory>/rpm/BUILD/pmic_reg-1.0 and binary will be located at /usr/bin on your i.MX system rootfs. pmic_reg Usage To get pmic_reg help, just type pmic_reg: PMIC_REG v1.0 (2009.12.15) Usage To read all PMIC registers: pmic_reg r To write to a specific register: pmic_reg w <register address> <register value>

The miscellaneous service is in charge of providing access to all features not handled by the other services some examples include the following features: Subsystems controls - Some subsystems have settings that can be configured through the SCFW. For instance it is possible to set thresholds for a temperature alarm and get the temperature value of the sensor in different resources. For a complete list of resources and its controls please refer to the sc_fw_api document Chapter 5 Control List. DMA configurations - The SCFW provides access to DMA grouping and priority functions. Security functions - The SCFW provides some security functions such as: Image loading and authentication Fuse writing Life cycle management. Debug features - The SCFW provides some debug functionality through its miscellaneous service, some examples include:  Output a character through the SCU UART port Obtain SCFW build information (SCFW version) Obtain device Unique ID For a complete list of functions supported by your device please refer to the (SVC) Miscellaneous Service chapter of the sc_fw_api document.  This guide will cover the most common functions,  Getting and setting a control The process to get and set a control on a resource is the same for all available controls. Refer to the Control list chapter of your SoC SCFW API document for a complete list of the available controls. The following example will be based on an i.MX8QM.  The control list looks as follows: The table lists the controls available per resource as well as the width of the data to get/set, the 'Set' column describes whether a control is 'settable' or not, for instance the temperature sensor on the A53 resource can only be read/retrieved it cannot be 'written' (set) therefore the 'Y' (yes) in this column is missing, a brief description of the control is also provided. To get a control sc_misc_get_control must be called: uint32_t val; sc_misc_get_control(ipc, SC_R_A53, SC_C_TEMP, &val)‍;‍‍‍‍‍‍ By default all calls to get_control need a pointer to a 32 bit unsigned integer, the width field on the control list table defines the span of meaningful data. In the example above the data from the temperature sensor in the A53 resource is retrieved. This call returns SC_ERR_NONE whenever it succeeds. If the parameters are invalid it returns SC_PARM and if the caller does not have access to that resource it returns SC_ERR_NOACCESS. To set a control sc_misc_set_control must be called: uint32_t val = high_alarm_temperature_value; sc_misc_set_control(ipc, SC_R_A53, SC_C_TEMP_HI, val);‍‍‍‍‍‍‍‍ As in the get example sc_misc_set_control expects a 32 bit unsigned integer, it is the responsibility of the user to pass a value within the width limits defined in the control list table. In the example above the upper threshold for the A53 resource is being set/configured. The return values are the same as in sc_misc_get_control. Other functions There is a different method for getting/setting temperatures in a friendly human readable format, the method above uses a 'raw' format to interact with the temperature sensors in the resources, an easier way is to use the sc_misc_get_temp and sc_misc_set_temp functions. This functions return the temperature value in degrees Celsius as well as it's fractional part. To define whether to get/set the value for the temperature sensor itself or one of it's alarm the sc_misc_temp_t has been defined. SC_MISC_TEMP      -> Temperature sensor SC_MISC_TEMP_HIGH -> Upper threshold temperature sensor alarm SC_MISC_TEMP_LOW  -> Lower threshold temperature sensor alarm‍‍‍‍‍‍‍‍‍ For instance to get the temperature reading from the A53 resource the following call can be made: int16_t celsius; int8_t tenths; sc_misc_get_temp(ipc, SC_R_A53, SC_MISC_TEMP, &celsius, &tenths);‍‍‍‍‍‍‍‍‍ And to set the upper threshold alarm: int16_t celsius = 80; int8_t tenths = 0; /* Set High temperature alarm to 80 degrees Celsius */ sc_misc_set_temp(ipc, SC_R_A53, SC_MISC_TEMP_HIGH, celsius, tenths);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Unique ID of the chip as well as the build info of the SCFW can also be obtained through the miscellaneous service, the following example queries for this information: /* Getting SCFW version information */ uint32_t build_version; uint32_t commit_hash; sc_misc_build_info(ipc, &build_version, &commit_hash);‍‍‍ /* Getting Device Unique ID */ uint32_t ID_L; uint32_t ID_H; /* The ID is a 64-bit number ID_L stores the lower 32-bit portion and ID_H the 32-bit upper portion */ sc_misc_unique_id(ipc, &ID_L, &ID_H);‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Refer to the sc_fw_api document for a definition of the remaining miscellaneous functions. https://community.nxp.com/docs/DOC-342654 

You can use TV Out on i.MX27ADS board by following these steps: Remove the R71 and solder it on R69 place; See the image before of this process: And after this process: Set SWITCH S15: 1 = on; [2-5] = off. See the image for more details: Add to your Linux command line (in Redboot) the following parameter: video=mxcfb:TV-NTSC After this modification, the video signal will operate at 27MHz, that are applicable just with TV-OUT card. The LCD card will not work at this frequency.

Enabling Dual Display in Ubuntu with the i.MX53 Quick Start Board Here you will learn how to enable two displays in a Ubuntu system running in an iMX53 Quick Start Board. We assume here that you already have a micro SD card with a valid Ubuntu image (including uboot, Linux kernel and Ubuntu filesystem). You can use the original SD card that comes with the i.MX53 Quick Start Board, which brings an image of Ubuntu or, if you do not have the original SD card, you can reproduce it by downloading Ubuntu binaries package (L2.6.35_MX53_ER_1101_IMAGE) from Freescale iMX53qsb download area. You will also need to update U-boot and kernel binaries in the SD card with more recent images. You can find the most recent binaries (L2.6.35_MX53_ER_1109_IMAGE_) from Freescale iMX53qsb download area as well. Introduction To enable dual display, you need to perform two tasks: Enable two displays at kernel level Configure your Xorg server accordingly Enabling Two Displays at Kernel Level To enable two displays at kernel level means to map one display interface to fb0 device and the other to fb1 device. So first thing is to choose which interface will be the primary one, mapped as fb0. As an example, we consider the VGA interface as primary in this tutorial. Second thing is to choose one of the other available external video interfaces to be secondary, mapped as fb1 device in the system. We consider the 4.3" seiko LCD display in this tutorial as the secondary interface. Once chosen primary and secondary interfaces, we need to configure kernel video arguments accordingly. The arguments are available in specific variables in the U-boot that comes with the Ubuntu binaries. You can see them (HDMI, VGA, etc.) by printing the U-boot environment variables from the U-boot shell, but you will probably not find those variables in other versions of U-boot and their contents will probably need to be adapted to the kernel version in use, as arguments recognized by kernel modules varies considerably between kernel versions. You can always refer to the Linux Release Notes documents for video arguments. It's available for each Linux BSP that can be found on the Freescale website. For the 1109 BSP, we have the following video arguments (extracted from i.MX53_START_Linux_BSP_Release_Note.pdf that comes with L2.6.35_11.09.01_ER_docs.tar.gz downloaded from here - IMX53_1109_LINUXDOCS_BUNDLE😞 VGA: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga SEIKO LCD: video=mxcdi0fb:RGB24,SEIKO-WVGA di0_primary Both are considered primary, because these are the arguments for single display setups. Now that we have video arguments for both desired interfaces, we only need to merge them together removing the primary argument from the one that is the secondary. In our case, we need to pass the following arguments to the kernel: video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA For this, we can add these arguments to one of the variables that are used in the boot process. We can add the content to bootarg_base, for instance. In the U-boot command line, execute following commands to setup the environment: setenv vga_and_seiko 'video=mxcdi1fb:GBR24,VGA-XGA di1_primary vga video=mxcdi0fb:RGB24,SEIKO-WVGA' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 vga_and_seiko' saveenv After applying a reset and booting the board, you shall have both interfaces enabled, but the secondary will not be used by the Xorg server until we complete the next step. Configuring Xorg Server Now that we have two video interfaces properly configured and mapped to /dev/fb0 and /dev/fb1 devices, we need to tell Xorg server how to use them. Here is an example of xorg.conf file that you can use to replace the default one, found at /etc/X11: Section "InputDevice" Identifier     "Generic Keyboard" Driver          "kbd" Option          "XkbRules"     "xorg" Option          "XkbModel"     "pc105" Option          "XkbLayout"     "us" EndSection  Section "InputDevice" Identifier     "Configured Mouse" Driver          "mouse" Option          "CorePointer" EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 0" Driver          "imx" Option          "fbdev"               "/dev/fb0"  # This option only recognized when "mxc_epdc_fb" frame buffer driver in # use.  Values are "RGB565" (default, 16-bit RGB), "Y8" (8-bit gray), # and "Y8INV" (8-bit gray inverted). Option          "FormatEPDC"               "Y8INV"  EndSection  Section "Device" Identifier     "i.MX Accelerated Framebuffer Device 1" Driver          "imx" Option          "fbdev"               "/dev/fb1"  EndSection  Section "Monitor" Identifier     "Configured Monitor 0" EndSection  Section "Monitor" Identifier     "Configured Monitor 1" EndSection  Section "Screen" Identifier     "Screen 0" Monitor          "Configured Monitor 0" Device          "i.MX Accelerated Framebuffer Device 0"  # These "Display" SubSection's are needed for working with the # "mxc_epdc_fb" frame buffer driver. SubSection     "Display" Depth     8 Visual     "StaticGray" EndSubSection SubSection     "Display" Depth     16 Visual     "TrueColor" EndSubSection EndSection  Section "Screen" Identifier     "Screen 1" Monitor          "Configured Monitor 1" Device          "i.MX Accelerated Framebuffer Device 1" EndSection  Section "ServerLayout" Identifier     "Xinerama Layout" Screen          "Screen 0" Screen          "Screen 1" RightOf "Screen 0" EndSection  Section "ServerFlags" Option          "Xinerama"          "true" EndSection Results The following picture shows the i.MX 53 QSB running the extended desktop previously configured. You can see the VGA monitor with a Firefox instance and the SEIKO LCD display with a calc instance.

The decommission of the git.freescale.com has caused some problems to BSPs dependent on packages stored in this repository. All contents on git.freescale.com have been moved to one of three locations: NXP · GitHub  (github.com/NXP) NXP Micro · GitHub  (github.com/NXPMicro) https://source.codeaurora.org/external/imx/   In the case of some older Android BSP this causes an error when fetching the imx-firmware packages originally stored in this repository. A workaround to this is to switch the original location to the new location. To do this we would need to manually create a build directory and initialize repo to locally load the manifest files and then make this change. Android BSP won’t require this workaround. Please note that this workaround only addresses this specific error that may show up when running the script included on the BSP release. We will be using the Oreo o8.0.0_1.0.0_ga BSP release as an example. Sources for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Design_Tools_Tab Documentation for this BSP can be found on the following link: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/android-os-for-i-mx-applications-processors:IMXANDROID?tab=Documentation_Tab    1) Initialize the repo. If you have tried running the imx_android_setup.sh script the android build directory should already have been created. If this is the case, please skip to the next step. If not, please create it either by running imx_android_setup.sh or manually with the following commands (using the android setup script is preferred): $ mkdir android_build Once inside the build directory, initialize the repo and then sync it: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest.git -b imx-android-oreo -m imx-o8.0.0_1.0.0_ga.xml $ repo sync   2) Find and edit the Android Manifest. Once inside the build directory after synching, enter the repo manifests directory by executing the following command while inside the android build directory $ cd .repo/manifests  And look for the corresponding Android manifest. In this case imx-o8.0.0_1.0.0_ga.xml Open this file in any text editor (use sudo if running in a directory which requires it) In this case we’ll exemplify with nano $nano imx-o8.0.0_1.0.0_ga.xml And change the git://git.freescale.com/proprietary/  to git://github.com/NXP/ Also the path for imx-firmware so the complete line goes from: <project path="vendor/nxp/imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ To the following: <project path="imx-firmware" name="imx-firmware" remote="imx-proprietary" revision="87ba304b9efbb2e8dbdd54af4c087584fb259535" />‍‍‍ The manifest should look like the following. Save the file with these changes.   Now you can run the imx_android_setup.sh build script successfully. Since the repo was already synced it won’t fetch the manifests again and the change we made will persist, which will allow to find the imx-firmware package on its new location.

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 typing: $cd <ltib instalation folder> $./ltib -c 2 - On first page menu, go to "Target Image Generation -> Options" as in the picture below. 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/

Platform: imx8qm mek imx-yocto-L4.14.98_2.0.0_ga Building Step: Apply the nvp6324 patches.   Symbol: IMX8_NVP6324 [=y] Type : tristate Prompt: IMX8 NVP6324 Driver Location: -> Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> V4L platform devices (V4L_PLATFORM_DRIVERS [=y]) -> MX8 Video For Linux Video Capture (VIDEO_MX8_CAPTURE [=y]) (1) -> IMX8 Camera ISI/MIPI Features support ‍‍‍‍‍‍‍‍‍ select nvp6324 to y in menuconfig(default is 'y') make Image -j8; make freescale/fsl-imx8qm-mek-nvp6324.dtb, to build kernel and dts, outputs are at  work/imx8qmmek-poky-linux/linux-imx/4.14.98-r0/build/arch/arm64/Image work/imx8qmmek-poky-linux/linux-imx/4.14.98-r0/build/arch/arm64/boot/dts/freescale/fsl-imx8qm-mek-nvp6324.dtb copy them to the sd boot partition. reboot the board, you can test the first camera with command: ./mx8_v4l2_cap_drm.out -cam 1 -ow 1280 -oh 720 mx8_v4l2_cap_drm.out is at /unit_tests/V4L2/mx8_v4l2_cap_drm.out The corresponding video device should be default to /dev/video0 ~ /dev/video3.

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"