i.MX Processors Knowledge Base

Discussions

Question: 1) Is WDOG2 somehow accessible from customers code in normal mode? Is it only used within the trust zone to protect against DOS attacks from normal world?) 2) Is there any mechanism preventing changing of the watchdog registers like being able to write them only during a period after Reset? If yes, which registers are protected? Answer: WDOG1 and WDOG2 are identical the only difference is how the signals are connected. There is nothing presenting someone from using both WDOGs for non-secure purposes. There is no time window for WDOG access but there are some write-once only bits in the register, which can be written only once after reset, after that all following writes will be ignored. They are clearly described in the RM. The bits are: WDZST, WDBG, WDW, WDE, WDT, WIE, WICT, and PDE.

What is HOB? Hob is a graphical user interface for BitBake. Its primary goal is to enable a user to perform common tasks more easily. It basically runs the Bitbake commands on the background while showing a Graphic User Interface. Hob may not work correctly with Daisy metadata as it is getting deprecated in favor of a new web based interface for Yocto under the name Toaster. Here is what you can do with the current version of Hob on the Freescale Community BSP and BSP Release. - Build images - Edit existing image recipes - Create your own image recipes Note: HOB will write the local.conf file and make modifications which may conflict with baking images outside of HOB. In this case you may need to re-run the environment initialization in order to restore the local.conf file. Starting HOB Once the environment has been initialized (using the setup-environment script on the Freescale Community BSP or the fsl-setup-release on the Freescale BSP Release) use the command below. $ hob & The GUI should then appear: You may then select the MACHINE for which you will build and the Layers of your project. HOB will take and updated the local.conf and bblayers.conf values so the desired BSP layers will already be selected and available MACHINES on these layers will appear on the drop down menu. Once these options are set HOB will parse the recipes and create a dependency tree in order to show available images for that MACHINE. Image File System Types Advance configuration options include image file system types. Please note that HOB does not support the sdcard format so if it is needed it has to be added manually on the local.conf file and then run bitbake outside of HOB. As HOB changed the local.conf file even if the sdcard format was originally available it may be rewrite and no longer available until the following line is added to local.conf. IMAGE_FSTYPES="tar.bz2 ext3 sdcard" Recipes screen On the recipes screen we can see the recipes included on the image and available recipes, then also package groups. Time to bake! After these configurations you may either build the packages using HOB interface or run Bitbake outside of HOB. (In case you wish to have your image on the sdcard format please see the earlier image types clarification) The resulting image will be stored on <BUILD>/tmp/deploy/images/<MACHINE> You may also save your image recipe with the selected customizations.

Network File System (NFS) Setting the Host 1 - Install NFS Service on host typing: $sudo apt-get install nfs-kernel-server 2 - Create symbolic link to ltib/rootfs $sudo ln -s <ltib instalation folder>/rootfs /tftpboot/rootfs 3 - Setup exports typing: $sudo gedit /etc/exports and add the following line: /tftpboot/rootfs/ *(rw,no_root_squash,no_subtree_check,async) 4 - Restart the NFS server: $sudo /etc/init.d/nfs-kernel-server restart Now the host is ready to use NFS. Setting Target Linux Image to use NFS 1 - Run LTIB configuration typing: $cd <ltib instalation folder> $./ltib -c 2 - On first page menu, go to "Target Image Generation -> Options" as in the picture below. 3 - Select the option NFS only and exit LTIB configuration to compile with the new configuration. 4 - LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/zImage 5 - Copy the created image on /<ltib instalation folder>/rootfs/boot/zImage to /tftpboot/zImage 6 - The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/

