Here is a quick summary at building a bootloader, a kernel and a root filesystem for the i.MX 6 sabre sd platform, using buildroot. This assumes you have a "working" Linux development environment at hand (e.g. Debian). Buildroot is a fine build system, which makes deploying Linux on embedded platforms really easy. It is comparable to Yocto in spirit, but much simpler. Thanks to my colleague gillestalis, buildroot now has builtin support for the i.MX6 sabre sd platform. Get buildroot sources We will use git to fetch buildroot sources: $ git clone git://git.busybox.net/buildroot This should create a buildroot directory with all the latest sources (after a while). 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 '201*', and git checkout <the-desired-tag>. Compile The beauty of buildroot is that it will take care of everything for you, including preparing a cross compiler. You can download and build everything by doing: $ cd buildroot $ make freescale_imx6sabresd_defconfig $ make This should download and build everything, so it will take a while. buildroot detects the number of CPUs you have in your machine and builds with parallel jobs automatically; no need to specify any -j argument to make here. All build results fall under the output/images folder: output/images/ +- rootfs.ext2 +- rootfs.tar +- u-boot.bin `- uImage Format the SD card As for Debian, we need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel, and one large ext4 partition, which will contain the root filesystem with the buildroot generated 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 the FAT boot partition with: # mkfs.vfat /dev/<your-sd-card-first-partition> Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. You can format the Linux partition with: # mkfs.ext4 /dev/<your-sd-card-second-partition> Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Put on SD As explained here, u-boot should reside at offset 1024B of your SD card. Also, as buildroot generates an u-boot.bin (and not an u-boot.imx) we should skip its first KB, too. In summary, to put u-boot on your SD, do:   # dd if=output/images/u-boot.bin of=/dev/<your-sd-card> bs=1k seek=1 skip=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. Similarly to what this post describes, you can copy the kernel to the FAT boot partition with: # mount /dev/<your-sd-card-second-partition> /mnt # cp output/images/uImage /mnt/ # umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. And not unlike what is done in this post, You can install your generated root filesystem to the Linux partition with: # mount /dev/<your-sd-card-second-partition> /mnt # tar -C /mnt -xvf output/images/rootfs.tar # umount /mnt Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. 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. Like with Debian, u-boot default settings will not allow it to boot from the SD card, so we need to interrupt it by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this: MX6Q SABRESD U-Boot > setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk1p2 rootwait' MX6Q SABRESD U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc dev 2; fatload mmc 2:1 ${loadaddr} ${kernel}; bootm' MX6Q SABRESD U-Boot > setenv bootcmd 'run bootcmd_mmc' MX6Q SABRESD U-Boot > saveenv Saving Environment to MMC... Writing to MMC(2)... 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 buildroot system should boot to a prompt: (...) Welcome to Buildroot buildroot login: From there you may login as root. Enjoy! Tweak buildroot uses Linux kernel kconfig to handle its configuration. So, as for the Linux kernel, changes to the configuration can be done with e.g.: $ make menuconfig Most of the options can be tuned from there, including (most importantly) which packages get installed into the generated root filesystem. This is configuration section 'Filesystem images'. Further details are documented in buildroot manual. Tips ccache is natively supported by buildroot and can be easily enabled with configuration option BR2_CCACHE. If you only use the generated rootfs.tar as described in this post and do not care about the rootfs.ext2, you might as well save a few seconds of build by disabling its generation. This is done with configuration option BR2_TARGET_ROOTFS_EXT2. It is recommended to install an ssh server inside the target for further development. This is conveniently done with configuration option BR2_PACKAGE_OPENSSH. See also... Other root filesystems may make more sense for you; see this post for a Debian root filesystem, and this post for a minimal busybox filesystem. Freescale Yocto Project main page

