When working on the IOMUX settings of an i.MX processor for our design it’s always good to make use of the IOMUX Tool provided by Freescale on the Download Page of most i.MX processors. We’ll focus on the latest release of the IOMUX tool for i.MX6. The IOMUX tool provides a Graphic User Interface to easily assign internal signals to external pins/balls and resolve any potential pin conflict and muxing options for the different modules available on the i.MX processors. IOMUX Tool Download (Will request to log in) Freescale’s Boards IOMUX settings. On the IOMUX tool package you’ll find the User’s Manual and also a folder containing the muxing options for Freescale’s Reference Boards, which may be of help when working with the Reference Designs as a starting point. You may load these settings files using the file/open option. MMDC pins Since the Multi-mode DDR controller MMDC pins are not muxed these cannot be changed on the IOMUX tool. This because the memory interfaces are much more sensitive to interference and thus have dedicated pins that do not share pad with other signals. The registers are also set on the default value so it’s good to keep this in mind when working with the code provided by the IOMUX tool. Considerations when using generated code The tool can generate code to be used as reference of the IOMUX configuration but still requires manual tweaking and the header files available on the i.MX Processor’s BSP in order to be implemented in an actual application code. It’s important to review the register settings on the Register tab in order to export the desired values; otherwise the code will have the default values for the registers according to the IOMUX tool. This is especially true for the Daisy Chain settings, always manually review these. Import function limitations There is an import function available so IOMUX configuration files saved in previous versions of the IOMUX tool can be loaded on the newest version. However, this feature should be used carefully. When importing a design it’s recommended to save the imported design on the new version of the IOMUX tool as imported.xml; then opening a new configuration and saving it as new.xml and comparing register value differences to manually correct the imported.xml values. In small projects it might be recommended to manually load the IOMUX information on the new IOMUX tool version to avoid register conflicts from version to version. For more information please refer to the documentation available within the IOMUX tool package. An advanced example is also included in that document.

All, This document will help you to understand the " YOCTO PROJECT COMMUNITY LAYERS" and the "YOCTO PROJECT FREESCALE OFFICIAL RELEASE" differences and where the layer content is coming from.   Best Regards, Luis

It is based on 3.0.35 GA 4.1.0 BSP.   0001-Correct-mipi-camera-virtual-channel-setting-in-ipu_c.patch It is the updated IPU code for MIPI ID and SMFC setting in ipu_capture.c. These setting should not be combined with MIPI virtual channel value, they shoule be fixed with ID 0.   0002-Use-virtual-channel-3-for-ov5640-mipi-camera-on-iMX6.patch The sample code to modify ov5640_mipi camera to use virtual channel 3 on SabreSD board.   The followed command can be used to verify the mipi camera function after booted into Linux: $ gst-launch mfw_v4lsrc capture-mode=1 device=/dev/video1 ! mfw_v4lsink     2014-09-30 update: Added the patch for 3.10.17_GA1.0.0 BSP. "L3.10.17_1.0.0_mipi_camera_virtual_channel_3.zip"  

The reference code is based on L4.14.78 GA1.0.0 BSP and M4 SDK 2.5.1.  It is tested on iMX8QXP MEK board, and it should also work for iMX8QM board. In L4.14.78 GA1.0.0 BSP, MU_5 is used for RPMSG between M4 FreeRTOS and A35 Linux, SC_R_MU_5B is M4 side and SC_R_MU_5A is A35 side. In linux side, we used the "imx_rpmsg_tty.ko" for this test, this driver is built as module in default BSP. Case 1: M4 wake up A35. Apply "L4.14.78_rpmsg_wakeup.patch" to linux kernel, this patch will enable the RPMSG wake up feature. "rpmsg_lite_pingpong_rtos.tar.bz2" is the M4 side test code. After booted the board with Linux + M4 rpmsg software, run followed test commands: 1. In A35 UART side, run followed commands:     # echo enabled > /sys/bus/platform/devices/90000000.rpmsg/power/wakeup     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30     # echo mem > /sys/power/state 2. M4 UART side:    After run "echo deadbeaf > /dev/ttyRPMSG30" from Linux side, it will show "Got ping..." and wait there, after run A35 suspend commane "echo mem > /sys/power/state", Linux suspends. Then from M4 UART side, press "c" key, it will send RPMSG to A35 and wake up A35 Linux. Case 2: A35 wake up M4. "power_mode_switch_rpmsg_wakeup.tar.bz2" is the M4 side test code, After booted the board with Linux + M4 rpmsg software, the M4 UART will wait for A35 RPMSG driver ready. Test commands: 1. In A35 UART side, run followed commands to make RPMSG driver ready:     # insmod ./imx_rpmsg_tty.ko     # /unit_tests/Remote_Processor_Messaging/mxc_mcc_tty_test.out /dev/ttyRPMSG30 115200 R 100 1000 &     # echo deadbeaf > /dev/ttyRPMSG30 2. Now M4 UART shows ping pong messages to make sure RPMSG is ready. Now M4 is in power switch menu, select VLLS power mode in M4 UART:      Press  H for enter: VLLS     - Very Low Leakage Stop mode     ... ...      Press R for RPMSG. After press "R" key in M4 UART, M4 will print "Send a RPMSG message to wake up" and goto suspend mode. 3. Wake up M4 from A35 side, send any data to RPMSG:     # echo deadbeaf > /dev/ttyRPMSG30 M4 resumed and goto power switch menu again. SDK folder to compile the two M4 sample code: SDK/boards/mekmimx8qx/multicore_examples/rpmsg_lite_pingpong_rtos SDK/boards/mekmimx8qx/demo_apps/power_mode_switch

