i.MXプロセッサ ナレッジベース

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

i.MX Processors Knowledge Base

ディスカッション

ソート順:
You already know. Your source code is one week old now, so please, update it! $ repo sync What was the changes? Please, read the output and determinate what file was changed. Directory tree This is what I have under fsl-community-bsp directory: $ tree -d -L 2 -A . ├── build_mx53 │   ├── conf │   ├── sstate-cache │   └── tmp ├── build_mx6 │   ├── conf │   ├── sstate-cache │   └── tmp ├── downloads │   └── git2 └── sources     ├── base     ├── meta-fsl-arm     ├── meta-fsl-arm-extra     ├── meta-fsl-demos     ├── meta-openembedded     └── poky Sstate-cache keeps the pre-build packages cache so once one package is built, and it´s not changes, no need to re-build it again. If a team shares the same build environment, the sstate-cache folder can be shared as well. I´m not personally used to configure it, so, please, follow the doc: Yocto Project Reference Manual The downloads folder is shared for any build folder. It holds every package´s source code. For example, the ssh source code (and this source code can be built for any architecture) In addition, you may want to share the download folder with your team (one download folder for the complete team), so please, go to Yocto Project Reference Manual and look for DL_DIR. Build_mx6 tree .../build_mx6$ tree -d -L 2 -A . ├── conf ├── sstate-cache └── tmp     ├── buildstats     ├── cache     ├── deploy     ├── log     ├── pkgdata     ├── sstate-control     ├── stamps     ├── sysroots     ├── work     └── work-shared Inside tmp folder you will find images and build results. Images is placed inside deploy. Build statistics like initial and final time for each package/task are under buildstats The complete log for any 'bitbake' you did is under log. Take a look, for example, on the file  log/cooker/imx6qsabresd/11111111111.log. Please, notice that 111111111 is the PID number, so every time you run bitbake you have a different one. The source code, the patches, and the logs for the last bitbake, for each package is under work. Take a look on the files under tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ for example, for the kernel. .../build_mx6$ tree -d -L 1 -A tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ ├── deploy-linux-imx ├── deploy-rpms ├── git ├── image ├── license-destdir ├── package ├── packages-split ├── pkgdata ├── pseudo ├── sysroot-destdir └── temp Go under temp, and see a lot of log.* and run.*: .../build_mx6$ ls tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/temp/ log.do_bundle_initramfs             log.do_uboot_mkimage                run.do_package_write_rpm.28992      run.perform_packagecopy.16364 log.do_bundle_initramfs.28986       log.do_uboot_mkimage.2325           run.do_patch                        run.populate_packages.16364 log.do_compile                      log.do_unpack                       run.do_patch.2556                   run.read_shlibdeps.16364 log.do_compile.3483                 log.do_unpack.1155                  run.do_populate_lic                 run.read_subpackage_metadata.28992 log.do_compile_kernelmodules        log.task_order                      run.do_populate_lic.10988           run.split_and_strip_files.16364 log.do_compile_kernelmodules.29051  run.base_do_fetch.28859             run.do_populate_sysroot             run.split_kernel_module_packages.16364 log.do_configure                    run.base_do_unpack.1155             run.do_populate_sysroot.17692       run.split_kernel_packages.16364 log.do_configure.3048               run.BUILDSPEC.28992                 run.do_qa_configure.3048            run.sstate_create_package.10988 log.do_deploy                       run.debian_package_name_hook.16364  run.do_qa_staging.17692             run.sstate_create_package.16364 log.do_deploy.617                   run.do_bundle_initramfs             run.do_sizecheck                    run.sstate_create_package.17692 log.do_fetch                        run.do_bundle_initramfs.28986       run.do_sizecheck.2323               run.sstate_create_package.2724 log.do_fetch.28859                  run.do_compile                      run.do_strip                        run.sstate_create_package.28992 log.do_install                      run.do_compile.3483                 run.do_strip.2321                   run.sstate_create_package.617 log.do_install.2327                 run.do_compile_kernelmodules        run.do_uboot_mkimage                run.sstate_task_postfunc.10988 log.do_package                      run.do_compile_kernelmodules.29051  run.do_uboot_mkimage.2325           run.sstate_task_postfunc.16364 log.do_package.16364                run.do_configure                    run.do_unpack                       run.sstate_task_postfunc.17692 log.do_packagedata                  run.do_configure.3048               run.do_unpack.1155                  run.sstate_task_postfunc.2724 log.do_packagedata.2724             run.do_deploy                       run.emit_pkgdata.16364              run.sstate_task_postfunc.28992 log.do_package_write_rpm            run.do_deploy.617                   run.fixup_perms.16364               run.sstate_task_postfunc.617 log.do_package_write_rpm.28992      run.do_fetch                        run.package_depchains.16364         run.sstate_task_prefunc.10988 log.do_patch                        run.do_fetch.28859                  run.package_do_filedeps.16364       run.sstate_task_prefunc.16364 log.do_patch.2556                   run.do_install                      run.package_do_pkgconfig.16364      run.sstate_task_prefunc.17692 log.do_populate_lic                 run.do_install.2327                 run.package_do_shlibs.16364         run.sstate_task_prefunc.2724 log.do_populate_lic.10988           run.do_package                      run.package_do_split_locales.16364  run.sstate_task_prefunc.28992 log.do_populate_sysroot             run.do_package.16364                run.package_fixsymlinks.16364       run.sstate_task_prefunc.617 log.do_populate_sysroot.17692       run.do_packagedata                  run.package_get_auto_pr.16364       run.sysroot_cleansstate.3048 log.do_sizecheck                    run.do_packagedata.2724             run.package_get_auto_pr.2327        run.sysroot_stage_all.17692 log.do_sizecheck.2323               run.do_package_qa.16364             run.package_get_auto_pr.617         run.write_specfile.28992 log.do_strip                        run.do_package_rpm.28992            run.package_name_hook.16364 log.do_strip.2321                   run.do_package_write_rpm            run.patch_do_patch.2556 For each package, you will be able to see the log for the latest task, and what was done on the latest task. For example: log.do_compile - shows the log output from latest do_compile made for kernel run.do_compile - shows the compile command line log.do_compile.111111 - shows the log output from 1111111 time of do_compile In order to know the tasks and the task sequence, take a look to log.taskorder file For the images generated, you will find something like that: .../build_mx6$ ls -la tmp/deploy/images/imx6qsabresd/ total 146260 drwxr-xr-x 2 user user     4096 Mar  6 21:21 . drwxrwxr-x 3 user user     4096 Mar  6 21:12 .. -rw-r--r-- 1 user user 67108864 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.ext3 -rw-r--r-- 1 user user 83886080 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.sdcard -rw-r--r-- 1 user user 18782361 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.tar.bz2 lrwxrwxrwx 1 user user       55 Mar  6 21:21 core-image-base-imx6qsabresd.ext3 -> core-image-base-imx6qsabresd-20140306173758.rootfs.ext3 lrwxrwxrwx 1 user user       57 Mar  6 21:21 core-image-base-imx6qsabresd.sdcard -> core-image-base-imx6qsabresd-20140306173758.rootfs.sdcard lrwxrwxrwx 1 user user       58 Mar  6 21:21 core-image-base-imx6qsabresd.tar.bz2 -> core-image-base-imx6qsabresd-20140306173758.rootfs.tar.bz2 -rw-rw-r-- 2 user user   439697 Mar  6 21:12 modules--3.0.35-r37.14-imx6qsabresd-20140306173758.tgz lrwxrwxrwx 2 user user       54 Mar  6 21:12 modules-imx6qsabresd.tgz -> modules--3.0.35-r37.14-imx6qsabresd-20140306173758.tgz -rw-rw-r-- 2 user user      294 Mar  6 21:20 README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt lrwxrwxrwx 2 user user       35 Mar  6 21:16 u-boot.imx -> u-boot-imx6qsabresd-v2013.10-r0.imx lrwxrwxrwx 2 user user       35 Mar  6 21:16 u-boot-imx6qsabresd.imx -> u-boot-imx6qsabresd-v2013.10-r0.imx -rwxr-xr-x 2 user user   297984 Mar  6 21:16 u-boot-imx6qsabresd-v2013.10-r0.imx lrwxrwxrwx 2 user user       53 Mar  6 21:12 uImage -> uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin -rw-r--r-- 2 user user  4042496 Mar  6 21:12 uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin lrwxrwxrwx 2 user user       53 Mar  6 21:12 uImage-imx6qsabresd.bin -> uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin You can access any generated image, the image name ending with the yearmothdaypid (long number) is the real image, and every time your bitbake complete, it generate a new image. The symbolic link points to the latest created image. The .ext3 file is the EXT3 image for the rootfs. (you can copy it directly to SD card using dd: $sudo dd if=core-image-base.ext3 of=/dev/sdb2 ) The .sdcard file is the complete image to be copied to sdcard. It´s u-boot+uImage+rootfs The .tar.bz2 file is the tarball for the rootfs, you can extract it on your PC. uImage is the latest kernel image u-boot is the latest u-boot image. and so on. Play around with generated files. A lot of them I don´t know. And a lot of them I don´t use. For a standard image generation you only need to know where the final images is placed. Any question, comment, issue, please let me know. Before you go, let your bitbake creates the biggest image ever: $ bitbake fsl-image-gui Note (24Feb2014): Required disk space for build image is ~44GB Start it and let it finish while you do something else. Go HOME Go to Task #2 Go to Task#4
記事全体を表示
       Overview The purpose of this document is to describe how to enable Bluetooth on i.MX 6Dual/Quad SabreSD board (RevC) for Android software. Hardware Changes i.MX 6Dual/Quad SabreSD board doesn't enable Bluetooth connection by default. To support bluetooth, the hardware rework is required. The above diagram shows the reserved connections for Bluetooth in SabreSD RevC board (All connections are marked as "DNP"). This Bluetooth cable connector is designed specifically for the WiFi/BT combo card SX-SDCAN-2830BT which is developed and sold by Silex Technology. Note that pin 1 (BT_DISABLE) of the cable connector on i.MX 6Dual/Quad SabreSD RevC is opposite Pin 20 of the WiFi/BT module. Note: when connecting Silex module and J13, the connection is reverted (For example, PIN 1 in J13 connects to PIN 20 in Silex module). To use the J13 connector, the following reworks are required:   R209-R211, R214-R215 need to be populated.           Where is them, you can refer to the below chart.   SPI nor flash U14 need to be depopulated. No other AUX boards should be connected.. Exchange UART5_RXD and UART5_TXD. Orange PAD connects to Orange PAD. Green PAD connects to Green PAD.      After hardware rework, the Bluetooth connection will like the following:   Pin on Silex Module Sabresd Board Mux Pad Pin-2  BT_UART_RTS  (output) UART5.RTS   (input) MX6Q_PAD_KEY_COL4__UART5_RTS Pin-3  BT_UART_TXD   (output) UART5.RXD   (input) MX6Q_PAD_KEY_ROW1__UART5_RXD Pin-4  BT_UART_CTS   (input) UART5.CTS   (output) MX6Q_PAD_KEY_ROW4__UART5_CTS Pin-5  BT_UART_RXD   (input) UART5.TXD   (output) MX6Q_PAD_KEY_COL1__UART5_TXD Pin-14  BT_PWD_L       (input) GPIO_2         (output) MX6Q_PAD_GPIO_2__GPIO_1_2   Software Information For earlier android version before Jelly Bean4.2 Take ICS as an example, for we didn't do this work when our last ICS version R13.4.1 released. So our formal release had no support on BT. Here will give out patches based on R13.4.1. Enable Bluetooth with the following setting (e.g. device/fsl/imx6/sabresd/init.rc)      # No bluetooth hardware present -    setprop hw.bluetooth 0 +    setprop hw.bluetooth 1 Ensure BOARD_HAVE_BLUETOOTH := true in device/fsl/imx6/sabresd/SabreSDBoardConfigComm.mk. Add BT feature support in device/fsl/imx6/sabresd/required_hardware.xml: <permissions>      <feature name="android.hardware.camera" /> +    <feature name="android.hardware.bluetooth" />   Add UART5 support in kernel: In this step you can refer to the attached (kernel patch for UART5 based on ICS.zip) to change PinMux PAD configuration for UART5.   Add AR3002 BT firmware support: Update external/linux-firmware with the attached patch(0001-ENGR00270791-BT-add-AR3002-firmware-support.patch) to add AR3002 BT firmware support for Silex's BT is AR3002.   Then you can manually run the command “hciattach -n -s 115200 /dev/ttymxc4 ath3k 115200 flow nosleep” in console to see whether bluetooth can attach HCI successfully.   At last, you need add rfkill for BT reset in kernel, here also give a patch for reference: 0001-ENGR00270791-BT-add-rfkill-for-bt-reset.patch   BT is not enable in kernel default. You can control whether to enable it in bootargs like the following  in device/fsl/sabresd_6dq/BoardConfig.mk. BOARD_KERNEL_CMDLINE := console=ttymxc0,115200 init=/init video=mxcfb0:dev=ldb,bpp=32 video=mxcfb1:off video=mxcfb2:off fbmem=10M fb0base=0x27b00000 vmalloc=400M androidboot.console=ttymxc0 androidboot.hardware=freescale  bluetooth For android version since Jelly Bean4.2 From Jelly Bean4.2, Bluez is no longer used.Android provides a default Bluetooth stack, BlueDroid, that is divided into two layers: The Bluetooth Embedded System (BTE), which implements the core Bluetooth functionality and the Bluetooth Application Layer (BTA), which communicates with Android framework applications. A Bluetooth system service communicates with the Bluetooth stack through JNI and with applications through Binder IPC. The system service provides developers access to various Bluetooth profiles. The following diagram shows the general structure of the Bluetooth stack: For bluedroid, we have supported it in our formal release including Android4.3. You can get it from our website. Or just get HAL code from attached(libbt-ath3k.zip). Known issue For  KEY_COL4 is both used by uart5 and pcie,  if you enable BT, 3G  mobile will not work. For its power disable pin is conflict with uart5's UART_RTS. This is also why we didn't enable BT in formal release. Supported and tested profile workable profile not tested profile Hid Handset & Handfree(not support for hardware restrict) A2DP Pbap Opp Pan