Recently, I was asked about software/hardware floating point support on i.MX6. There are some great articles on the freescale community already but lacks of introduction. This document shares some basic knowledge on it. VFP is ARM's "Vector Floating Point" unit. SIMD operations can be better performed on several FPU extensions provided by ARM (NEON as in Cortex-A8 and Cortex-A9) [1]. To test if hardware floating support on freescale's toolchain, I used a simple application below: $ cat haha.c #include <stdio.h>; int main() {         float a = 0.3f, b=1.2f;         printf("%f\n", a * b);         return 0; } Compile it as below, and got the hardware floating point enabled. $ arm-linux-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -o haha haha.c This can be checked by readelf. If Tag_ABI_VFP_args[2] shows VFP, it is hard floating. Otherwise, soft floating. $ arm-linux-readelf -A haha Attribute Section: aeabi File Attributes   Tag_CPU_name: "7-A"   Tag_CPU_arch: v7   Tag_CPU_arch_profile: Application   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-2   Tag_FP_arch: VFPv3   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align_needed: 8-byte   Tag_ABI_align_preserved: 8-byte, except leaf SP   Tag_ABI_enum_size: int   Tag_ABI_HardFP_use: SP and DP   Tag_ABI_VFP_args: VFP registers   Tag_DIV_use: Not allowed Compared to the one by not specifying floating, compiler use soft floating by default, $ arm-linux-gcc -o haha_soft haha.c And readelf won't have Tag_ABI_VFP_args. $ arm-linux-readelf -A haha_soft Attribute Section: aeabi File Attributes   Tag_CPU_name: "ARM10TDMI"   Tag_CPU_arch: v5T   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-1   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align8_needed: Yes   Tag_ABI_align8_preserved: Yes, except leaf SP   Tag_ABI_enum_size: int   Tag_unknown_44: 1 (0x1) [1]: https://wiki.debian.org/ArmHardFloatPort/VfpComparison [2]: For more detail on the Tag expression, check http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045d/IHI0045D_ABI_addenda.pdf

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.

Guide for Accessing GPIO From UserSpace Summary for Simple GPIO Example - quandry https://community.freescale.com/message/598834#598834