ADB is very well known as the tool to manually install APK’s, but there are some other useful commands. ADB is a command line tool that acts as the bridge between you and your android device. I want to show you some of them, but first, let’s make sure we have everything needed to use ADB. Requirements First, you need to have Java and the Android SDK installed on your PC, you can download it from here: Java SDK: Java SE - Downloads | Oracle Technology Network | Oracle Android SDK: http://developer.android.com/sdk/index.html Once it is installed, it is recommended to update the SDK Manager Once you have done this, flash the Freescale Android BSP onto your board… Once you have installed it, you need to enable USB Debugging in the Developer Options of your board.        Here's the steps to enable USB debugging: Go to Settings. Click on "about tablet" Scroll down to the last row (Build Number) and tap that row 7 times. Return to the previous screen and click on "developer options" Confirm that "usb debugging" is checked. Once you enable it, your OS (assuming you are using Windows) will look for the Android ADB Interface driver. Windows systems are the only ones that need this ADB driver. After this procedure, you can now start using ADB. Open a terminal window and go to the platform-tools directory of your SDK installation to find the ADB program. The usual path to find it would be: adt-bundle-windows-x86 >> sdk >>platform-tools adb start-server                              ::  Starts the ADB server in case it is not running already adb kill-server                   :: Terminates de ADB server adb devices                        :: Checks  and prints the status of each device plugged to your PC  (If you don’t see your device, make sure USB debugging is enabled in your tablet.) adb install  'apk file'       :: It will install an apk to the tablet.   This apk must be located in the same folder where the adb is. adb uninstall 'apk file' :: It will uninstall an apk adb pull 'file'                                               :: It copies a file or directory (and sub-directories) from your device to the PC. adb push 'file'                          :: It copies a file of directory (and sub-directories) from your PC to the device. adb logcat                        :: Prints the logdata to the screen adb logcat –c                  :: Clears the buffer to remove any old log data. adb bugreport               :: Prints dumpsys, dumpstate and logcat. adb shell pm list packages –f    ::  List all installed packages adb shell input keyevent 26     :: Send the power button event to turn on/off the device adb shell screencap –p /sdcard/screen.png      :: Takes a screenshot of the android display adb shell screenrecord /sdcard/demo.mp4      :: Records any activity on the android display Using the window manager There is also a very useful tool to manage the display. This can be ran through a terminal connection to your board. You run this command from the following path /system/bin of your android BSP These are some of the commands available: wm density 'density number'              :: Changes the display density wm size 'display size'                                :: Changes your display’s resolution Using the activity manager In the same path is the activity manager which has several other commands for use: am start 'package'   :: Starts an activity am monitor                     :: Monitors activities am bug-report               :: Requests a bug report am restart                        :: Restarts the OS

