Question: If the i.mx6’s internal real time clock is not used,  instead an external I2C device is used,  does this create a problem with using any of the i.mx6’s security features? Answer: iMX6 Secure features uses and internal real time counter (SRTC) which if enabled and reaches the maximum value it generates an interrupt informing a security violation. External RTC can't be used in security iMX6 context. I2C external RTC for applications is needed, but for security features SNVS uses the internal SRTC. Question: If I'm interpreting your comments correctly - The customers external RTC can't be used in the context of iMX6 security but can still used be used for their applications needs.  To utilize the security features of the SNVS Module (RM Chp. 60), it must use the internal SRTC.  Disabling or otherwise not implementing the requirements the SNVS module has a cascading effect on many other security features such as High-Assurance Boot (HAB) and CAAM operation.  So it seems that if the customer must have an external RTC, they should still implement the requirements of the internal SNVS/SRTC. Answer: That's the case if secure features are needed they will end up using the internal SRTC, actually I don't think is possible to be used in other scenario as is part of SNVS. Question: To better understand the implications of not having battery backup for the SNVS supply as it pertains to security, if it is normally powered all the time via either a local AC supply or POE+ and is never powered down except for service, and reboots are done with a pushbutton. Given this, can you list what types of security features cannot be implemented or will be problematic? Answer: ???

The default FSL android BSP support 1 SD card slot. If customer need to support more sd slot in android.Please reference below steps. There are two steps need to set up. 1 device/fsl.git NOTE: 1  change the fstab. 2194000 is the address of usdhc2.             2  change the mount point in storage_list.xml diff --git a/sabresd_6dq/fstab.freescale b/sabresd_6dq/fstab.freescale index 7f23edb..1529a27 100644 --- a/sabresd_6dq/fstab.freescale +++ b/sabresd_6dq/fstab.freescale @@ -4,6 +4,7 @@ # specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK /devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host /mnt/media_rw/extsd vfat defaults voldmanaged=extsd:auto +/devices/soc0/soc.0/2100000.aips-bus/2194000.usdhc/mmc_host /mnt/media_rw/extsd_expand vfat defaults voldmanaged=extsd_expand:auto /devices/soc0/soc.0/2100000.aips-bus/2184000.usb/ci_hdrc.0  /mnt/media_rw/udisk vfat defaults voldmanaged=udisk:auto /dev/block/mmcblk3p5    /system      ext4    ro,barrier=1                                                                               wait,verify /dev/block/mmcblk3p4    /data        ext4    nosuid,nodev,nodiratime,noatime,nomblk_io_submit,noauto_da_alloc,errors=panic    wait,encryptable=/dev/block/mmcblk3p9 diff --git a/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml b/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml index 3639bdc..c3f5105 100644 --- a/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml +++ b/sabresd_6dq/overlay/frameworks/base/core/res/res/xml/storage_list.xml @@ -41,6 +41,10 @@               android:storageDescription="@string/storage_sd_card"               android:primary="false"               android:removable="true" /> +    <storage android:mountPoint="/storage/extsd_expand" +             android:storageDescription="@string/storage_sd_card" +             android:primary="false" +             android:removable="true" />      <storage android:mountPoint="/storage/udisk" 2  system/core.git NOTE: mkdir the mount point. build@scmbld2:~/maddev_lp5.1_consolidate_ga_10_30/system/core/rootdir$ git diff diff --git a/rootdir/init.rc b/rootdir/init.rc index 2211cc2..fac37c2 100644 --- a/rootdir/init.rc +++ b/rootdir/init.rc @@ -72,7 +72,9 @@ on init      mkdir /storage 0751 root sdcard_r      mkdir /mnt/media_rw/extsd 0755 system system +    mkdir /mnt/media_rw/extsd_expand 0755 system system      symlink /mnt/media_rw/extsd /storage/extsd +    symlink /mnt/media_rw/extsd_expand /storage/extsd_expand      mkdir /mnt/media_rw/udisk 0755 system system

