NOTES: Empty cells do not mean there is no bitbake parameter for the corresponding ltib one. This is still work in progress. Both engines are completely different and doing a one-to-one comparison is not actually fair. The following tables compare the two core build tools, ltib for LTIB and bitbake for the Yocto Project (YP, hereafter). For YP, there is another important tool called HOB,  when appropriate, we add comments on the Comment's column. There are two main tables, 'ltib modes versus bitbake' 'ltib options versus bitbake'.          We split in two based how ltib splits its parameter, so the order is the same as the one shown when typing './ltib --help'. LTIB comes in every released BSP, follow the User Guide to install it. The command 'ltib' is a script located on the folder with the same name, so all ltib commands should be run with './' as prefix YP can be seen of a series of layers (folders). To download these, including the Freescale layers, follow this link. The command 'bitbake' must be installed independently, you can either use the package manager of you OS (e.g. sudo apt-get install bitbake on Ubuntu) or download the source code and do the setup manually. Both ways should place the bitbake script into a executable path. ltib modes versus bitbake Mode description ltib command bitbake command Comment Just prep the package ltib -m prep -p <package> bitbake <package> -c patch With bitbake when running the patch task, it executes two lower tasks: fetch and unpack. For example, if one wants a untouched (no yocto patches) kernel, one can try: 'bitbake linux-imx -c unpack' and code unpacked code is placed on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/<version>/git/ rpmbuild -bc --short-circuit ltib -m scbuild -p <package> bitbake <package> -c compile With bitbake running compile also runs a lower task: configure. rpmbuild -bi --short-circuit ltib -m scinstall -p <package> bitbake <package> -c With ltib the install task executes the %Install section of the package's spec. With bitbake the same task executes all related package's recipe install functions, e.g. do_install. Note: with ltib running a higher task (like scinstall) will not execute lower tasks (like scbuild and prep); this is not the case for bitbake: it runs lower tasks automatically. does an scinstall followed by an install to the rootfs ltib -m scdeploy -p <package> bitbake <package> -c build With bitbake, build is the default task, so one can even omit the -c build parameter, e.g. 'bitbake <package>' generate and merge a patch (requires -p <pkg>) ltib -m patchmerge -p <package> NA This is a pretty nice feature from LTIB, unfortunately with bitbake the command does not exit. For example, to patch the Kernel's recipe, take a look at this procedure. In case you follow all these steps to fix a bug, do not forget to send your patch to the community. lean/uninstall target packages ltib -m clean -p <package> NA With bitbake the 'clean' counterpart does not exit. If one needs to remove a specific package from a build, you may remove it from the image configuration file (e.g. file meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb, remove item on IMAGE_INSTALL variable); if package is inside a package group (e.g. ./meta-fsl-demos/recipes-fsl/packagegroup/packagegroup-fsl.bb) you may remove it there. After this change, bitbake again and the resulting image won't have the package. With HOB, this is much simpler due to its Graphical User Interface. Just type hob on your build directory, select the machine and the base image, then click on the 'Edit Image'. On that window you can easily deselect packages. Once deselection is done, build the image. full cleanup, removes nearly everything ltib -m distclean NA With bitbake the 'distclean' command does not exit. The way to remove all the built, remove the build/tmp folder. Be careful, next time you run bitbake, all tasks for all packages will be executed, in other words, you will start from scratch. list packages (alphanumeric) ltib -m listpkgs non-GUI: bitbake -g fsl-image-gui && cat pn-depends.dot GUI: bitbake -g -u depexp fsl-image-gui A bit more complex non-GUI: bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq list package names and licenses ltib -m listpkgseula NA With HOB, you can see every package name name and its licence. Just type hob, then select the machine and image, and click on the 'Edit Image' button. On the 'All recipes' tab, you get a list of packages with their licenses. list packages in twiki format ltib -m listpkgstw NA list packages in a format for import into spreadsheet ltib -m listpkgscsv NA make a binary release iso image ltib -m release NA make a non-distributable test iso release ltib -m trelease NA configure selected platform (no build) ltib -m config NA There is no way to open a configuration menu with bitbake. Instead, you can use hob. With hob, things are much easier. Just type hob under the build folder and you can select the machine and the image. If the image you want does not fit to the ones already available, you can add packages manually and even store your new tuned image. NOTES: 1. On YP, an image is a similar concept as LTIB's package profile (usually called just profile). There are many predefined images which can be used as starting point, so type 'bitbake <image name>'. 2. In case the kernel needs to be configure, run 'bitbake linux-imx -c menuconfig'. sub-platform selection (no build) ltib -m selectype NA The selectype on LTIB opens two menus: 1. Platform and the Package Profile selection 2. Configuration menu (the same menu as the one shown with -m config). In case one needs to do execute just the first task, just run 'bitbake <image name>'. In case you need to execute both, run hob. enter ltib shell mode (sets up spoofing etc) ltib -m shell bitbake <package name> -c devshell import srpms into ltib (semi-automatic) ltib -m addsrpms ltib options versus bitbake Option Description ltib command bitbake command Comments Root context number (0 is the primary and implicit) ltib --rootn | ltib -R operate on this package only ltib --pkg | ltib -p bitbake <package> With bitbake there is no need to add a '-' parameter, just use the package name without the .bb extension run the interactive configuration and build ltib --configure  | ltib -c NA See the mode -m config for more info run the sub-platform configuration and build ltib --selectype NA See the mode -m selectype for more info configuration file to build from (defaults to .config) ltib --preconfig bitbake <predefined image> With bitbake use any of the predefined images (assuming that these have not been modified), e.g. bitbake core-image-minimal or bitbake fsl-image-gui (it happens to be the smallest and the largest image, in terms of number of packages) profile file.  This is used to select an alternate  set of userspace packages, this is saved and used on later runs of ltib (e.g config/profiles/max.config) ltib --profile use this resource file ltib --rcfile <f> | ltib - r <f> batch mode, assume yes to all questions ltib --batch | ltib -b force rebuilds even if they are up to date ltib --force | ltib -f bitbake --force | bitbake -f For example, to force recompiling the kernel: bitbake linux-imx -c compile -f re-install rpms (but don't force rebuild) ltib --reinstall | ltib -e bitbake <package name> -c install -f remove (erase) rpm ltib --erase | ltib -E turn off install/uninstall dependency checks ltib --nodeps | ltib -n bitbake -b <somepath/somefile.bb> For example, to build just the kernel (no dependencies, just kernel): bitbake -b ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb NOTE: ALL dependencies should be already be installed, otherwise the command will fail don't force install rpms that have file conflicts ltib --conflicts | ltib -k keep the srpms after the build (deleted by default) ltib --keepsrpms | ltib -s more output ltib --verbose | ltib -v bitbake --verbose | bitbake -v On YP, the log can be too verbose, so one way to handle the amount of log is to store it and then grep it: bitbake linux-imx | tee log; grep -i <your string to seach> < log mostly a dry run (calls to system are just echos) ltib --dry-run | ltib -d bitbake --dry-run | bitbake -n try to continue on package build errors (autobuilds) ltib --continue | ltib -C bitbake --continue | bitbake -k print the application version and quit ltib --version | ltib -V bitbake --version do not redirect any output ltib --noredir | ltib -N run the deploy scripts even if build is up to date ltib --deploy | ltib -D bitbake <image name> -f disabled deployment (even with -p <pkg>) ltib --no-deploy just download the packages only ltib --dlonly bitbake -c fetchall <image name> E.g. bitbake -c fetchall core-image-minimal test that the BSP's packages are available ltib --dltest check against external staging repositories ltib --external leave the sources unpacked (only valid for pkg mode) ltib --leavesrc | ltib -l NA This is the default mode in YP. All source code can be found on tmp/work. In case you want to remove source code after building (as in LTIB), add INHERIT += "rm_work" to your local.conf. NOTE: If your adding changes to a particular package, these will be lost. In case you want to keep source code of a specific package, include this on the RM_WORK_EXCLUDE variable (e.g. RM_WORK_EXCLUDE += "busybox eglibc"). Make the selected root number sticky --sticky Remove root stickiness --no-sticky (re)configure/build/install the host support package set --hostcf use with package listings --enable use if you really want to ignore any locks (careful!) --ignorelock used with -m release to copy additional content --fullbsp used with -m release to copy specical packages into ISO --distmap don't check sudo, work around for broken sudo (fc9) --no-sudo use git for some package's build where use-git-mode is either: internal    Use fsl internal git external   Use fsl external git --use-git-mode use external git for some package's build --external-git help on usage --help | -h --help | -h

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343113 

platform: imx8qxp c0 mek OS: yocto 4.19.35_1.1.0 hardware connection: imx8qxp lvds0 => dummy panel ,  lvds1 => it6263 => display   On imx8qxp there are one DPU(display process unit) and one ISI(image subsystem interface), ISI supports input from dpu.   dpu block diagram: note that only dsi0 and lvds0 can be used for loopback. and this patch only test the lvds0, since lvds support dummy panel.   Please see the readme in the attchment for how to enale this feature.   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4]   