Linphone is an internet phone or Voice Over IP phone (VoIP). With Linphone you can communicate freely with people over the internet, with voice, video, and text instant messaging. Linphone makes use of the SIP protocol, an open standard for internet telephony. You can use Linphone with any SIP VoIP operator, including our free SIP audio/video service. Linphone is free software (or open-source), you can download and redistribute it freely. Linphone is available for desktop computers: Linux, Windows, Mac OSX, and for mobile phones: Android, iPhone, Blackberry. Linphone-android is a good example to show the integration of Java code based on Android SDK with native CODEC, network protocols. Not like XBMC-Android that is almost total c++/c project. Perform the following steps to build a linphone-android project: 1. git clone git://git.linphone.org/linphone-android.git --recursive 2. sudo apt-get install autoconf automake libtool pkg-config 3. "cd" to the root of "git clone" : cd /home/user/linphne-android // wherver git'ed linphone-android is 4. export PATH=/home/user/android-ndk:$PATH //wherever your android-ndk, android-sdk tools, and platform-tools, and ANT are stored in. For example on my PC. export PATH=/home/alanz/android-ndk-r8d:/home/alanz/android-sdk-linux/tools:/home/alanz/android-sdk-linux/platform- tools:/home/alanz/bin/apache-ant-1.8.4/bin:$PATH Note: PATH contains the ndk, sdk, and ant. 5. Make sure the network is working, then execute "./prepare_sources.sh" at the linphone-android root 6. Then, execute "/home/alanz/android-ndk-r8d/ndk-build", it will take a while to be finished 7. Modify Makefile as following example, modify it accordingly. NDK_PATH=/home/alanz/android-ndk-r8d SDK_PATH=/home/alanz/android-sdk-linux/tools SDK_PLATFORM_TOOLS_PATH=/home/alanz/android-sdk-linux/platform-tools ..................... generate-libs: $(NDK_PATH)/ndk-build ....... (remove -j$(NUMCPUS) by the end of this command line) 8. execute "make", after finish, the apk file can be found under bin/ subdirectory.

Platform: imx8qm mek imx-yocto-L4.14.98_2.0.0_ga Building Step: Apply the nvp6324 patches. Symbol: IMX8_NVP6324 [=y] Type : tristate Prompt: IMX8 NVP6324 Driver Location: -> Device Drivers -> Multimedia support (MEDIA_SUPPORT [=y]) -> V4L platform devices (V4L_PLATFORM_DRIVERS [=y]) -> MX8 Video For Linux Video Capture (VIDEO_MX8_CAPTURE [=y]) (1) -> IMX8 Camera ISI/MIPI Features support ‍‍‍‍‍‍‍‍‍ select nvp6324 to y in menuconfig(default is 'y') make Image -j8; make freescale/fsl-imx8qm-mek-nvp6324.dtb, to build kernel and dts, outputs are at work/imx8qmmek-poky-linux/linux-imx/4.14.98-r0/build/arch/arm64/Image work/imx8qmmek-poky-linux/linux-imx/4.14.98-r0/build/arch/arm64/boot/dts/freescale/fsl-imx8qm-mek-nvp6324.dtb copy them to the sd boot partition. reboot the board, you can test the first camera with command: ./mx8_v4l2_cap_drm.out -cam 1 -ow 1280 -oh 720 mx8_v4l2_cap_drm.out is at /unit_tests/V4L2/mx8_v4l2_cap_drm.out The corresponding video device should be default to /dev/video0 ~ /dev/video3.