KSZ9031 is a very common PHY used with many ethernet design. This document will show you how to add it in u-boot and kernel. 1. Schematic The MODE[3:0] strap-in pins are sampled and latched at power-up/reset. MODE[3:0]=1111 is RGMII mode - Advertise all capabilities (10/100/1000 speed half-/full-duplex) The PHY address, PHYAD[2:0], is sampled and latched at power-up/reset. Here PHY address is set to 001. In this design example, the ENET_RESET_B is connected to GPIO pin GPIO1_IO03. 2. Source code modification In u-boot source code, add the following code in the <board_name>.c file. - IOMUX setup for the GPIO1_IO03 pin. static iomux_v3_cfg_t const phy_reset_pads[] = {      MX7D_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(NO_PAD_CTRL), }; - In the function setup_fec(int fec_id), add the code for phy reset. imx_iomux_v3_setup_multiple_pads(phy_reset_pads, ARRAY_SIZE(phy_reset_pads)); gpio_request(IMX_GPIO_NR(1, 3), "ENET PHY Reset"); gpio_direction_output(IMX_GPIO_NR(1, 3) , 0); mdelay(20); gpio_set_value(IMX_GPIO_NR(1, 3), 1); - There is a PHY config for the KSZ9031. int board_phy_config(struct phy_device *phydev) {    /*      * Default setting for GMII Clock Pad Skew Register 0x1EF:      * MMD Address 0x2h, Register 0x8h      *      * GTX_CLK Pad Skew 0xF -> 0.9 nsec skew      * RX_CLK Pad Skew 0xF -> 0.9 nsec skew      *      * Adjustment -> write 0x3FF:      * GTX_CLK Pad Skew 0x1F -> 1.8 nsec skew      * RX_CLK Pad Skew 0x1F -> 1.8 nsec skew      *      */     /* control data pad skew - devaddr = 0x02, register = 0x04 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);     /* rx data pad skew - devaddr = 0x02, register = 0x05 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);     /* tx data pad skew - devaddr = 0x02, register = 0x05 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);     /* gtx and rx clock pad skew - devaddr = 0x02, register = 0x08 */     ksz9031_phy_extended_write(phydev, 0x02,                    MII_KSZ9031_EXT_RGMII_CLOCK_SKEW,                    MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x03FF);     if (phydev->drv->config)         phydev->drv->config(phydev);     return 0; } The KSZ9031 driver (drivers/net/phy/micrel.c) had already supported in the u-boot source code. Add the following #define in the <board_name>.h file to enable the driver for building. #define CONFIG_PHY_MICREL As the PHY address on the board is 001, change the PHYADDR to 1 in the <board_name>.h file. #define CONFIG_FEC_MXC_PHYADDR          0x1 In the kernel source code, add/modify the PHY setting in dts file like this. &fec1 {     pinctrl-names = "default";     pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet_reset>;     assigned-clocks = <&clks IMX7D_ENET_PHY_REF_ROOT_SRC>,               <&clks IMX7D_ENET_AXI_ROOT_SRC>,               <&clks IMX7D_ENET1_TIME_ROOT_SRC>,               <&clks IMX7D_ENET1_TIME_ROOT_CLK>,               <&clks IMX7D_ENET_AXI_ROOT_CLK>;     assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_25M_CLK>,                  <&clks IMX7D_PLL_ENET_MAIN_250M_CLK>,                  <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;     assigned-clock-rates = <0>, <0>, <0>, <100000000>, <250000000>;     phy-mode = "rgmii";     phy-handle = <&ethphy0>;     phy-reset-gpios = <&gpio1 3 0>;     fsl,magic-packet;     status = "okay";     mdio {         #address-cells = <1>;         #size-cells = <0>;         ethphy0: ethernet-phy@1 {    //here '@1' is the PHY address             compatible = "ethernet-phy-ieee802.3-c22";             reg = <1>;         };     }; }; Add the GPIO pin for the ENET_RESET_B &iomuxc { ... ... pinctrl_enet_reset: enet_resetgrp {             fsl,pins = <                 MX7D_PAD_GPIO1_IO03__GPIO1_IO3      0x14     //ENET_RESET_B             >;         }; } There is a PHY fixup in the arch/arm/mach-imx/<imx_cpu>.c Here is the example in mach-imx7d.c #define PHY_ID_KSZ9031    0x00221620 #define MICREL_PHY_ID_MASK 0x00fffff0 static void mmd_write_reg(struct phy_device *dev, int device, int reg, int val) {     phy_write(dev, 0x0d, device);     phy_write(dev, 0x0e, reg);     phy_write(dev, 0x0d, (1 << 14) | device);     phy_write(dev, 0x0e, val); } static int ksz9031rn_phy_fixup(struct phy_device *dev) {     /*      * min rx data delay, max rx/tx clock delay,      * min rx/tx control delay      */     mmd_write_reg(dev, -1, 0x4, 0);     mmd_write_reg(dev, -1, 0x5, 0);     mmd_write_reg(dev, -1, 0x6, 0);     mmd_write_reg(dev, -1, 0x8, 0x003ff);     return 0; } static void __init imx7d_enet_phy_init(void) {     if (IS_BUILTIN(CONFIG_PHYLIB)) {         phy_register_fixup_for_uid(PHY_ID_AR8031, 0xffffffff,                        ar8031_phy_fixup);         phy_register_fixup_for_uid(PHY_ID_BCM54220, 0xffffffff,                        bcm54220_phy_fixup);         phy_register_fixup_for_uid(PHY_ID_KSZ9031, MICREL_PHY_ID_MASK,                 ksz9031rn_phy_fixup);     } } Now, the PHY is working on your board. Reference: 1.  Create an Ubuntu VM environment to build Yocto BSP  2.  i.MX Software | NXP 

This document is aimed to introduce seamless switch on rear view camera function in android P9 auto, and this can also be referenced for sharing dpu(display process unit) between A core and m4 core on imx8qxp/qm platform. OS: Android p9 auto beta. (linux needs some modifies). SDK_2.5.1_MEK-MIMX8QX for m4 core. Hardware platform: imx8qxp/qm mek board IT6263 lvds to hdmi cable. max9286 deserializer board. ov16035 camera. Hardware block：     Imx8qxp dpu block, for imx8qm there are two dpus:     Android/Linux and M4 shared dpu path:     The switch function is done by framegen0 unit in dpu, framegen unit can select 7 modes: primary src only second src only primary on second second on primary .....etc. for more details, please refer to the kernel codes at include/video/dpu.h, fgdm_t type. Seamless switch booting flow: Patches contain three main parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core, add ui ready rpmsg pipe. M4 code: modify dpu pipes, add ui ready rpmsg handle. AOSP init.rc scripts: add sending ui ready message scripts.

Brief introduction on the aarch64 linux kernel memory mapping layout and basic management stuffs.  Contents include: Kernel's virtual memory layout and mapping after running i.MX8QM/QXP kernel reserved memory layout Kernel memory allocation method and technology (Buddy, cma, ION...) DMA buffer management, SWIOTLB, IOMMU GPU memory management How to customize the memory for different use cases How to avoid using CMA for a better stability and performance