►Playbin2 provides a stand-alone everything-in-one abstraction for an audio and/or video player. •Audio sink and video sink can be specified by application •Supports subtitle for video files •Adjustable A/V offset •Selects audio/video/subtitle streams by input selector •Audio post-processing by audio convert, audio resample and volume • ►The pipeline is created by playbin2 dynamically: •Typefind checks the source type •Demuxer parses the source data and create pads for all the streams, respectively •Playbin2 searches for and creates decoders in element factory who have capability to decode specific format of audio/video •Playbin2 creates and connects audio sink chain and video sink chain Playbin2: interaction with application ►Set/get properties of playbin2 •“audio-sink”, “video-sink” •“current-audio”, “current-video”, “current-text” •“n-audio”, “n-video”, “n-text” (read only) •“uri”, “suburi”, “av-offset”, “volume”, “mute” ►Events •Bidirectional: flush start, flush end •Downstream: eos, new segment, tag •Upstream: qos, seek ►Queries •Position, duration, latency, rate, seeking, segment ►Messages •Eos, error, warning, info, tag, buffering, state changed, duration, latency, ►Signals •“video-changed”, “audio-changed”, “text-changed” •“video-tags-changed”, “audio-tags-changed”, “text-tags-changed” Playback: track selection                                               ►Pipeline for audio/video/subtitle multi-track file •Demuxer creates src pads for all the tracks, respectively •Each track has its own decoder and sink pad of input selector •One sink pad in input selector is activated to play corresponding track •Audio, video and subtitle have separated input selectors. •Take audio for example:                                                                                                                                                         ►Input selector •Only push the data from active sink pad to its src pad •The data from all the sink pads shall be synchronized, so that timestamps can be consecutive when switch to another track. Otherwise, there will be no sound or video for a long time after switching track. •If demuxer gets samples in file mode (need a large queue before decoder):              A lock is set for each inactive tracks to synchronize tracks. Otherwise, the inactive tracks would be decoded in full speed (usually much more faster than active track).              The lock compares the received timestamp with the last timestamp of active track. If larger, waits until the next timestamp (buffer) of acitived track arrives; if smaller, drop this buffer and get the next buffer. •If demuxer gets samples in track mode and the queue is small:             All tracks is synchronized by demuxer

Fixing Redboot RAM bug (CSD1 not activated) Introduction i.MX 35 PDK board has 256 MB of RAM, due to a bug in Redboot bootloader compiled for the board effectively there is only 128 MB available.This procedure fixes this bug to be able to use 256 MB of RAM. Redboot supporting 256 MB of RAM 1. Download the attached Redboot256.bin file. 2. Flash the new redboot image instead of the old one: Configuring RedBoot

You can but building times will take much longer (approximately 2 times longer for the core-image-minimal) compared to a build done on a native machine. In case you can not do the build on a native machine, make sure your virtual has enough hard-disk room (at least 50GB). For example, these are the build folders sizes after baking core-image-minimal: build$ du -h --max-depth=1 1.3G    ./sstate-cache 3.2M    ./cache 12K    ./.hob 32K    ./conf 22G    ./tmp 23G    . The tmp folder is by far the largest (containing building statistics, source code, deployed images, etc.) build/tmp$ tree -L 2 -d . ├── buildstats │   ├── cogl-imx6qsabresd │   ├── fsl-image-gui-imx6qsabresd │   ├── fsl-image-gui-sdk-imx6qsabresd │   ├── mesa-dri-imx6qsabresd │   ├── mesa-imx6qsabresd │   └── pseudo-native-imx6qsabresd ├── cache │   └── default-eglibc ├── deploy │   ├── images │   ├── licenses │   └── rpm ├── log │   ├── cleanlogs │   └── cooker ├── pkgdata │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   └── imx6qsabresd-poky-linux-gnueabi ├── sstate-control ├── stamps │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   ├── work-shared │   └── x86_64-linux ├── sysroots │   ├── imx6qsabresd │   ├── imx6qsabresd-tcbootstrap │   └── x86_64-linux ├── work │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   └── x86_64-linux └── work-shared     └── gcc-4.7.2-r13

UPDATE: Note that this document describes eIQ Machine Learning Software for the NXP L4.14 BSP release. Beginning with the L4.19 BSP, eIQ Software is pre-integrated in the BSP release and this document is no longer necessary or being maintained. For more information on eIQ Software in these releases (L4.19, L5.4, etc), please refer to the "NXP eIQ Machine Learning" chapter in the Linux User Guide for that specific release.  Original Post: eIQ Machine Learning Software for iMX Linux 4.14.y kernel series is available now. The NXP eIQ™ Machine Learning Software Development Environment enables the use of ML algorithms on NXP MCUs, i.MX RT crossover processors, and i.MX family SoCs. eIQ software includes inference engines, neural network compilers, and optimized libraries and leverages open source technologies. eIQ is fully integrated into our MCUXpresso SDK and Yocto development environments, allowing you to develop complete system-level applications with ease. Source download, build and installation Please refer to document NXP eIQ(TM) Machine Learning Enablement (UM11226.pdf) for detailed instructions on how to download, build and install eIQ software on your platform. Sample applications To help get you started right away we've posted numerous howtos and sample applications right here in the community. Please refer to eIQ Sample Apps - Overview. Supported platforms eIQ Machine learning software for i.MX Linux 4.14.y supports the L4.14.78-1.0.0 and L4.14.98-2.0.0 GA releases running on i.MX 8 Series Applications Processors. For more information on artificial intelligence, machine learning and eIQ Software please visit AI & Machine Learning | NXP.

