This document shows how to run the multicore communication examples from MCUXpresso SDK while running the Android BSP on Cortex-A7 on i.MX 7ULP-EVK. Though this document is focused on the multicore demos, similar procedures can be applied to run any other demo in the SDK. 1. Source code This document is based on the following releases: Board Android BSP MCUXpresso SDK imx7ulp-evk Android O8.1.0 for i.MX 7ULP GA SDK2.4 for i.MX 7ULP GA Download releases at i.MX Software. 2. Building the Cortex-M4 SDK There are at least two multicore demos in the SDK package, rpmsg_lite_pingpong_rtos and rpmsg_lite_str_echo_rtos. They are located at: <SDK_2.4.0_EVK-MCIMX7ULP_dir>/boards/evkmcimx7ulp/multicore_examples/ Build the rpmsg_lite_str_echo_rtos demo according to the SDK Getting Started Guide. Remember to also follow the Chapter 6, Step 4 of the document to generate the ram bootable image (sdk20-app.img). 3. Building the Android BSP 3.1. RPMsg kernel module Before building the BSP, add the following line to the BoardConfig.mk file (<android_build_dir>/device/fsl/evk_7ulp/BoardConfig.mk): BOARD_VENDOR_KERNEL_MODULES += \    $(KERNEL_OUT)/drivers/net/wireless/qcacld-2.0/wlan.ko \ + $(KERNEL_OUT)/drivers/rpmsg/imx_rpmsg_tty.ko 3.2. Cortex-M4 image Copy the SDK image file (sdk20-app.img) to the following directory in the Android source code: $ cp <SDK_2.4.0_EVK-MCIMX7ULP_dir>/tools/imgutil/evkmcimx7ulp/sdk20-app.img \   <android_build_dir>/vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/sdk20-app.img Change the BoardConfig.mk file accordingly: # Copy prebuilt M4 demo image: PRODUCT_COPY_FILES += \ - vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/imx7ulp_m4_demo.img:imx7ulp_m4_demo.img + vendor/nxp/fsl-proprietary/mcu-sdk/7ulp/sdk20-app.img:imx7ulp_m4_demo.img After these changes, build and flash Android as described in the BSP User's Guide. 4. Enabling the multicore communication While booting, the SoC automatically loads the Cortex-M4 image. After complete booting, install the imx_rpmsg_tty.ko module to create the multicore communication channel: $ su $ insmod vendor/lib/modules/imx_rpmsg_tty.ko To send messages from Cortex-A7 to Cortex-M4, use the /dev/ttyRPMSG* channel: $ echo "MESSAGE" > /dev/ttyRPMSG* /dev/ttyRPMSG* refers to the RPMsg device created on the board, so change the number accordingly. Cortex-M4 will echo all messages received from Cortex-A7. This is a simple example on how to communicate different cores on i.MX using Android but it can be used as a starting point for Android multicore applications.

Random Number Generator - RNGA Download rng-tools: http://downloads.sourceforge.net/sourceforge/gkernel/rng-tools-2.tar.gz This tool tests the link between a random number generator hardware and the kernel's PRNG (pseudo-random number generator). ./ltib -m shell LTIB> cd rpm/BUILD/ LTIB> cp ~/hwrandom/rng-tools-2.tar.gz . LTIB> tar zxvf rng-tools-2.tar.gz LTIB> cd rng-tools-2 LTIB> ./configure --host=arm-linux LTIB> make LTIB> sudo cp rngtest /tftpboot/ltib/home/ Restart your board and execute this command in the board's console: $ cat /dev/hwrng | /home/rngtest -c 1000

Flashing Kernel and Root File System using RedBoot Creating an image A kernel image and a root file system can be created using All Boards LTIB or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs/ -e 0x20000 -n -p -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connections errors can be avoided by All Boards Configuring RedBoot. The process below uses TFTP to copy the files between host and target. See All Boards TFTP for detail in configurations. Copy the kernel image and the root file system image to the TFTP dir. For example, in  LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: fis init Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel at the right address (0x200000, for IMX31PDK) fis create -f 0x200000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for IMX31PDK. fis create -f 0x600000 root Testing You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock2 /mnt ls /mnt List the /mnt contents. The output must be the right file system. Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=none" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the ethernet cable.