記事全体を表示
This example makes use of a U-Boot image as a bootloader. U-Boot is commonly used as a bootloader for Linux devices and is provide by the Freescale Linux BSP. The default memory layout of the Freescale U-Boot port can be modified to meet the encrypted boot requirements. This is shown in figure 5. As it can be seen, this layout is similar to any other U-Boot port, with the addition of the security mechanisms appended at the end of the image.                          Figure  Chosen memory layout of the encrypted u-boot 1)Assumptions In designing a U-Boot image as an encrypted boot solution, there are three assumptions which accelerate and simplify the construction process. . The U-boot image can be build for multiple board configuration, but for demonstration purposes this example uses i.MX6 Solo X . The user is familiar with the secure configuration for U-Boot and is able to properly sign and boot a U-Boot image. . The encrypted image will be constructed by an individual party, and there is no need to worry about provisioning the DEK. 2)Requirements The components required to build an encrypted image are shown below. Note that the majority of these components are the product of following the signing U-Boot image procedure.    a)Code Signing Tool in encryption mode o To build the CST in encryption mode, run the following command make OSTYPE=linux ENCRYPTION=yes HAB_RELEASE=~/hab/hab_release release o Note: that CST is not in encryption mode by default. This feature needs to be enabled before encrypting the bootloader image. The performance of the CST might be affected, due to its dependency on the host entropy. Refer to the CST User Guide for more details.   b) iMX6 Solo X device in secure mode   c) U-Boot image with secure boot support enabled. o To configure U-Boot to be built with secure boot support, CONFIG_SECURE_BOOT will need to be defined in the board header file (i.e. at include/configs/mx6q_arm2.h)   d) Signed U-Boot image o A U-Boot image with a CSF and digital signature attached. 3) Implementation Many different implementations for constructing a encrypted U-boot image are possible. The right implementation depends on the solution’s requirement. The presented implementation is intended to provide the foundation principles; it can be modified to meet different needs.
記事全体を表示
The i.MX6Q-SDP is used to stream OV5642 parallel camera video encoded as JPEG using the hardware CODEC engine to a Linux client which decodes and displays on the screen.
記事全体を表示
Here we show how to bootstrap the Debian Linux distribution from a PC to the i.MX6 sabre sd platform. While bootstrapping Debian on any architecture "natively" is pretty straightforward, "cross-bootstrapping" requires some techniques that we will explain. This document assumes you are able to boot a Linux kernel on your platform already. See this post for details on how to do it. Also, this document assumes you are using a Debian PC for preparing your SD card. You will require the following packages to be installed: binfmt-support qemu-user-static debootstrap Note: all the commands found in the following steps need to be run as root. Formatting the SD card We need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel and its dtb, and one large ext4 partition, which will contain the root filesystem with the Debian userspace. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout:   +-----+------+--------+-----+---------------+-----------------   | MBR |  ... | u-boot | ... | FAT partition | Linux partition ...   +-----+------+--------+-----+---------------+-----------------   0     512    1024           1M              ~257M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk:   Device    Boot      Start         End      Blocks   Id  System   /dev/sdc1            2048      526335      262144    c  W95 FAT32 (LBA)   /dev/sdc2          526336     8054783     3764224   83  Linux (units: 512B sectors) You can format and mount the Linux partition with:   # mkfs.ext4 /dev/<your-sd-card-second-partition>   # mount /dev/<your-sd-card-second-partition> /mnt Your SD card second partition is typically something in /dev/sd<X>2 or /dev/mmcblk<X>p2. Do not forget to install u-boot and a Linux kernel as explained in those posts. Bootstrapping Debian First stage The first stage of Debian bootstrapping is done with:   # debootstrap --foreign --arch=armhf testing /mnt This will retrieve the base Debian packages from the internet, and perform a first stage of installation:   I: Retrieving Release   I: Retrieving Release.gpg   I: Checking Release signature   I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)   I: Validating Packages   I: Resolving dependencies of required packages...   I: Resolving dependencies of base packages...   I: Found additional required dependencies: insserv libbz2-1.0 libcap2 libdb5.1 libsemanage-common libsemanage1 libslang2 libustr-1.0-1   I: Found additional base dependencies: libee0 libept1.4.12 libestr0 libgcrypt11 libgnutls-openssl27 libgnutls26 libgpg-error0 libidn11 libjson-c2 liblognorm0 libmnl0 libnetfilter-acct1 libnfnetlink0 libp11-kit0 libsqlite3-0 libtasn1-3 libxapian22   I: Checking component main on http://ftp.us.debian.org/debian...   (...)   I: Extracting util-linux...   I: Extracting liblzma5...   I: Extracting zlib1g... At this point, the necessary tools for second stage of installation are under /mnt/debootstrap/. Second stage The second stage needs to run natively; on an arm platform, that is. But we can use the combination of two techniques to perform this stage on the PC anyway:   # cp /usr/bin/qemu-arm-static /mnt/usr/bin/   # chroot /mnt /debootstrap/debootstrap --second-stage Those commands copy an arm emulator on the target filesystem, and use the chroot command to execute the second stage of the installation into the SD card, on the PC, with transparent emulation:   I: Installing core packages...   I: Unpacking required packages...   I: Unpacking libacl1:armhf...   I: Unpacking libattr1:armhf...   I: Unpacking base-files...   (...)   I: Configuring tasksel...   I: Configuring tasksel-data...   I: Configuring libc-bin...   I: Base system installed successfully. You can now remove /mnt/usr/bin/qemu-arm-static, or keep it for later, subsequent chroot under emulation. Finetuning the root filesystem For development it is handy to remove the root password on the target by removing the '*' from /mnt/etc/shadow on the SD card:   root::15880:0:99999:7::: Also, we can add the following line in /mnt/etc/inittab to obtain a login prompt on the UART:   T0:23:respawn:/sbin/getty -L ttymxc0 115200 vt100 You can now unmount the filesystem with:   # umount /mnt Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. At the time of writing u-boot tells the kernel to boot from the wrong partition by default, so we need to interrupt by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this:   U-Boot > setenv mmcroot /dev/mmcblk0p2 rootwait rw   U-Boot > saveenv   Saving Environment to MMC...   Writing to MMC(1)... done As this is saved in the SD card it need only to be done once at first boot. You can reboot your board or type boot; your Debian system should boot to a prompt:   (...)   [ ok ] Starting periodic command scheduler: cron.   [ ok ] Running local boot scripts (/etc/rc.local).   Debian GNU/Linux jessie/sid debian ttymxc0   debian login: From there you may login as root. It is recommended to setup the network connection and install an ssh server inside the target for further development. Enjoy! See also... With the amounts of memory we have today in the systems, it is even possible to boot Debian in a ramdisk. See this post about busybox for the ramdisk generation. Another way of generating a root filesystem is by building it with buildroot. See and this post for details.
記事全体を表示
The reference code is based on L4.14.78 GA1.0.0 BSP and M4 SDK 2.5.1.  It is tested on iMX8QXP MEK board, and it should also work for iMX8QM board. In L4.14.78 GA1.0.0 BSP, MU_5 is used for RPMSG between M4 FreeRTOS and A35 Linux, SC_R_MU_5B is M4 side and SC_R_MU_5A is A35 side. In linux side, we used the "imx_rpmsg_tty.ko" for this test, this driver is built as module in default BSP. Case 1: M4 wake up A35. Apply "L4.14.78_rpmsg_wakeup.patch" to linux kernel, this patch will enable the RPMSG wake up feature. "rpmsg_lite_pingpong_rtos.tar.bz2" is the M4 side test code. After booted the board with Linux + M4 rpmsg software, run followed test commands: 1. In A35 UART side, run followed commands:     # echo enabled > /sys/bus/platform/devices/90000000.rpmsg/power/wakeup     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30     # echo mem > /sys/power/state 2. M4 UART side:    After run "echo deadbeaf > /dev/ttyRPMSG30" from Linux side, it will show "Got ping..." and wait there, after run A35 suspend commane "echo mem > /sys/power/state", Linux suspends. Then from M4 UART side, press "c" key, it will send RPMSG to A35 and wake up A35 Linux. Case 2: A35 wake up M4. "power_mode_switch_rpmsg_wakeup.tar.bz2" is the M4 side test code, After booted the board with Linux + M4 rpmsg software, the M4 UART will wait for A35 RPMSG driver ready. Test commands: 1. In A35 UART side, run followed commands to make RPMSG driver ready:     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30 2. Now M4 UART shows ping pong messages to make sure RPMSG is ready. Now M4 is in power switch menu, select VLLS power mode in M4 UART:      Press  H for enter: VLLS     - Very Low Leakage Stop mode     ... ...      Press R for RPMSG. After press "R" key in M4 UART, M4 will print "Send a RPMSG message to wake up" and goto suspend mode. 3. Wake up M4 from A35 side, send any data to RPMSG:     # echo deadbeaf > /dev/ttyRPMSG30 M4 resumed and goto power switch menu again. SDK folder to compile the two M4 sample code: SDK/boards/mekmimx8qx/multicore_examples/rpmsg_lite_pingpong_rtos SDK/boards/mekmimx8qx/demo_apps/power_mode_switch
記事全体を表示
This is the prototype demo to enable surround view demo on SabreSD.   The attached Files are HW&SW guides and demo video. Updating Notes: Add miniPCIE Surround View_Rev A design file (include schematic and layout) as attachement. Add Gerber file   i.MX6Q Surround view patch https://community.freescale.com/docs/DOC-95143 Original Attachment has been moved to: Gerber-file.zip Original Attachment has been moved to: miniPCIe-Surround-View_Rev-A.zip
記事全体を表示
This document describes the steps to create your own out-of-tree kernel module recipe for Yocto.
記事全体を表示
On default i.MX6UL EVK board, it supports three boot device: SD Card boot in main board, micro-SD card boot in CPU board and QSPI-FLASH in CPU board. As we know, i.MX6UL supports NAND device boot and there are NAND device footprint in the EVK board. If customer wants to use NAND boot, there is something to rework in both hardware and software. Hardware Modification NAND device boot mode is conflict with micro-SD card and QSPI-FLASH device boot modes. 1. Remove U303 in CPU board and DO NOT insert micro-SD card into J301 2. Solder U302 NAND FLASH on EVK board Software Modification In Yocto-Linux BSP standard release, NAND device boot is not supported. We need add support in u-boot, linux DTB and MFGTool. 1. u-boot-imx modification and build Replace u-boot-imx/include/configs/mx6ul_14x14_evk.h with the same file in the attachment Copy mx6ul_14x14_evk_nand_defconfig in the attachment to u-boot-imx/configs/ Build the new u-boot.imx: make distclean; make mx6ul_14x14_evk_nand_defconfig;make Rename u-boot.imx to u-boot-imx6ulevk_nand.imx 2. Linux DTB modification and build Copy imx6ul-14x14-evk-gpmi-weim.dts in the attachment to kernel/arch/arm/boot/dts/ Build imx6ul-14x14-evk-gpmi-weim.dtb: make imx6ul-14x14-evk-gpmi-weim.dtb Rename imx6ul-14x14-evk-gpmi-weim.dtb to zImage-imx6ul-14x14-evk-gpmi-weim.dtb 3. MFGTOOL modification Copy mfgtool2-yocto-mx6ul-evk-nand.vbs in the attachment to MFGTOOL root direcory Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\firmware\ Copy u-boot-imx6ulevk_nand.imx and zImage-imx6ul-14x14-evk-gpmi-weim.dtb to MFGTOOL\Profiles\Linux\OS Firmware\files\ Congratulations!!!  You can burn NAND image to i.MX6UL-EVK board with mfgtool2-yocto-mx6ul-evk-nand.vbs script now!!
記事全体を表示
Overview The purpose of this document is to demonstrate how to enable USB Bluetooth Dongle based on i.MX6 Android ICS. Hardware i.MX6Dual/Quad or i.MX6DualLite SabreSD board USB Bluetooth Dongle Software i.MX6DQ/MX6DL Android ICS R13.4 or R13.4.1 Release Changes 0001-enable-usb-dongle-BT.patch: Update bluedroid to disable RFKILL and enable HCIATTACH property for USB Bluetooth Dongle. diff --git a/bluedroid/Android.mk b/bluedroid/Android.mk index 17df49b..569be44 100644 --- a/bluedroid/Android.mk +++ b/bluedroid/Android.mk @@ -5,6 +5,13 @@ LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS) +ifeq ($(BOARD_BLUETOOTH_DOES_NOT_USE_RFKILL),true) +  LOCAL_CFLAGS := $(LOCAL_CFLAGS) -DBLUETOOTH_DOES_NOT_USE_RFKILL +endif + +ifeq ($(BOARD_BLUETOOTH_USES_HCIATTACH_PROPERTY),true) +  LOCAL_CFLAGS := $(LOCAL_CFLAGS) -DBLUETOOTH_HCIATTACH_USING_PROPERTY +endif LOCAL_SRC_FILES := \   bluetooth.c diff --git a/bluedroid/bluetooth.c b/bluedroid/bluetooth.c index 4cc9204..2636942 100644 --- a/bluedroid/bluetooth.c +++ b/bluedroid/bluetooth.c @@ -44,7 +44,7 @@ static int rfkill_id = -1; static char *rfkill_state_path = NULL; - +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL static int init_rfkill() {      char path[64];      char buf[16]; @@ -135,6 +135,7 @@ out:      if (fd >= 0) close(fd);      return ret; } +#endif static inline int create_hci_sock() {      int sk = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI); @@ -151,13 +152,20 @@ int bt_enable() {      int ret = -1;      int hci_sock = -1;      int attempt; - +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL      if (set_bluetooth_power(1) < 0) goto out; - +#endif +#ifndef BLUETOOTH_HCIATTACH_USING_PROPERTY      LOGI("Starting hciattach daemon"); -    if (property_set("ctl.start", "hciattach") < 0) { +    if (property_set("ctl.start", "hciattach") < 0) +#else +    if (property_set("bluetooth.hciattach", "true") < 0) +#endif +    {          LOGE("Failed to start hciattach"); +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL          set_bluetooth_power(0); +#endif          goto out;      } @@ -186,14 +194,18 @@ int bt_enable() {          if (property_set("ctl.stop", "hciattach") < 0) {              LOGE("Error stopping hciattach");          } +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL          set_bluetooth_power(0); +#endif          goto out;      }      LOGI("Starting bluetoothd deamon");      if (property_set("ctl.start", "bluetoothd") < 0) {          LOGE("Failed to start bluetoothd"); +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL          set_bluetooth_power(0); +#endif          goto out;      } @@ -222,14 +234,20 @@ int bt_disable() {      ioctl(hci_sock, HCIDEVDOWN, HCI_DEV_ID);      LOGI("Stopping hciattach deamon"); -    if (property_set("ctl.stop", "hciattach") < 0) { +#ifndef BLUETOOTH_HCIATTACH_USING_PROPERTY +    if (property_set("ctl.stop", "hciattach") < 0) +#else +   if (property_set("bluetooth.hciattach", "false") < 0) +#endif +   {          LOGE("Error stopping hciattach");          goto out;      } - +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL      if (set_bluetooth_power(0) < 0) {          goto out;      } +#endif      ret = 0; out: @@ -246,9 +264,10 @@ int bt_is_enabled() {      // Check power first +#ifndef BLUETOOTH_DOES_NOT_USE_RFKILL      ret = check_bluetooth_power();      if (ret == -1 || ret == 0) goto out; - +#endif      ret = -1;      // Power is on, now check if the HCI interface is up 0002-usb_dongle-on-SabreSD.patch: Update MX6 board configuration files to enable USB Bluetooth dongle feature. diff --git a/imx6/imx6.mk b/imx6/imx6.mk @@ -63,6 +63,7 @@ PRODUCT_PACKAGES += \ PRODUCT_PACKAGES += \   audio.tinyalsa.freescale   \   audio.legacy.freescale    \ +        audio.a2dp.default                      \   alsa_aplay                \   alsa_arecord    \   alsa_amixer        \ diff --git a/imx6/sabresd/SabreSDBoardConfigComm.mk b/imx6/sabresd/SabreSDBoardConfigComm.mk index 03d8ce5..1a8a6bd 100755 --- a/imx6/sabresd/SabreSDBoardConfigComm.mk +++ b/imx6/sabresd/SabreSDBoardConfigComm.mk -# atheros 3k BT -BOARD_USE_AR3K_BLUETOOTH := true +# Default use USB BT dongle for imx6, so should enable below +BOARD_BLUETOOTH_DOES_NOT_USE_RFKILL := true +BOARD_BLUETOOTH_USES_HCIATTACH_PROPERTY := true + USE_ION_ALLOCATOR := false USE_GPU_ALLOCATOR := true diff --git a/imx6/sabresd/init.rc b/imx6/sabresd/init.rc index ff9f0ff..f127177 100755 --- a/imx6/sabresd/init.rc +++ b/imx6/sabresd/init.rc @@ -84,9 +84,12 @@ on boot      # No bluetooth hardware present      setprop hw.bluetooth 0      setprop wlan.interface wlan0 +    setprop hw.bluetooth 1 diff --git a/imx6/sabresd/required_hardware.xml b/imx6/sabresd/required_hardware.xml index c9a2271..f7db37b 100644 --- a/imx6/sabresd/required_hardware.xml +++ b/imx6/sabresd/required_hardware.xml @@ -22,6 +22,7 @@      <feature name="android.hardware.camera.flash" />      <feature name="android.hardware.camera.front" />      <feature name="android.hardware.location" /> +    <feature name="android.hardware.bluetooth" />      <feature name="android.hardware.location.network" />      <feature name="android.hardware.location.gps" />      <feature name="android.hardware.telephony" />
記事全体を表示
Downloading and building the IPU examples IPU examples - v0.1 are available at https://github.com/rogeriorps/ipu-examples To download, just clone the project: $ git clone https://github.com/rogeriorps/ipu-examples.git Follow the README.md on the project root folder to build and install it. Available demos Alpha Blending Basic Combining Cropping Color Space Conversion Deinterlacing Resizing Rotation i.MX5 basic_ex1 rot_ex1 i.MX6 alpha_ex1 alpha_ex2 crop_ex1 csc_ex1 dint_ex1 res_ex1 rot_ex1 i.MX5 Basic examples basic_ex1: Prints all information from all framebuffers. It uses only the framebuffer device /dev/fb*. Rotation examples rot_ex1: Rotate an image a show on display. This example uses the ipu library instead using directly the /dev/mxc_ipu. i.MX6 Alpha blending examples alpha_ex1: This example shows how to use global alpha blending. It fills layer 1 with white color, an overlay layer with 4 color strips and varies the global alpha blending, showing on display 2 planes at the same time with different transparency rates. alpha_ex2: This example shows how to use local alpha blending. This example uses 3 buffers: 1 - Input buffer: Used as layer 1 (background). 2 - Overlay buffer: Used as layer 2 (foreground). 3 - Alpha buffer: Used as alpha buffer, where each pixel will correspond to the transparency value between input and overlay buffers. When running it will fill input and overlay buffers with solid colors, alpha buffer with 4 different alpha strips and will turn on and off the local alpha blending. Color space conversion examples csc_ex1: This example shows how to use color space conversion. It reads 4 different formats images (RGB565, RGBA32, NV12 and YUYV422) and show them on background framebuffer on a RGB565 format. Crop example crop_ex1: This example shows how to crop an image using "output crop". It fills the input buffer with a solid color and crop the output buffer. The result will be a solid block on the display. De-interlace example dint_ex1: This example shows how to de-interlace a single interlaced frame. The example loads an 320x240 interlaced NV12 image and show on display turning on and off the de-interlace feature. Resize examples res_ex1: This example resizes the image freescale_1024x768.raw (1024x768 RGB565 format) to an 800x480 RGB24 format image, storing into a local file output_file.raw. Rotation examples rot_ex1: This example rotates the image freescale_1024x768.raw (1024x768 RGB565 format) and displays using all rotation modes: 0 - No rotation 1 - Vertical flip 2 - Horizontal flip 3 - 180 degrees 4 - 90 degrees right 5 - 90 degrees right with vertical flip 6 - 90 degrees right with horizontal flip 7 - 90 degrees left Known issues
記事全体を表示
Video, bad performance gst-launch filesrc location=test.mp4 typefind=true ! aiurdemux ! vpudec ! mfw_v4lsink Video, better performance gst-launch filesrc location=sample.mp4 typefind=true ! aiurdemux ! queue max-size-time=0 ! vpudec ! mfw_v4lsink # typefind=true allows to 'type find' the source file before negotiating # max-size-time=0 indicates to ignore possible blocking issues # In case of ASF files gst-launch filesrc location=sample.asf typefind=true ! aiurdemux ! queue max-size-time=0 ! mfw_wmvdecoder ! mfw_v4lsink Audio gst-launch filesrc location=sample.mp3  typefind=true ! beepdec ! audioconvert  ! 'audio/x-raw-int, channels=2' ! alsasink Audio with visualization gst-launch filesrc location=sample.mp3 typefind=true ! beepdec ! tee name=t ! queue ! audioconvert  ! 'audio/x-raw-int, channels=2' ! alsasink t. ! queue ! audioconvert ! goom ! autovideoconvert ! autovideosink Video/Audio long version gst-launch filesrc location=sample.avi typefind=true ! aiurdemux name=demux demux. ! queue max-size-buffers=0 max-size-time=0 ! vpudec ! mfw_v4lsink demux. ! queue max-size-buffers=0 max-size-time=0 ! beepdec ! audioconvert ! 'audio/x-raw-int, channels=2' ! alsasink # queue properties, max-size-buffers=0 and max-size-time=0, allows a smoother playback; type 'gst-inspect queue' for more info VA short version gplay sample.avi VA short version gst-launch playbin2 uri=file://<full path to sample file>
記事全体を表示
This documents describes the neceesary steps to set up Qt Creator with the Qt5 toolchain that is available as part of the 3.14.28 BSP Release. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release L3.14.28 or higher. For this example we'll use the Freescale BSP Release L3.14.28 but you may use future BSP releases that include the Qt toolchain. - Freescale BSP Release Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=gz&WT_ASSET=Documentation&fileExt=.gz&Parent_nodeId=1337637154535695831062&Parent_pageType=product&Parent_nodeId=1337637154535695831062&Parent_pageType=product 3) Qt5 Meta Toolchain (Poky 1.7 qt5 / L3.14.28 for our example but you may use the qt toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document but with the following command: $ bitbake meta-toolchain-qt5 https://community.freescale.com/docs/DOC-95122 Task #7 - Create the toolchain Then run the script. fsl-release-bsp/<BUILD_DIR>/tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-vfp-neon-toolchain-1.7.sh Installing Qt Creator We will use the Open Source version of Qt Creator. Please make sure that your application does comply with the requirements of Open Source Software before installing. You may download Qt Creator Open Source for Linux from the following link: http://www.qt.io/download-open-source/ Once you downloaded the installer you will need to make sure that the file has permission to be executed. You can add this with the following command: $ chmod +x qt-unified-linux-x64-2.0.2-2-online.run Then run the installer $ ./ qt-unified-linux-x64-2.0.2-2-online.run After the information from the repositories has been fetched you will be asked where to install Qt Creator. Then you will be asked which components to install. We will install Qt 5.4 which is the one supported on the 3.14.28 BSP release. You will need to accept the License Agreement and then the installer will fetch and install the necessary files. Configuring Qt Creator Once it’s finished downloading, launch Qt Creator. You can do this with the following command: cd <INSTALATION_DIR>/Tools/QtCreator/bin $./qtcreator.sh Under the Tools top bar menu, chose Options… On the Options window’s left menu chose Build & Run and then the Compilers tab and select Add GCC. On the next screen chose a name for this Compiler (i.e. i.MX Qt5) and then select the Compiler path, which may vary depending on where you have it installed but by default should be in: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ It should then be detected as arm-linux on the ABI section. Next select the Qt Versions tab and click on Add… Look for the qmake on the toolchain path, which is by default: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake Finally, on the Kits tab add a new kit and select the sysroots from the toolchain, which is by default located in: /opt/poky/<VERSION>/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi Qt Creator is now configured for building for the i.MX6.
記事全体を表示
The purpose of this document is to provide supportive information for selection of suitable LPDDR4, DDR4 and DDR3L devices that are supported by i.MX 8M family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products.  It is strongly recommended to consult with NXP and the memory vendor the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the NXP Hardware Developer's Guides for the specific SoCs available on NXP.com Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket.  LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad 32-bit 32Gb/4GB dual rank, dual-channel  device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8M Mini  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16) 1, 2 i.MX 8M Nano  16-bit 32Gb/4GB dual rank, single-channel  device with 17-row addresses (R0-R16) 1, 2, 3, 12 i.MX 8M Plus  32-bit 64Gb/8GB dual rank, dual-channel  device with 17-row addresses (R0-R16)  1, 2   LPDDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Memory Vendor Validated Memory Part#  Notes i.MX 8M Quad  24Gb/3GB    Micron MT53B768M32D4NQ-062 WT:B  15 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D  14 4Gb/512MB ISSI IS43LQ16256B-062BLI  5, 14 8Gb/1GB ISSI IS43LQ32256B-062BLI  5, 14 i.MX 8M Mini 16Gb/2GB Micron MT53D512M32D2DS-053 WT:D  15 16Gb/2GB    ESMT M56Z16G32512A-SMBIG 5, 14 32Gb/4GB Micron MT53E1G32D2FW-046 WT:A  5, 14 64Gb/8GB Micron MT53E2G32D4DT-046 AIT:A  5, 14 64Gb/8GB Micron MT53E2G32D4DE-046 AUT:C 5, 14 32Gb/4GB Intelligent Memory IMBG32L4KBB 5,14 32Gb/4GB Kingston B3221PM3BDGUI -U 5 16Gb/2GB Kingston D1621PM4CDGVIW-U 5 i.MX 8M Nano  16Gb / 2GB  Kingston C1612PC2WDGTKR-U  15 16Gb / 2GB  Kingston  D1611PM3BDGUI-U 5,14 32Gb / 4GB Micron MT53E2G32D4DT-046 AIT:A  5, 13, 15 16Gb / 2GB Intelligent Memory  IMAG16L4KBB 5,14 4Gb / 512MB Nanya NT6AN256M16AV-J2 5,14 4Gb / 512MB  Winbond W66CP6RBQAHJ 5,14 8Gb / 1GB ISSI IS43LQ16512A-053BLI 5,14 8Gb / 1GB  Micron MT53D512M32D2DS-053 WT:D 13, 15   i.MX 8M Plus     48Gb/6GB  Micron MT53E1536M32D4DT-046 WT:A  15 64Gb/8GB  Micron MT53E2G32D4DE-046 AUT:C  5, 14 32Gb/4GB Samsung K4FBE3D4HB-KHCL  5, 14 32Gb/4GB Kingston B3221PM3BDGVIW-U 5, 14 64Gb/8GB Kingston Q6422PM3BDGVK-U  5, 14 8Gb/1GB Winbond W66DP2RQQAHJ  5, 14 32Gb/4GB ISSI IS46LQ32K01S2A-046BLA2 5, 14 16Gb/2GB ISSI IS46LQ32512A-046BLA3 5 32Gb/4GB ISSI IS43LQ32K01S2A-046BLI 5, 14 32Gb/4GB IM IMBG32LK4BBG-046I 5, 14 32Gb/4GB Nanya NT6AN1024F32AV-J2 5, 14   LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table:   Memory Vendor Memory Part# Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX 8M Quad  The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL K4UJE3D4AA-KU(H/F)CL 24Gb/3Gb 48Gb/6GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX 8M Quad i.MX 8M Mini i.MX 8M Nano i.MX 8M Plus A byte mode memory device. The memory device only supports the LPDDR4X mode.    DDR4 - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 6 i.MX 8M Mini  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7 i.MX 8M Nano  16-bit 64Gb/8GB x8, 16Gb device with 2 bank group addresses, 17-row addresses and 10 column addresses 1, 8 i.MX 8M Plus  32-bit 64Gb/8GB x16, 16Gb device with 1 bank group address, 17-row addresses and 10 column addresses 1, 7   DDR4 - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required.   SoC Density Memory Vendor Validated Memory Part#  Notes i.MX 8M Quad 32Gb/4GB Micron 4x MT40A512M16JY-083EAAT  15 i.MX 8M Mini  16Gb/2GB Micron 2x MT40A512M16LY-075:E  15 i.MX 8M Nano 16Gb/2GB Micron 1x MT40A1G16RC-062E:B  15 8Gb/1GB Rayson 1x RS512M16Z2DD-62DT 14 8Gb/1GB UniIC SCB12Q8G160BF-06SI 14 i.MX 8M Plus 64Gb/8GB Micron 4x MT40A1G16RC-062E:B  15 16Gb/2GB Nanya NT5AD512M16C4-JRI  14   DDR3L - maximum supported densities SoC Max data bus width Maximum density Assumed memory organization Notes i.MX 8M Quad  32-bit 32Gb/4GB x16, 8Gb device with 16-row addresses and 10 column addresses 1, 9 i.MX 8M Mini  32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 10 i.MX 8M Nano  16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 1, 11 i.MX 8M Plus  i.MX 8M Plus does not support DDR3L   DDR3L - list of validated memories Please note that the validation process is an ongoing effort - regular updates of the table are expected. Please contact NXP if a specific vendor or configuration is required. SoC Density Vendor Validated Memory Part#  Notes i.MX 8M Quad  16Gb/2GB Micron 4x MT41K256M16TW-107 AAT  14 i.MX 8M Mini  16Gb/2GB Micron 4x MT41K256M16TW-107 AAT  14              i.MX 8M Nano 8Gb/1GB Micron MT41K512M16VRN-107  15   Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standards JESD209-4/JESD209-4A (LPDDR4), JESD279-4/JESD279-4A (DDR4), and JESD79-3E/JESD79-3F/JESD79-3-1A (DDR3/DDR3L). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chips to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the DDR Controller Note 5: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 6: The density can be achieved by connecting 2 single-rank discrete devices with one 16Gb die each. Since the SoC supports x8 devices and also has connectivity for a second rank, usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Two x16 16Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (only two discrete devices used), and bandwidth aspects (full data bus width used). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 64Gb/8GB of address space dedicated for the DDR. Four x16 16Gb devices giving 64Gb/8GB in total is the optimal choice that balances the maximum density aspects, the signal integrity aspects (only four discrete devices used), and the bandwidth aspects (full data bus width used). Note 8: The density can be achieved by connecting 4 single rank discrete devices with one 16Gb die each, 2 devices connected to each chip select.  Note 9: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Since the SoC supports x8 devices, the usage of more discrete devices is possible. However, this advantage cannot be used to get higher density since this SoC has only 32Gb/4GB of address space dedicated for the DDR. Four x16 8Gb devices giving 32Gb/4GB in total is, therefore, the optimal choice that balances the maximum density aspects, the signal integrity aspects (four discrete devices used), and bandwidth aspects (full data bus width used). Note 10: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that the first option significantly exceeds the number of devices used on the validation board (4 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis. Practically, it is not recommended to use more than 4 discrete DDR3L devices. This corresponds to the maximum density of 32Gb/4GB in the case of the single rank devices containing one 8Gb die or 64Gb/8GB in case of the dual-rank devices, each containing two 8Gb dies. Note 11: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note 12: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (Q1 2022). Note 13: Only one channel of the device (and hence, half of its density) was utilized due to the reduced data bus width (x16) of the SoC. Note 14: Part is active. Reviewed Jan 2026 Note 15: Part will either EoL or is not recommended for new designs by the respective vendor.   Additional Links https://community.nxp.com/t5/iMX-and-Vybrid-Support/i-MX-8-8X-8XL-maximum-supported-LPDDR4-and-DDR3L-densities/ta-p/1152715           
記事全体を表示
This document is a user guide for the GStreamer version 1.0 based accelerated solution included in all the i.MX 8 family SoCs supported by NXP BSP L5.4.24_1.1.0. Some instructions assume a host machine running a Linux distribution, such as Ubuntu, connected to i.MX 8 device. These commands were tested using Ubuntu 18.04 LTD, and while Ubuntu is not required on the host machine, other distributions have not been tested. These instructions are targeted for use with the following hardware: • i.MX 8MQ EVK • i.MX 8MN EVK • i.MX 8MN EVK • i.MX 8QXP MEK B0 • i.MX 8QM MEK B0   Release History v1.0 - Mar 2020 - Initial release. v2.0 - Sep 2020: Added the following content: - Mux/Demux Examples - Audio Examples - Image Examples - Transcode Examples - Streaming Examples - Multi-Display Examples - Scaling and Rotation Examples - Zero-copy Examples - Debug Examples Maintainers: . Marco Franchi . Pedro Jardim
記事全体を表示
Notes: First run the playback pipeline then the streaming pipeline. The above example streams H263 video and AMR audio data. Change codec format to your needs. In case where the iMX is the streaming machine, the audio encoder 'amrnbenc' must be installed before. This scenario has not been tested Shell variables and pipelines Playback machine (receiver) # On playback machine, set either IMX2PC or PC2IMX variables, then run the pipeline ## IMX2PC: Case where PC does the playback     AUDIO_DEC_SINK="rtpamrdepay ! amrnbdec ! alsasink "     VIDEO_CAPS="\"application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H263-1998\""     VIDEO_DEC_SINK="rtph263pdepay ! ffdec_h263 ! autovideosink" ## End of IMX2PC Settings ## PC2IMX: Case where iMX does the playback     AUDIO_DEC_SINK="rtpamrdepay ! mfw_amrdecoder ! alsasink "     VIDEO_CAPS="\"application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H263-1998\""     VIDEO_DEC_SINK="rtph263pdepay ! vpudec ! mfw_v4lsink " ## End of PC2IMX Settings PLAYBACK_AUDIO="udpsrc caps=\"application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)AMR,encoding-params=(string)1,octet-align=(string)1\" \             port=5002 ! rtpbin.recv_rtp_sink_1 \         rtpbin. ! $AUDIO_DEC_SINK \      udpsrc port=5003 ! rtpbin.recv_rtcp_sink_1 \      rtpbin.send_rtcp_src_1 ! udpsink port=5007 sync=false async=false" PLAYBACK_VIDEO="udpsrc caps=$VIDEO_CAPS port=5000 ! rtpbin.recv_rtp_sink_0 \         rtpbin. ! $VIDEO_DEC_SINK \         udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 \         rtpbin.send_rtcp_src_0 ! udpsink port=5005 sync=false async=false" PLAYBACK_AV="$PLAYBACK_VIDEO $PLAYBACK_AUDIO" # Playback pipeline gst-launch -v gstrtpbin name=rtpbin $PLAYBACK_AV Streaming Machine (sender) # On Streaming machine, set either IMX2PC or PC2IMX variables, then run the pipeline ## IMX2PC: Case where iMX does the streaming     IP=x.x.x.x # IP address of the playback machine     VIDEO_SRC="mfw_v4lsrc"     VIDEO_ENC="vpuenc codec=h263 ! rtph263ppay "    AUDIO_ENC="audiotestsrc ! amrnbenc ! rtpamrpay " ## END IMX2PC settings ## PC2IMX: Case where PC does the streaming     IP=y.y.y.y # IP address of the playback machine     VIDEO_SRC="v4l2src"     VIDEO_ENC="ffenc_h263 ! rtph263ppay "     AUDIO_ENC="audiotestsrc ! amrnbenc ! rtpamrpay " # END PC2PC settings STREAM_AUDIO="$AUDIO_ENC ! rtpbin.send_rtp_sink_1 \         rtpbin.send_rtp_src_1 ! udpsink host=$IP port=5002 \         rtpbin.send_rtcp_src_1 ! udpsink host=$IP port=5003 sync=false async=false \         udpsrc port=5007 ! rtpbin.recv_rtcp_sink_1" STREAM_VIDEO="$VIDEO_SRC ! $VIDEO_ENC ! rtpbin.send_rtp_sink_0 \         rtpbin.send_rtp_src_0 ! queue ! udpsink host=$IP port=5000 \         rtpbin.send_rtcp_src_0 ! udpsink host=$IP port=5001 sync=false async=false \         udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0" STREAM_AV="$STREAM_VIDEO $STREAM_AUDIO" # Stream pipeline gst-launch -v gstrtpbin name=rtpbin $STREAM_AV
記事全体を表示
Overview This document provides some solutions for building i.MX 6 series LTIB on an Ubuntu 14.04 Trusty Tahr host. A Virtualbox virtual machine was created for the Ubuntu computer which is used for the build host.   Linux Target Image Builder (LTIB) is a perl script used for creating images (Bootloader u-boot, Linux uImage, and root file system). The build example shown here was for the i.MX 6Q and minimum root file system.   Software Versions L3.0.35_4.1.0_ER_SOURCE_BSP L3.0.35 : Linux version 3.0.35 4.1.0 :  Freescale release number ER_SOURCE_BSP : Engineering Release source Board support package File download URL:  L3.0.35_4.1.0_130816_source.tar.gz. Note this requires a free account registration at freescale.com. md5sum L3.0.35_4.1.0_130816_source.tar.gz dec08bb266134b94af0f54356e2e9de9  L3.0.35_4.1.0_130816_source.tar.gz L3.0.35_4.1.0_docs.tar.gz Documentation bundle. File download URL: L3.0.35_4.1.0_docs.tar.gz md5sum L3.0.35_4.1.0_docs.tar.gz 85f122c72735f3d162a99ae42554e886  L3.0.35_4.1.0_docs.tar.gz Ubuntu 14.04 LTS Trusty Tahr LTS : Long Term Supported 64-bit version File download URL: http://www.ubuntu.com/download/desktop md5sum ubuntu-14.04-desktop-amd64.iso dccff28314d9ae4ed262cfc6f35e5153  ubuntu-14.04-desktop-amd64.iso Virtualbox Version 4.3.10 File download URL: Oracle VM VirtualBox Machine Setup 4 CPU 4 GB RAM 64 GB Hard disk from USB 3.0 connected drive Host Computer Dell M4600, 8GB RAM,  8 CPU Ubuntu Linux 12.04.02 LTS   Ubuntu Host 14.04 Host Packages Various packages are required to meet build requirements of LTIB. Please refer to "Setting_Up_LTIB_host.pdf" document found in the L3.0.35_4.1.0_docs.tar.gz download. See below for the trustyPkgs.txt attachment that shows all the packages that were installed. This was created using the command: dpkg --list   On your host you can run the command "dpkg --list" and compare with the trustyPkgs.txt using your favorite diff tool. (examples, meld, diff). Any package missing can be added using your favorite package manager.  For example to install mkimage which is found in the u-boot-tools package:  sudo apt-get install u-boot-tools   Build LTIB Host Package M4 Failure The package m4 fails to build. Paste of the error messages:   gcc -std=gnu99  -I.     -g -O2 -MT clean-temp.o -MD -MP -MF .deps/clean-temp.Tpo -c -o clean-temp.o clean-temp.c In file included from clean-temp.h:22:0,                  from clean-temp.c:23: ./stdio.h:477:1: error: 'gets' undeclared here (not in a function) make[3]: *** [clean-temp.o] Error 1 make[3]: Leaving directory `/opt/freescale/ltib/usr/src/rpm/BUILD/m4-1.4.16/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/opt/freescale/ltib/usr/src/rpm/BUILD/m4-1.4.16/lib'   Solution Replace the m4 package with a newer version. The m4 package bundled with LTIB is version 1.4.16. A newer version 1.4.17 is available and does not have build failures. File download URL: http://ftp.gnu.org/gnu/m4/m4-1.4.17.tar.gz Create a md5 file:           md5sum m4-1.4.17.tar.gz > m4-1.4.17.tar.gz.md5 Move both files to /opt/freescale/pkgs which is where ltib searches for packages.           mv m4* /opt/freescale/pkgs Edit the m4.spec file that specifies the version           cd <ltib>/dist/lfs5.1/m4/           Edit m4.spec using your favorite editor.  Line 5 is the Version number to change from 16 to 17:   Original: 1 %define pfx /opt/freescale/rootfs/%{_target_cpu} 2 3 Summary : The GNU macro processor 4 Name  : m4 5 Version : 1.4.16 6 Release : 1 7 License : GPL   Updated: 1 %define pfx /opt/freescale/rootfs/%{_target_cpu} 2 3 Summary : The GNU macro processor 4 Name  : m4 5 Version : 1.4.17 6 Release : 1 7 License : GPL       busybox   Failure   /opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/../lib/gcc/arm-fsl-linux-gnueabi/4.6.2/../../../../arm-fsl-linux-gnueabi/bin/ld: cannot find /lib/libc.so.6 /opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/../lib/gcc/arm-fsl-linux-gnueabi/4.6.2/../../../../arm-fsl-linux-gnueabi/bin/ld: cannot find /usr/lib/libc_nonshared.a /opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/../lib/gcc/arm-fsl-linux-gnueabi/4.6.2/../../../../arm-fsl-linux-gnueabi/bin/ld: cannot find /lib/ld-linux.so.3 collect2: ld returned 1 exit status make: *** [busybox_unstripped] Error 1 error: Bad exit status from /home/user/imx6/ltib/tmp/rpm-tmp.60711 (%build)     RPM build errors:     Bad exit status from /home/user/imx6/ltib/tmp/rpm-tmp.60711 (%build) Build time for busybox: 93 seconds   Failed building busybox   Solution:   Go into ltib/dist/lfs-5.1/base_libs/base_libs.spec and find these lines:      # remove absolute paths from text search files (if they exist)      perl -w -e '          @ARGV = grep { `file $_` =~ m,ASCII C program text, } @ARGV;          exit(0) unless @ARGV; Remove the last two (the lines beginning with "@ARGV" and "exit(0)"   Adding the # character removes the lines 299 and 300 297 # remove absolute paths from text search files (if they exist) 298 perl -w -e ' 299 #@ARGV = grep { `file $_` =~ m,ASCII C program text, } @ARGV; 300 #exit(0) unless @ARGV; 301$^I = ".bak";     Success When the build completes, u-boot.bin and uImage are found in <ltib>/rootfs/boot   [user@trusty ltib]$ tree rootfs/boot rootfs/boot ├── bootable_kernel -> uImage ├── linux.config ├── System.map ├── u-boot ├── u-boot.bin ├── uImage ├── vmlinux └── zImage Original Attachment has been moved to: trustyPkgs.txt.zip Original Attachment has been moved to: lkc-1.4.tar.gz
記事全体を表示
1. INTRODUCTION:      This document explains the general and basic steps to customize U-Boot for your own board. The board used in this document it is a working and stable board, the UDOO board (http://udoo.org). 2. REQUIREMENTS:     Install Yocto Project. See the Freescale Yocto Project User's Guide.     Generate and install the meta-toolchain. Follow this great training to do so  Yocto Training - HOME     Generate core-image-minimal of L3.14.28 of FSL BSP obtained from https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_iMX6QDLS_BUNDLE&appType=license&location=null&Parent_no…   3. ADDING i.MX6 CUSTOM BOARD SUPPORT FOR U-BOOT.     This section follows the steps found in Chapter 1 of the i.MX6 BSP Porting Guide of the Yocto documentation (L3.14.28) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… . Obtain U-Boot Source Code. After having installed Yocto project and generate a valid imx6 image, the U-Boot code should be located at <build directory>/tmp/work/<machine>-poky-linuxgnueabi/u-boot-imx/<version>/git. Prepare the Code. Choose a board as reference, this board should be as similar as possible to your custom board. Copy the board directory :                $ cp -R board/freescale/mx6sabresd/ board/freescale/mx6_udoo Copy the existing mx6sabresd.h configuration file as mx6_udoo.h                $ cp include/configs/mx6sabresd.h include/configs/mx6_udoo.h Create one entry in boards.cfg. Add a configuration entry in the boards.cfg file. Active  arm  armv7  mx6  freescale  mx6_udoo mx6_udoo mx6_udoo:IMX_CONFIG=board/freescale/mx6_udoo/mx6dl_4x_mt41j128.cfg,MX6Q,DEFAULT_FDT_FILE="imx6q-udoo.dtb",DDR_MB=1024 Rename <board>.c file. Rename board/freescale/mx6sabresd/mx6sabresd.c   to   board/freescale/mx6_udoo/mx6_udoo.c Modify Makefile. Change the line of COBJS to your custom board at  board/freescale/mx6_udoo/:      obj-y  := mx6sabresd.o Create a Shell script. Create a script to compile your new configuration. The script for this example is shown below and its name is build_u-boot.sh: #!/bin/bash export ARCH=arm export CROSS_COMPILE=/opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi- make distclean; make mx6_udoo_config make Run the script to verify if the new configuration is correct.      $./build_u-boot.sh 4. CUSTOMIZING BOARD CODE      The fist part to customize is the DCD table. The DCD table contains configuration data for the DDR controller and memory. The DCD is read by the BootROM code in the iMX family and executed before copying the Uboot image to DDR. The DCD is built in the .cfg file pointed in the new entry we just added in the boards.cfg file (mx6dl_4x_mt41j128.cfg). Below you can find an example of the data that can be found in this file: /* * Device Configuration Data (DCD) * * Each entry must have the format: * Addr-type           Address        Value * * where: *      Addr-type register length (1,2 or 4 bytes) *      Address   absolute address of the register *      value     value to be stored in the register */ DATA 4, 0x020e0774, 0x000C0000 DATA 4, 0x020e0754, 0x00000000 DATA 4, 0x020e04ac, 0x00000030 DATA 4, 0x020e04b0, 0x00000030 DATA 4, 0x020e0464, 0x00000030 DATA 4, 0x020e0490, 0x00000030 DATA 4, 0x020e074c, 0x00000030 DATA 4, 0x020e0494, 0x00000030 DATA 4, 0x020e04a0, 0x00000000 The .cfg files used in this example were taken from an old U-Boot version (2009) non dtb capable. The used files are found in the attached .zip file. The specific initialization code for each board is found in mx6<customer board>.c in board/freescale/mx6<customer board>.c  in this case board/freescale/mx6_udoo/mx6_udoo.c file. Below it is explained the needed changes to route the serial console to the correct UART module, disable an external watchdog, configure and initialize the Ethernet PHY, change the lvds clock and configure the correct USDHC module.        U-Boot calls already defined functions from a function pointer array that takes care of the board initialization at different stages. For example the board_early_init_f() is called at an        early phase where we can disable the wdog and initialize the uart pins; board_init() and board_late_init() are called after board_early_init_f(). The UDOO board features an external watchdog that needs to be disabled with a GPIO, otherwise U-Boot resets after a few seconds:          The WDOG pins need to be configured and in the mx6_udoo.c file a global struct configuration for those pins is declared, as well as macros for each pin #define WDT_EN  IMX_GPIO_NR(5, 4) #define WDT_TRG IMX_GPIO_NR(3, 19) iomux_v3_cfg_t const wdog_pads[] = {         MX6_PAD_EIM_A24__GPIO5_IO04 | MUX_PAD_CTRL(NO_PAD_CTRL),         MX6_PAD_EIM_D19__GPIO3_IO19, }; static void setup_iomux_wdog(void) {         imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));         gpio_direction_output(WDT_TRG, 0);         gpio_direction_output(WDT_EN, 1);         gpio_direction_input(WDT_TRG); } This configuration needs to be called at some point of the board_early_init_f() int board_early_init_f(void) {         setup_iomux_wdog();         This way the board_early_init_f() calls the iomux for the external wdog and disables it. The UART console is routed to UART2, EIM_D26/UART2_TXD and EIM_D27/UART2_RXD. A different structure is defined with the pin configuration for the UART2.      iomux_v3_cfg_t const uart2_pads[] = {         MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),         MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), }; This configuration should be called at early stage too. static void setup_iomux_uart(void) {         imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); } int board_early_init_f(void) {         setup_iomux_wdog();         setup_iomux_uart(); Also the UART BASE register has to be defined as well as the console device. This is defined in the include/configs/mx6_udoo.h file. #define CONFIG_MXC_UART_BASE   UART2_BASE #define CONFIG_CONSOLE_DEV      "ttymxc1" The UDOO board features only one micro SD slot to boot and U-Boot environment storage. It uses only 4 bits and it has to be configured too. In the include/configs/mx6_udoo.h file the USDHC module has to be defined and the MMC environment device. #define CONFIG_SYS_FSL_USDHC_NUM   3 #define CONFIG_SYS_MMC_ENV_DEV       0     /* SDHC3 */          The USDHC3 pin configuration has to be defined:      iomux_v3_cfg_t const usdhc3_pads[] = {         MX6_PAD_SD3_CLK__SD3_CLK   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_CMD__SD3_CMD   | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT0__SD3_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),         MX6_PAD_NANDF_D0__GPIO2_IO00    | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ }; struct fsl_esdhc_cfg usdhc_cfg[1] = {         {USDHC3_BASE_ADDR, 0, 4}, }; This must be called and configured from the board_mmc_init() function: int board_mmc_init(bd_t *bis) {         s32 status = 0;         imx_iomux_v3_setup_multiple_pads(         usdhc3_pads, ARRAY_SIZE(usdhc3_pads));         usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);                 status |= fsl_esdhc_initialize(bis, &usdhc_cfg[0]);         return status; } The Ethernet PHY is configured in the board_eth_init() function. This function should initialize the pins for the external ethernet phy, mdio and phy configuration.  Just a piece of code is shown below: iomux_v3_cfg_t const enet_pads1[] = {         MX6_PAD_ENET_MDIO__ENET_MDIO            | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_MDC__ENET_MDC              | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TXC__RGMII_TXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD0__RGMII_TD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD1__RGMII_TD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD2__RGMII_TD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TD3__RGMII_TD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_ENET_REF_CLK__ENET_TX_CLK       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RXC__RGMII_RXC       | MUX_PAD_CTRL(ENET_PAD_CTRL),         /* RGMII reset */         MX6_PAD_EIM_D23__GPIO3_IO23              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* alimentazione ethernet*/         MX6_PAD_EIM_EB3__GPIO2_IO31              | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 32 - 1 - (MODE0) all */         MX6_PAD_RGMII_RD0__GPIO6_IO25            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 31 - 1 - (MODE1) all */         MX6_PAD_RGMII_RD1__GPIO6_IO27            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 28 - 1 - (MODE2) all */         MX6_PAD_RGMII_RD2__GPIO6_IO28            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 27 - 1 - (MODE3) all */         MX6_PAD_RGMII_RD3__GPIO6_IO29            | MUX_PAD_CTRL(NO_PAD_CTRL),         /* pin 33 - 1 - (CLK125_EN) 125Mhz clockout enabled */         MX6_PAD_RGMII_RX_CTL__GPIO6_IO24         | MUX_PAD_CTRL(NO_PAD_CTRL), }; static iomux_v3_cfg_t const enet_pads2[] = {         MX6_PAD_RGMII_RD0__RGMII_RD0       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD1__RGMII_RD1       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD2__RGMII_RD2       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RD3__RGMII_RD3       | MUX_PAD_CTRL(ENET_PAD_CTRL),         MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL      | MUX_PAD_CTRL(ENET_PAD_CTRL), }; static void setup_iomux_enet(void) {         imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));         udelay(20);         gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power on enet */         gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* assert PHY rst */         gpio_direction_output(IMX_GPIO_NR(6, 24), 1);         gpio_direction_output(IMX_GPIO_NR(6, 25), 1);         gpio_direction_output(IMX_GPIO_NR(6, 27), 1);         gpio_direction_output(IMX_GPIO_NR(6, 28), 1);         gpio_direction_output(IMX_GPIO_NR(6, 29), 1);         udelay(1000);         gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* deassert PHY rst */         /* Need delay 100ms to exit from reset. */         udelay(1000 * 100);         gpio_free(IMX_GPIO_NR(6, 24));         gpio_free(IMX_GPIO_NR(6, 25));         gpio_free(IMX_GPIO_NR(6, 27));         gpio_free(IMX_GPIO_NR(6, 28));         gpio_free(IMX_GPIO_NR(6, 29));         imx_iomux_v3_setup_multiple_pads(enet_pads2, ARRAY_SIZE(enet_pads2)); }           Let's notice that the external PHY is not the same as the SABRESD AR8031. The UDOO features the MICREL KSZ9031 PHY. The latter needs to be defined and the former undefined in the include/configs/mx6_udoo.h file. #undef  CONFIG_PHY_ATHEROS #define CONFIG_PHY_MICREL #define CONFIG_PHY_MICREL_KSZ9031 Besides the PHY address has to be changed. #define CONFIG_FEC_MXC_PHYADDR  6 At this point, the serial console, SD card saving arguments and ethernet should be working. The last point is to configure the LVDS display. The LVDS display of the UDOO board is connected in the same port as the SABRE-SD board, but the operation frequency is different and it has to be modified to work at ~ 33.26MHz for the 7 inches LVDS display.      The mx6_udoo.c file contains a setup_display function that configures the LDB module. This functions is called in the board_early_init_f(). With the current clock configuration is not possible to get  the 33.2MHz for the LVDS and a different clock source for the LDB module must be chosen. The backlight and lvds power signals must be on.           The current configuration uses the mmdc_ch1 clock and to get closer to 33.26MHz the PLL2_PFD0 is chosen.        gpio_direction_output(IMX_GPIO_NR(1, 2), 1); /* LVDS power On */         gpio_direction_output(IMX_GPIO_NR(1, 4), 1); /* LVDS backlight On */         imx_iomux_v3_setup_multiple_pads(di0_pads, ARRAY_SIZE(di0_pads));         enable_ipu_clock();         imx_setup_hdmi();         /* Turn on4LDB0, LDB1, IPU,IPU DI0 clocks */         reg = readl(&mxc_ccm->CCGR3);         reg |=  MXC_CCM_CCGR3_LDB_DI0_MASK | MXC_CCM_CCGR3_LDB_DI1_MASK;         writel(reg, &mxc_ccm->CCGR3);         /* set LDB0, LDB1 clk select to 011/011 */         reg = readl(&mxc_ccm->cs2cdr);         reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK                  | MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);         reg |= (1 << MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)               | (1 << MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);         writel(reg, &mxc_ccm->cs2cdr); With this changes you can compile the new U-Boot image with ./build_u-boot.sh and then just copy the uboot.imx file to your sd: # sudo cp if=uboot.imx of=/dev/sdX bs=512 seek= 2 && sync 5. TESTING YOUR CHANGES Inser the sd with the U-Boot image to micro sd slot and power up the board. You should get the U-Boot serial console like shown below. In the console you can test the ethernet and phy configuration with the PING command: I hope you find these basic steps useful for different boards.
記事全体を表示
Audio, from a file gst-launch filesrc location=test.wav ! wavparse ! mfw_mp3encoder ! filesink location=output.mp3 Audio Recording gst-launch alsasrc num-buffers=$NUMBER blocksize=$SIZE ! mfw_mp3encoder ! filesink location=output.mp3 # where #     duration = $NUMBER*$SIZE*8 / (samplerate *channel *bitwidth) # Example: 60 seconds recording # gst-launch alsasrc num-buffers=240 blocksize=44100 ! mfw_mp3encoder ! filesink location=output.mp3 # # To verify that is correct, do a normal audio playback gst-launch filesrc location=output.mp3 typefind=true ! beepdec ! audioconvert ! 'audio/x-raw-int,channels=2' ! alsasink Video, from a test source gst-launch videotestsrc ! queue ! vpuenc ! matroskamux ! filesink location=./test.avi Video, from a file gst-launch filesrc location=sample.yuv blocksize=$BLOCK_SIZE ! 'video/x-raw-yuv,format=(fourcc)I420, width=$WIDTH, height=$HEIGHT, framerate=(fraction)30/1' ! vpuenc codec=$CODEC ! matroskamux ! filesink location=output.mkv sync=false # where #     BLOCK_SIZE = WIDTH * HEIGHT * 1.5 #     CODEC = 0(MPEG4), 5(H263), 6(H264) or 12(MJPG). # # For example, encoding a CIF raw file gst-launch filesrc location=sample.yuv blocksize=152064 ! 'video/x-raw-yuv,format=(fourcc)I420, width=352, height=288, framerate=(fraction)30/1' ! vpuenc codec=0 ! matroskamux ! filesink location=sample.mkv sync=false Video, from Web camera # when the web cam is connected, the device node /dev/video0 should be present. In order to test the camera, without encoding gst-launch v4l2src ! mfw_v4lsink # in recording, run: # gst-launch v4l2src num-buffers=-1 ! queue max-size-buffers=2 ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false # # where sync=false indicates filesink to to use a clock sync # # In case a specific width/height is needed, just add the filter caps gst-launch v4l2src num-buffers=-1  ! 'video/x-raw-yuv,format=(fourcc)I420, width=352, height=288, framerate=(fraction)30/1' ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false # # In case you want to see in the screen what the camera is capturing, add a tee element # gst-launch v4l2src num-buffers=-1 ! tee name=t ! queue ! mfw_v4lsink t. ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false Video, from Parallel/MIPI camera # The camera driver needs to be loaded before executing the pipeline, refer to the BSP document to see which driver to load # MIPI (J5 port): modprobe ov5640_camera_mipi modprobe mxc_v4l2_capture   # Parallel (J9 port): modprobe ov5642_camera modprobe mxc_v4l2_capture   gst-launch mfw_v4lsrc ! queue ! vpuenc codec=0 ! matroskamux ! filesink location=output.mkv sync=false   # Do a 'gst-inspect mfw_v4lsrc' or 'gst-inspect vpuenc' to see other possible settings (resolution, fps, codec, etc.)
記事全体を表示
This is a simple step by step guide on how to change the Android boot animation which is shown when the system is loading.   Requirements   - Android L5.1.1_2.1.0 BSP. The basics of the boot animation may also apply to older and upcoming releases but L5.1.1_2.1.0 BSP was used for this document. File names, settings or paths may be changed in older or newer releases.   - i.MX6Q Sabre SD Board or any other i.MX board supported by the BSP release, for testing.   - 7-Zip. This is a free compression tool and has the necessary settings for preparing the boot animation file. It is important that the boot animation file is in Zip format with no compression, otherwise the file won’t be read and the animation will not be shown. Zip tools integrated on some Operating Systems may not always allow for these configurations. You may download this utility from the link below: http://www.7-zip.org/   - Android adb tool. This tool is part of the Android SDK. You may download the SDK as part of Android Studio or the SDK as Stand Alone on the following link. Only the adb is required to follow up this document. http://developer.android.com/sdk/installing/index.html   Understanding the boot animation format.   The animations used by Android when booting are actually a series of images in either jpg or png format in a zip file with no compression (storage mode) and a text file (desc.txt) with the specified resolution, framerate and loops to be played by the animation. Each folder containing a part of the animation must contain the images numbered from 000 onwards.  This file is always called bootanimation.zip An example of a boot animarion can be found attached to this document.   The contents of the desc.txt file on the attached example are as follow: 480 292 30 p 1 0 part0 p 0 0 part1 (please note that there should be an empty line at the end of the document).   Line 1: Screen resolution followed by FPS (Frames per Second) of the animation.   Lines 3-5: The p serves to describe that the line contains a part of the animation; followed by the number of times the section of the animation will play (with zero being an infinite loop); followed by a delay in frames before moving to the next line. Finally, the folder containing the files of that specific part of the animation (this is why most animations use “part” for the folder name).   Line 6: A blank line. This is important as without it the animation may not run as it will consider the description file incomplete. There are some animations available around the web as well as some free tools or apps that allow you to create your own animations. You may find an example animation attached to this document which you may use as reference.   It is important that no other files are included on the bootanimation.zip file. This includes the thumbnails created automatically by Windows. Please delete them from your fule before loading it to the board.   Please note that the animation may be repeated in a loop if it’s shorter than the actual time it takes for the system to load. However, the animation will play complete regardless of the loading time so very long boot animations may give the appearance of a longer booting time.   The location of the boot animation file is given on the bootanimation_main.cpp file, which is located on the following path: <MYANDROID_DIR>/frameworks/base/cmds/bootanimation/bootanimation_main.cpp   There are two definitions that give the file location. We’re focusing on the default image for this document (unencrypted). #define SYSTEM_BOOTANIMATION_FILE "/system/media/bootanimation.zip" #define SYSTEM_ENCRYPTED_BOOTANIMATION_FILE "/system/media/bootanimation-encrypted.zip"   Note: These definitions may be different from those in third party BSPs. It is common to find BSPs using the "/data/local/” folder as USER_BOOTANIMATION. This is not supported by default on NXP’s BSP.   Loading the new boot animation file.   - Building a User Debug image Android protects certain folders to avoid tampering, so in order to change the boot animation we will use adb in order to access the file system. However, it is necessary to use a image with root access so we will be using a user debug image.   In order to compile as user debug use the following lunch command after following the instructions in the Android User's Guide: $ lunch sabresd_6dq-userdebug   After configuring the build for user debug you can then build using make. (This process may take several hours)   - Enabling USB Debug mode Your board should be running android and then be connected to the computer using the USB OTG port. In order for adb to work you have to enable USB debugging by opening Settings and scrolling down to the “About” option clicking the "About" option 7 times.   - Using adb to load the new boot animation We’ll connect to the SABRE board using the Android SDK for Windows adb tool available at the path below: android-sdk-windows\platform-tools   Open a command promt in windows and go to the adb path. Then start the adb server with the following command: $ adb start-server   This will initialize the adb daemon. In order to connect to the device permission must be granted. A pop up will appear asking whether to trust or not the computer host. Since we will be changing the system partition we must initialize adb as root: $ adb root   This will restart the adb daemon in root mode. You will need to grant access from your device. You may see the list of connected with: $ adb devices   If you wish to see the contents of the filesystem you may enter the shell with the following command: $ adb shell   However, we will be using the pull/push commands from adb in order to change the bootanimation.   If you wish to download the current bootanimation for backup you may do so with the following command: $ adb pull /system/media/bootanimation.zip C:\ This will download the bootanimation.zip file to C:   Since the system partition is read only you will need to remount with the adb prior to pushing the replacing boot animarion $ adb remount $ adb root push C:\BootAni\bootanimation.zip /system/media   After this you may reboot your board and you should see the new boot animation. Original Attachment has been moved to: bootanimation.zip
記事全体を表示