Extending to the impact produced by being the First to release WEC7 on i.MX6 Development Platform, iWave Systems adds yet another accomplishment by announcing the availability of Windows Embedded Compact 7 (WEC7) reference BSP for Freescale’s i.MX6x SABRE SDB/SDP. The Freescale’s i.MX6x SABRE SDB/SDP Platform is powered with Freescale’s i.MX6 Quad/Dual Lite 1GHz, MMPF0100 Freescale PMIC. The WEC7 BSP release supports SATA II, Standard SD/SDIO, Gigabit Ethernet, LVDS, Touch Panel, HDMI port and also necessary hardware codecs supported by the CPU. Debugging tools like KITL and CETK are also supported. All the latest features that WEC7 offers such as Silverlight 3.0, MPEG-4 HD, Expression Blend, Active Sync and also Adobe Flash10.1 are made available.                                                                                                                                                                 Benefits: WEC7 Source code can be easily customized with respect to the target hardware platform Simple and low cost integration for any Freescale i.MX6x based platform       Quick time to market Highlights: Ideal for Quick Proof of concept (POC) development Shortens up to 60% of the new product development life cycle                                       Quick customization services in a very short period Features: Standard Features: i.MX6 Quad/Dual Lite 1GHz CPU MMPF0100 Freescale PMIC 1 GB DDR3 RAM Serial console SD boot SATA II SD/SDIO HDMI Gigabit Ethernet USB OTG Audio LVDS display Touch Optional Features: PCIe Camera CAN GPS VPU (HD Coding and Decoding supported) GPU (Open GL, Open VG, Direct3DM and DirectDraw) Target Applications: Automotive IVI Telematics Interactive POS Industrial HMI Medical Click Here for more details on WEC7 BSP Support for Freescale's i.MX6x Sabre SDB/SDP by iWave Click Here for more details on WEC7 BSP Support for various other i.MX processors

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

i.MX27 PDK Board Flashing This tutorial teaches how to flash bootloader using ATK. To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. Using ATK ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board. Set red and cream switches as below: Switch SW5 -> 00000 Switch SW4 -> 10000001 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. PS: On SW5 and SW4, "1" means the keys selected towards the edge of the board. 3 - Run ATK by clicking Start -> Programs -> AdvancedToolKit -> AdvancedToolKit       Set the options:    Device memory -> DDR; Custom Initial File -> (keep it unmarked)    Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO. Flash Erasing 1 - To erase Flash memory, select the parameters as shown in the figure below: 2 - Turn on the board and press Erase. 3 - ATK shows this message when flash is erased Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NAND, Address: 0x00000000 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot.