We use PCIe to connect Intersil TW6865 chip for the surround view solution. This is the connection of PCIe to iMX6Q SabreSD board.   This is the block diagram of the connection: This is the 4 camera surround view:   Code base is L3.0.35_12.10.02 release. You can merge the patch file to the latest Freescale release. Please check the attach file for the patch code.   Note:  It is only a test version. The last code for L3.0.35 BSP: L3.0.35_GA4.1.0 Patches.7z The last code for L3.10.53 BSP: L3.10.53_TW686x_patch.7z Patch for L4.1.15 1.1.0 GA BSP: TW6865 driver for Linux L4.1.15_1.1.0-ga.7z

One of the new feature of  the i.MX8 family is to support CAN FD. Fortunately the MEK board has a TJA1043 supporting CAN FD. The following document show you how to do simple CAN (FD) test under Linux. First of all let configure the CAN0 to be at 500kps in CAN, and 4Mbps in CAN FD: ip link set can0 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on ‍‍‍‍‍‍‍ Let's do the same for CAN1: ip link set can1 up type can bitrate 500000 sample-point 0.75 dbitrate 4000000 dsample-point 0.8 fd on‍‍‍‍ Now you can do a bridge between CAN0 and CAN1 on the board. The easiest way is to put simple wires (pin 2 to pin 2 a,d pin 7 to pin 7), normally you have to twist your wires, but as it is on your desk, you can get rid of it): You can check the configurations of your FlexCAN: root@imx8qxpmek:~# ip -details link show can0 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 link/can promiscuity 0 can <FD> state ERROR-WARNING (berr-counter tx 0 rx 0) restart-ms 0 bitrate 500000 sample-point 0.750 tq 25 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 flexcan: tseg1 2..64 tseg2 1..32 sjw 1..32 brp 1..1024 brp-inc 1 dbitrate 4000000 dsample-point 0.800 dtq 25 dprop-seg 3 dphase-seg1 4 dphase-seg2 2 dsjw 1 flexcan: dtseg1 1..39 dtseg2 1..8 dsjw 1..8 dbrp 1..1024 dbrp-inc 1 clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 root@imx8qxpmek:~# ip -details link show can1 4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 link/can promiscuity 0 can <FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 bitrate 500000 sample-point 0.750 tq 25 prop-seg 29 phase-seg1 30 phase-seg2 20 sjw 1 flexcan: tseg1 2..64 tseg2 1..32 sjw 1..32 brp 1..1024 brp-inc 1 dbitrate 4000000 dsample-point 0.800 dtq 25 dprop-seg 3 dphase-seg1 4 dphase-seg2 2 dsjw 1 flexcan: dtseg1 1..39 dtseg2 1..8 dsjw 1..8 dbrp 1..1024 dbrp-inc 1 clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 root@imx8qxpmek:~#‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now a simple test can be to send random CAN FD messages, for that use "cangen" to send random CAN FD messages (read "cangen" documentation: https://manpages.debian.org/stretch-backports/can-utils/cangen.1.en.html 😞 root@imx8qxpmek:~# cangen can0 -v -b -g 20 can1 3E6 [00] can1 735 [20] F9 ED 40 53 AC CF 48 34 F9 ED 40 53 AC CF 48 34 F9 ED 40 53 can1 513 [20] 92 D2 E7 32 48 E6 EA 39 92 D2 E7 32 48 E6 EA 39 92 D2 E7 32 can1 03B [12] 6D 34 2F 11 52 8A 52 50 6D 34 2F 11 can1 47D [24] 72 08 88 0D E0 04 F7 09 72 08 88 0D E0 04 F7 09 72 08 88 0D E0 04 F7 09 can1 245 [00] can1 6F6 [48] B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 B9 82 A1 49 4E ED BA 06 can1 1F4 [16] 03 5B 7C 00 DA E5 FA 03 03 5B 7C 00 DA E5 FA 03 can1 38A [48] 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 71 CE A3 1A C0 8A 4F 20 can1 4C9 [20] 6C 5A 98 54 DD D1 CB 09 6C 5A 98 54 DD D1 CB 09 6C 5A 98 54 can1 536 [48] 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 25 B8 B6 43 71 CD 54 71 can1 308 [02] C3 57 can1 33E [05] 65 8C 7B 21 83 can1 3F5 [05] EA E0 07 63 EB can1 633 [03] 39 10 18 can1 25D [32] 01 4E 65 41 E8 4D 94 6F 01 4E 65 41 E8 4D 94 6F 01 4E 65 41 E8 4D 94 6F 01 4E 65 41 E8 4D 94 6F can1 2FB [03] A8 D8 E3 can1 0DE [04] A1 11 3F 32 can1 012 [06] 85 23 B2 07 1A 03 can1 658 [08] A0 8A 2D 67 97 79 A1 64 can1 37D [05] 1A 57 E8 4F 72 can1 70A [04] 5E 6A B8 0F can1 3A8 [07] 65 C5 48 76 05 B6 11 can1 5D4 [07] ED 03 A6 07 CF D8 DC can1 7DA [05] 94 18 50 09 B8 can1 7A9 [05] CC 5E 02 74 BC can1 3FC [01] D6 can1 599 [06] EB 23 02 61 16 D9 can1 47C [06] 88 20 F2 62 86 3B can1 30A [06] C4 98 57 61 B2 4E can1 57E [16] B8 04 86 5B 52 EB DF 45 B8 04 86 5B 52 EB DF 45 can1 191 [05] 22 C4 BC 26 6B can1 53B [06] 23 AA AA 00 E4 F4 can1 6EB [64] A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D A0 64 BE 5E E7 FA 20 1D‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can check with a scope your CAN FD frame (here CAN High): And you can see the first part of the frame sent @500kps and the second part @4Mbps. If you unplug one wire, the messages will no longer be sent as no acknowlege will occurs. You can also send message without flexible datarate. In our case, we'll send long frame at 500kps (no more 4Mbps transfer for end of the frame): imx8qxpmek:~# cangen can0 -v -f -g 20 can0 6FE##0.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E.6B.C6.BA.1A.82.2D.29.7E can0 3E2##0.D4.9E.3D can0 1DE##0.D0.D8.33.50.7E.39 can0 7CE##0.FA.68.25.74.86.E7.E1.4A.FA.68.25.74.86.E7.E1.4A.FA.68.25.74 can0 7C3##0.58.E6.F2.1E.BD.7D.F8.7F can0 32A##0.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E.0D.06.98.0D.08.81.5C.4E can0 48B##0.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47.76.48.B4.34.59.81.B9.47 can0 3FC##0.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00.6E.70.F7.36.FB.82.B9.00 can0 4BE##0.7D.B0.E2.7E.A0.F0.DF.24.7D.B0.E2.7E can0 60C##0.0E can0 257##0.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65.69.11.0C.4B.25.CA.16.65 can0 0BA##0.AB.B1.F8 can0 0FC##0.3A.7E.FB.34 can0 452##0.2F.4D.04.26.DE.80.EA can0 2C7##0.37.02.A4.4D.C3 can0 0B4##0.BE.39.AD.3B.73 can0 17E##0.13.66.44.6A.8A.8F.CE.7A.13.66.44.6A.8A.8F.CE.7A.13.66.44.6A‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You can also force the CAN to only send CAN 2.0b frames (not FD, you'll have 8-byte data max frames): imx8qxpmek:~# cangen can0 -v -g 20 can0 7FF#8F.04.3F.31.EB can0 135#92.7C.46.5C.95.4E.6C.48 can0 0F8#E3.E4.7E.4D.92.2A.1D.69 can0 68F#C6.B7.BA.35.78.06 can0 4EC#D8.D9.86.19.40.BE.64.05 can0 09F#EE.E1.70.7D.13.C9.18.53 can0 7CE#BB.CD.FE.50.3E.B6.A4.4A can0 3C7#04 can0 1F6#B2.E4.4B.42 can0 080#C1.81.65.41 can0 14C#0B.B4.7E.5D can0 15A#53 can0 1CF#86.D4.ED.11.6E.BA.20.14 can0 257#82.83.39.67 can0 2C1#64.20.DF.0D.89.0E.14.55 can0 45E#50.72.44.76.55.4E.96.0F can0 6FC#80.81 can0 046#F6 can0 1E5#6D can0 0D2# can0 7EB#0F.3D.29.78.42.72.60.61 can0 480#68 can0 1CE#CB.05.12.74.2D.0E.F2.14 can0 634#82.5C.88.24.31.75.AF.03 can0 71D#AE.4C can0 144#F5.A8.17.70 can0 2A5#69.BE can0 222#18.C6.AA.4A.0D.5A.EC.48 can0 5FA#4F.CC.4C.2A.7B.BA.31 can0 3B9#BD.B1.2F.3C.87.D5.D1 can0 583#B4.E3.C3.4E.B8.D3.22.43‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Quaestion: What does exactly the RNG_TRIM after burning the SRK hash table? There is no such thing on the former i.MX HAB procedure. What would a random generator stuff bring here? Additionnally, there is the possibility to lock the SRK shadow register via an OTP bit. Is it recommeneded to lock it? if not, is it really possible to change the SRK hash value by modofying the shadow register value before performing the SRK hash key check in a HAB boot process? One last question: the PKI requires the user to enter a certificate lifetime. Does that really mean that openssl will refuse generating new signatures once the certificates lifetime is expired? Answer: 1. The intent of the of the RNG_TRIM fuses is for Freescale to essentially extendthe amount of time the RNG4 in CAAM has to generate entropy.  The longer this period the more likely it is that RNG4 will generate entropy that will pass its internal statistical tests.  The reason for the fuses is HAB (in the Closed configuration only) instantiates the RNG by default and needs some external indication on how to progran the RNG4 in CAAM to ensure the internal HW statistical tests will pass.  This was to allow the RNG to be useable by application code after execution has left the ROM.  However this requires that the RNG_TRIM fuse value be fully characterized across numerous conditions temperature, voltage etc.  This effort is still on going.  For customers performing secure boot (in Closed configuration) we recommend they follow Section 6.3 of http://cache.freescale.com/files/32bit/doc/app_note/AN4581.pdf.  In this case the RNG4 can be instantiated by CAAM driver code which can be easily changed if required. 2. Yes, once the SRK hash is provisioned to the SRK_HASH field it is recommended to blow the corresponding SRK_LOCK fuse.  If the SRK_LOCK fuse is not blown then additional fuses in the SRK_HASH field can be blown.  This will cause devices in the closed configuration to fail to boot.  i.e. "bricking" the device. 3. Please see https://community.freescale.com/message/334186#334186 for the answer to your question on the certificate validity period.