Enter inside ~/ltibdir/rpm/BUILD and create a directory 'alpha': $ cd ltib/rpm/BUILD $ mkdir alpha Enter in 'alpha' dir and create setalpha.c file: $ cd alpha #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <unistd.h> #include <asm/arch/mxcfb.h>  int main(int argc, char **argv) {              int fb_fd;              struct mxcfb_gbl_alpha gbl_alpha;               if(argc != 2){                       printf("Usage: %s alpha_val[0-255]\n",argv[0]);                       return -1;              }               fb_fd = open("/dev/fb0",O_RDWR,0);              gbl_alpha.enable = 1;              gbl_alpha.alpha = atoi(argv[1]);              ioctl(fb_fd, MXCFB_SET_GBL_ALPHA, &gbl_alpha);              close(fb_fd);              return 0; } Compile it using this command: ./ltib -m shell LTIB> cd rpm/BUILD/alpha LTIB> gcc -I../linux/include setalpha.c -o setalpha In your board execute it: root@freescale /home$ /unit_tests/mxc_v4l2_output.out -iw 320 -ih 240 -ow 480 -oh 640 -d 3 -r 4 -fr 5 qvga.yuv & While it is playing execute: root@freescale /home$ setalpha 128 root@freescale /home$ cat screen.raw > /dev/fb0 We used frame rate at 5 fps to have more time to execute next two commands.

The Register Programming Aid (RPA) provides a default DRAM PLL setting (DRAM frequency) based on the default setting supported in u-boot.  It is highly recommended to use the default DRAM frequency settings in the RPA for ease of use and to align with u-boot.  Otherwise, in addition to updating the RPA for the new DRAM frequency, the u-boot SPL code itself will need to be manually updated with the new DRAM PLL setting.   Should the user wish to change the DRAM frequency, the following steps are required:   First, the user needs to update the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to the desired DRAM frequency       2. Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054”.  The address “0x30360054” is for the DRAM PLL register address and its setting needs to be updated to the desired frequency.        Note that there is another place where the DRAM frequency is also updated “freq0 set 0x30360054” but it is automatically updated based on the setting above.    Below is a table of various frequencies to choose from.  For frequencies not listed in the table below, it is up to the user to calculate a new register setting based on the formula:     (24MHz x m)/(p x 2^s)   Where “m” represents the PLL_MAIN_DIV, “p” represents the PLL_PRE_DIV, and “s” represents the PLL_POST_DIV.  NOTE:  The DRAM frequency is double the DRAM PLL frequency DRAM_freq = DRAM_PLL x 2   The DRAM PLL register and bit settings are shown below:          The following table provides examples of the various settings to create the desired frequency:       For example, in the i.MX 8M Mini LPDDR4 RPA where the default DRAM frequency is 1500MHz, let’s assume that the user instead wants 1200MHz.    First, the user changes the RPA Register Configuration worksheet tab Device Information table “Clock Cycle Freq (MHz)“ setting to 1200.   Next, in the RPA DDR stress test file worksheet tab search for “memory set 0x30360054” and replace “0xFA080” (original setting from DRAM frequency 1500MHz) with “0x000C8022” (updated for DRAM frequency 1200MHz).  Note that for a DRAM frequency of 1200MHz, the DRAM PLL is configured for 600MHz, as the DRAM frequency is double the DRAM_PLL.   The steps outlined above are sufficient in order to create a DDR script for use with the DDR stress test tool to run the calibration and execute the DDR stress test.  However, to deploy the generated code in SPL, more steps are needed as the u-boot SPL DDR driver does not automatically change the DRAM PLL according to the generated code. Hence the user will need to manually modify related code in u-boot.  It is highly recommended to work with a software engineer familiar with u-boot when making the following modifications.    3. Modify DRAM PLL configuration in uboot-imx/drivers/ddr/imx8m.c, specifically the code highlighted below (function call dram_pll_init).  Note that the files and file paths in u-boot change frequently, so if this particular file (or file path) does not exist in the current u-boot, simply search for dram_pll_init or ddr_init.   void ddr_init(struct dram_timing_info *dram_timing) { ……    debug("DDRINFO: cfg clk\n");      if (is_imx8mq())           dram_pll_init(DRAM_PLL_OUT_800M);      else          dram_pll_init(DRAM_PLL_OUT_750M); ……  }   In the above code, the user should update the macro “DRAM_PLL_OUT_750M” with the new DRAM PLL value.  Note that the default DRAM_PLL_OUT_750M results in the DRAM frequency of 1500MHz, where the DRAM frequency is double the DRAM PLL (as previously stated above).   For example, if the user desires to run the DRAM at 1200MHz, they would change the above to: dram_pll_init(DRAM_PLL_OUT_600M);   Note that DRAM_PLL_OUT_600M is a supported macro in the dram_pll_init() API.  If the desired DRAM PLL configuration does not exist in dram_pll_init(), you will need to add support in uboot-imx/arch/arm/mach-imx/imx8m.c  (as stated above, if this file path does not exist in the current u-boot simply search for dram_pll_init):   void dram_pll_init(enum dram_pll_out_val pll_val) { …… }   Related Links i.MX8 MSCALE SERIES DDR Tool Release (V3.10) 