This documents describes how to add the NFC support to i.MX8M mini evk running Yocto. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on i.MX Linux 4.14.78_1.0.0 BSP software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_LINUX_DOCS. Just flash the demo image (downloaded from here: https://www.nxp.com/lgfiles/updates/NFC/LINUX_L4-14-78_IMAGE_MX8MMEVK.zip) following guidelines from i.MX_Linux_User's_Guide document (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above). Then in a terminal you can run the demo application included in the image executing the command:    # nfcDemoApp poll Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger such display: Adding PN7150 support to imx-linux-sumo release: Pre-condition is to have L4.14.78_1.0.0 release installed and already built as described in i.MX Yocto Project User's Guide (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above) :     $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest  -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml     $ repo sync     $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source fsl-setup-release.sh -b build_dir     $ bitbake fsl-image-validation-imx Then to add PN7150 support to your imx-linux-sumo environment, follow below step by step guidelines: In the sources directory, download the meta-nxp-nfc layer from https://github.com/NXPNFCLinux/meta-nxp-nfc     $ git clone https://github.com/NXPNFCLinux/meta-nxp-nfc.git  Define hardware connection between CPU and PN7150 in device-tree adding the following lines to file build_dir/tmp/work-shared/imx8mmevk/kernel-source/arch/arm64/boot/dts/freescale/fsl-imx8mm-evk.dts: @@ -227,6 +227,8 @@                         fsl,pins = <                                 MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL                  0x400001c3                                 MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA                  0x400001c3 +                               MX8MM_IOMUXC_ECSPI2_MOSI_GPIO5_IO11             0x41 +                               MX8MM_IOMUXC_ECSPI2_MISO_GPIO5_IO12             0x41                         >;                 };   @@ -747,6 +749,13 @@         pinctrl-0 = <&pinctrl_i2c3>;         status = "okay";   +       pn54x: pn54x@28 { +               compatible ="nxp,pn547"; +               reg = <0x28>; +               interrupt-gpios = <&gpio5 11 0>; +               enable-gpios = <&gpio5 12 0>; +       }; +         pca6416: gpio@20 {                 compatible = "ti,tca6416";                 reg = <0x20>; Add the meta-nxp-nfc layer to the build definition updating file build_dir/conf/bblayers.conf with: BBLAYERS += " ${BSPDIR}/sources/meta-nxp-nfc" Add the meta-nxp-nfc layer components to the image definition updating file build_dir/conf/local.conf with: IMAGE_INSTALL_append = " kernel-module-nxp-pn5xx nxp-nfc-bin " Re-build the linux kernel:     $ bitbake -f -c compile linux-imx && bitbake -f -c deploy linux-imx Build meta-nxp-nfc layer:     $ bitbake nxp-nfc Re-build the complete image to include the modifications:     $ bitbake fsl-image-validation-imx Then you can flash the updated image to your i.MX8M mini evk and run the demo application as described in above "Quick start using demo image" chapter. Reference: This porting have been done (demo image and instructions) following guidelines provided in AN11679_PN71xx_Linux_Software_Stack_Integration_Guidelines document.

After porting u-boot to your i.MX5x board you might want add it on LTIB menu, "Choose your board for u-boot" section. For this, edit ltib/config/platform/imx/main.lkc to add your board: Enter board on menu: comment "Choose your board for u-boot" choice prompt "board" default BOARD_MX51_BBG depends on PLATFORM = "imx51" help This menu will let you choose the board you use. ... + config BOARD_MX53_MYBOARD + bool "mx53_myboard" ... endchoice Add the "mx53_myboard_config" that matches your board configuration on the u-boot Makefile to PKG_U_BOOT_CONFIG_TYPE: config PKG_U_BOOT_CONFIG_TYPE   string   ... + default "mx53_myboard_config" if ( PLATFORM = "imx51" && BOARD_MX53_MYBOARD && !PKG_KERNEL_UPDATER )   ...

Quick Steps Four quick steps to build and flash a UBIFS image on i.MX35 NAND (K9LBG08U0D-PCB0), for information on how to you another memory, please see next section. Enable MTD_UBI and UBIFS_FS on kernel Create UBI image from rootfs (used for NFS) - ON PC mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg Format NAND using UBI image - ON TARGET ubiformat -f ubi.img /dev/mtd8 Load UBI file system load -r -b 0x100000 zImage fis create -f 0x300000 kernel fis load kernel exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none" How To First of all, install mtd-utils on both target and host: Target: ./ltib -c Package list [*] mtd-utils Host sudo aptget install mtd-utils 1. Enable MTD_UBI and UBIFS_FS on kernel MTD_UBI -> Device Drivers     -> Memory Technology Device (MTD) support (MTD [=y])           -> UBI - Unsorted block images                   <*> Enable UBI                    (4096) UBI wear-leveling threshold (NEW)                    (1) Percentage of reserved eraseblocks for bad eraseblocks handling (NEW)                 < > MTD devices emulation driver (gluebi) (NEW)                    ** UBI debugging options **                    [ ] UBI debugging (NEW) UBIFS_FS -> File systems         ->Miscellaneous filesystems             <*> UBIFS file system support                 [ ] Extended attributes support (NEW)                 [ ] Advanced compression options (NEW)                 [ ] Enable debugging (NEW) 2. Create UBI image On TARGET Collect some information needed in order to create the UBI image according to your NAND device root@freescale \~$ cat /proc/mtd dev:   size   erasesize name mtd0: 00080000 00020000 "Bootloader" mtd1: 00400000 00020000 "nor.Kernel" mtd2: 01e00000 00020000 "nor.userfs" mtd3: 01c00000 00020000 "nor.rootfs" mtd4: 00003000 00020000 "FIS directory" mtd5: 02001000 00020000 "Redboot config" mtd6: 00300000 00040000 "nand.bootloader" mtd7: 00500000 00040000 "nand.kernel" mtd8: 10000000 00040000 "nand.rootfs" mtd9: 00800000 00040000 "nand.configure" mtd10: 6f000000 00040000 "nand.userfs" I will use mtd8, because I want the NAND rootfs MTD partition. More on [1] root@freescale ~$ ubiattach /dev/ubi_ctrl -m 8 UBI: attaching mtd8 to ubi0 UBI: physical eraseblock size:   262144 bytes (256 KiB) UBI: logical eraseblock size:    258048 bytes UBI: smallest flash I/O unit:    2048 UBI: VID header offset:          2048 (aligned 2048) UBI: data offset:                4096 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd8 to ubi0 UBI: MTD device name:            "nand.rootfs" UBI: MTD device size:            256 MiB UBI: number of good PEBs:        979 UBI: number of bad PEBs:         45 UBI: max. allowed volumes:       128 UBI: wear-leveling threshold:    4096 UBI: number of internal volumes: 1 UBI: number of user volumes:     0 UBI: available PEBs:             966 UBI: total number of reserved PEBs: 13 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 0/0 UBI: image sequence number: 0 UBI: background thread "ubi_bgt0d" started, PID 2098 UBI device number You will need: -p = physical eraseblock size = 256KiB -e = logical eraseblock size = 258048 -m = smallest flash I/O unit = 2048 -s = VID header offset = 2048 -c = available PEB = 966 Values only for iMX35 PDK NAND - K9LBG08U0D-PCB0 3. ON HOST - Now, create the images (two steps) You need to create ubinize.cfg file! ubinize.cfg [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=237MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize $ mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img mkfs.ubifs      root:                rootfs/      min_io_size:    2048      leb_size:         258048      max_leb_cnt:   966      output:            ubifs.img      jrn_size:          8388608      reserved:         0      compr:            lzo      keyhash:         r5      fanout:            8      orph_lebs:       1      super lebs:      1      master lebs:    2      log_lebs:         4      lpt_lebs:          2      orph_lebs:       1      main_lebs:       132      gc lebs:           1      index lebs:       2      leb_cnt:           142      UUID:              CC2057F9-B20F-46D1-A399-1FCA95DCAFF7 Success\! $ ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg $ ls -lh u* -rw-r--r-- 1 daiane daiane 35M 2010-11-26 15:21 ubifs.img -rw-r--r-- 1 daiane daiane 36M 2010-11-26 15:22 ubi.img -rw-r--r-- 1 daiane daiane 113 2010-11-26 15:22 ubinize.cfg $ sudo cp ubi.img rootfs/home/ 4. Format NAND using UBI image - ON TARGET Turn on target (or reset it) and format MTD partition $ cd /home $ ubiformat -f ubi.img /dev/mtd8 5. Load UBI file system Reset and change redboot script: .. fis load kernel .. exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none"

i.MX evaluation board can be a simple solution to program i.MX boards in a factory for instance. i.MX evaluation board are not for industrial usage, but you can find plenty of cheap i.MX insdustrial boards on the web. Here I am using an i.MX8QXP rev B0 MEK board and I will program an i.MX6Q SABRE SD board. The first step is to generate your image. Follow the documentation steps to generate the "validation" image. You will have to customize a little bit the local.conf file (in conf/local.conf) to have git, cmake, gcc and other missing package. edit local.conf and add the following lines at the end of the file: IMAGE_INSTALL_append = " git cmake htop packagegroup-core-buildessential xz p7zip rsync"‍‍‍‍‍ I have added rsync package in local, it can replace cp (copy) but with the --progress option you can see the copy progression. P7zip replace unzip for our images archives avaialable on nxp.com as unzip as issues with big files. then rebake your image: bitbake -k fsl-image-validation-imx‍‍‍‍‍ When it is done, go in tmp/deploy/image/<your image generated> and use uuu to program your board (I use a sd card; thus I can increase the partition esily): sudo ./uuu -b sd_all imx-boot-imx8qxpmek-sd.bin-flash fsl-image-validation-imx-imx8qxpmek.sdcard.bz2/*‍‍‍‍‍ As the rootfs can be too small, use gparted under Linux for instance to increase the size of the partition. Put the SD card and start your board. Here here the dirty part... You may know archlinux|ARM websitesite (Arch Linux ARM ), you have a lots of precompiled packages. Thus on the board you can download it, and copy the file in /usr folder (you can use it to have the latest openSSL for  instance!). Plug an ethernet cable on the board and check if it is up: ifconfig -a ifconfig eth0 up‍‍‍‍‍‍‍‍‍‍ Now you should have access to the internet. On uuu webpage you can find all the packages you need (here I am using a 4.14.98_2.0.0 Linux): mkdir missinglibs cd missinglibs wget http://mirror.archlinuxarm.org/aarch64/core/bzip2-1.0.8-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/nettle-3.5.1-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/libusb-1.0.22-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/libzip-1.5.2-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/zlib-1:1.2.11-3-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/p7zip-16.02-5-aarch64.pkg.tar.xz cd ..‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Wait all the archives are downloaded (otherwise you'll decompress before the archive is downloaded) as wget is running in background! Now untar the archives and copy it in the rootfs (dirty): tar -xJf libzip-1.5.2-2-aarch64.pkg.tar.xz tar -xJf libusb-1.0.22-1-aarch64.pkg.tar.xz tar -xJf nettle-3.5.1-1-aarch64.pkg.tar.xz tar -xJf bzip2-1.0.8-2-aarch64.pkg.tar.xz cp zlib-1:1.2.11-3-aarch64.pkg.tar.xz zlib tar -xJf zlib tar -xJf p7zip-16.02-5-aarch64.pkg.tar.xz cd usr sudo cp -R . /usr cd ../../ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download and compile uuu: git clone git://github.com/NXPmicro/mfgtools.git cd mfgtools/ cmake . make‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download an image on nxp.com for instance. I have downloaded on the i.MX6 4.14.98_2.0.0 image and put it on a usb key. then unzip it in the uuu folder: 7z e L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip‍‍‍‍ As mentionned before unzip cannot hadle big files... so use 7z as me plug the i.MX6Q SABRE SD to the i.MX8X and program your i.MX6 board: ./uuu uuu.auto-imx6qsabresd‍ uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.74-0-g64eeca1 Success 1 Failure 0 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Configuring RedBoot The configuration is made using a Minicom session that need to be established between host and target through serial port. To have an operational system been executed just on the power on, configure the right for Boot script. The chooses are shown in Boot Script section. To avoid the start of operational system, power on the board and press CTRL-C immediately. Wait until RedBoot> prompt appears. Overview The main command for beginners is fconfig -l that can be abbreviated as fc -l    This command shows the actual configuration of Redboot, like: RedBoot> fc -l Run script at boot: true Boot script: .. load -r -b 0x100000 /tftpboot/zImage .. exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/n" Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false RedBoot> Run script at boot: set true for booting with a script or false to always enter on prompt directly Boot script: define what commands to execute as script at the startup Boot script timeout: how many time to wait before execute boot script Use BOOTP for network configuration: set true for getting configuration from BOOTP or false for manually configuring gateway and IP address Gateway IP address: The IP address of the gateway Local IP address: The board IP address Local IP address mask: The board IP mask address Default server IP address: The host IP address when NFS and TFTP server are running Configuring Network Execute the command to configure network parameters: RedBoot> fc This step guarantee the possibilities to load images from some server previously connected and configured. For Use BOOTP for network configuration: answer false. For Gateway IP address: type the gateway IP address of your network; For Local IP address: type an IP address to your board, it needs to be a valid IP in your network; For Local IP address mask: type the IP mask address; For Default server IP address: type the IP of your host server where are running TFTP and NFS. Pay special attencion for Update RedBoot non-volatile configuration - continue (y/n)?. Answer y to have your configuration saved in the flash. To verify if your configuration is working use ping, be patient this command is very slow: RedBoot" ping -h 10.29.244.99 Network PING - from 10.29.241.6 to 10.29.244.99 PING - received 10 of 10 expected Use the "-n" option to change the number of pings and the "-r" option to speed things up, such as: ping -n 3 -h 10.29.244.99 -r 10. The boot script configuration is done in the next section. Boot Script NFS Boot In NFS Boot mode, a kernel image and a root file system image are loaded from a configured server through TFTP and NFS that can be executed doing the development more easy. To configure RedBoot for NFS Boot reset the board and press CTRL-C immediately. In a Minicom session type fc to modify the configuration boot. Enter the script boot below: RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> load -r -b 0x100000 /tftpboot/zImage >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> The script is composed by two lines. The first line load the kernel image (zImage) by TFTP from /tftpboot, the directory configured in TFTP.\ The second line executes the kernel and mount the root file system using NFS. The path /tftpboot/ltib indicates the path that should be exported in the host machine. (It's the path in the /etc/exports) 10.29.244.99 is the host IP address 10.29.241.6 is the target IP address Flash Boot For flash boot the Boot Script differs a little bit: fis init kernel exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=none" The value for root can be different for each board type.

This doc describe the steps to enable HAB on i.MX7D EVK board with plugin boot mode. The BSP version is L3.14.52_ga_1.1.0 or L4.1.15_ga_1.2.0, the CST tool version is cst-2.3.2. Since fast authentication is supported after HAB 4.1.2, and the HAB version of i.MX7D is 4.2, we use fast authentication here. The PC to run the CST tool is Ubuntu 10.04, x86 version. 1. Generate HAB4 Keys and Certificates 1.1. Unpack the CST package, there are seven folders: ca, code, crts, docs, keys, linux32 and linux64     In "keys" folder, create "serial" file, openSSL uses the contents of this file for the certificate serial numbers.     In "keys" folder, create "key_pass.txt" file, this file contains your passphrase that will protect the HAB code signing private keys.     In this example, the content in "serial" file is         $ cat serial         12345678       The content in "key_pass.txt" file is         $ cat key_pass.txt         nxp_imx7d         nxp_imx7d   1.2 Prior to running the hab4_pki_tree.sh, ensure that OpenSSL is included in your search path by running         $ openssl version         OpenSSL 0.9.8k 25 Mar 2009   1.3 Run the hab4_pki_tree.sh script to generate hab4 keys and certificates         $ cd keys         $ ./hab4_pki_tree.sh         Do you want to use an existing CA key (y/n)?: n         Do you want to use Elliptic Curve Cryptography (y/n)?: n         Enter key length in bits for PKI tree: 2048         Enter PKI tree duration (years): 10         How many Super Root Keys should be generated? 4         Do you want the SRK certificates to have the CA flag set? (y/n)?: n     Since we are verifying fast authentication, answer 'n' here.   1.4 Generating HAB4 SRK tables and efuse Hash         $ cd ../crts         $ ../linux32/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c        SRK1_sha256_2048_65537_v3_usr_crt.pem,SRK2_sha256_2048_65537_v3 _usr_crt.pem,SRK3_sha256_2048_65537_v3_usr_crt.pem,SRK4 _sha256_2048_65537_v3_usr_crt.pem     SRK_1_2_3_4_fuse.bin is SRK efuse binary file.     SRK_1_2_3_4_table.bin is SRK table binary file. 2. Program SRK_HASH fuse 2.1 Dump SRK_1_2_3_4_fuse.bin.         $ od -t x4  SRK_1_2_3_4_fuse.bin         0000000 ac7ab98f 8febd6b4 b6e15ce3 3e870783         0000020 6f06d6a9 e1107545 3e19d19c e79d1556   2.2 Boot up the board with Linux rootfs, after log in, program SRK_HASH fuse.         # echo 0xac7ab98f > /sys/fsl_otp/HW_OCOTP_SRK0         # echo 0x8febd6b4 > /sys/fsl_otp/HW_OCOTP_SRK1         # echo 0xb6e15ce3 > /sys/fsl_otp/HW_OCOTP_SRK2         # echo 0x3e870783 > /sys/fsl_otp/HW_OCOTP_SRK3         # echo 0x6f06d6a9 > /sys/fsl_otp/HW_OCOTP_SRK4         # echo 0xe1107545 > /sys/fsl_otp/HW_OCOTP_SRK5         # echo 0x3e19d19c > /sys/fsl_otp/HW_OCOTP_SRK6         # echo 0xe79d1556 > /sys/fsl_otp/HW_OCOTP_SRK7 3 Sign u-boot 3.1 Apply the HAB patch and build the u-boot.     Goto u-boot source code folder and apply the patch:     $ git apply 0001-iMX7D-SabreSD-enable-HAB-boot-for-plugin-mode.patch     Build u-boot.     $ make distclean     $ make mx7dsabresd_defconfig     $ make       The followed two defines should be enabled in "uboot-imx/include/configs/mx7dsabresd.h" for secure configure and plugin mode.         #define CONFIG_SECURE_BOOT         #define CONFIG_USE_PLUGIN   3.2 Create u-boot folder in cst-2.3.2 folder, copy u-boot.imx to u-boot folder. Dump u-boot.imx IVT structures.     Dump plugin IVT header:         $ cd u-boot         $ od -x -N 48 u-boot.imx         0000000 00d1 4020 042c 0091 0000 0000 0000 0000         0000020 0420 0091 0400 0091 2400 0091 0000 0000         0000040 0000 0091 8000 0000 0001 0000 401f e92d       Plugin IVT header layout is: Offset   Name                    Value 0           ivt.header              0x402000d1 4           ivt.entry                 0x0091042c 8           ivt.reserved1         0x00000000 12         ivt.dcd_ptr             0x00000000 16         ivt.boot_data_ptr   0x00910420 20         ivt.self                    0x00910400 24         ivt.csf                     0x00912400 28         ivt.reserved2          0x00000000 32         boot_data.start      0x00910000 36         boot_data.size       0x00008000 40         plugin                     0x00000001       IVT address:  ivt.self = 0x00910400     Image length: ivt.csf – ivt.self = 0x00912400 - 0x00910400 = 0x2000     So the [Authenticate Data] field of csf file "csf_u-boot_plugin_ivt1.txt" is         Verification index = 0         Blocks = 0x00910400 0x000 0x2000 "u-boot.imx"     Dump u-boot IVT header:         $ dd if=u-boot.imx of=u-boot-body.bin bs=1 skip=16384         $ od -x -N 48 u-boot-body.bin         0000000 00d1 4020 0000 8780 0000 0000 0000 0000         0000020 fff4 877f ffd4 877f 8bd4 8785 0000 0000         0000040 bbd4 877f f000 0005 0000 0000 00be ea00       U-boot IVT header layout is: Offset   Name                   Value 0          ivt.header              0x402000d1 4          ivt.entry                 0x87800000 8          ivt.reserved1         0x00000000 12        ivt.dcd_ptr             0x00000000 16        ivt.boot_data_ptr   0x877ffff4 20        ivt.self                    0x877fffd4 24        ivt.csf                    0x87858bd4 28        ivt.reserved2         0x00000000 32        boot_data.start     0x877fbbd4 36        boot_data.size      0x0005F000       IVT address:  ivt.self = 0x877fffd4     Image length: ivt.csf – ivt.self = 0x87858bd4 - 0x877fffd4 = 0x58c00     So the [Authenticate Data] field of csf file "csf_u-boot_plugin_ivt2.txt" is         Verification index = 0         Blocks = 0x877fffd4 0x0000 0x58c00 "u-boot-body-pad.bin"       When enable CONFIG_SECURE_BOOT, boot_data consists of uboot image and csf data, so it's larger than uboot Image length.     And the u-boot-body.bin should be padded to 0x58c00.   3.3 The command to sign u-boot         $ ../linux32/cst -o csf_plugin.bin -i csf_u-boot_plugin_ivt1.txt         $ objcopy -I binary -O binary --pad-to 0x58c00 --gap-fill=0x00 u-boot-body.bin u-boot-body-pad.bin         $ ../linux32/cst -o csf_u-boot.bin -i csf_u-boot_plugin_ivt2.txt         $ objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 csf_plugin.bin csf_plugin-pad.bin         $ objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 csf_u-boot.bin csf_u-boot-pad.bin         $ dd if=u-boot.imx of=plugin-body.bin bs=1 count=8192         $ cat plugin-body.bin csf_plugin-pad.bin u-boot-body-pad.bin csf_u-boot-pad.bin > u-boot-signed.imx   3.4 Download u-boot-signed.imx to SD         $ sudo dd if=u-boot-signed.imx of=/dev/sdx bs=1K seek=1   3.5 Bootup from SD card, check HAB status by uboot command         => hab_status     If see "No HAB Events Found",  the signature is verified successfully.  

In January 2013, Adeneo Embedded launched 2 dedicated blogs. These blogs are both run by Adeneo Embedded Windows and Linux experts, multiple time MVP awarded. The goal is to provide the windows and linux communities with specific up-to-date information as well as the latest announcements concerning these two companies. Click here to visit our Windows dedicated blog Click here to visit our Linux dedicated blog Follow, comment and subscribe ! Ce document a été généré à partir de la discussion suivante : Adeneo Embedded experts launch 2 dedicated blogs !

document about how to use usb camera on imx6 android-4.0 platform.

Before QT5 Qt3D was a separate project and was maintained separately.  Now it is offered along with other official plugins. QT3D supports the addition of 3D elements. In order to install it this is needed: Clone the git Qt3D repository $ git clone git://gitorious.org/qt/qt3d.git Using the Qmake that you already created when installing Qt5, this will setup the Makefile in order to cross compile the plugin. $ qmake $ make $ sudo make install Ready to play with Qt3D! This is the HelloWorld of 3D,  teapot.bez  is a bezier curves file with the forms of the famous teapot. import QtQuick 2.0 import Qt3D 1.0 Viewport{    width: 640; height: 480    Item3D{    id: teapot    mesh: Mesh { source: "teapot.bez" }    effect: Effect {}   } }

Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.

Procrank can be used to check if a process has memory leakage. Procrank will list four types of memory usage. For details refer to: http://elinux.org/Android_Memory_Usage Vss = virtual set size Rss = resident set size Pss = proportional set size Uss = unique set size Uss can be used to check if a process has memory leakage. If the Uss increases when some operations start and stop, this means there could be memory leakage. Procrank can get from: <myandroid>/out/target/product/<product_name>/system/xbin/procrank and also needs to push to the library you target: <myandroid>/out/target/product/< product_name >/system/lib/libpagemap.so