Since JB4.3, we have added a customer library in myandroid/devices/fsl/common/recovery to give a chance for customer to customize their UI menu in recovery.img Be sure you define the TARGET_RECOVERY_UI_LIB to be same as your defined in Android.mk in myandroid/devices/fsl/common/recovery, as we did in myandroid/devices/fsl/imx6/BoardConfigCommon.mk TARGET_RECOVERY_UI_LIB := librecovery_ui_imx Once you defined TARGET_RECOVERY_UI_LIB, myandroid/bootable/recovery will use the one to replace the default ui lib  as the source code myandroid/bootable/recovery/default_device.cpp. By default, we define below menu as below: const char* ITEMS[] = { "reboot system now",   "apply update from ADB",   "wipe data/factory reset",   "wipe cache partition",   NULL }; Below is an example to add a new menu as "apply update from SD Card": diff --git a/common/recovery/recovery_ui.cpp b/common/recovery/recovery_ui.cpp index ccf8ccd..9cbd91e 100644 --- a/common/recovery/recovery_ui.cpp +++ b/common/recovery/recovery_ui.cpp @@ -31,6 +31,7 @@ const char* HEADERS[] = { "Volume up/down to move highlight;", const char* ITEMS[] = { "reboot system now",   "apply update from ADB", + "apply update from SD Card",   "wipe data/factory reset",   "wipe cache partition",   NULL }; @@ -77,8 +78,9 @@ class ImxDevice : public Device { switch (menu_position) { case 0: return REBOOT; case 1: return APPLY_ADB_SIDELOAD; - case 2: return WIPE_DATA; - case 3: return WIPE_CACHE; + case 2: return APPLY_EXT; + case 3: return WIPE_DATA; + case 4: return WIPE_CACHE; default: return NO_ACTION; } } The handle on the menu is defined in function prompt_and_wait(Device* device, int status) in myandroid/bootable/recovery/recovery.cpp. Below is the buildin menu function in recovery.     enum BuiltinAction { NO_ACTION, REBOOT, APPLY_EXT, APPLY_CACHE,   APPLY_ADB_SIDELOAD, WIPE_DATA, WIPE_CACHE };

Pre-requisites: An TFTP server U-boot with TFTP capabilities If you need to run a script (for example, running multiple setenv's commands) in U-boot for many boards, you can instead create a U-boot script (called script image), place it into your tftp folder, then ask U-boot to fetch it and run it. For example, you want to run the following setenv instructions setenv loadaddr 0x10800000 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666' setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc dev 3;mmc read ${loadaddr} 0x800 0x2000;bootm' run bootcmd_mmc save it into a file, I choose the name 'myscript'; under your <U-boot folder>/tools, execute $ mkimage -T script -C none -n 'My Script' -d myscript myscript.img and copy myscript.img file into your TFTP folder. On the target, set the following two variables (serverip and bootcmd) # Set the Server IP, where the TFTP server is running setenv serverip <the server IP> # In case the server IP is static, you can place this line into the U-boot script setenv scriptaddr 0x10700000 setenv scriptname myscript.img # You can use either TFTP or DHCP setenv tftpcmd tftp # or 'dhcp'  in case you want to use dhcp U-boot command # Not needed for dhcp setenv ipaddr <the target IP> # needed in case the command tftp is used setenv gatewayip <the Gateway IP> # needed in case the command tftp is used setenv bootcmd '${tftpcmd} ${scriptaddr} ${scriptname}; source ${scriptaddr}' saveenv reset That is all you need to do. Enjoy U-booting!

Introduction There are four boot logos in kk4.4.3_2.0.0-beta  system at first: uboot logo\linux logo\android init logo\android animation. We plan to use uboot logo to cover linux logo and android init logo so that we  can combine first three logoes into one logo.This guide provides a step by step explanation of how to transfer uboot UI to  linux kernel and android init smoothly on board sasbresd_6dq sabresd_6dl. The core ideas of the patch: need to  keep display clock from uboot to kernel. When kernel boot up , we do not break the frambuffer for that it stores uboot logo data. need to disable show android init logo. what do the patch do in uboot 1、 can not shut down video after uboot is over.The patch delete releted code in function  arch_preboot_os() 2、 keep hsp clock (ipu clock) the same with linux 3.10 the below is the setting in sabrasd DQ board: osc(24MHz) -> pll2(528MHz) -> mmdc_ch0(528MHz) -> ipu1_hsp_clk(264MHz) the below is the setting in sabrasd DL board: osc(24MHz) -> pll3(480MHz) -> pll3_pdf1(540MHz) -> ipu1_hsp_clk(270MHz) 3、 keep pixel clock the same with linux 3.10 the below is the setting in sabrasd DQ board: osc(24MHz) -> pll2(528MHz) -> pll2_pfd0(452.57MHz) -> ldb_di1(64.65MHz) -> ipu1_di1(64.65MHz) -> ipu1_pixel(64.65MHz) the below is the setting in sabrasd DL board: osc(24MHz) -> pll2(528MHz) -> pll2_pfd0(452.57MHz) -> ldb_di1(64.65MHz) -> ipu1_di1(64.65MHz) -> ipu1_pixel(64.65MHz) 4、 keep pwm clock In kernel,there is a 100% duty pwm to drive lvds panel.So the patch set the pad SD1_DATA3 to a 100% duty pwm pin. 5、 add fbbase and fbmem to bootargs the fbbase is the uboot logo’s phy addr. So the patch pass the parament to kernel through cmdline.we should allocate address aligned 1M for linux 3.10 reserve address aligned by 1 M. what do the patch do in linux 3.10 1、 reserve the address which come from fbbase 2、 keep  ipu related clock when system init the clock in clk-imx6q.c The patch  enable ldb_di1_clk、ipu1_di1_clk、ipu1_clk、pwm1_clk.  Do not disable pll2 and pll3 related clock for the clock may be the source of  ipu clock. Although we enable ldb_di1_clk、ipu1_di1_clk and so on in register, we need to use the function clk_prepare_enable(). Because  the system may close some clocks for their user count is 0(if we use clk_prepare_enable(),it and it’s parent  user count will add 1 ) 3、 disable cabc which will light the panel according the content. Change cabc_enable in dts file. 4、 Move global alpha and color key setting in probe  after framebuffer is registered. Delay       register IPU interrupts used by framebuffer  until IPU hsp clock is enabled.Because global alpha and color key setting and register IPU interrupts may disable hsp clock. disable show android init logo android init logo is the text"android_". we need disable to show it so that the former three logos looks the same logo.The patch 92-system_core solve this problem. The environment of the patch: Hardware: SABRASD DQ&DL Soft ware: kk4.4.3_2.0.0-beta on linux 3.10 How to use the patch: $ cd my_android/kernel_imx/ $ patch -p1 < ./92-kernel_v2 $ cd my_android/bootable/bootloader/uboot-imx/ $ patch -p1 < ./92-uboot_v2     $ cd my_android/system/core $ patch -p1 < 92-system_core Note:      1、 If you want to have this feature on sabraSD dq&dl board,this patch is OK .After you use this patch, you want to change to  other board such as sx, you may meet this problem that the kernel logo penguin don’t appear. You may change this file: arch/arm/configs/imx_v7_android_defconfig                 CONFIG_LOGO=y                 CONFIG_FRAMEBUFFER_CONSOLE=y                 CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y                 #CONFIG_MX6_CLK_FOR_BOOTUI_TRANS=y                 #CONFIG_MX6_CLK_FOR_BOOTUI_TRANS_LVDS_IPU1_DI1=y

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

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345322 

Prerequisites: The build is verified on prebuilt rootfs(based on LTIB) which can be downloaded from freescale.com EGL uses framebuffer backend libEGL.so -> libEGL-fb.so libGAL.so -> libGAL-fb.so QT4.8 1. Download the git respository for qt4.8: $ git clone http://git.gitorious.org/qt/qt.git qt $ cd qt Let us consider this as <QTDir> 2. Create /tftpboot and point your target fileystem. As like $ mkdir -p /tftpboot $ cd /tftpboot $ ln -s $(ROOTFFS) rootfs TBD:Need to work on this to use sysroot option 3. Create a build directory to install for the qt4 packages. This directory can be  in any location. For example, $ mkdir /opt/qt4 $ sudo chown -R <username> /opt/qt4 Let us consider the the <installdir> as /opt/qt4 4. Extract the attached mkspecs(linux-imx6-g++.tar.gz) to  <QTDir>/mkspecs/qws/ 5. Apply the attached cd 0001-add-i.MX6-EGL-support.patch attached to enable egl support for i.MX6 $ cd <QTDir> $ patch -p1<0001-add-i.MX6-EGL-support.patch 6. Export CROSS-COMPILE location path to PATH $ export PATH=$PATH:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/ 7. Enter to the <QTDir>. Do configure. You can select the options as you like. Here is an example $ cd <QTDir> $ ./configure -qpa -arch arm -xplatform qws/linux-imx6-g++ -no-largefile -no-accessibility \ -opensource -verbose -system-libpng -system-libjpeg -system-freetype -fast -opengl es2 -egl -confirm-license \ -qt-zlib  -qt-libpng  -no-webkit -no-multimedia \ -make examples -make demos \ -release -make libs -exceptions -no-qt3support -prefix <installdir> 8. When the configure summary is shown make sure the Qt has OpenGL ES 2.0 support. Do build $ make $ make install 9. Now need to build eglfs plugin $ cd <QTDir>/src/plugins/platforms/eglfs $ make $ make install     Now the eglfs will be installed to the QT Install directory. 10. By now all required QT files are in <install directory> 11. Copy the install directory to target filesystem $ cp -rf /opt/qt4 /tftpboot/rootfs/opt/. 12. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt4/examples/opengl/hellogl_es2 $ ./hellogl_es2 -platform eglfs QT5 These steps are performed on the host 1. Download the git respository for qt5: $ git clone git://gitorious.org/qt/qt5.git qt5 $ cd qt5     Let us consider this as <QTDir> 2. Create a build directory to install for the qt5 packages. This directory can be  in any loctation. For example, $ sudo mkdir /opt/qt5 $ sudo chown -R <username> /opt/qt5 Let us consider the the installdir as /opt/qt5 3. Enter the Qt5 directory and run the init-repository script to download all the source code for    Qt5. To download all the source code will take about an hour. $ ./init-repository Update:  In the latest Qt5 release the webkit library is included by default and there are some issues trying to compile it. use the next line to avoid problems if not desired to use webkit. $ ./init-repository --no-webkit 4. From the following path $ gedit qtbase/mkspecs/devices/linux-imx6-g++/qmake.conf 5. At the top of the qmake.conf, there is a configure line. Copy and paste the configure line into a text file located    in your build build directory. Edit the configure line to find your toolchain and filesystem. Also make sure to    include the options -no-pch, -no-opengl, -opengl es2, Here is an example of    a configure line. Update: In the latest Qt5 stable, the option to compile the examples/demos is -compile-examples, instead of -make examples -make demos If you are running into problems with webkit,  use the option -no-icu, this will disable the webkit. $ cd <QTDir> $ cd qtbase $ ./configure -v -opensource -confirm-license -no-pch -no-xcb -no-opengl -opengl es2  \         -make libs -device imx6 \        -compile-examples \       -device-option CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi- \        -sysroot <rootfs> -no-gcc-sysroot \       -prefix <installdir> 7. Make the textfile that has the configure line and executable and run it. When the configure summary is shown make sure the Qt5 has openGL ES 2.0 support. Do build $ make $ sudo make install    When Qt5 has finished building, Qt5 will be installed in two places:            1. <location of rootfs>/<installdir>            2. <HOST Machine>/<install dir> This is good because now all the libraries and binaries for Qt5 are installed on the host and the target filesystem. Therefore, the target already has all the libraries and  binaries needed to run Qt5. 8. Also need to build qtjsbackend and qtdeclarative. $ cd <location to Qt5 git> $ cd qtjsbackend $ ../qtbase/bin/qmake -r $ make && sudo make install $ cd <location to Qt5 git> $ cd qtdeclarative $ ../qtbase/bin/qmake -r $ make && sudo sudo make install 9. Running Qt apps on target     - Boot the target either with NFS or SD Image     - Ensure that folder <installdir> is copied on target file system at “/usr/local”.     - Launch application using $ cd /opt/qt5/examples/opengl/hellowindow $ ./hellowindow -platform eglfs FAQ: On the target file system, the location of target libaries and includes may present in arm-linux-gnueabi directory. Make sure to create soflinks to QT can find. For example $ cd $(ROOTFS)/usr/lib $ ln -s arm-linux-gnueabi/libffi.so.6 libffi.so.6 While building QT5, you may see a build error that libQt5V8.so.5 is not found. This might be some problem to be addressed in QT. Workaround is to copy all the binaries to correct path as like this $ cp  <ROOTFS>/<installdir>/lib/* <HOST Machine>/<installdir>/. What is coming up next: 1. QT on X is already available on Yocto filesystem. Steps to enable GPU Acceleration TDB. 2. QT with Wayland support.

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"

Hi All, The new i.MX 6 SL L3.0.35_2.1.0 release is now available on the http://www.freescale.com/site. ·         Files available # Name Description 1 L3.0.35_2.1.0_LINUX_DOCS i.MX   6SoloLite Linux BSP Documentation. Includes Release Notes, Reference Manual,   User guide. API Documentation 2 L3.0.35_2.1.0_LINUX_MMDOCS i.MX 6SoloLite Linux Multimedia Codecs   Documentation. Includes   CODECs Release Notes and User's Guide 3 L3.0.35_2.1.0_ER_SOURCE i.MX   6SoloLite Linux BSP Source Code Files 4 L3.0.35_2.1.0_MM_CODECS i.MX   6SoloLite Linux Multimedia Codecs Sources 5 L3.0.35_2.1.0_AACP_CODECS i.MX   6SoloLite Linux AAC Plus Codec 6 L3.0.35_2.1.0_DEMO_IMAGE i.MX   6SoloLite Linux Binary Demo Files ·         Target HW boards o   i.MX6SL-EVK ·         New features o   Updated thermal equation for i.MX 6SoloLite o   Added Fuse check for all the devices o   Enabled DISPLAY power gating feature on TO1.2 ·         Known issues o   For known issues and limitations please consult the release notes.

Dear All,       Our board is designed based on both EVK and HEG (Adeneo Embedded Home Energy Gateway), the ENET_FEC_RESET_B on EVK is replaced by LCD_D11 as it on HEG. We have re-config all pins based on i.mx28 BSP and successfully built by ltib. However, eth0 is not working due to "PHY is not found"! and we are still trying to figure it out.       The changes we apply on the BSP are(in mx28evk_pins.c): in static struct pin_desc mx28evk_fixed_pins[]:       the definition of LCD_D11 change to { .name = "LCD_D11", .id = PINID_LCD_D11, /* PHY reset pin*/ .fun = PIN_GPIO,      .voltage    = PAD_3_3V,      .strength = PAD_8MA,      .output     = 0, },      and replace all "PINID_ENET0_RX_CLK" in mx28evk_pins.c by "PINID_LCD_D11"      To prevent any possible interrupt, we also disable all LCD pins in both mx28_pins.h and mx28evk_pins.c since we don't have LCD.      Any comment/suggestion is highly appreciate! BR, TF

  IMX6 S/DL for consumer has both PXP and IPU. Automotive and Industrial versions doesn't have PXP. As IMX6 also has IPU, the Linux framebuffer driver uses IPU and not PXP. Note : “pxp_v4l2_test.out” from unit_tests was made for processors (i.MX6 SL), that have only PXP and its framebuffer driver applies PXP to accelerate image processing. “pxp_v4l2_test.out” should not be used with i.MX6 S/DL. To test PXP device with i.MX6 S/DL users have to try “pxp_test.out”.

One chunk of the file system for the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Hi all, Most of IoT customers request to enable/demo i.MX EVK with FSL Zigbee solution. In default i.MX Linux/Android BSP, Zigbee function is not enabled. Here we make a lighting demo setup through i.MX6Q SabreSD, KW20 USB dongle and Philips Hue light. KW20 is configured as Zigbee coordinator, connected with USB OTG in i.MX6Q, then i.MX6Q can issue On/Off, brightness and color control commands through KW20 to toggle Philips Hue light directly. Please find the attachment for details. Best regards, Carl

The i.MX 6 D/Q L3.035_1.0.2 patch release is now available on the www.freescale.com ·         Files available # Name Description 1 L3.0.35_1.0.2_LDO_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux   12.09.01 release. The purpose of this patch release is to manage the LDO and   PMIC ramp-up time correctly.

Computer On Module • Processor Freescale i.MX 6Quad, 1GHz • RAM 1GB DDR3 SDRAM 64-bit • ROM 4GB NAND Flash UP to 16GB • ROM 2M SPI Nor Flash ! • Power supply Single 5V • Size 40mm SO-DIMM • Temp.-Range          0 to + 95C (Consumer)         -20 to + 105C (Extended Consumer)         -40 to +105C (Industrial)         -40 to + 125C (Automotive) Key Features • 10/100Mbps Ethernet • One High Speed USB 2.0 ports • Full HD LCD controller, 24bpp • OpenGL ES 2.0 and OpenVG 1.1 hardware accelerators • Multi-format HD 1080p60 video decoder and 1080p30 encoder hardware engine • Two Camera Interfaces • NEON MPE coprocessor — SIMD Media Processing Architecture — dual, single-precision floating point execute pipeline • Unified 1MB L2 cache • Several interfaces: 5x UART, 2x SDIO, 1x SSI/AC97/I2S, 3x I2C, 2xCSPI • 3.3V I/O • 2x Controller Area Network (FlexCAN) • PCIe 2.0 (1-lane) OS Support     • Linux 3.0     • Android 4.2 Application:Media Tablet,Education Tablet PC,EBook,Automotive Infotainment,Aviation Infotainment,HMI,Portable Medical Instruments,IPTV,IP Phone,Smart Energy Systems,Intelligent industrial control systems For more information, please see Attachment We can provide a complete solution

INTRODUCTION REQUIREMENTS CREATE A NEW PROJECT GPU EXAMPLE GSTREAMER EXAMPLE 1. INTRODUCTION:      The below steps show how to create different application examples using Elipse IDE. 2. REQUIREMENTS:      A fully working image and meta-toolchain generated in Yocto . You can follow the  next training: Yocto Training - HOME      Install and configure the Yocto Eclipse Plug-in. For more details about this requirement please refer to Setting up the Eclipse IDE for Yocto Application Development         To demonstrate the steps, L3.14.28  BSP, fsl-image-qt5 image and i.MX6Q SABRE-SDP board were used. 3. CREATE A NEW PROJECT      Follow the section Creating a Hello World Project of this document Setting up the Eclipse IDE for Yocto Application Development 4. GPU EXAMPLE           For this project we use the source code found in the fsl-gpu-sdk that can be downloaded from:      https://www.freescale.com/webapp/Download?colCode=IMX6_GPU_SDK&location=null&Parent_nodeId=1337637154535695831062&Parent…      Follow section 3 and create a new project named gputest.      From the IMX6_GPU_SDK choose one of the examples of GLES2.0 folder. In this case the 01_SimpleTriangle is chosen.      Copy the .c and .h files to the src directory of the gputest project. The Project Explorer window should look like this:              Add the needed files and libraries to compile and link in the Makefile.am file found in the ´src´ folder. The Makefile.am file should have the below content:          bin_PROGRAMS = gputest          gputest_SOURCES = gputest.c fsl_egl.c fslutil.c          AM_CFLAGS = @gputest_CFLAGS@          AM_LDFLAGS = @gputest_LIBS@ -lstdc++ -lm -lGLESv2 -lEGL -lX11 -ldl          CLEANFILES = *~ ​    Add the PATH to CFLAGS where the compiler will look for the headers at Project->Properties->Autotools->configure:           In this project there is no need to add extra PATHs for the headers. Apply the changes by clicking on Reconfigure Project. Build the project To test the file you can send the executable to the board with:           $ scp gputest root@<board_ip>:/home/root      $./gputest      You should get the next output in the display: 5. GSTREAMER EXAMPLE      For this project we use the source code found at Basic tutorial 1: Hello world! - GStreamer SDK documentation - GStreamer SDK documentation    Follow section 3 and create a new project named Gstreamer.    Copy the code of the basic tutorial to your Gstreamer.c file.    Add the needed files and libraries to compile and link in the Makefile.am file found in the ´src´ folder. The Makefile.am file should have the below content:                           bin_PROGRAMS = Gstreamer      Gstreamer_SOURCES = Gstreamer.c      AM_CFLAGS = @Gstreamer_CFLAGS@      AM_LDFLAGS = @Gstreamer_LIBS@ -lstdc++  -lVDK -lm -lGLESv2 -lGAL -lEGL  -ldl -lgstreamer-0.10 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lglib-2.0      CLEANFILES = *~         ​    Add the PATH to CFLAGS where the compiler will look for the headers at Project->Properties->Autotools->configure:           For this example the next lines are added             -I${Sysroot}/usr/include/gstreamer-1.0        -I${Sysroot}/usr/include/glib-2.0        -I${Sysroot}/usr/include/libxml2        -I${Sysroot}/usr/lib/glib-2.0/include      Apply the changes by clicking on Reconfigure Project. Build the project To test the file you can send the executable to the board with:           $ scp Gstreamer root@<board_ip>:/home/root To execute the application on the board:      $./Gstreamer The board should have internet access and the application should play the video found at http://docs.gstreamer.com/media/sintel_trailer-480p.webm

Join FSL-community-bsp project: https://lists.yoctoproject.org/listinfo/meta-freescale In order to test Yocto Project for i.MX6 or any other supported board please follow the instructions pointed by FSL Community BSP. In order to download the source code, please follow this instructions FSL Community BSP. With the downloaded source code, you can follow the steps from this training: Yocto Training - HOME If you face a problem, please, send an email to https://lists.yoctoproject.org/listinfo/meta-freescale This page made sense when there was not other tutorial to point people on how to download and build the very first image using Yocto Project tools for i.MX family boards. Today, FSL Community BSP has become a complete environment with its own landing page (FSL Community BSP) and a collaborative community around meta-freescale mailing list. I encourage you to register in meta-freescale mailing list. I configured this document to be closed for new comments. In case of any issue or bug, please, send an email to meta-freescale.