iMX6DQ TP2854 MIPI CSI2 720P HD-TVI camera surround view solution for Linux BSP. For iMX6DQ, there are two IPUs, so they can support up to 4 cameras at the same time. But the default BSP can only support up to two cameras at the same time. The attached patch can make the BSP support up to 4 cameras based on 3.14.52 GA 1.1.0 BSP and 4.1.15 GA1.2.0 BSP. The 4 cameras can be: - 1xCSI, 3xMIPI - 2xCSI, 2xMIPI - 4xMIPI For 4xMIPI case, the four cameras should be combined on the single MIPI CSI2 interface, and each camera data should be transfered on a mipi virtual channel. In this patch, we given the example driver for Techpoint TP2854, it was verified working on iMX6DQ SabreAuto board. The input to TP2854 is four 720P30 HD-TVI cameras. The MIPI CSI2 720P digital camera surround view solution can be found at: iMX6DQ MAX9286 MIPI CSI2 720P camera surround view solution for Linux BSP The kernel patches: 0001-IPU-update-IPU-capture-driver-to-support-up-to-four-.patch Updated IPU common code to support up to four cameras. 0002-Remove-the-page-size-align-requirement-for-v4l2-capt.patch With this patch, the mxc_v4l2_tvin test application can use overlay framebuffer as V4l2 capture buffer directly. 0003-Add-TP2854-support-on-SabreAuto-board-which-can-supp.patch TP2854 driver. How to builld the kernel with TP2854 support: make imx_v7_defconfig make menuconfig (In this command, you should select the TP2854 driver: Device Drivers ---> <*> Multimedia support ---> [*] V4L platform devices ---> <*> MXC Video For Linux Video Capture MXC Camera/V4L2 PRP Features support ---> <*>Techpoint tp2854 HD CVBS Input support <*>mxc VADC support <*>Select Overlay Rounting (Queue ipu device for overlay library) <*>Pre-processor Encoder library <*>IPU CSI Encoder library) make zImage make dtbs The built out image file: arch/arm/boot/dts/imx6q-sabreauto.dtb arch/arm/boot/zImage "mxc_v4l2_tvin_3.14.52.zip" is the test application, test command to capture the four cameras and render on 1080P HDMI display: /mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 960 -oh 540 -d 1 -x 0 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 0 -ow 960 -oh 540 -d 1 -x 1 -g2d & /mxc_v4l2_tvin.out -ol 0 -ot 540 -ow 960 -oh 540 -d 1 -x 2 -g2d & /mxc_v4l2_tvin.out -ol 960 -ot 540 -ow 960 -oh 540 -d 1 -x 3 -g2d & Details for TP2854, please contact with Techpoint. [2019-04-04] Update Add application to preview + encode at the same time: /mxc_vpu_test.out -E "-x 0 -o /enc.h264 -w 1280 -h 720 -L 0 -T 0 -W 512 -H 384 -c 5000 -f 2" The camera input data go through CSI->MEM path, and IDMAC 0/1 will convert data from YUV422 ro NV12 for VPU encoder, no resize. Another modification in the mxc_vpu_test, it use different thread to encode and preview.

According to section 13.5 (Cortex-M4 Boot Requirements) of the i.MX6SX Reference Manual : • Cortex-A9 always boots as the primary core. • Cortex-M4 does not have a boot ROM and at POR is not provided a clock. • Cortex-A9 ROM is responsible for the following: • Loading and authenticating A9 bootloader and initiating Cortex-M4 firmware as a unified image. • Setting up Cortex-M4 initial exception table in TCRAML • Launching the Cortex-M4 by enabling its clock. In addition : M4 obtains minimal initial vector table, containing a) Initial Stack pointer b) Reset vector c) NMI vector from a fixed location (zero offset) in TCM(L) after A9 enables it’s clock. So, A9 (bootloader) is responsible for: Configuring M4 initial vector table in TCM(L) ; Loading M4 code ; Configuring CSU and RDC for TrustZone (if needed) and A9/M4 domain separation ; Enabling M4 clock. Please look at the enclosed projects, which help to understand how to build, load and run startup codes for both Cortex-A9 and Cortex-M4 cores of i.MX6 SoloX. Also note : the i.MX6 SoloX has two cores with different address mapping. Please refer to Table 2-1 (System memory map) for Cortex-A9 core and to Table 2-2 (CM4 memory map) for Cortex-M4 of the i.MX6 SoloX Reference Manual. To run Cortex-M4 it is needed to fill TCM(L), that is addressed as TCML ALIAS (from zero). The same memory is mapped to 0x007f8000 of the Cortex-A9 (non-reflected in the Table 2-1). Note, this area is accessible by the Cortex-A9 after M4 clock is enabled in CCM_CCGR3. The following resources may be helpful, when working with i.MX6 SoloX : “How to configure Real View ICE and RealView debugger to work with i.MX6 SoloX” https://community.freescale.com/docs/DOC-106198 “Integrating Processor Expert for i.MX and ARM GCC with Eclipse” https://community.freescale.com/docs/DOC-103736 “I.MX6SX start M4 from U-Boot with QSPI flash” https://community.freescale.com/message/499465 "Loading Code on Cortex-M4 from Linux for the i.MX 6SoloX and i.MX 7Dual/7Solo " http://cache.nxp.com/files/soft_dev_tools/doc/app_note/AN5317.pdf