The document in attachment describes how to learn System Boot Flow of Linux by code using Trace32. The hardware platform is i.MX6Q SABRE and the software in PC is Trace32. Contents 1. Introduction 2. Hardware Connection 3. Serial Connection Setup 4. U-boot Directory Setup 5. Trace32 Installation & U-boot Debugging

Q:How use USB as both gadget mode and host mode usb USB_OTG? A: Hardware: imx6 sabresd board usb otg diagram, as follow Software:   You can use USB OTG port for both host mode and device gadget mode. There are 2 signals you should care: - USB_OTG_ID - USB_OTG_MODE (control power for usb vbus in host mode, this is EIM_D22 pin)   In device tree: reg_usb_otg_vbus: regulator@0 {                         compatible = "regulator-fixed";                         reg = <0>;                         regulator-name = "usb_otg_vbus";                         regulator-min-microvolt = <5000000>;                         regulator-max-microvolt = <5000000>;                         gpio = <&gpio3 22 0>;                         enable-active-high;                 };   pinctrl_usbotg: usbotggrp {                         fsl,pins = <                                 MX6QDL_PAD_GPIO_1__USB_OTG_ID           0x17059                                 MX6QDL_PAD_EIM_D22__GPIO3_IO22           0x80000000                         >;                 };   &usbotg {         vbus-supply = <&reg_usb_otg_vbus>;         pinctrl-names = "default";         pinctrl-0 = <&pinctrl_usbotg>;         disable-over-current;         srp-disable;         hnp-disable;         adp-disable;         dr_mode = "otg";                 status = "okay"; };  With above config, one can use OTG port for mouse, usb stick in host mode, and gadget mode for ADB...   https://community.nxp.com/message/943460 

It's the demo for hibernation for Android. Restore Android and UI can operate about 6 sec.

Agenda: 1. How-to M4 boot-up from TCM, DDR, OCRAM or QSPI in i.MX7D SABRE board 2. About multicore communication, Linux / Cortex-A and FreeRTOS / Cortex-M    a. RPMsg Ping-Pong FreeRTOS demo    b. RPMsg String Echo FreeRTOS demo 3. Multi-core Resource Sharing and Protection, RDC (Resource Domain Controller), Master Assignment Registers, Peripheral Mapping and Memory region Map 4. RDC settings in FreeRTOS BSP

Introduction Disk encryption on Android is based on dm-crypt, which is a kernel feature that works at the block device layer. Therefore, it is not usable with YAFFS, which talks directly to a raw nand flash chip, but does work with emmc and similar flash devices which present themselves to the kernel as a block device. The current preferred filesystem to use on these devices is ext4, though that is independent of whether encryption is used or not. [1] Let's encrypt! I will show the whole process first, and then point out the issue I noticed on i.MX6. To use this feature, go to settings and security as below: Encrypted phones need to set the numeric PIN, so click Screen lock to set password: Choose PIN: After setting up PIN code, the Screen lock is showed "Secured with PIN" as below: We can then click Encrypt phone to start: Note the words on this page, it needs start with a charged battery and the charger needs to be on. Click Encrypt phone button and it will ask PIN code setup before: Enter the PIN code and then has the confirmed page: Click Encrypt phone, it will reset framework and starting to encrypt: After running 100%: It then reset the device. When it boots, it will ask you enter the PIN to enter system. Check Setting -> Security again: The status showed Encrypted under Encrypt phone. Errors While Doing Encryption on i.MX6 In the following, I list the error I met and the way to fix. Orig filesystem overlaps crypto footer region.  Cannot encrypt in place It needs to make sure the filesystem doesn't extend into the last 16 Kbytes of the partition where the crypto footer is kept. The encryption in place and get_fs_size() in system/vold/cryptfs.c will check it, so needs to re-make data partition. sudo mke2fs -t ext4 /dev/sde7 1034000 -Ldata The original size is larger than 103400, so I used this value to reserved 16 Kbytes for crypto footer. device-mapper: table: 254:0: crypt: Error creating IV E/Cryptfs ( 2221): Cannot load dm-crypt mapping table. The actual encryption used for the filesystem for first release is 128 AES with CBC and ESSIV:SHA256. The master key is encrypted with 128 bit AES via calls to the openssl library. This is done by enable CONFIG_CRYPTO_SHA256 in kernel. Enable post_fs_data_done Vold sets the property vold.post_fs_data_done to "0", and then sets vold.decrypt to "trigger_post_fs_dat". This causes init.rc to run the post-fs-data commands in init.rc and init..rc. They will create any necessary directories, links, et al, and then set vold.post_fs_data_done to "1". Vold waits until it sees the "1" in that property. Finally, vold sets the property vold.decrypt to "trigger_restart_framework" which causes init.rc to start services in class main again, and also start services in class late_start for the first time since boot. This is done by: diff --git a/imx6/etc/init.rc b/imx6/etc/init.rc index 17cbd4c..f2823f2 100644 --- a/imx6/etc/init.rc +++ b/imx6/etc/init.rc @@ -203,7 +203,7 @@ on post-fs-data      # must uncomment this line, otherwise encrypted filesystems      # won't work.      # Set indication (checked by vold) that we have finished this action -    #setprop vold.post_fs_data_done 1 +    setprop vold.post_fs_data_done 1 Don't unmount data partition when cryptfs_restart After the steps above, it can finish encryption. But I found Android will crash after encryption and reboot. When data partition is encrypted, Android's init to mount /data will fail. The cryptfs.c here to try unmount will fail since the data partition isn't mounted before. diff --git a/cryptfs.c b/cryptfs.c index 052c033..fd05259 100644 --- a/cryptfs.c +++ b/cryptfs.c @@ -694,7 +694,7 @@ int cryptfs_restart(void)      if (! get_orig_mount_parms(DATA_MNT_POINT, fs_type, real_blkdev, &mnt_flags, fs_options)) {          SLOGD("Just got orig mount parms\n"); -        if (! (rc = wait_and_unmount(DATA_MNT_POINT)) ) { +        //if (! (rc = wait_and_unmount(DATA_MNT_POINT)) ) {              /* If that succeeded, then mount the decrypted filesystem */              mount(crypto_blkdev, DATA_MNT_POINT, fs_type, mnt_flags, fs_options); @@ -710,7 +710,7 @@ int cryptfs_restart(void)              /* Give it a few moments to get started */              sleep(1); -        } +        //}      } References: [1]: Notes on the implementation of encryption in Android 3.0 | Android Open Source