Bad and Ugly gstreamer plugins has their own special licensing, so it cannot be released formally inside any tarball. (I do not understand it deeply, if you want more info, please go to GStreamer: Licensing advice) But you can add it on your own image, and you only need to change the local.conf Please, add the following code to your local.conf: LICENSE_FLAGS_WHITELIST = "commercial" COMMERCIAL_AUDIO_PLUGINS ?= " \ gst-plugins-ugly-mad \ gst-plugins-ugly-mpegaudioparse \ " COMMERCIAL_VIDEO_PLUGINS ?= " \ gst-plugins-ugly-mpeg2dec \ gst-plugins-ugly-mpegstream \ gst-plugins-bad-mpegvideoparse \ " CORE_IMAGE_EXTRA_INSTALL += " \ packagegroup-fsl-gstreamer \ gst-plugins-base-videotestsrc \ gst-plugins-bad-fbdevsink \ gst-ffmpeg alsa-utils \ gst-plugins-good-isomp4 \ " Please, note that this will not install *every* plugin from ugly or bad. It will only install the plugins from the list. Go to Yocto Training - HOME Go to Task #8 - Build kernel manually using created toolchain

Development environment: i.MX6Q SabreSD w/ L3.0.35_1.1.0_121218 release. Quoting from Wikipedia about exFAT (exFAT - Wikipedia, the free encyclopedia) as following: exFAT (Extended File Allocation Table) is a Microsoft file system optimized for flash drives. [3] It is proprietary and patent-pending. [1] It is supported in Windows XP and Windows Server 2003 with update KB955704, [2] Windows Embedded CE 6.0, Windows Vista with Service Pack 1, [4] Windows Server 2008, [5] Windows 7, Windows 8, Windows Server 2008 R2 (except Windows Server 2008 Server Core), Mac OS X Snow Leopard starting from 10.6.5, [6] Mac OS X Lion and OS X Mountain Lion. The history of support exFAT in Linux was since from 2.6.x, it involves several parts that will be described followingly. Part 1: Linux Kernel            Enable FUSE (Filesystem in userspace) feature in Kernel Config, then build a new uImage and module if set it to be "M"; Part 2: fuse-2.9.2.tar.gz            Download fuse-2.9.2.tar.gz from http://sourceforge.net/projects/fuse/files/fuse-2.X/, untar it, then build it with following commands: ./configure --prefix=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/usr --host=`/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-gcc -dumpmachine` --enable-lib --enable-util --enable-example --exec-prefix=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/usr make sudo make install Part 3: exfat-utils-1.0.1.tar.gz            Download exfat-utils-1.0.1.tar.gz from http://code.google.com/p/exfat/downloads/list, untar it, then build it with following command: sudo scons SYSROOT=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs DESTDIR=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/sbin CC=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-gcc AR=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ar RANLIB=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ranlib STRIP=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-strip install Part 4: fuse-exfat.git git clone git://sources.progress-linux.org/git/releases/baureo-backports/packages/fuse-exfat.git  fuse-exfat.git cd fuse-exfat.git Replace the root SConstruct with the attached one, then execute command: sudo scons SYSROOT=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs DESTDIR=/home/alanz/i.MX6_L3.0.35_121218/ltib/rootfs/sbin CC=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-gcc AR=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ar RANLIB=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-ranlib STRIP=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-none-linux-gnueabi-strip install After all above steps done, you can check whether the necessary files under your rootfs like I did as following: http://en.wikipedia.org/wiki/ExFAT#cite_note-uspatent-2alanz@alanz-VirtualBox:~/i.MX6_L3.0.35_121218/ltib$ find ./rootfs/ -name *exfat*./rootfs/sbin/exfatlabel ./rootfs/sbin/mount.exfat ./rootfs/sbin/fsck.exfat ./rootfs/sbin/dumpexfat ./rootfs/sbin/exfatfsck ./rootfs/sbin/mount.exfat-fuse ./rootfs/sbin/mkexfatfs ./rootfs/sbin/mkfs.exfat alanz@alanz-VirtualBox:~/i.MX6_L3.0.35_121218/ltib$ find ./rootfs/ -name *fuse*./rootfs/usr/include/fuse ./rootfs/usr/include/fuse/fuse_common_compat.h ./rootfs/usr/include/fuse/fuse_compat.h ./rootfs/usr/include/fuse/fuse_lowlevel_compat.h ./rootfs/usr/include/fuse/fuse_opt.h ./rootfs/usr/include/fuse/fuse_lowlevel.h ./rootfs/usr/include/fuse/fuse.h ./rootfs/usr/include/fuse/fuse_common.h ./rootfs/usr/include/fuse.h ./rootfs/usr/src/linux/include/linux/fuse.h ./rootfs/usr/lib/libfuse.so ./rootfs/usr/lib/libfuse.a ./rootfs/usr/lib/libfuse.so.2.9.2 ./rootfs/usr/lib/libfuse.la ./rootfs/usr/lib/libfuse.so.2 ./rootfs/sbin/mount.exfat-fuse Check Steps can be referenced by the steps presented on internet. NOTE: The directory name "/home/alanz/i.MX..." should be revised per your self development environment.

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. NOTE: See this link to instrument a board with a Smart Sensor. Overview The i.MX Power Profiler system consists of one to fourteen "smart" current sensors, an aggregator shield, and a Kinetis FRDM board (the FRDM-KL25 has been used in prototyping but the FRDM-K64F and FRDM-K66F should also be fully compatible). One of the biggest improvements of this system over its preceeding dual-range measurement system is that the microcontroller on each sensor board allows near-simultaneous measurement of all instrumented rails on a board. The dual range profiler has only a single MCU for all sensors, so only one measurement can be made at a time.  It is intended to be used to instrument one to fourteen rails of a target i.MX appliation board. Ideally, the target board will have been designed with a matching/mating power sense footprint for each rail to be measured.  Each smart sensor can sense current in three ranges with three current sense amplifiers. They are "smart" because each sensor board has a Kinetis KL05Z on it to control the switching FETs and to digitize the analog signals (the sense amplifier outputs and the target's power supply rail voltage). A 1% voltage regulator on each smart sensor provides a good voltage reference right next to the KL05Z to ensure better ADC accuracy. Each smart sensor board communicates via I2C. The aggregator shield has three I2C bus extenders (PCA9518) which essentially provide a dedicated I2C bus for each of the connected smart sensors. The FRDM board's I2C is also connected to one of the bus extenders ports. Individual GPIO lines are routed to each smart sensor's connected along with a ganged reset and trigger line for all of the connected smart sensors. A boost regulator generates almost 12V from the FRDM board's 5V supply, which is used for all the switching FETs on the smart sensor boards. The FRDM board's 5V rail is also routed to each smart sensor, which is regulated down to 3.3V locally on each connected smart sensor. Here is a photo of the very first prototypes after moving to 10-pin 0.05" spaced headers and ribbon cables instead of FFC: The smart sensor is intended to mate with through-hole current sense tap points on the target i.MX application board. Three holes spaced at 0.05" each. When not instrumented with sensor, a short needs to be placed across the outer two pins so that the board will function normally. The through hole connections provide physical protection to the target board, keeping traces from getting ripped off. The ground connection in the center provides a reference for meauring the rail voltage on the target board. A partial layout example of the implementation of the current sense footprint is below, where two 0805 shorting resistors in parallel are placed on each side of the holes. The top trace connects to the regulator output and the bottom to the load, usually an i.MX power supply rail. To include the current sense footprint into a board during the design phase, it should be configured as in the following partial schematic:  Every effort should be made to place the feedback on the i.MX side of the sense points so that the regulator compensates for the additional series resistance of the smart sensor, which effectively eliminates the additional series resistance the smart sensor adds. The Feedback should be before the smart sensor if the switching supply won't tolerate the additional series resistance (i.e., output becomes unstable).

Pre-requisites: An TFTP server U-boot with TFTP capabilities If you need to run a script (for example, running multiple setenv's commands) in U-boot for many boards, you can instead create a U-boot script (called script image), place it into your tftp folder, then ask U-boot to fetch it and run it. For example, you want to run the following setenv instructions setenv loadaddr 0x10800000 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666' setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc dev 3;mmc read ${loadaddr} 0x800 0x2000;bootm' run bootcmd_mmc save it into a file, I choose the name 'myscript'; under your <U-boot folder>/tools, execute $ mkimage -T script -C none -n 'My Script' -d myscript myscript.img and copy myscript.img file into your TFTP folder. On the target, set the following two variables (serverip and bootcmd) # Set the Server IP, where the TFTP server is running setenv serverip <the server IP> # In case the server IP is static, you can place this line into the U-boot script setenv scriptaddr 0x10700000 setenv scriptname myscript.img # You can use either TFTP or DHCP setenv tftpcmd tftp # or 'dhcp'  in case you want to use dhcp U-boot command # Not needed for dhcp setenv ipaddr <the target IP> # needed in case the command tftp is used setenv gatewayip <the Gateway IP> # needed in case the command tftp is used setenv bootcmd '${tftpcmd} ${scriptaddr} ${scriptname}; source ${scriptaddr}' saveenv reset That is all you need to do. Enjoy U-booting!

   

HDMI Dongle SW: The attachment is an HDMI dongle patch based on R13.4 GA. The patches include r13.4-ga-add-on-patches. You can patch it after applying R13.4 GA patch such as add-on patches. You can run script to revb_dongle_patch_install.sh to apply these patches. How to apply the hdmidongle_REVB_R13.4_patch-20121115.tgz: 1. Suppose your android source top is ~/myandroid 2. tar zfvx hdmidongle_REVB_R13.4_patch-20121115.tgz -C ~/ 3. copy revb_dongle_patch_install.sh to ~/ 4. cd hdmidongle_REVB_R13.4_patch 5. ~/revb_dongle_patch_install.sh 6. The  revb_dongle_patch_install.sh will take ~/myandroid as default directory to do patch 7. If your android source tree top is not ~/myandroid. For example, ~/myandroid_ICS, please run ~/revb_dongle_patch_install.sh ~/myandroid_ICS   The following is the release notes for  hdmidongle_REVB_R13.4_patch-20130118.tgz 1. New features:    a. uboot fastboot    b. ldo bypass    c. ntfs support    d. bluetooth A2DP   2. Bug fix    a. WifiDirect connect issue    b. realtek throughput issue with TPLink AP   3. File list:    README.TXT                                      --- this file    0001-uboot_fastboot.patch                       --- uboot fastboot  patch    0002-LDOBYPASS.patch                            --- enable ldo bypass  patch    0003-WifiDirect.patch                           --- wifi direct connect patch    0004-ntfs_support.patch                         --- ntfs support patch    0005-BT_enable.patch                            --- enable bluetooth A2DP    0006-1G_boot_stable.patch                       --- make 1G bootup stable    ntfs-3g.tar.gz                                  --- open source ntfs-3g for ntfs support    rtl8192ce_v4.0.0_6239.20121226_TPIOT1.tgz       --- realtek new driver for TPLink AP throughput issue    MD5SUM.TXT                                      --- md5 check sum   4. Patch guide    Please run md5sum -c MD5SUM.TXT first to confirm all the files received are ok.    All these patches are based on the patch release hdmidongle_REVB_R13.4_patch-20121115.tgz    You need to do as following: R13.4 GA--->patch hdmidongle_REVB_R13.4_patch-20121115.tgz --> patch hdmidongle_REVB_R13.4_patch-20130118.tgz    Supposed the ~/myandroid is your top directory of the android source tree.    Please run the following command to apply the patches .    $tar zfvx hdmidongle_REVB_R13.4_patch-20130118.tgz -C ~/    $cd ~/myandroid    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0001-uboot_fastboot.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0002-LDOBYPASS.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0003-WifiDirect.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0004-ntfs_support.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0005-BT_enable.patch --verbose    $git apply  ~/hdmidongle_REVB_R13.4_patch-20130118/0006-1G_boot_stable.patch --verbose    $rm -rf kernel_imx/drivers/net/wireless/rtl8192ce    $tar zfvx ~/hdmidongle_REVB_R13.4_patch-20130118/rtl8192ce_v4.0.0_6239.20121226_TPIOT1.tgz    $tar zfvx ~/hdmidongle_REVB_R13.4_patch-20130118/ntfs-3g.tar.gz -C external   5. Build and run     new patch 0007-battery_always_full.patch:   Some games check the battery capacity to determine, it could run or not. But on the hdmi dongle we have no real battery, it makes some games can not run on the hdmi dongle.  We enable the fake battery let the andorid feel it has battery and it is 100% full. 1. Please use this patch after patch hdmidongle_REVB_R13.4_patch-20130118.tgz 2. suppose your android top directory is ~/myandroid and you put he 0007-battery_always_full.patch in your home directory ~ 3. cd ~/myandroid 4. git apply --verbose ~/0007-battery_always_full.patch 5. please rebuild bootimage and run   patch   0008-boot_unlock_screen.patch: When bootup, it goes into desktop rather than screen locker.   1. suppose your android top directory is ~/myandroid and you put the 0008-boot_unlock_screen.patch in your home directory ~ 2. cd ~/myandroid 3. git apply --verbose ~/0008-boot_unlock_screen.patch 4. please rebuild systemtimage and run 2. cd ~/myandroid 3. git apply --verbose ~/0008-boot_unlock_screen.patch patch 0009-uboot-enable-mmu-fix.patch: This patch is for some issue in mmu enable. It will improve all the modules in uboot.   1. suppose your android top directory is ~/myandroid and you put the 0009-uboot-enable-mmu-fix.patch in your home directory ~ 2. cd ~/myandroid 3. git apply --verbose ~/0009-uboot-enable-mmu-fix.patch 4. please rebuild uboot  and rub     patch tarball   hdmidongle_REVB_R13.4_patch-20130123.tgz:   hdmidongle_REVB_R13.4_patch-20130123.tgz contains 0007-battery_always_full.patch  0008-boot_unlock_screen.patch 0009-uboot-enable-mmu-fix.patch remove attached files here: 0007-battery_always_full.patch  0008-boot_unlock_screen.patch 0009-uboot-enable-mmu-fix.patch     Remove hdmidongle_REVB_R13.4_patch-20130123.tgz, hdmidongle_REVB_R13.4_patch-20130118.tgz and upload hdmidongle_REVB_R13.4_patch-20130124.tgz   hdmidongle_REVB_R13.4_patch-20130124.tgz  contains all patches in hdmidongle_REVB_R13.4_patch-20130123.tgz, hdmidongle_REVB_R13.4_patch-20130118.tgz. Please use the  hdmidongle_REVB_R13.4_patch-20130124.tgz.   hdmidongle_REVB_R13.4_patch-20130131.tgz: Besides all the patches released before. Three more patches are added in this patch tar ball.     0010-boot_disable_screenlocker.patch                     --- For fix  0008-boot_unlock_screen.patch 0011-wm8326-DC_CONTROL_RATE.patch                        --- Change the wm8326 pmic rate to immediate voltage change 0012-Added-default-video-mode-check-make-sur.patch       --- Video mode check   hdmidongle_REVB_R13.4_patch-20130201.tgz:   Just change the readme  to place emphasis on   the 0006-1G_boot_stable.patch reverse   Reverse patch 0008-boot_unlock_screen.patch and 0006-1G_boot_stable.patch   0008-boot_unlock_screen.patch: it has some problem but doesn't do any harm to the hdmi dongle.                                                  Please use 0010-boot_disable_screenlocker.patch, instead. 0006-1G_boot_stable.patch:  The patch take more cpu delay to adapt the pmic, we change the pmic setting                                             in  0010-boot_disable_screenlocker.patch. This patch is no needed. And it will lower                                            the performance. Please reverse it.                                            cd ~/myandroid                                            git apply --verbose ~/0006-1G_boot_stable.patch                                                                                           hdmidongle_REVB_R13.4_patch-20130221.tgz: There are three important fixes include in this release. They make the dongle stable. 1. lowmem killer issue fix 2. Update realtek wifi driver to fix the soft ap issue 3. Wifi p2p framework fix to resovle wifi direct only one side work issue   Please read the README.TXT for detail and the other changes.   hdmidongle_REVB_R13.4_patch-20130308.tgz: This patch tar ball include all the patches in hdmidongle_REVB_R13.4_patch-20130221.tgz. Besides, it has a new patches 0020-DL_WifiDirect_Concunrrent_crash_fix.patch to fix the crash issue on DL board.   HDMI Dongle HW:   HDMI Dongle schematic, pcb, gerber and BOM have been attached, the detailed hardware feature has been list below:   Android 4.x HDMI Dongle SPECIFICATION Core Configure Operating System Android 4.x Operating System Based on Micro-PC Platform CPU Processor Freescale i.MX6x DualLite/Quad Core DRAM Storage DDR3 1GigaByte Size, Data rate 1066MT/s Flash Storage 4GigaByte NAND flash ROM Power System Power Supply DC JACK / Micro USB : 5V/2A LED Status Green: Power ON; Red: System Run Socket/Connector MicroSD Socket SDXC Support, Up to 32GB size USB HOST 2.0 USB 2.0 HOST Support USB OTG 2.0 USB 2.0 OTG Support Display/Audio HDMI Output HDMI TypeA Plug connector, 1080p@60Hz output Video Decoder Support Variety of Video Format: MPEG4/H.263/H.264/MJPEG/Xvid/VC-1/WMV/MPEG2/VP8... Audio Decoder Support Variety of Audio Format: MP3/AAC/LPCM/FLAC/AMR/AC3/WMA/Vorbis GPU Support GC2000 GPU core,2D/3D engine support,OpenGL support Wireless Network WiFi Network IEEE 802.11b/g/n,Up to 300Mbps,AP/P2P/Sta Mode Support Others Key Recovery key support RevB2     OTT TV BOX LINK: https://community.freescale.com/docs/DOC-94561   JB4.2 patches link : Patches for HDMI Dongle JB4.2.2_1.0.0-GA Release

It is based on L3.0.35_GA4.1.0 BSP.   In default Linux BSP, there are 3 kinds of de-interlace mode, motion =0,1,2 mode, motion mode 0 and 1 will use three fields for de-interlace, and motion mode 2 wil use one field for de-interlace, so the whole fps is 30. In this mode, for motion mode 0 and 1, field 1,2,3 was used for first VDI output frame of display; and field 3,4,5 was used for second VDI output frame of display; field 5,6,7 was used for third VDI output frame of display. One field data (such as 2,4,6) was used only once, so there is data lost.   After applied these patches, the VDI de-interlace output will be 60fps: for motion mode 0 and 1, field 0,1,2 was used for first VDI output frame of display; and field 1,2,3 was used for second VDI output frame of display; field 2,3,4 was used for third VDI output frame of display. So all field data will be used twice, there is no video data lost, the VDI quality was improved.   Kernel patches: 0001-Add-MEM-to-VDI-to-MEM-support-for-IPU.patch 0002-Add-IPU-IC-memcpy-support.patch 0003-IPU-VDI-support-switch-odd-and-even-field-in-motion-.patch 0004-IPU-VDI-correct-vdi-top-field-setting.patch   mxc_v4l2_tvin_imx6_vdi_60fps.zip: this is the test application sample code.   Test commands, parameter "-vd" means double fps VDI: ./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 720 -oh 480 -m 0 -vd  

Instrumenting A Board To instrument a board, the connection between the power supply and the target device needs to be broken, usually via a series resistor that's placed on the board. Sometimes the inductor needs to be lifted if no series resistor was included on the rail by the board's designer. In the ideal case, through-hole connections were also provided on the board for the connection of these off-board sensors. Here are three close-up photos that show several boards that have been instrumented: In all three cases, the sensors stand in place via the two outer current carrying wires. The middle and right used insulated wires where as the one on the left used bare wires. In all three cases, the sensor's + connection needs to go towards the power supply and the - connection goes to the target device. The outer wires here are 24-26 gauge. (The relatively heavy gauge wire is used to keep the series resistance of inserting a smart sensor to a minimum.) The ground connection is the middle hole of the smart sensor. In the left and middle photos, a 30 gauge wire connects to the middle hole ground connection on the  board. In the right photo, the ground wire was more conveniently added to a big cap just below the bottom of edge of the photo. Here are wider angle view photos of two of the boards above: The sensors on the left are free-standing since the current carrying wires are stiff enough to hold them upright. Care must be taken since too much flexing will cause a wire to break. Too much bending can also cause a short to the board (and that's why insulated wires were used on these boards). The board on the right has the sensors laying parallel to the board. They are not affixed to the board, but a wire is wrapped around the bundle of ribbon cables out of view past the right edge of the photo. For boards without the through hole connections, the smart sensors need to be immobilized to keep from pulling the SMT pads off the board. If there is room on the board or sides of connectors or large components, the sensors may be attached down with foam double-sticky tape (see photo below, sensor affixed on top i.MX7ULP): For boards where there are no convenient unpopulated areas or there are too many sensors, some other means needs to be devised to immoblize the smart sensors. In the left photo below, two inductors per sensor have been flipped and the two sensors inserted to instrument the two rails. The solder pads on the inductors would easily be broken off by any movement of the smart sensors, so a cage with clamps to hold the ribbon cables was 3D printed. On the back side, there is room for the aggregator to be zip tied to the bottom plate, so the instrumented board can be moved as a single unit with minimal flexing of the ribbon cables.

When configuring i.MX6 IPU IDMAC CPMEM parameters or debugging it, it's hard to find the value of a parameter inside the 160 bits word. This web tool separates the 160 bits words into parameters making it easier to check their values. Link: i.MX Tools 

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.

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‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

In the i.MX51 default WINCE6  release, the eCSPI doesn't support multiple bursts mode and set the wait states. Attached was the document and code for how to enable the multiple bursts mode and how to set the wait states between two burst.

We have a ATK tool which can program image, also it can burn fuse for i.MX51. Since fuse is one time program, so please take care the fuse can't be turn back after programmed.