Here is a quick summary at booting u-boot on the i.MX 6 sabre sd platform. This assumes you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get u-boot sources We will use git to fetch the U-Boot sources: $ git clone git://git.denx.de/u-boot.git This should create a u-boot directory with all the latest sources. Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v2*', and git checkout <the-desired-tag>. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing: $ cd u-boot $ export CROSS_COMPILE=arm-linux-gnueabihf- $ make mx6qsabresd_config $ make This should create a number of files, including u-boot.imx. Put on SD U-boot should reside at offset 1024B of your SD card. To put it there, do: $ dd if=u-boot.imx of=/dev/<your-sd-card> bs=1k seek=1 $ sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. 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, power up the platform and you should see something like: U-Boot 2013.07-rc1-00014-g74771f4 (Jun 20 2013 - 19:05:09) CPU: Freescale i.MX6Q rev1.2 at 792 MHz Reset cause: POR Board: MX6Q-SabreSD DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FEC [PRIME] Warning: FEC using MAC address from net device Hit any key to stop autoboot: 0 Enjoy! See also... u-boot most common mission is to boot the Linux kernel. See this post for details on how to do it. If you plan to compile u-boot often, you might want to use a C compiler cache; see this post. Running a Script in U-boot u-boot on the Vybrid tower board in a few commands

Tested on Android 10 (android_Q10.0.0_1.0.0) After your the first BSP build the kernel sources are at: ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/ For the i.MX8M Mini, You can check the defconfig files being used on: ${MY_ANDROID}/device/fsl/imx8m/evk_8mm/UbootKernelBoardConfig.mk # imx8mm kernel defconfig TARGET_KERNEL_DEFCONFIG := android_defconfig TARGET_KERNEL_ADDITION_DEFCONF := android_addition_defconfig You could change one of them to add the desired configuration. - android_defconfig - is ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/android_defconfig - android_addition_defconfig - is on the same folder ${MY_ANDROID}/device/fsl/imx8m/evk_8mm/ "merge_config.sh" is called to generate the final defconfig file prior to building the kernel Check out: https://source.android.com/devices/architecture/kernel/config For example, I want to add DEVMEM support on my build: 1. Change the defconfig I add the line below to android_addition_defconfig CONFIG_DEVMEM=y (Or could have added it android_defconfig) 2. Build the kernel ./imx-make.sh kernel -c -j8 3. Verify your change After compiling, you can confirm your change by reading: ${MY_ANDROID}/out/target/product/evk_8mm/obj/KERNEL_OBJ/.config Then rebuild boot.img and reprogram the target.

The Yocto Project is open-source, so anyone can contribute. No matter what your contribution is (bug fixing or new metadata), contributions are sent through patches to a community list. Many eyes will look into your patch and at some point it is either rejected or accepted. Follow these steps to contribute: Make sure you have previously configured your personal info $ git config --global user.name "Your Name Here" $ git config --global user.email "[email protected]" Subscribed to the Freescale Yocto Project Mailing List Download `master` branches fsl-community-bsp $ repo init \ -u https://github.com/Freescale/fsl-community-bsp-platform \ -b master Update fsl-community-bsp $ repo sync Create local branches so your work is *not* done on master fsl-community-bsp $ repo start <branch name> --all Where `<branch name>` is any name you want to give to your local branch (e.g. `fix_uboot_recipe`, `new_gstreamer_recipe`, etc.) Make your changes in any Freescale related folder (e.g. sources/meta-fsl-arm). In case you modified a recipe (.bb) or include (.inc) file, do not forget to *bump* (increase the value by one) either the `PR` or `INC_PR` value Commit your changes using `git`. In this example we assume your change is on `meta-fsl-arm` folder sources/meta-fsl-arm $ git add <file 1> <file 2> sources/meta-fsl-arm $ git commit On the commit's log, the title must start with the filename change or introduced, then a brief description of the patch's goal, following with a long description. Make sure you follow the standards (type ` git log --pretty=oneline` to see previous commits) Create a patch sources/meta-fsl-arm $ git format-patch -s --subject-prefix='<meta-fsl-arm][PATCH' -1 Where the last parameter (`-1`) indicate to patch last commit. In case you want to create patches for older commits, just indicate the correct index. If your patch is done in other folder, just make sure you change the `--subject-prefix` value. Send your patch or patches with git send-email --to [email protected] <patch> where `<patch>` is the file created by `git format-patch`. Keep track of patch's responses on the mailing list. In case you need to rework your patch, repeat the steps but this time the patch's subject changes to `--subject-prefix='<meta-fsl-*][PATCH v2'` Once your patch has been approved, you can delete your working branches fsl-community-bsp $ repo abandon <branch name>