iMX8QXP/iMX8QM have hardware JPEG decoder: The JPEG-D-X core. This is the example code to use this hw decoder in M4 SDK to decode JPEG files. M4_JPEG_DECODER_SDK_2.5.1.7z The attached "rear_view_camera_jpegdec.tar.bz2" is the updated source code for "SDK\boards\mekmimx8qx\demo_apps\rear_view_camera". It is based on SDK 2.5.1 for iMX8QXP MEK. The "rear_view_camera_jpegdec.patch" is the modified code, it hasn't included the added "fsl_jpeg_dec.c" and "fsl_jpeg_dec.h".   The testing used two 256*256 JPEG files, they are RGB color space. We used followed commands to build them into flash.bin: ./mkimage_imx8 -soc QX -rev B0 -append ahab-container.img -c -scfw scfw_tcm.bin -m4 m4_rear_view_camera.bin 0 0x34FE0000 --data demo_rgb.jpg 0x84000000 --data demo_rgb2.jpg 0x84008000 -out flash.bin   If customer need change the JPEG resoluion, they can change them in file "fsl_jpeg_dec.h", APP_JPEG_SIZE_OF_KB is the JPEG file length in memory, aligned in KB.   #define APP_JPEG_WIDTH (256) #define APP_JPEG_HEIGHT (256) #define APP_JPEG_SIZE_OF_KB (32) #define APP_JPEG_FORMAT JPEG_RGB #define APP_JPEG_BUFFER (0x84000000)   To created RGB format JPEG file from RGB data, the customer can use linux unit test application "/unit_tests/JPEG/encoder_test.out". M4_JPEG_DECODER_WINDOW_MODE_SDK_2.5.1.7z Based on JEPG decoder, added DPU CSC support and render JEPG decoded video in overlay window. The architecture is followed: NXP logo is put in FetchLayer0 with RGB565 format, after LayerBlend0, it will be the prim layer for LayberBlend1 (FetchLayer0 can't be used as prim layer for LayerBlend), the JPEG decoder output is put to FetchDecoder0. RGB888 format, and it will be resize to 640*480, and put to x=100, y=100 of the display. (Only the sec layer of LayerBlend can be window mode). Some limitation for layer selection in LayerBlend:

