i.MX Processors Knowledge Base

cancel
Showing results forΒ 
Search instead forΒ 
Did you mean:Β 

i.MX Processors Knowledge Base

Discussions

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.
View full article
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.
View full article
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/
View full article
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.
View full article
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.
View full article
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
View full article
1.- Set SW602 Boot mode pin settings to Serial Downloader mode 2.-Connect JTAG debug probe and turn on the board 3.-Run script to bring-up DRAM In Lauterbach this script is called 'mcimx6ul_sieve_dram.cmm' under the mcimx6ul folder, the scripts can be found here and are also attached (download the imx6ultralite package). If you are not using Lauterbach please ask your probe vendor for a similar script. NOTE: this u-boot image has been built to run off DRAM if your bootloader runs from OCRAM you might not need a script. While running the script you might be prompted with and error telling you there is a syntax error in the script system.cpu IMX6ULL simply edit the script and change the CPU name to IMX6ULTRALITE 4.- Load u-boot.srec to DRAM and start executing it The srec is being used in this case because it contains the addresses where the binary needs to be loaded and the entry point for the application is automatically recognised and set by Lauterbach. To load it simply issue 'data.load.S3record u-boot.srec' and then click on go to let it run. You should now be able to see the output from u-boot on the console hit any key on the console to stop the boot process. 5.- Load QuadSPI configuration to DRAM and flash it to the memory The Boot ROM on the i.MX6UL requires the configuration data for the QuadSPI memory to be stored at address 0x400 of the QuadSPI memory, the length of this configuration data is 512 bytes. Attached is a configuration binary that can be used for the NOR flash memory used in the i.MX6UL EVK. For more details on the configuration parameters please refer to chapter '8.6.3 QuadSPI Configuration Parameters' of the i.MX6UL Reference Manual. Stop the execution on T32 (Lauterbach's environment) and load the configuration to DRAM by issuing 'data.load.binary QSPI_cfg2.bin 0x90000000' and resume execution. On u-boot execute the 'sf probe' command (sf stands for Serial Flash) to detect the memory. You should see an output like the following: => sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB Now issue the sf erase command to erase the first sector (remember our erase size is of 4KiB): => sf erase 0x0 0x1000 SF: 4096 bytes @ 0x0 Erased: OK Now we are ready to write our configuration to address 0x400 => sf write 0x90000000 0x400 0x200 SF: 512 bytes @ 0x400 Written: OK 6.- Load u-boot.imx to DRAM and download it to memory. We will follow the same procedure to download the u-boot image to the memory. Stop execution on Lauterbach and load u-boot.imx to DRAM using 'data.load.binary u-boot_SPI.imx 0x90000000' and resume execution (u-boot.imx contains the IVT header which basically stores all the information the device needs to boot u-boot.bin and u-boot.imx). The boot ROM expects to find the IVT header at address 0x1000 of the SPI NOR Flash memory. We will load u-boot.imx to this address by issuing ' sf update 0x90000000 0x1000 0x57830 '(the size of u-boot.imx is 358448 bytes) this will erase and write the memory. => sf update 0x90000000 0x1000 0x57830 358448 bytes written, 0 bytes skipped in 23.741s, speed 15458 B/s If you want to verify that the image was flashed correctly you can read from QuadSPI to DRAM by issuing 'sf read 0x90000000 0x1000 0x57830 ' and verify the data. 7.- Now we can end our debug session and turn off our board Set SW602 to Internal boot mode (ON/OFF) and SW601 to select boot from QuadSPI (all OFF) Turn on the board again and you should be able to see u-boot's output on your terminal. This procedure can be used with other boards/i.MX6 derivatives, I am just posting the setup in which I tested it.
View full article
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
View full article
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/         
View full article
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
View full article
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      
View full article
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.
View full article
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>‍‍‍‍‍‍‍‍ ‍ ‍
View full article
The Register Programming Aid (RPA) provides a default DRAM PLL setting (DRAM frequency) based on the default setting supported in u-boot.  It is highly recommended to use the default DRAM frequency settings in the RPA for ease of use and to align with u-boot.  Otherwise, in addition to updating the RPA for the new DRAM frequency, the u-boot SPL code itself will need to be manually updated with the new DRAM PLL setting.   Should the user wish to change the DRAM frequency, the following steps are required:   First, the user needs to update the RPA Register Configuration worksheet tab Device Information table β€œ Clock Cycle Freq (MHz) β€œ setting to the desired DRAM frequency     2. Next, in the RPA DDR stress test file worksheet tab search for β€œ memory set 0x30360054 ”.  The address β€œ 0x30360054 ” is for the DRAM PLL register address and its setting needs to be updated to the desired frequency.      Note that there is another place where the DRAM frequency is also updated β€œ freq0 set 0x30360054 ” but it is automatically updated based on the setting above.    Below is a table of various frequencies to choose from.  For frequencies not listed in the table below, it is up to the user to calculate a new register setting based on the formula:    (24MHz x m)/(p x 2^s)   Where β€œm” represents the PLL_MAIN_DIV, β€œp” represents the PLL_PRE_DIV, and β€œs” represents the PLL_POST_DIV.  NOTE:  The DRAM frequency is double the DRAM PLL frequency DRAM_freq = DRAM_PLL x 2   The DRAM PLL register and bit settings are shown below:        The following table provides examples of the various settings to create the desired frequency:   For example, in the i.MX 8M Mini LPDDR4 RPA where the default DRAM frequency is 1500MHz, let’s assume that the user instead wants 1200MHz.  First, the user changes the RPA Register Configuration worksheet tab Device Information table β€œ Clock Cycle Freq (MHz ) β€œ setting to 1200. Next, in the RPA DDR stress test file worksheet tab search for β€œmemory set 0x30360054” and replace β€œ0xFA080” (original setting from DRAM frequency 1500MHz) with β€œ 0x0012C032 ” (updated for DRAM frequency 1200MHz).  Note that for a DRAM frequency of 1200MHz, the DRAM PLL is configured for 600MHz, as the DRAM frequency is double the DRAM_PLL.   The steps outlined above are sufficient in order to create a DDR script for use with the DDR stress test tool to run the calibration and execute the DDR stress test.  However, to deploy the generated code in SPL, more steps are needed as the u-boot SPL DDR driver does not automatically change the DRAM PLL according to the generated code. Hence the user will need to manually modify related code in u-boot.  It is highly recommended to work with a software engineer familiar with u-boot when making the following modifications.    3. Modify DRAM PLL configuration in   uboot-imx/drivers/ddr/imx8m.c , specifically the code highlighted below (function call dram_pll_init).  Note that the files and file paths in u-boot change frequently, so if this particular file (or file path) does not exist in the current u-boot, simply search for dram_pll_init or ddr_init.   void ddr_init(struct dram_timing_info *dram_timing) { ……    debug("DDRINFO: cfg clk\n");      if (is_imx8mq())           dram_pll_init(DRAM_PLL_OUT_800M);      else            dram_pll_init(DRAM_PLL_OUT_750M); ……  }   In the above code, the user should update the macro β€œ DRAM_PLL_OUT_750M ” with the new DRAM PLL value.  Note that the default DRAM_PLL_OUT_750M results in the DRAM frequency of 1500MHz, where the DRAM frequency is double the DRAM PLL (as previously stated above).   For example, if the user desires to run the DRAM at 1200MHz, they would change the above to:  dram_pll_init(DRAM_PLL_OUT_600M) ;   Note that DRAM_PLL_OUT_600M is a supported macro in the dram_pll_init() API.  If the desired DRAM PLL configuration does not exist in dram_pll_init(), you will need to add support in uboot-imx/arch/arm/mach-imx/imx8m.c  (as stated above, if this file path does not exist in the current u-boot simply search for dram_pll_init):   void dram_pll_init(enum dram_pll_out_val pll_val) { …… } Related Links i.MX8 MSCALE SERIES DDR Tool Release (V3.10) 
View full article
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
View full article
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 
View full article
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"
View full article
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
View full article
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.
View full article
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
View full article