This is an example to show how to connect two cameras (with same I2C address) on the i.MX6Q board. In this example, the I2C switch is PCA9543A. Two cameras are OV5640 & OV5645. OV5640 is connected to CSI0, and other one OV5645 is connected to MIPI. The Linux BSP is L3.0.35. In the your_board.c file, add the following for pca954x. static struct pca954x_platform_mode pca954x_modes[] = { { .adap_id = 4, .deselect_on_exit = true, }, { .adap_id = 5, .deselect_on_exit = true, }, }; static struct pca954x_platform_data pca954x_data = { .modes = pca954x_modes, .num_modes = ARRAY_SIZE(pca954x_modes) }; In this example, the I2C switch is connected to i.MX6Q’s I2C0. The I2C address of the PCA9543A is 0x70. static struct i2c_board_info mxc_i2c0_board_info[] __initdata = { { I2C_BOARD_INFO("pca9543", 0x70), .platform_data = (void *)&pca954x_data, }, }; The channel 0 of PCA9543A is connected to the I2C of OV5645 MIPI. static struct i2c_board_info mux_i2c4_board_info[] __initdata = { { I2C_BOARD_INFO("ov5645_mipi", 0x3c), .platform_data = (void *)&mipi_csi2_data, }, }; The channel 1 of PCA9543A is connected to the I2C of OV5640 CSI0. static struct i2c_board_info mux_i2c5_board_info[] __initdata = { { I2C_BOARD_INFO("ov5640", 0x3c), .platform_data = (void *)&csi0_camera_data, }, }; In the board_init function, register the I2C4 and I2C5. i2c_register_board_info(4, mux_i2c4_board_info, ARRAY_SIZE(mux_i2c4_board_info)); i2c_register_board_info(5, mux_i2c5_board_info, ARRAY_SIZE(mux_i2c5_board_info)); Select the PCA954x driver In kernel configuration In Kernel Configuration, go to Device Drivers --> I2C support --> I2C bus multiplexing support --> Multiplexer I2C Chip support --> Select <*> Philips PCA954x I2C Mux/switches

Booting from NAND Some hardware configurations (switches) must be set for booting from NAND: On the debug board: Switch SW4 -> 10000001 Switch SW5 -> Off Switch SW6 -> Off Switch SW7 -> Off Switch SW8 -> Off Switch SW9 -> Off Switch SW10 -> Off On the personality board: Switch SW21 -> 10011000 Switch SW22 -> 00100000 Booting from SD Card Some hardware configurations (switches) must be set for booting from an SD card: On the debug board: Switch SW4 -> 10000001 Switch SW5 -> Off Switch SW6 -> Off Switch SW7 -> Off Switch SW8 -> Off Switch SW9 -> Off Switch SW10 -> Off On the personality board: Switch SW21 -> 11000000 Switch SW22 -> 00000000

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

EVK Rev C上的i.MX 8M-Mini QSPI启动

MX6X_eMMC_turning_2014.11.11_V2.doc

i.MX6 DL/S L3.035_3.0.4 patch release

MX28 battery charging current limit when boot from battery

Q&A: Watchdogs in i.MX6

HOB Quick Start Guide

iMX5 Android Gingerbread Memory Usage and Optimization

All Boards NFS on Ubuntu

ubuntu-freescale-pkgs.tar

Build Linphone Android for i.MX6

Nvp6324 driver for imx8qm.

iMX6DQ TP2854 MIPI CSI2 720P HD-TVI camera surround view solution for Linux BSP

xab

MX6 SoloX bare metal startup

适用于 i.MX Linux 4.14.y 的 eIQ 机器学习软件

u-boot on the i.MX6 sabre sd platform in a few commands

How to change kernel configuration on Android build

i.MX Yocto Project: How can I contribute to the community?

Using I2C switch to connect two cameras

i.MX25 PDK Board Running Linux