Although you can develop your own driver to control GPIOs inside kernel space, there is a much simpler way for accessing GPIOs from user space. When timing requirements are not an issue, you are able to use GPIO-SYSFS. SYSFS is a virtual file system that exports some kernel internal framework functionalities to user space and GPIO is one of the frameworks that can have functionalities exported through SYSFS. The GPIO-SYSFS feature is available in all mainline kernels from 2.6.27 onwards. Configuring Kernel to export GPIO through SYSFS To enable GPIO in SYSFS, select the following kernel option: Device Drivers --->       --- GPIO Support             [*] /sys/class/gpio/... (sysfs interface) If you are using i.MX233 or i.MX28, after recompiling the kernel, do not forget to generate boot streams again, because this is not automatic even in ltib. Be sure that the pins you will try to use are really accessible as GPIO pins and were not requested by the kernel (gpio_request). If pin was gpio_request'ed, you will need to gpio_export the same pin inside the kernel in order to have it accessible through SYSFS. If pin is not set as GPIO by default, you will need to set IO MUX in the proper file inside <kernel>/arch/arm/mach-XXX. Accessing GPIO in user space After enabling GPIO-SYSFS feature, you can boot your device with the new kernel to make some tests. First you need to export the GPIO you want to test to the user space: echo XX > /sys/class/gpio/export XX shall be determined by the following algorithm: GPIOA_[B] is the GPIO you want to export, where "A" is the GPIO bank and "B" is the offset of the pin in the bank. if the first available GPIO bank is 0 // (iMX.28, for example)     XX = A*32 + B; else // first GPIO bank is 1     XX = (A-1)*32 + B; After exporting a GPIO pin, you shall be able to see the GPIO interface exported to: /sys/class/gpio/gpioXX Through this interface, you are now able to do things like: # Reading the pin value cat /sys/class/gpio/gpioXX/value # Changing pin direction echo in > /sys/class/gpio/gpioXX/direction echo out > /sys/class/gpio/gpioXX/direction # Toggling GPIO output level echo 0 > /sys/class/gpio/gpioXX/value echo 1 > /sys/class/gpio/gpioXX/value It is important to note that through the GPIO virtual filesystem it is only possible to deal with one GPIO pin at a time (per command).