When a board is brought up and  the ddr test by link of "https://community.nxp.com/docs/DOC-96412' hashttps://community.nxp.com/docs/DOC-96412' hashttps://community.freescale.com/docs/DOC-96412' hashttps://community.nxp.com/docs/DOC-96412' has been verified, some of boards will have pfd issue(ERR006282). It is suggested that below method could be used to check the issue.The detail steps are: As boards may have no jtag port, the internal usdhc4 root clock out needs to be remapped. When “CUP not initialized” issue has been seen and in download mode, DDR test tools can be used with the script to remap clock output. Please check the attached for test script and the empty the binary. Put the two files to DDR stress test tool folder “DDR_Stress_Tester\binary\”. The attached ddr-stress-test-mx6dq.bin is an empty file. Please backup the original file first. After eMMC boot failed and in download mode, run command “DDR_Stress_Tester.exe -t mx6x -df test.inc” on PC side. There is no clock output on GPIO19. For normal test, please erase the eMMC chip and boot the board. It will also fail to boot and run into download mode. After run “DDR_Stress_Tester.exe -t mx6x -df test.inc” , clock can be measured from GPIO19 if no PDF issue happens. Below is  the details: The script file. wait = on A: Config GPIO19(ENET_ RST_ PHY_B) as CLKO1 setmem /32 0x020E0254 = 0x3    // Config GPIO19(ENET_ RST_ PHY_B) as CLKO1      On your board, it is R112 for the test point. B: enabled, CKO1 output drives cko2 clock, divide by 5, usdhc4_clk_root setmem /32 0x020C4060 = 0x01820101  // CKO2 enabled, CKO1 output drives cko2 clock, divide by 5, usdhc4_clk_root Hex 0 1 8 2 0 1 0 1 Bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Binary 0 0 0 0 0 0 0 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 And for the normal boot, erase the emmc, and reboot to enter the download mode. There will be no signal output but high voltage on R112. After the script runs, 40Mhz clock will be seen. For the boot fail case, there will be no signal output but high voltage on R112 and 40Mhz clock will be pulled to low. 1: CKO2 enabled 2: divide by 5 3 usdhc4_clk_root 4: CKO1 output drives cko2 clock 5

