i.MX Processors Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

A new version of the Pins Tool for i.MX Application Processors has been released and is available for download as desktop tool from Pins Tool for i.MX Application Processors|NXP. The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE What's New Added Label support to give signals a name Added ‘Log’ and ‘Problems’ view to report conflicts between settings Added support for templates to store user configurations as starting point for new configurations Added ability to download and share data for devices, especially for off-network host machines i. MX header files are now automatically part of the device data Import of legacy Processor Expert .pe files Export of register defines Various bug fixes and documentation improvements The release notes of the desktop application are attached to this article. Import Processor Expert Files A new importer has been added to import legacy Processor Expert for i.MX files: Labels Signals can now have user defined labels: Templates, Kits, Boards and Processors When creating a new configuration, it offers Templates, Boards and Processors. Custom configurations can be stored as templates and then used for new configurations. Board Specific Functions With the provided board and kit configurations, there are now pre-configured initialization functions for major blocks on the board: Export Data To simplify downloading the device specific data for the desktop tool, the 'Export' function can be used to download and export the data. The data can be copied that way to another machine or all data for a set of devices can be loaded. Export Registers With the Export command the registers can be exported as text/source: This is used to store the register values: /*FUNCTION********************************************************************** * * Function Name : init_audmux_pins * Description   : Configures pin routing and optionally pin electrical features. * *END**************************************************************************/ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT_VALUE            0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT_VALUE         0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT_VALUE          0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19 */ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ We hope you will find this new release useful. Thanks for designing with NXP! 
View full article
GTK+ GTK is a graphic library developed initially by Gimp (Gimp ToolKit). GTK was selected as default GUI to create the Gnome Desktop and currently it is used on many desktop environment (XFCE, LXDE, etc). When GTK was developed it was depending on X Server (X11) but currently it can run over DirectFB. In order to add GTK+ support on i.MX board you need first to choice DirectFB or X11 to be it's default graphic infrastructure. The following pages contain informations and instruction of how to compile and use them. If you want to compile GTK over DirectFB: All Boards DirectFB If you want to compile GTK over X11: All Boards X11 All Boards GTK Manually All Boards GTK Glade GTK Demo GTK2 package comes with "gtk-demo". It's a demo executable to demonstrate some GTK gadgets. In order to use it with DirectFB, compile the following packages using LTIB: [*] GTK2 [*] DirectFB [*]  configure for use with touchscreen [*]  DirectFB-examples "if you would like to test DirectFB" [*] Liberation fonts [*] Tslib After starting Linux on i.MX, load the following modules: mx# /etc/rc.d/init.d/gtk2 start gtk: creating gdk-pixbuf.loaders mx# /etc/rc.d/init.d/pango start pango: creating module list Execute gtk-demo: mx# /usr/bin/gtk-demo GTK Demo with X If you would like to test the gtk-demo application over X, start X first (tested on i.MX25 PDK): mx# Xfbdev -screen 480×640 -mouse tslib,,device=/dev/input/event1 & mx# export DISPLAY=:0.0 mx# /usr/bin/gtk-demo
View full article
Changing the storage for U-boot environment variables   U-Boot on Freescale BSP has a compiling option that allows you to choose the storage for environment variables.   1 - Extract the u-boot source using LTIB: ./ltib -m prep -p u-boot   2 - The source will be extracted to <ltib path>/rpm/BUILD/u-boot-2009.08   3 - On u-Boot source locate the i.MXEVK config file, <ltib path>/rpm/BUILD/u-boot-2009.08/include/configs/mx51_bbg.h   4 - To change the storage of variables environment to SD card, on this file, comment out CONFIG_FSL_ENV_IN_SF and define CONFIG_FSL_ENV_IN_MMC:   //#define CONFIG_FSL_ENV_IN_SF   #define CONFIG_FSL_ENV_IN_MMC 5 - Adjust CONFIG_ENV_SECT_SIZE and CONFIG_ENV_OFFSET accordingly. Recall that sd card read block size is 512B.   For example:   #define CONFIG_ENV_SECT_SIZE (256 * 512)   #define CONFIG_ENV_SIZE CONFIG_ENV_SECT_SIZE   #if defined(CONFIG_FSL_ENV_IN_MMC)   #define CONFIG_ENV_IS_IN_MMC 1 #define CONFIG_ENV_OFFSET (1023 * 512)   6 - Save the file.   7 - Recompile u-boot: ./ltib -m scbuild -p u-boot   8 - Your new compiled u-boot image will be saved at: <ltib path>/rpm/BUILD/u-boot-2009.08/u-boot.bin
View full article
Download ATK from Freescale Extract ATK: # unzip ATK_1_41_STD_installer.zip Get the wine-tricks script and install MFC-4.2 and VisualC++-6.0. ./winetricks  vcrun6sp6 Execute the default install process: # wine SETUP.EXE Edit the file /etc/udev/rules.d/50-udev-default.rules to set permission for everyone: KERNEL=="tty[A-Z]*|pppox*|ircomm*|noz*", GROUP="uucp", MODE="0666" Run ATK: # wine ADSToolkit_std.exe
View full article
Recently I published this i.MX Dev Blog post about the Gateworks plugin gst-variable-rtsp-server support for i.MX 6. Now, you can check how to use it on i.MX 8 SoCs as well. 1. Preparing the image In order to use gst-variable-rtsp-server plugin, prepare your machine and distro: Add the following line to conf/local.conf: IMAGE_INSTALL_append += " gstreamer1.0-rtsp-server gst-variable-rtsp-server " Download the attached patch and apply it by doing: $ cd <yocto_path>/sources/meta-fsl-bsp-release/ $ git am ~/Download/0001-Add-RTSP-support-for-i.MX-8-L4.14.78_ga1.0.0-or-olde.patch Note: This patch is not necessary for L4.14.98_ga2.0.0 BSP! Then, build the image with bitbake and deploy it to the SD card. 2. Video Test Source Example Server $ gst-variable-rtsp-server -p 9001 -u "videotestsrc ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client 2. Camera Example Server $ gst-variable-rtsp-server -p 9001 -u "v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480 ! v4l2h264enc ! rtph264pay name=pay0 pt=96" Client In order to use VLC or other application as the client, just enter the URL as shown in the image below:
View full article
This is a workaround—this page needs to be updated to add instructions for multi-touch support. Based on Freescale BSP 11.05. The LVDS panel (MCIMX-LVDS1) has a serial multi-touch controller, eGalax. As a workaround to have it supported on directly on Qt, we can force the driver to behave as a single touch. To do this: 1 - Edit the file ltib/rpm/BUILD/linux-2.6.35.3/drivers/input/touchscreen/egalax_ts.c adding the following line: + #define FORCE_SINGLE_POINTER_SUPPORT 1 2 - Compile the kernel ./ltib -m scbuild -p kernel 3 - Copy the new kernel to Card/Memory and boot it. 4 - Start your Qt app: $ Xfbdev -screen 1024x768 -mouse tslib,,device=/dev/input/event0  & $ export DISPLAY=:0.0 $ ./yourQTapp Note: You can read the touch events with "evtest" $ evtest  /dev/input/event0 or tslib apps: $ export TSLIB_TSDEVICE=/dev/input/event0 $ ts_print
View full article
Q: How to program i.MX6 eFUSE? A: what about using the mfg tool? In the end only the supplies, USB OTG and the boot mode pins need to be connected. The customers Idea was to have all devices (i.MX6 eFUSE , Flash, PFUZE, etc) pre- programmed before mounting on the board. I presented the flows we support (MFG Tool, Platform SDK) for eFUSE programming last Friday when I was at the customer. KITPF0100SKTEVBE Product Summary Page MfgTools is the most convenient way to burn eFuse . Or the customer can burn the fuse on their jig/socket board by the u-boot: How to Fuse in U-Boot U-Boot contains a tool, imxotp , which is used for fusing. U-Boot > imxotp imxotp - One-Time Programable sub-system Usage: imxotp imxotp read <index> - read fuse at 'index' imxotp blow [--force] <index> <value> - blow fuse at 'index' with hex value 'value' Tips: ' addr ' to 'index': convert 'index' from 'address' index = ( addr - otp_base) / 0x10 eg , addr is 0x021bc410, otp_base is 0x021bc400, the index = 1 '-- force ' must be present in order to blow the fuse. Command will abort if '--force' is missing. index = ( addr - otp_base) / 0x10, where the addr is the address of the fuse you want to operate, the otp_base is the base address of the fuse block. ' value ' should correspond to fuse settings according to the fuse map and desired fuse configuration. ---------------------------------- FIrst of all thanks for your reply. However both flow assumes the i.MX6 is already soldered on the board. Please note the specific request was if it is possible (and we can support a programming house) to pre program the efuses BEFORE they are soldered on the PCB thus on a standard programmer. Take an FLASH programmer as an example.
View full article
In order to get Redboot running on i.MX35 PDK without a flashing procedure, a little modification in the binary file is needed. After that it can be loaded into RAM memory using the ATK tool. The Redboot Header To execute the binary Redboot file a header of 32 bytes long must be added: ddccbbaa0000000000000000hhggffee00000000000000000000000000000000 Where ddccbbaa is the 4-byte start address and hhggffee is the start address (all in Hexadecinal format) modified by the following procedure: value - 0x20 (or 32 decimal) + 0x08 (or 8 decimal) Note that in this header the values are placed from LSB to MSB bytes, so if the start address for MX35PDK is 0x87F00000 then the header should looks like: Start Address    --> 0x87F00000                                               --> 0000F087 Modified Address --> 0x87F00000 - 0x20 + 0x08 = 0x87EFFFE8 --> E8FFEF87 Header --> 0000F0870000000000000000E8FFEF8700000000000000000000000000000000 Now, this header must be appended to the beginning of the redboot.bin file.
View full article
This tutorial has been done with an i.MX51 EVK. This example can be easily adapted to i.MX35 or i.MX53 that share the same GPU Core (Z160) and the same API (OpenVG 1.1). This tutorial show you how to do a simple image warp deformation with OpenVG 1.1.     Generation of Linux Image with 2D gpu support To support 2D/3D gpu, you need to select gpu driver in LTIB. In LTIB's "package list" select the following packages: [x] amd-gpu-bin-mx51 [x] libz160-bin Build your Linux Image and copy it to your SD card. Building OpenVG simple application Download the application (see attached archive) Untar/unbz2 the application source code. To build the simple OpenVG application, you need to adapt the Makerules file. First you have to indicate where your linux image has been generated withLTIB: ROOTFS = /home/fsl/LTIB_1_7/ltib/rootfs You also need to indicate the compiler path (usualy installed in /opt/freescale/usr/local/....): GNUTOOL_PATH=/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/ After that you have to copy gpu's driver headers files in the include folder of the project. You will find these header in /opt/freescale/pkgs/amd-gpu-bin-mx51-x.x.x.tar.gz archive: extract all the include folders/files in the include folder of the project. Now you can build the application:   fsl@fsl-laptop:~/SW/openVG_sample$ make /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -mfloat-abi=softfp -mfpu=vfp -Wall -O3 -fsigned-char -D_LINUX -I/home/fsl/SW/openVG_sample/include -c warp.c -o warp.o In file included from warp.c:37: roselend_savoie_france_350x350.c:12391:66: warning: trigraph ??) ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:12964:71: warning: trigraph ??/ ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:14518:10: warning: trigraph ??- ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15118:67: warning: trigraph ??) ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15327:67: warning: trigraph ??' ignored, use -trigraphs to enable roselend_savoie_france_350x350.c:15795:62: warning: trigraph ??! ignored, use -trigraphs to enable /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -I/home/fsl/SW/openVG_sample/include -lOpenVG -legl13 -Wl,--library-path=/home/fsl/LTIB_1_7/ltib/rootfs/usr/lib,-rpath-link=/home/fsl/LTIB_1_7/ltib/rootfs/usr/lib -o warp warp.o fsl@fsl-laptop:~/SW/openVG_sample$ Copy the application on your SD card Put the SD card in the i.MX51 and run the gpu drivers $ login:root $ modprobe gpu Run the application $ ./warp Modifying the image A simple way to modify the image, is to use The Gimp. When you want to save your image, choose "C source code format": Then choose the prefix name (here "roselend"): Click on "Save". The "C" file of your image is generated: /* GIMP RGBA C-Source image dump (roselend_savoie_france.c) */ static const struct {   guint        width;   guint        height;   guint        bytes_per_pixel; /* 3:RGB, 4:RGBA */   guint8       pixel_data[350 * 350 * 4 + 1]; } roselend = {   350, 350, 4,   "\265\303\357\376\264\304\357\376\262\304\357\376\260\304\356\376\260\303"   "\356\376\257\303\356\376\257\302\355\376\257\301\355\376\257\302\355\376"   "\257\302\355\377\256\302\356\376\256\302\357\376\256\302\356\377\255\302" "\357\376\254\302\360\376\253\302\357\376\254\302\355\376\255\302\357\376" ...
View full article
When working with an evaluation kit you will be provided with a System Controller Firmware (SCFW) binary included in your BSP. This scfw binary has been tailored for that specific board and you might need to modify some board dependencies to fit your specific hardware. This document aims to provide an overview on the SCFW porting process, for detailed information please refer to the System Controller Porting guide (sc_fw_port.pdf). Setting up the system The SCFW is built on a Linux host. The steps to set-up your system are the following: Download the GNU ARM Embedded Toolchain: 6-2017-q2-update June 28, 2017 from the ARM website: Select a directory to untar the file unto, for instance: mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ Set TOOLS environment variable to the directory containing the tool chain, "~/gcc_toolchain" on the example above, .bash_profile can also be modified to export this environment variable: export TOOLS=~/gcc_toolchain/ srec_cat is also necessary for the build, this is usually contained in the srecord package, on ubuntu you can do: sudo apt-get update sudo apt-get install srecord Now you can change to the porting kit directory (e.g. scfw_export_mx8qm) and build the scfw. System Controller Firmware Porting kit  The SCFW porting kit contains source files and object files that will allow you to modify the SCFW to work with your board. You can get the latest System Controller Firmware Porting kit from the   i.MX Software and development webpage : Once you obtain the porting kit untar it: tar xvzf imx-scfw-porting-kit-1.1.tar.gz ‍ You will see the following file structure: The porting kit is contained under packages, the README contains the instructions to extract the porting kit, basically: cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin ‍ ‍ ‍ You will be prompted to accept an End User License Agreement: Once you accept the agreement the porting kit will be extracted in a new folder, the folder structure is as follows: All documentation regarding SCFW is under doc/pdf or in html format if preferred, it is recommended to go over sc_fw_port.pdf. The porting kits for different SoC variants (QM A0, QM B0 and QXP B0) are under src packaged as tar.gz, all other files are SCFW libraries for different software packages, such as Linux, QNX, FreeRTOS, U-boot, ARM Trusted Firmware, etc... If you will be working with several SoC variants (working with both QXP and QM) it is recommended to extract all porting kits into a single directory, that way you will be able to build for any variant from this directory, the command to do this is: cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \; ‍ ‍ ‍ A scfw_export_mx8 folder will be created, from here you will be able to build SCFW for any supported variant. Or you can just extract the package for the variant you are interested on and use that. cd scfw_export_mx8/ ‍ All the build folders contain the results of building the SCFW and platform is where the source of the SCFW is stored. All the code that is specific to a board configuration is under "platform/board/mx8<derivative>_<board_name>" where derivative is the i.MX8 silicon family such as QXP or QM, and board name is the name of the board the SCFW package is for. The first step in porting the SCFW to your board is to create a folder for your i.MX8 derivative and board, you can take one of the available board examples and rename the folder, that will provide you a project to get started with, for instance: cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍ ‍ The board in this example will be called "myBoard" and it is for an i.MX8QM B0 device. To build a SCFW for this board simply call: make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍ ‍ If the target is an i.MX8QXP simply take a board based on this device and change the call to "make qx". Additional information such as build options and in detailed boot information can be found in the SCFW porting guide (sc_fw_port.pdf), chapter 2 of this document is a great introduction to the porting process. Overview and useful information Configuring the PMIC overview and board.c common modifications The main file that needs to be altered (if not the only) is the "board.c" file, it is located at "platform/board/mx8X_board/". The board.c file contains most of the board related information such as SCU UART ports, PMIC initialization routines, PMIC temperature alarms settings and you can also modify it to configure LDOs voltages and communicate with the PMIC in general. All functions in the board.c file are executed by the SCU itself and this gives you access to the I2C interface that is used to communicate with the PMIC. SoC resources that are powered by an external supply (PMIC LDO for instace) such as AP cores and GPUs are powered off/on by board_set_power_mode, the mapping of the resource to an specific PMIC supply happens in board_get_pmic_info, for instance in our i.MX8QM validation board using the A53 subsystem is powered by SW2 of the third PMIC (PMIC_2_ADDR addresses start at PMIC_0) on the PF100 PMIC card and by SW5 of the first PMIC (PMIC_0_ADDR) on the PF8100 PMIC card. case SC_SUBSYS_A53 : pmic_init ( ) ; if ( pmic_card == PF100 ) { pmic_id [ 0 ] = PMIC_2_ADDR ; pmic_reg [ 0 ] = SW2 ; * num_regs = 1 ; } else { /* PF8100_dual Card */ pmic_id [ 0 ] = PMIC_0_ADDR ; pmic_reg [ 0 ] = PF8100_SW5 ; * num_regs = 1 ; } break ; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ The voltages of SoC resources that are powered by an external supply (AP cores, GPUs, etc...) are managed by board_set_voltage in the board.c file. The mapping of resource to power supply occurs in board_get_pmic_info as in the example above. Eight "board resources" (SC_R_BOARD_R0, ... SC_R_BOARD_R7) are available, these resources allow you to define components in your board that the SCU can manage, for instance a sensor on your board powered by one of the PMIC LDOs can be mapped to a board resource and the board.c file can be modified to power on/off the sensor as well as modifying its voltage. Modifying the voltage on a board resource can be either be done by modifying the voltage at board_trans_resource_power (see below) or if the voltage needs to change at run time the function board_set_control can be modified to change the voltage whenever a miscellaneous call (more details in the Miscellaneous Service 101) is made on that resource. For instance to change the voltage on SC_R_BOARD_R7 you would have the following case to board_set_control: case SC_R_BOARD_R7 : if ( ctrl == SC_C_VOLTAGE ) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface . pmic_set_voltage ( PMIC_X_ADDR , PMIC_SUPPLY , val , step ) ; } else return SC_ERR_PARM ; break ; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ The case above will be executed by the SCU every time the application calls the function below: sc_misc_set_control ( ipc , SC_R_BOARD_R7 , SC_C_VOLTAGE , voltage_val ) ; ‍‍‍‍‍‍‍ ‍ Powering on/off a board resource happens at board_trans_resource_power in the board.c file. For instance in NXP's validation board the PTN5150 on the board is managed through a board resource 0, and the power on/off is managed as follows: case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if ( pmic_ver . device_id == PF100_DEV_ID ) { if ( to_mode > SC_PM_PW_MODE_OFF ) { pmic_interface . pmic_set_voltage ( PMIC_2_ADDR , VGEN6 , 3300 , SW_RUN_MODE ) ; pmic_interface . pmic_set_mode ( PMIC_2_ADDR , VGEN6 , VGEN_MODE_ON ) ; } else { pmic_interface . pmic_set_mode ( PMIC_2_ADDR , VGEN6 , VGEN_MODE_OFF ) ; } } else { /* PF8100_dual Card */ if ( to_mode > SC_PM_PW_MODE_OFF ) { pmic_interface . pmic_set_voltage ( PMIC_1_ADDR , PF8100_LDO1 , 3300 , REG_RUN_MODE ) ; pmic_interface . pmic_set_mode ( PMIC_1_ADDR , PF8100_LDO1 , RUN_EN_STBY_EN ) ; } else { pmic_interface . pmic_set_mode ( PMIC_1_ADDR , PF8100_LDO1 , RUN_OFF_STBY_OFF ) ; } } break ; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ Whenever the function below is called from the application side the SCU will execute the code above: sc_pm_set_resource_power_mode ( ipc , SC_R_BOARD_R0 , SC_PM_PW_MODE_ON / OFF ) ; ‍‍‍‍‍‍‍ ‍ board_config_sc is used to mark resources that the SCU needs, such as the I2C module and pads used to communicate with the PMIC, any resource needed by the board.c functions to work should be marked in this function as not movable, for instance to keep the SCU I2C module the following line is added: rm_set_resource_movable ( pt_sc , SC_R_SC_I2C , SC_R_SC_I2C , false ) ; ‍‍‍‍‍‍‍‍ ‍ The following pads are part of the SCU and the application will not be able to access them: - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0 through SC_P_SCU_BOOT_MODE5 board_system_config is where early resource management occurs, this function is only called when the alt_config flag is set in the image, and it can create partitions and allocate resources to it. More details are found in the resource management service 101. board_get_pcie_clk_src defines the clock that the PCIe uses, it can be either BOARD_PCIE_PLL_EXTERNAL or BOARD_PCIE_PLL_INTERNAL. board_print is very useful to debug your changes the syntax is as follows: board_print ( 3 , "Debug printout %d\n" , val ) ; ‍‍‍‍‍‍ ‍ Where the first parameter is the Debug Level and from there on it works as a standard printf. The output will only be visible on the SCU debug output whenever the SCU is built with the corresponding debug level, in the case above the SCFW needs to be built as follows in order to see the output: make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍ ‍ Usage examples The following utility shows how to make System Controller Firmware requests and provides a way to make such requests through command line interface on both QNX and Linux System Controller Firmware Command Line Utility for Linux and QNX System Controller Firmware 101  
View full article
The KTV Demo is a common user case for KTV OEM. In this charpter, we will see what it is and how to use it. HW Platform imx6qp-sabresd SW Platform 3.14.52_1.0.0-ga, fb backend Display Connection LVDS0 XGA 1024*768 RGB666                          - IPU1 DI0 HDMI Display1920*1080@60                              - IPU0 DI1 HDMI Display1920*1080@56 via sii902x            - IPU0 DI0 LVDS1 XGA 1024*768 RGB666                          - IPU1 DI1 User case The demo has following output: Display # UI Video Stream Output Resolution DISP0-LVDS0 3D Cube@60fps 1920x1080@24fps (overlay) XGA(1024x768,RGB666) DISP1-HDMI 3D Cube@60fps 720p@20fps (overlay) 1080P@60(1920x1080,RGB24) DISP2-SII902X 3D Cube@60fps N/A 1080P@56(1920x1080,RGB24) DISP3-LVDS1 N/A 720p@20fps XGA(1024x768,RGB666) The DISP0 and DISP1 has overlay framebufffer, so output UI to bottom framebuffer and output video stream to overlay framebuffer. Run Demo The customer can refer to following script: #!/bin/sh echo "KTV demo start!" # Set environment variables export FB_FRAMEBUFFER_0=/dev/fb0 export FB_FRAMEBUFFER_1=/dev/fb2 export FB_FRAMEBUFFER_2=/dev/fb4 export FB_FRAMEBUFFER_3=/dev/fb5 # Run cube on DISP0,DISP1, DISP3 echo 0 > /sys/class/graphics/fb0/blank ./cube display=0 & sleep 1 echo 0 > /sys/class/graphics/fb2/blank ./cube display=1 & sleep 1 echo 0 > /sys/class/graphics/fb4/blank ./cube display=2 & echo "Open DISP0(LVDS0)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/1080p_24fps.mp4 \   video-sink="imxv4l2sink device=/dev/video17" & sleep 3 echo "Open DISP1(HDMI)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/720p_20fps.mp4 \   video-sink="imxv4l2sink device=/dev/video19" & #sleep 3 echo "Open DISP3(LVDS1)" gst-launch-1.0 playbin \   uri=file:///home/root/ktv_demo/720p_20fps.mp4 \   video-sink="imxv4l2sink device=/dev/video21" & sleep 3 The demo image can be downloaded at: \\10.193.102.186\public_share\ZhengTao\KTV Demo​ VPU frequency The vpu can run at 352MHz or  266MHz. We run it at 352MHz in this demo. The customer can configure the VPU frequcency from Linux kernel Kconfig options. Performance Utilization: 33% Overall Bus Load: 71% For 1080p@24fps, the real fps can only up to 13.319fps. The GPU may influence VPU performance .
View full article
FAQ Question: I receive the following error message when compiling GTK2 using LTIB" Making all in demos make[2]: Entering directory `/home/ltib/rpm/BUILD/gtk+-2.14.3/demos' no --raw --build-list \         apple_red  ./apple-red.png \                 gnome_foot ./gnome-foot.png \         > test-inline-pixbufs.h \ || (rm -f test-inline-pixbufs.h && false) /bin/sh: no: command not found make[2]: *** [test-inline-pixbufs.h] Error 1 make[2]: Leaving directory `/home/ltib/rpm/BUILD/gtk+-2.14.3/demos' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ltib/rpm/BUILD/gtk+-2.14.3' make: *** [all] Error 2 error: Bad exit status from /home/ltib/tmp/rpm-tmp.69212 (%build) Answer: Some packages on your host are missing, install the following packages: For deb distributions: sudo apt-get install libgtk2.0-dev or For Fedora distributions: sudo yum install gtk2-devel IMPORTANT: After install the package above, be sure to remove the installed GTK package on your ltib: On your LTIB directory: rm -rf rpm/BUILD/gtk+-2.14.3/ Question: I receive the following error message when booting through NFS: "Root-NFS: Server returned error -13 while mounting /tftpboot/ltib" Answer: Probabilty you remake your rootfs and forgot to restart NFS server. To solve this issue the command: "service nfs restart" Question: I am receiving "error: cannot open Name index using db3" when installing LTIB on new Ubuntu 9.10 Answer: Edit the file "ltib" and modify line 2428 to: $cf->{rpm}           = "rpm --force-debian"; Question: I receive the error message "Cannot create lockfile. Sorry." when I try to open minicom. Answer: This error message is generated because your user doesn't have permission to create a lock file in /var/lock. Change /var/lock permission: # chmod 777 /var/lock Question: I receive the error message "cannot open /dev/ttyS0: Permission denied" when I try to open minicom. Answer: This error message is generated because your user doesn't have permission to open /dev/ttyUSB0. Change /dev/ttyUSB0 permission: # chmod 777 /dev/ttyS0 Question: Compilation of e2fsprogs package or others packages with dependencies like Qtopia using LTIB in Debian derived linux system like Ubuntu makes an error like: make[1]: Leaving directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/tests/progs' making all in po make[1]: Entering directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/po' : --update cs.po e2fsprogs.pot rm -f cs.gmo && : -c --statistics -o cs.gmo cs.po mv: cannot stat `t-cs.gmo': No such file or directory make[1]: *** [cs.gmo] Error 1 make[1]: Leaving directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/po' make: *** [all-progs-recursive] Error 1 error: Bad exit status from /home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/tmp/rpm-tmp.66904 (%build) Answer: This error is caused by lack of the new version of package gettext. Install the gettext. For Ubuntu, the command line is: sudo apt-get install gettext But LTIB just recognize the existence of this package if it was installed before the LTIB installation. So, reinstall the LTIB. Question Compiling LTIB I got this error message: checking for glib-genmarshal... no configure: error: Could not find a glib-genmarshal in your PATH error: Bad exit status from /home/alan/ltib/tmp/rpm-tmp.48168 (%build) Answer: This error happen when you don't have glib2.0-dev in your system. To Ubuntu execute: sudo apt-get install libglib2.0-dev Question: How to convert an ELF binary to raw ARM binary? Answer: arm-none-linux-gnueabi-objcopy -O binary test.elf test.bin Question: How to inform to kernel to print all message on screen? Answer: echo 8 > /proc/sys/kernel/printk Question: How to disassembly an ARM binary? Answer: arm-none-linux-gnueabi-objdump -b binary -m arm -D test.bin Question: RedBoot returns invalid parameter: RedBoot> load -r -b 0x100000 zImage Using default protocol (TFTP) Can't load 'zImage': invalid parameter Answer: Verify if your tftp server is running correctly. If so, then verify if RedBoot network is configured correctly. You can use ping command to verify if communication with computer is working. Insert non-formatted text here Configure RedBoot to not use script and configure network: RedBoot> ^C RedBoot> fc Run script at boot: false Use BOOTP for network configuration: true. Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0xa1fe0000: . ... Erase from 0xa1fe0000-0xa2000000: . ... Program from 0x07ee0000-0x07f00000 at 0xa1fe0000: . RedBoot> Reset the board and then load the image Question: How can I test GPIO using a very simple test? Answer: You can find a very simple test here
View full article
To fix LCD problem: Download DirectFB patches (click here). Copy patches and kernel spec to LTIB: tar zxvf DirectFB-patches-specs.tar.gz cd specs cp kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch /opt/freescale/pkgs/ cp kernel.spec.in ~/ltib-imx31pdk-r14/config/platform/imx/ Remove old kernel: ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/linux* Issue LTIB to decompress kernel and apply patches: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m prep You will see at end: + echo Patch #1 (kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch): Patch #1 (kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch): + patch -p1 -s + exit 0 Build time for kernel: 21 seconds It means which kernel-imx31_3stack-2.6.24-DirectFB-LCD-fix.patch was applied correctly! Now compile your kernel: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m scbuild Install it on your rootfs: ~/ltib-imx31pdk-r14$ ./ltib -p kernel -m scdeploy To fix Touch-Screen Copy specs to LTIB: cd specs cp tslib.spec ~/ltib-imx31pdk-r14/dist/lfs-5.1/tslib/ cp DirectFB.spec ~/ltib-imx31pdk-r14/dist/lfs-5.1/DirectFB/ Remove old directories: ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/tslib-1.0/ ~/ltib-imx31pdk-r14$ rm -rf rpm/BUILD/DirectFB-1.1.0/ Edit your pkg_map and change tslib order. DirectFB needs tslib, then this lib needs be compiled first: [alan@localhost ltib-imx31pdk-r14]$ vi config/userspace/pkg_map ... PKG_TSLIB                                      = tslib PKG_DIRECTFB                               = DirectFB PKG_DIRECTFB_EXAMPLES            = DirectFB-examples ... Now run: alan@armagedon:~/ltib-imx31pdk-r14$ ./ltib -c Then select DirectFB and tslib packages. To test Touch-Screen mx31# mknod /dev/input/tslib0 c 13 65 mx31# export TSLIB_TSDEVICE=/dev/input/tslib0 mx31# rm -f /etc/pointercal mx31# ts_calibrate mx31# df_window
View full article
How To Understand JTAG BSDL File This example explains how to understand the BSDL file in order to create an OpenOCD configure file. IR Len That information can be retrieved directly: attribute INSTRUCTION_LENGTH of imx_device: entity is 5; This means that IR Len is 5, then in OpenOCD config it will be informed this way: -irlen 5 IR Capture The IR Capture also can be retrieved directly: attribute INSTRUCTION_CAPTURE of imx_device : entity is "XXX01"; This means that IR Capture is 1, then in OpenOCD config it will be informed this way: -ircapture 0x1 IR Mask The IR Mask is based on IR Len size. Just create a binary number with "IR Len" bits 1. If the IR Len is 4 then the IR Mask will be 0xF (1111). Case the IR Len is 5 the IR Mask will be 0x1F (11111). In this BSDL example (IR Len = 5) the OpenOCD config needs to inform the IR Mask this way: -irmask 0x1f TAP ID attribute IDCODE_REGISTER  of imx_device : entity is     "0010"            & -- Version     "000110"          & -- Design Center Number     "0100000001"      & -- Sequence Number     "00000001110"      & -- Manufacturer Identity     "1";                -- IEEE 1149.1 Requirement This code can be converted directly to TAP ID: Binary: 0010-0001-1001-0000-0001-0000-0001-1101 Hexadecimal: 2-1-9-0-1-0-1-D Then in OpenOCD configure you will create: if { [info exists SDMATAPID ] } {   set _SDMATAPID $SDMATAPID } else {   set _SDMATAPID 0x2190101d } The final configure line will be: jtag newtap $_CHIPNAME smda -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id $_SDMATAPID
View full article
How To Convert RealView CP15 Config To OpenOCD? # arm11 mcr <jtag_target> <coprocessor> <opcode 1> <CRn> <CRm> <opcode 2> <32bit value to write> Setting CP15 Control RealView: setreg @CP15_CONTROL=0x00050078 OpenOCD: arm11 mcr 1 15 0 1 0 0 0x00050078 Setting CP15 Peripheral Memory Remap RealView: setreg @CP15_PERIP_MEM_REMAP=0x40000015 OpenOCD: arm11 mcr 1 15 0 15 2 4 0x40000015
View full article
Splash Screen on U-boot for i.MX25 PDK Having a bitmap on the LCD a few seconds after boot is a requirement on several embedded systems, u-Boot supports this feature. However, currently, the code provided on Freescale's BSP only implements support for the LCD controller on Linux. This page provides instructions to add support for the LCDC on the u-boot. 1 - Install Freescale i.MX25 BSP, SDK 1.7 It is available on www.freescale.com. If needed follow the getting started section instructions. 2 - Update u-boot source After installing the BSP and running LTIB for the first time, it's time to update u-boot: - Download u-Boot patch and spec file. - Replace the file "u-boot.spec.in" located at <ltib_path>/config/platform/imx by the one downloaded - Copy the "u-boot-2009.08-1273860148.patch" downloaded to /opt/freescale/pkgs 3 - Extract and rebuild u-boot - To extract the source and aply the patch run: <Ltib_path>$ ./ltib -p u-boot -m prep - Now Build:      <Ltib_path>$ ./ltib -p u-boot -m scbuild    After completing this step an u-Boot binary (u-boot.bin) will be saved at <ltib_path>/rpm/BUILD/u-boot-2009.08 4 - Program the SD card Program a SD card with the new u-Boot binary and a bitmap image to be displayed. Insert the SD and run:       $sudo dd if=<ltib_path>/rpm/BUILD/u-boot-2009.08/u-boot.bin of=/dev/mmcblk0 bs=512 "/dev/mmcblk0" should replaced according to your host, use "dmesg" after inserting the SD to find out where is the SD on your host. Unmount it before issuing the dd command. $sudo dd if="your_image".bmp of=/dev/mmcblk0 bs=512 seek=608 Argument seek 608, skips the first 608 blocks of the SD (608x512) where the uboot is stored. If you need to relocate the image, update also the environment variable "splashimage_mmc_init_block", see step 6. 5 - Boot Boot the image from the SD. Personality Board settings:   12345678 SW22 -> 00000000 SW21 -> 11000000    Debug Board settings: SW5,6,7,8,9,10 -> OFF      12345678 SW4 -> 10000001 Turn on the board and stop at u-boot prompt: MX25 U-Boot > 6 - u-Boot environment variables Update u-Boot environment variables for the splash screen to work: The address in memory to load the splash screen from: MX25 U-Boot > setenv splashimage 0x80800000 The SD device on the board: MX25 U-Boot > setenv splashimage_mmc_dev 0 The block on the SD where the bitmap is stored, this must match the block on step 4. MX25 U-Boot > setenv splashimage_mmc_init_block 0x260  The amount in blocks to be read from the SD card, this depends on the bitmap size, i.e. for a 308278 bytes bitmap, 0x2B5 blocks are enough on a 512 bytes per block SD, (308278 / 512). MX25 U-Boot > setenv splashimage_mmc_blkcnt 0x2b5 The SD card block size in bytes: MX25 U-Boot > setenv splashimage_mmc_blksize 512 Save the environment variables: MX25 U-Boot > saveenv Now reboot the board and you should see the splash screen on the LCD. 7 - Booting Linux When Linux takes control of the board it initializes the LCD controller and Framebuffer again. To maintain the splash screen on the LCD you can replace the Linux Logo with the figure used for the splash screen, the side effect is a blink when Linux takes over the LCDC. To achieve this, create a new image in Gimp and save it as ".ppm". Copy it to Linux "logo" folder <ltib_path>/rpm/BUILD/linux-2.6.31/drivers/video/logo Run: $ ppmquant -mapfile clut_vga16.ppm "my_image.ppm" | pnmnoraw > logo_linux_vga16.ppm where: logo_linux_vga16.ppm is the current logo being used by Linux. Recompile the kernel and boot it.
View full article
i.MX6Q Automotive board has one ADV7180 analog video decoder with 2 video inputs. By default, only input 1 is used (connector J42).     To connect 2 analog video sources and switch the display between them, the following changes are needed:   1 - Create a new IOCTL on V4L2_capture and ADV7180 device drivers to receive the information from user space application on what input will be selected. 2 - In this new IOCTL, use the "Fast Switch Script" for ADV7180 described at Analog Devices site: ADV7180 Fast Switch Script | EngineerZone  3 - Create a user space application to call the IOCTL mentioned on step 1.   See attached:   1 -  0001-ADV7180-Adding-input-switch-IOCTL.patch.zip - Patch to be applied on NXP kernel 4.1.15_1.0.0_ga 2 - example2.c.zip - Source code example of user space application. It changes the video input in each 2 seconds. (See it working on attached video) 3 - example2.zip - U ser space application e xecutable file  4 - Makefile.zip - Makefile of user space application to be used as example 5 - adv7180_switch.mp4 - Video showing the application   In the application,  VIDIOC_S_CHIP_INPUT IOCTL is called to change the input:   int input = 0 ; if ( ioctl ( fd_capture_v4l , VIDIOC_S_CHIP_INPUT , & input ) < 0 ) { printf ( "VIDIOC_S_CHIP_INPUT failed\n" ) ; return TFAIL ; } ‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍   This IOCTL calls the ADV7180 Fast Switch Script, added on ADV7180 driver (see attached patch).
View full article
The following are a couple of recommendations for setting up a Host machine for building the Android Nougat 7.1.1_1.0.0 BSP. Some of these recommendations are not exclusive of the Nougat release and may help in other scenarios. These also apply to using Virtual Machines as Host. Installing Open JDK 8 on Ubuntu 14.04 As mentioned on the Android guide for Establishing a Build Environment (http://source.android.com/source/initializing.html) there are no available supported OpenJDK 8 packages for Ubuntu 14.04, which is the version recommended and tested on the Nougat Android BSP. An alternative is downloading the Ubuntu 15.04 Open JDK 8 packages and installing them manually, which can be done by following this procedure: Download the .deb packages for 64-bit architecture from archive.ubuntu.com: openjdk-8-jre-headless_8u45-b14-1_amd64.deb with SHA256 0f5aba8db39088283b51e00054813063173a4d8809f70033976f83e214ab56c0 http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jre-headless_8u45-b14-1_amd64.deb  openjdk-8-jre_8u45-b14-1_amd64.deb with SHA256 9ef76c4562d39432b69baf6c18f199707c5c56a5b4566847df908b7d74e15849 http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jre_8u45-b14-1_amd64.deb  openjdk-8-jdk_8u45-b14-1_amd64.deb with SHA256 6e47215cf6205aa829e6a0a64985075bd29d1f428a4006a80c9db371c2fc3c4c http://archive.ubuntu.com/ubuntu/pool/universe/o/openjdk-8/openjdk-8-jdk_8u45-b14-1_amd64.deb  Once you have downloaded these three packages and checked the checksum for them install the packages (optional) install them by running: $ sudo apt-get update $ sudo dpkg -i openjdk-8-jre-headless_8u45-b14-1_amd64.deb $ sudo dpkg -i openjdk-8-jre_8u45-b14-1_amd64.deb $ sudo dpkg -i openjdk-8-jdk_8u45-b14-1_amd64.deb ‍ ‍ ‍ ‍   Increasing SWAP to compensate for the lack of RAM Having insufficient RAM especially on the linking part of the image build may cause a number of issues that are difficult to troubleshoot. In these cases it’s good to take a look at the resource monitor to see if indeed the RAM was depleted. One way to make up for the limited RAM is using a bigger swap. Google recommends at least 16GB of RAM/swap so it’s not uncommon to create a 10GB swap when working in VM, to do this please use the following commands.    $ sudo fallocate -l 10g /mnt/10GB.swap $ sudo chmod 600 /mnt/10GB.swap $ sudo mkswap /mnt/10GB.swap $ sudo swapon /mnt/10GB.swap ‍ ‍ ‍ ‍   Increasing heap size to avoid out of memory errors It is possible to encounter an out of memory error with the recommendation “try increasing heap size witj java option ‘-Xmx<size>’. If you encounter this error or would like to proactively avoid it you may run the following commands that will increase heap size to four gigabytes and then reset the Jack Server by killing it and starting it again. With the android environment initialized: $ cd my android $ export JACK_SERVER_VM_ARGUMENTS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g" $ jack-admin kill-server && jack-admin start-server‍‍‍ ‍ ‍ ‍  Fixing Jack Servers errors due to multiple users on the Host Android Nougat uses Jack Server as mono-user by default. If this is not the case for your host you would need to choose different port numbers for each user and adjust SERVER_NB_COMPILE accordingly. You can also disable the Jack server by setting SERVER=false in your $HOME/.jack. Alternatively, you may also use the patch available on the following link to myandroid/prebuilts/sdk. It will help to fix the mono-user build restriction. When installing the jack-server, it will detect if Jack server is running in the same build machine and then generate a random ports for my build instead of using the default one. https://groups.google.com/forum/#!topic/android-building/UWhJrXH8Vig
View full article
Minicom       It's a simple terminal program, easy to configure and use. Can be downloaded and installed from your Linux package distribution (Synaptic, apt-get, yum) or through this link.       Minicom is a terminal emulation that can access a remote serial console enabling the configuration of Bootloader or the flash file system of the board.   Configuring       Run Minicom calling it from Terminal:     $ minicom       Reach the cofiguration by typing CTRL-A Z Press key Z after releasing CTRL and A. Configure Minicom to work with i.MX, follow the procedure below.   Set the Serial Port       At the screen configuration, type O, choosing Configure Minicom In menu, choose Serial Port Setup Below, the configuration option:       +-----------------------------------------------------------------------+ | A - Serial Device  : /dev/ttyS0                            | | B - Lockfile Location  : /var/lock                          | | C - Callin Program  :                                          | | D - Callout Program  :                                        | | E - Bps/Par/Bits  : 115200 8N1                          | | F - Hardware Flow Control : No                          | | G - Software Flow Control : No                            | |                                                                        | | Change which setting?                                      | +-----------------------------------------------------------------------+       Type the letter of option to enable the modification. Remember to choose the right Serial Device. Screen       Another useful program to use with serial ports is screen. It is a screen manager with VT100/ANSI terminal emulation usually available in Linux distributions. To open serial device /dev/ttyS0, for example, using 115200 baudrate, simply use:     $ screen /dev/ttyS0 115200       To kill the screen manager, use Ctrl + a, k. For a list of useful parameters and commands, try:     $ man screen
View full article
INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION AND TESTING 1. INTRODUCTION This document explains how to generate and compile a custom Linux application on the UDOO NEO board  for using the GPIO headers to connect a 16x2 LCD. 2. REQUIREMENTS First of all, the Linux image used is UDOObuntu 2 RC1 (Ubuntu 14.04), available for download from the following link:      Downloads - UDOO​ For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start Then, it is required to install the proper drivers to ensure connectivity, including USB communication with Linux terminal of the target board. Please refer to the link below:      Usb Direct Connection The LCD driver of this document was already implemented on a previous application, and could be found on the following document: Customizing MQX applications on i.MX6SX. 3. HARDWARE CONNECTIONS Now, the hardware connection considers a 4-bit interface to the LCD plus the Register Select (RS) and Enable (E) pins, so, six GPIO are used. For this example, digital input/output pins are used as shown on the following figure (purple rectangle): Where: NEO GPIO GPIO148 GPIO105 GPIO149 GPIO140 GPIO141 GPIO142 LCD pin E RS DB7 DB6 DB5 DB4 4. IMPLEMENTATION AND TESTING After booting Linux, a text editor like nano should be used to generate the program. The three main configurations for GPIOS are the following (using the E pin as example): Export the GPIO. echo 148 > /sys/class/gpio/export Configure the direction of the GPIO (as output). echo out > /sys/class/gpio/gpio148/direction Set the GPIO value to Low or High: echo 0 > /sys/class/gpio/gpio148/value echo 1 > /sys/class/gpio/gpio148/value So, based on these configurations and the LCD driver already implemented on the document mentioned on Requirements section, the complete C application for Linux could be generated (find it attached). The GCC compiler already included on the UDOObuntu image could be used to generate the executable application. The picture below shows the terminal of the UDOO NEO board including the text editor, compilation and execution commands of the application. The used commands are the following: $ nano lcd16x2_imx6sx.c $ sudo gcc lcd16x2_imx6sx.c -o lcd $ sudo ./lcd Finally, the following image shows the LCD with the application working on the UDOO NEO board, connecting the LCD using a proto shield : NOTE: Ensure that M4 core is not running or using the same pins, in order to avoid unexpected behavior on GPIOs.
View full article