Hardware connection: there are two board-to-board connectors on E-INK daughter card IMXEBOOKDC4, while there is only one on i.MX7D Sabre board, as the picture below. This might be a bit confusing to connect the two: Checked with internal, the original design was trying to wire both eLCDIF and EPDC bus out to one daughter card, add the flexibility to have different configurations on one display daughter card(LCD/EPD). On i.MX7D Sabre board, only one connector is available for EPDC bus. Here is how we connect i.MX7D Sabre and IMXEBOOKDC4: Software setup: here we use pre-build L3.14.38_6UL7D_Beta Linux as our boot-image, steps to setup/boot/test EPDC: 1. download and decompress BSP pre-build image package "L3.14.38_beta_images_MX6UL7D.tar.gz", you should be able to find the SD image in it -- "fsl-image-gui-x11-imx7dsabresd.sdcard" 2. program the SD image on your SD card(>800 MBytes) with command(I'm running this in Ubuntu): "dd if=fsl-image-gui-x11-imx7dsabresd.sdcard of=/dev/sdb;sync" 3. insert SD card to the slot(J6) on i.MX7D Sabre board, connect debug-UART and power-on the board 4. modify the u-boot environment variables as below:      a.) setenv fdt_file imx7d-sdb-epdc.dtb           (originally this is "fdt_file=imx7d-sdb.dtb")      b.) setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} epdc video=mxcepdcfb:E060SCM,bpp=16'           (originally this is "mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}") 5. boot into Linux kernel, run unit-test: "/unit_tests/mxc_epdc_fb_test.out", should be able to have test patterns running on EPD.

NXP i.MX 8 series of application processors support running ArmV8a 64-bit and ArmV7a 32-bit user space programs.  A Hello World program that prints the size of a long int is cross-compiled as 32-bit and as 64-bit from an Ubuntu host and then each is copied to MCIMX8MQ-EVK and run. Resources: Ubuntu 18.04 LTS Host i.MX 8M Evaluation Kit|NXP  MCIMX8MQ-EVK Linux Binary Demo Files - i.MX 8MQuad EVK L4.9.88_2.0.0_GA release Source Code: Create a file with contents below using your favorite editor, example name hello-sizeInt.c. #include <stdio.h> int main (int argc, char **argv) { printf ("Hello World, size of long int: %zd\n", sizeof (long int)); return 0; }‍‍‍‍‍‍‍ Ubuntu host packages: $ sudo apt-get install -y gcc-arm-linux-gnueabihf $ sudo apt-get install -y gcc-aarch64-linux-gnu‍‍‍‍ Line 1 installs the ArmV7a cross-compile tools: arm-linux-gnueabihf-gcc is used to cross compile on Ubuntu host Line 2 install the ArmV8a cross-compile tools: aarch64-linux-gnu-gcc is used to cross compile on Ubuntu host Create Linux User Space Applications Build each application and use the static option to gcc to include run time libraries. Build ArmV7a 32-bit application: $ arm-linux-gnueabihf-gcc -static hello-sizeInt.c -o hello-armv7a‍-static‍‍ Build ArmV8a 64-bit application: $ aarch64-linux-gnu-gcc -static  hello-sizeInt.c -o hello-armv8a‍-static‍‍ Copy Hello applications from Ubuntu host and run on MCIMX8MQ-EVK Using a SDCARD written with images from L4.9.88_2.0.0 Linux release (see resources for image link), power on EVK with Ethernet connected to network and Serial Console port which was connected to a windows 10 PC. Launched a terminal client (TeraTerm) to access console port. Login credentials: root and no password needed. Since Ethernet was connected a DHCP IP address was acquired, 192.168.1.241 on the EVK.  On the Ubuntu host, secure copy the hello applications to EVK: $ scp hello-armv7a-static root@192.168.1.241:~/ hello-armv7a-static                           100%  389KB   4.0MB/s   00:00    $ scp hello-armv8a-static root@192.168.1.241:~/ hello-armv8a-static                           100%  605KB   4.7MB/s   00:00 ‍‍‍‍‍‍‍‍‍‍ Run: root@imx8mqevk:~# ./hello-armv8a-static Hello World, sizeof long int: 8 root@imx8mqevk:~# ./hello-armv7a-static Hello World, sizeof long int: 4‍‍‍‍‍‍‍‍

Background Configure Trace32 Attach to SCFW with Lauterbach Snooping Perf Examples Example 1 : Snoop a function call (or a variable) Example 2: MonitorFrame Per Second Example 3: Monitor Frame Per Second and rendering size Background None of my automotive have trace pins on their board. Trace is consequently not possible. Anyway you can do "Snooping" with your Lauterbach JTAG probe. Snooping just send data as fast as possible. In the following example I will Snoop the i.MX8X' SCFW, notice I do not have the sources (except board.c) but I have the elf file (thus I have debug info with functions names for instance). Notice Snooping is available on all MCU/MPU with JTAG.   In my case I used it for the first time in 2015 on Vybrid, our first heterogeneous dual core (Cortex-A5 & Cortex-M4) with no XRDC... My customer has sent the final product with a JTAG connector and flashed SW product to me. I had a laconic comment: "software is done all around the world in UK, India and the US, when we flash all the software the Vybrid Reset for some version, we don't have the sources for this specific software we have flashed in this product. Good Luck". In this case snooping on both core at the same time was the only solution for me... At the end I have discovered (thanks to the last PC addresses before the crash) the cortex-A5 was deconfiguring a pin of the QSPI flash interface on which the M4 was eXecuting In Place (XiP). Configure Trace32 When your Trace32 is open, CPU>>System Settings... menu and configure the JtagClock as fast as possible (here 40MHz) to have fast data streaming: go in Trace>>Configuration menu Select "SNOOPer" Select to stream the Pointer Counter thus select the mode "PC" Pass to State to "Arm" You can increase also the SIZE of the buffer Launch your code: Attach to SCFW with Lauterbach In Trace32, CPU>>System Settings, chose IMX8QXP-SCU: And then do an "Attach": Then yu should see your SCU core running: Snooping And break your code, your "used" field " should be filled: Open Trace>>List>>Default Click on "Chart" On the trace list you can see the sampling rate: around 48µs in our case. It means you may (almost) not see functions lasting less than 48µs (depends when it is sampled), or you'll see it sometimes. But for performance analysis it can be useful to see which function is too slow (rather then instrument the code), but as I mentioned in my case function has to last more than 48µs! Perf You can also get Performance analysis. But keep in mind if your function is faster than 48µs in my case, the result will not be accurate! Go in Perf>>Perf Configuration (it can also be done un real time with Perf>>Perf List Dynamic)... and select "Snoop": Then put the State in "Arm" and click on "List" to open the "List Window" Launch your code and stop it. In the "List" window you'll see all the function ranked according to their usage occurrence (my SCFW is almost always in sleep!) Examples Example 1 : Snoop a function call (or a variable) With Snooping you cannot trace a function calls. To do that I add a global variable in the function. You'll have a little overhead due to that. I will use an i.MXRT1170 with the SDK 2.6.1. I have built the Tiger example (vglite). April 4th 2020: i.MXRT1170 is not public, meaning not officially supported by Lauterbach. Please follow the instruction in my SharePoint folder (if the link disappears, it may signify i.MXRT1170 is supported) to add support of the i.MXRT1170. https://nxp1-my.sharepoint.com/:f:/g/personal/vincent_aubineau_nxp_com/Ej8ID8mXaNZPnVgTWgYgqHQBzR0XcE0K4sl1WusR3UMBnw?e=…  I want to know the framerate. To do that I have to monitor the redraw() calls. What I do, is I put the "n" variable as global. Trace>>Configuration ... Chose "memory" and "changes" (to log only when the variable is changing): Then then click on select... and "i" Search for "n" variable and select it: Launch your software and then do a break. Click on "List": You have the list of your function call (as you can see it is not always the same), in the "ti. call" you have the duration between 2 call (keep in mind the function must not be called at high frequency: If you click on "draw", you can display the variable values (click on  to scale it): Example 2: Monitor Frame Per Second I can also monitor the fps if I pass "time" variable global: And you can have a reprensentation of you fps (notive I have unchecked "Changes" to have an easy to intrepret curve Example 3: Monitor Frame Per Second and rendering size Results often depends of several variables. If you display 2 variables on 1 display window, if the 2 variable does not have the same range, it is not easy to observe. The best solution I have found in this case is to have 2 "Draw" Windows. Add the 2 variables in the "SElect" field ("time" and "ScaleCount", beware, it is case sensitive). Launch your code, and stop it after a while. Then right click on the "time" and "ScaleCount" variable in your code to display 2 "Draw" window: Thus you have 2 "Draw" windows, and you see FPS depends on rendering size... logical!  

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

Hello everyone! In this document you'll find an example on how to setup your own recipe for Yocto Project to add your own custom changes, such as custom device tree, patches, custom drivers, etc. Linux kernel used in this guide 6.1.36_2.1.0 At least 120(250)GB HDD in the host PC Ubuntu 20.04 or later host PC ##Host Setup $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales -y $ sudo locale-gen en_US.UTF-8 ##Setup Repo utility $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH ##Git Setup $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config --list ##Yocto Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b buildwayland ##Create the new layer $ cd ../sources $ bitbake-layers create-layer meta-newlayer ##Add the new layer to the bblayers.conf in the build directory $ bitbake-layers add-layer meta-newlayer ##Check that it has been added correctly $ tree -L 4 ./meta-newlayer ##Edit the new layer and delete the samples created by yocto $ cd meta-newlayer $ rm -r recipes-example $ rm conf/layer.conf ##Use any text editor to create the layer configuration $ nano conf/layer.conf ##Add the following to the layer configuration file BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \             ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-newlayer" BBFILE_PATTERN_meta-newlayer := "^${LAYERDIR}/" BBFILE_PRIORITY_meta-newlayer = "8" LAYERSERIES_COMPAT_meta-newlayer = "mickledore" ##Prepare bbappend files so the patches get applied $ mkdir -p recipes-kernel/linux $ cd recipes-kernel/linux $ nano linux-imx_%.bbappend ##Add the following to the .bbappend file FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file://001-add-imx8mp-dts-test.patch" PACKAGE_ARCH = "${MACHINE_ARCH}" KERNEL_DEVICETREE:append = " freescale/imx8mp-evk-test.dtb" ##Copy the patches to the layer file path, for this example I have created a simple patch to just rename the default device tree. $ mkdir files $ cp ~/patches/001-add-imx8mp-dts-test.patch files ##Make sure that the layers is created correctly $ bitbake-layers show-layers  ##Finally we bitbake our image $ cd ~/imx-yocto-bsp/buildwayland $ bitbake imx-image-multimedia #All the images built should appear at  <build directory>/tmp/deploy/images/<machine> Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.