I was trying to implement an E-Ink solution using IMX7D. Unfortunately I only had a IMXEBOOKDC3 available, not the DC4 shown on the IMX7D E-Ink tutorials. After a couple of tries I found the right way of connecting the expansion board and the the definition of the arguments on U-boot to make the IMX7D and DC3 work together.  I logged these considerations on the blog post below: http://bit.ly/IMX7D_IMXEBOOKDC3   Andres

It is one mandatory patch if you are in the case: The chip you are using is imx6sx TO1.3 and newer, and use the kobs-ng to flash your image to the Nand memory chip. If you are using MFG, you also need rebuild the kobs-ng, and update the binary into your MFG tool.  The patch have been integrated into the default release yocto_4.1.15, but if you are using the older version release before yocto_4.1.15, please make sure you have integrated the modification when you need to use kobs-ng to flash the image to Nand memory chip. commit 5ecf08703da489a3bd317341f630870a3d07dab9 Author: Han Xu <[email protected]> Date:   Thu Jan 28 14:40:14 2016 -0600     MMT-105: change the i.mx6sx revision check change the i.mx6sx revision check since v1.3 uses v1.2 boot config as well.     Signed-off-by: Han Xu <[email protected]>     (cherry picked from commit 1dac0c14d1e2016c2fa804f6628543d8d238c680) diff --git a/src/plat_boot_config.c b/src/plat_boot_config.c index 461675a..e1ef6f3 100644 --- a/src/plat_boot_config.c +++ b/src/plat_boot_config.c @@ -1,5 +1,5 @@ /* -* Copyright (C) 2010-2015 Freescale Semiconductor, Inc. All Rights Reserved. +* Copyright (C) 2010-2016 Freescale Semiconductor, Inc. All Rights Reserved. */ /* @@ -256,10 +256,12 @@ int discover_boot_rom_version(void)                                         }                                         fgets(line_buffer, sizeof(line_buffer), revision);                                         if (!strncmp(line_buffer, "1.0", strlen("1.0")) || -                                                       !strncmp(line_buffer, "1.1", strlen("1.1"))) +                                                       !strncmp(line_buffer, "1.1", strlen("1.1"))) {                                                 plat_config_data = &mx6sx_boot_config; -                                       if (!strncmp(line_buffer, "1.2", strlen("1.2"))) +                                       /* all other revisions should use the latest boot config */ +                                       } else {                                                 plat_config_data = &mx6sx_to_1_2_boot_config; +                                       }                                 }                                 if (!strncmp(line_buffer, plat_imx6ul, strlen(plat_imx6ul))) How to apply it to older version quickly:  Apply the patch and rebuild the kobs-ng in yocto_3.14_x environment: bitbake -c compile -v -f imx-kobs cd tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/5.0-r0/imx-kobs-5.0 git apply yocto_3_14_x.patch bitbake -c compile -v -f imx-kobs you can find the new binary “kobs-ng” under “tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/5.0-r0/build/src” Apply the patch and rebuild the kobs-ng in yocto_3.10_53 environment: . ./setup-environment build bitbake -c compile -v -f imx-kobs cd tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/3.10.53-1.1.0-r0/imx-kobs-3.10.53-1.1.0 git apply yocto_3_10_53patch bitbake -c compile -v -f imx-kobs you can find t he new binary “kobs-ng” under tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/imx-kobs/3.10.53-1.1.0-r0/imx-kobs-3.10.53-1.1.0/src As one alternation method, you also can download the whole imx-kobs-5.4 package which yocto_4.1.15 is using to build. wget http://www.freescale.com/lgfiles/NMG/MAD/YOCTO//imx-kobs-5.4.tar.gz

Question: LVDS in split mode (dual lvds) is used. In this configuration, only LVDS0_CLK is used. What is the suggestion for the LVDS1_CLK?  The HW user guide says that if this is unused, then to leave it floating.  Would we also suggest the same for this case or would termination be more appropriate?  Or is there some possible way to gate this clock?  (if so, it isn't obvious in the RM) Answer: According to the MX6 Developer's Guide, any unused LVDS pins should be left floating, so the LVDS1_CLK pair, in this case should be left floating. In order to minimize any potential EMC, the lands for those balls should not have any additional traces leading away. To add a bit more information, the customer ran some tests and found that the clock gate bits for the LVDS1 are essentially ignored in Dual mode.  The only way to disable it is if they are both disabled which is not helpful in this case.  It seems that the Dual mode setting overrides the CG.

The Android O8.0.0_1.4.0 for i.MX 7ULP RFP(GA) release is now available on IMX_SW web page. Overview -> BSP Updates and Releases -> Android O8.1.0 for i.MX 7ULP GA.   Files available:   # Name Description 1 android_o8.1.0_1.4.0_7ulp-ga_docs.tar.gz Android O8.1.0_1.4.0 for 7ULP GA Documentation 2 imx-o8.1.0_1.4.0_7ulp-ga.tar.gz i.MX Android proprietary source code for Android O8.1.0_1.4.0_7ULP_GA 3 android_o8.1.0_1.4.0_7ulp-ga_image_7ulpevk.tar.gz Prebuilt images with NXP extended features for the i.MX7ULP EVK board 4 android_o8.1.0_1.4.0_7ulp-ga_tools.tar.gz Manufacturing Toolkit and VivanteVTK for Android O8.1.0_1.4.0_7ULP_GA 5 fsl_aacp_dec_O8.1.0-7ULP_GA.tar.gz AAC Plus Codec for  O8.1.0_1.4.0_7ULP_GA   Target boards: i.MX 7ULP EVK   Features and Known issues For features and known issues, please consult the Release Notes in detail.#

View Webinar Recording

目录 1 创建 i.MX8QXP Linux 5.4.24 板级开发包编译环境 ..... 3 1.1 下载板级开发包 ....................................................... 3 1.2 创建yocto编译环境: ................................................. 4 1.3 独立编译 ................................................................. 9 2 Device Tree .............................................................. 16 2.1 恩智浦的device Tree结构 ..................................... 16 2.2 device Tree的由来(no updates) ............................ 19 2.3 device Tree的基础与语法(no updates) ................. 22 2.4 device Tree的代码分析(no updates) ..................... 44 3 恩智浦i.MX8XBSP 包文件目录结构 .......................... 77 4 恩智浦i.MX8XBSP的编译(no updates) ..................... 79 4.1 需要编译哪些文件 ................................................. 79 4.2 如何编译这些文件 ................................................. 80 4.3 如何链接为目标文件及链接顺序 ............................ 81 4.4 kernel Kconfig ....................................................... 83 5 恩智浦BSP的内核初始化过程(no updates) .............. 83 5.1 初始化的汇编代码 ................................................. 85 5.2 初始化的C代码 ...................................................... 89 5.3 init_machine........................................................ 102 6 恩智浦BSP的内核定制 ........................................... 105 6.1 DDR修改 ............................................................. 106 6.2 IO管脚配置与Pinctrl驱动 ..................................... 107 6.3 新板bringup......................................................... 123 6.4 更改调试串口 ...................................................... 132 6.5 uSDHC设备定制(eMMC flash,SDcard, SDIOcard)137 6.6 LVDS LCD 驱动定制 ........................................... 147 6.7 LVDS LDB SerDas驱动支持 ............................... 150 6.8 MiPi DSI SerDas驱动支持 .................................. 156 6.9 V4L2框架汽车级高清摄像头/桥驱动：数字/模拟 . 160 6.10 GPIO_Key 驱动定制 .......................................... 177 6.11 GPIO_LED 驱动定制 ......................................... 181 6.12 Fuse nvram驱动 .................................................. 184 6.13 SPI与SPI Slave驱动 ........................................... 185 6.14 USB 3.0 TypeC 改成 USB 3.0 TypeA(未验证) .... 193 6.15 汽车级以太网驱动定制 ........................................ 193 6.16 i.MX8DX MEK支持 .............................................. 212 6.17 i.MX8DXP MEK支持 ........................................... 212 6.18 NAND Flash支持与烧录 ...................................... 213

This is a How-To documentation for OpenCL on i.MX6 using LTIB, there are all necessary steps and sample code to create,  build and run a HelloWorld application.

http://freescale.eefocus.com/bbs/article_175_179914.html Freescale i.mx53 i.mx6x series solution to speed up the progress of your product 深圳市优创科技有限公司 Josephwang 王伟 深圳市南山区高新技术产业园南区创维大厦C15 Tel:0755-26017990  13128865181        Mail:[email protected]        QQ:[email protected]

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

logcat Logcat is the most powerful debug tool for Android. Logcat is to Android what the dmesg is to kernel. It shows messages logs from system and applications. logcat can be used directly on board console or via adb. $ logcat directly on board console. It gives the complete log message list and waits for any new log message. $ logcat & board console. It gives log list and run in background. Any new log message will be displayed. # adb logcat Using adb you can get log messages through Ethernet or USB connection. $ logcat -d > logcat.txt it sends log messages to logcat.txt file and exits. $ logcat *:W it filters expression displays all log messages with priority level "warning" and higher, on all tags * * http://developer.android.com/guide/developing/debugging/debugging-log.html

i.MX6 4.0.0 BSP release doesn't support ASRC_P2P function. This patch provides the reference codes to enable ASRC_P2P function for SSI. It can convert input sample rate to 44.1K_16bit/44.1K_24bit and 48K_16bit/48K_24bit. You can modify the configurations in the Board file. By the way, the SSI controler works at slave mode. Known limitations for the patch: -- The SDMA doesn't support SSI Dual FIFO when using ASRC_P2P function. -- From the waveform, the converted 24bit data have some abnormal data(values between 0 and 1) , but can't hear any abnormal sound from headphone. One suggestion is given under https://community.freescale.com/docs/DOC-95340

When streaming, if you want to play a streaming URL, it can be inconvenient if the browser cannot recognize the URL as a media stream and downloads the content rather than using Gallery to play it. To create this kind of media streaming, you need to write an apk to use VideoView to play the URL/media stream from the console. Here is the command of how to play a media file or network stream from console. Gingerbread am start -n com.cooliris.media/com.cooliris.media.MovieView -d "<URL>"       The URL can be file position or network stream URL, such as: you can play a local file by: am start -n com.cooliris.media/com.cooliris.media.MovieView -d "/mnt/sdcard/test.mp4" You can also play a http stream by: am start -n com.cooliris.media/com.cooliris.media.MovieView -d "http://v.iask.com/v_play_ipad.php?vid=76710932" Or play a rtsp stream by: am start -n com.cooliris.media/com.cooliris.media.MovieView -d "rtsp://10.0.2.1:554/stream" ICS am start -n com.android.gallery3d/com.android.gallery3d.app.MovieActivity -d "<URL>"        The URL has the same definition of Gingerbread.