When the customer want to use the PCIE module on the i.MX6SX SDB board, they can use the oscillator to do the pretset, there are the test report.

Abstract: On the time otp driver initializes, it will check the mac bits of eFuse,  when the value is invalid, generate a random mac, and program  it to eFuse. Environment: i.mx6dl android-4.2.2 kernel-3.0.35 Changes: 1. kernel_imx/arch/arm/mach-mx6/mx6_fec.c ---------------------------------------------------------------- void __init imx6_init_fec(struct fec_platform_data fec_data) {   fec_get_mac_addr(fec_data.mac);   if (!is_valid_ether_addr(fec_data.mac))       fec_data.mac[0] = 0x10; // changed by xxx   if (cpu_is_mx6sl())   imx6sl_add_fec(&fec_data);   else   imx6q_add_fec(&fec_data); } 2. kernel_imx/drivers/char/fsl_otp.c ---------------------------------------------------------------- //add by xxx static void check_otp_mac(void) {   unsigned int index_mac0 = 34;   unsigned int index_mac1 = 35;   u32 value_mac0 = 0;   u32 value_mac1 = 0;   u32 value_random_mac0 = 0;   u32 value_random_mac1 = 0;   char otp_mac[6], random_mac[6];   memset(otp_mac, 0, sizeof(otp_mac));   memset(random_mac, 0, sizeof(random_mac));   mutex_lock(&otp_mutex);   //get   if (otp_read_prepare(otp_data)) {   mutex_unlock(&otp_mutex);   return 0;   }   value_mac0 = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUSTn(index_mac0));   value_mac1 = __raw_readl(REGS_OCOTP_BASE + HW_OCOTP_CUSTn(index_mac1));   otp_read_post(otp_data);   mutex_unlock(&otp_mutex);   if(value_mac0 != 0 && value_mac1 != 0)   {   otp_mac[5] = value_mac0 & 0xff;   otp_mac[4] = (value_mac0 >> 😎 & 0xff;   otp_mac[3] = (value_mac0 >> 16) & 0xff;   otp_mac[2] = (value_mac0 >> 24) & 0xff;   otp_mac[1] = value_mac1 & 0xff;   otp_mac[0] = (value_mac1 >> 😎 & 0xff;   }   printk("otp_mac=%pM\n", otp_mac);   //check   if (!is_valid_ether_addr(otp_mac))   {   random_ether_addr(random_mac);   printk("get random mac:%pM\n", random_mac);   //set   value_random_mac0 = 0;   value_random_mac0 = value_random_mac0 | random_mac[2];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[3];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[4];   value_random_mac0 = (value_random_mac0 << 😎 | random_mac[5];   value_random_mac1 = 0;   value_random_mac1 = value_random_mac1 | random_mac[0];   value_random_mac1 = (value_random_mac1 << 😎 | random_mac[1];   mutex_lock(&otp_mutex);   if (otp_write_prepare(otp_data)) {   mutex_unlock(&otp_mutex);   return 0;   }   otp_write_bits(index_mac0, value_random_mac0, 0x3e77);   otp_write_bits(index_mac1, value_random_mac1, 0x3e77);   otp_write_post(otp_data);   mutex_unlock(&otp_mutex);   } } //end 3.  kernel_imx/drivers/char/fsl_otp.c ---------------------------------------------------------------- static int __devinit fsl_otp_probe(struct platform_device *pdev) {   ...   retval = sysfs_create_group(otp_kobj, &attr_group);   if (retval)   goto error;   mutex_init(&otp_mutex);   //add by xxx   check_otp_mac();   //end

Assemble wxWidgets version 2.8. TinyX used. Powered by touchscreens 4 "- 8".

iWave's i.MX6 UltraLite (i.MX6UL) based SODIMM CPU module integrates power efficient high performance ARM Cortex A7 CPU core operating up to 528MHz speed. iMX6 UL SOM is ultra-compact in size and integrated with on-board PMIC, Flash, DDR3 and dual Ethernet PHY. The SOM is ideally suitable for the cost & power optimized general embedded and industrial applications.                                                                                                                                                                                                                                                                                                    i.MX6UL SODIMM Development Kit    i.MX6UL SODIMM SOM                                                                                                                                                                                                                                                                                                 Benefits: Ultra-compact form factor module with size of 67.6mm x 29mm Long term support: 7+ years Technical & Quick customization support Compatible with ARM Cortex A9 i.MX6 Q/D/S SODIMM SOM Highlights: Power efficient ARM Cortex-A7 @ 528MHz Advanced hardware enabled security PMIC with DVFS support Industrial temperature support available  Features: CPU: Freescale’s i.MX6UL1/2/3 @ 528MHz ARM Cortex A7 PMIC: Freescale PF3000 Memory: 256MB DDR3 RAM(Expandable) 256MB NAND Flash (Expandable) MicroSD Slot (Optional) 1 eMMC Flash (Optional) 1 QSPI Flash (Optional) 1 Communication: 10/100 Ethernet PHY – 2 Ports SODIMM Edge Interfaces: Debug UART Data UART – 2 Ports CAN – 2 Ports SD(4-Bit) – 1 Port 10/100 Ethernet – Up to 2 Ports 2 USB OTG – 2 Ports 24bpp RGB display port 8-Bit Parallel Camera Port I2S Audio or JTAG I2C x 1 Port PWM GPIOs OS Support: Linux 3.14.28 Power Supply: 3.3V @ 1A through SODIMM edge Note 1: At a time either NAND Flash or eMMC & QSPI flash or uSD & QSPI flash can be used in the SOM. By default NAND Flash is supported. Note 2: If 2 nd Ethernet (ENET2) not used, it can be used as additional 3 UARTs or Key pad 4x4 or RMII interface. Target Applications: Industrial HMI & Access Control Energy management & IOT gateway Industrial control & automation White goods & Smart appliances Medical & Healthcare equipments Mobile POS & Secure e-commerces To send us an enquiry on this product, please click here Enquiry Form To get more details on this product, please write us on [email protected]

imx53 DDR stress tester V0.042

1.  Software change for Certification Test Compared to standard Linux/Android release, you may need to do below software changes to implement the certification tests, it is applicable from imx_3.10.31_1.1.0 Linux BSP GA release, for the release before that, user may need to apply the related patches before doing below things, and some examples may be different for former releases, the user needs to change accordingly. See the detailed information in this document “How to do USB Compliance Test for 3.10.y kernel”. And there is also a link describes the patch for USB Certification Test: Patch to make i.MX6DQ USB to support test modes for certification test 2. I.MX6 series USB Certification Guide http://cache.freescale.com/files/microcontrollers/doc/user_guide/IMXUSBCGUG.pdf Include the descriptions of all the Certification Test requirements, equipment, procedures for I.MX6 series. For example, Host/Device High Speed Eye Diagram Test(眼图测试).   3. Description of USBCertification related Registers AN4589 Configuring USB on i.MX 6 Series Processors http://cache.freescale.com/files/32bit/doc/app_note/AN4589.pdf   4. I.MX6Q/I.MX6DL/I.MX6SL/ I.MX6SX Certification Reports, see attachments   5. Checklist and TPL, see attachments. Original Attachment has been moved to: I.MX6SX-Checklist-and-TPL.zip

Understanding and using the .sdcard format One very useful feature enabled by default in both the Yocto Communiy BSP and Release BSP is the option of generating the baked images in .sdcard format. If the .sdcard format is not selected by default it can be enabled on the conf/local.conf file by adding it with the IMAGE_FSTYPES as follow: IMAGE_FSTYPES="sdcard" It’s important to note that if this variable is specified only the file systems typed defined will be created. The default value used most often for this variable is: IMAGE_FSTYPES="tar.bz2 ext3 sdcard" The .sdcard format creates an image with all necessary partitions and loads the bootloader, kernel and rootfs to this image. You can just low level copy the data on this file to the SD card device using dd as on the following command example: $ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync Partitions used on the .sdcard file The .sdcard partitions looks as follow: IMAGE_ROOTFS_ALIGNMENT Unpartitioned space reserved for the bootloader BOOT_SPACE Kernerl and other data ROOTFS_SIZE The rootfs. Granting more free space on the RootFS partition The size of the .sdcard file will depend solely on the size of the rootfs. This means that the resulting file won’t partition all our SD Card capacity unless we add extra space to the rootfs partition. (Of course there is always the option of editing the partitions once loaded on the SD Card) In order to add more space you may use the IMAGE_ROOTFS_EXTRA_SPACE variable. You may add it to your local.conf file with the added free disk space in Kbytes. For example, if you would like to guarantee 1GB of extra space you may add the following line to your local.conf file. IMAGE_ROOTFS_EXTRA_SPACE = "1048576" It is important to note that this is space additional to the IMAGE_OVERHEAD_FACTOR variable which defines a multiplier that is applied to the initial image size. This is only applied when the multiplier times the By default, the build process uses a multiplier of 1.3 for this variable. This default value results in 30% free disk space added to the image when this method is used to determine the final generated image size. This would mean that there should be 30% of free disk space before post install scripts. If you wish for more space you may edit this variable as bellow: IMAGE_OVERHEAD_FACTOR = "1.5" Which would result in 50% free disk space added to the image, before post install scripts and without considering overhead that may come from the package management system. How the IMAGE_ROOTFS_SIZE is calculated This variable is also measured in Kbytes and it’s determined by the OpenEmbedded build system using an algorithm that considers the initial disk space used for the generated image, the requested size for the image (trough the overhead factor) and the additional free space to be added to the image (trough the extra space variable). The build system first runs a du (disk usage) command to determine the size of the rootfs directory tree. If the IMAGE_ROOTFS_SIZE current value is larger than the disk usage times the overhead factor only the extra space is added. If the IMAGE_ROOTFS_SIZE is smaller than the disk usage times the overhead factor then the disk usage is multiplied times the overhead factor prior to adding the extra space. IMAGE_ROOTFS_SIZE must be set on a default value which is usually very low as it’s just initialized and updated with the actual size requirements each time an image is baked. You may also use this variable directly in order to select the space you would like to allocate to the RootFS.For example setting the RootFS to 2GB would require the following addition to the local.conf file: IMAGE_ROOTFS_SIZE = “2097152” IMAGE_OVERHEAD_FACTOR = “1.0” In this example we would leave the overhead factor to 1 so no extra space is added since we’re specifying the rootfs size that we want.

1  Introduction   This document explains how to configure a cross compiler running in iMX6Q. The target is the Kinetis L family.  For the iMX6Q, Yocto is used to generate the iMX6Q image. 2 Requirements   Basic knowledge of Yocto and Linux is required. The steps explained were performed for the iMX6Q SABRE-SD and the Freedom KL25.  Installation of Yocto in your host system is needed too. 3 Procedure   The chosen method to configure the cross compiler for the Kinetis L, needs a native compiler that will run in the iMX6Q. Below are the general steps:   Generate native compiler for the iMX6Q and adding the needed packages for the configuration. Get and extract the source packages of the compiler. Configure, build and install the packages Test the generated cross compiler   3.1 Generating packages and native compiler for the iMX6Q   The iMX6Q image needs certain packages in order to configure and generate correctly the cross-compiler. After setting up the environment and chose the MACHINE the below lines added in the local.conf file to install those packages in our rootfs:   IMAGE_INSTALL_append = " gcc g++ binutils libgcc libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev gawk gzip perl autoconf automake libtool gettext gperf tcl guile gmp mpfr make m4 texinfo flex bison git"   The image to generate is the core-image-minimal:   bitbake core-image-minimal   Once the building is finished, a native compiler for the iMX6 and other packages needed to configure the Kinetis Compiler should be added to the Yocto image. 3.2 Getting and Extracting the Kinetis L compiler   The arm cross compiler version was gotten from CodeSourcery. arm-2011.03-42-arm-none-eabi is used in this document. You can get the source code by:   wget https://sourcery.mentor.com/sgpp/lite/arm/portal/package8736/public/arm-none-eabi/arm-2011.03-42-arm-none-eabi.src.tar.bz2   Once the image was built, boot the imx6 board with this image. Copy the source code (arm-2011.03-42-arm-none-eabi.src.tar.bz) in your target that is running Linux and extract the files.   For example, a new folder was created in /home/root directory:   $ mkdir gcc_test $ cd gcc_test   And extract the files in this folder:   $ tar –jxvf  arm-2011.03-42-arm-none-eabi.src.tar.bz2 $ cd arm-2011.03-42-arm-none-eabi   Create a source and a build folder:   $ mkdir source build   Move all the files to the source folder:   $ mv *.tar.bz2 source/   Create a new folder in /opt where the kinetis cross compiler will be installed   $ cd /opt              $ mkdir arm-none-eabi   3.3 Configure, Build and Install Kinetis Compiler on the iMX6   To configure, build and install the compiler these general steps are followed for certain packages:   Extract the package Configure the package Build and Install the package   Create an environment variable that will specify where the cross compiler will be installed:   $ export INSTALL_PREFIX=/opt/arm-none-eabi   3.3.1 GMP Package   Extract the gmp files: $ cd ~/gcc_test/arm-2011.03-42-arm-none-eabi/source $ tar –jxvf gmp-2011.03-42.tar.bz2   Create a new folder in build directory. This folder will contain a generated Makefile that will be used to build and install the package:   $ cd ../build $ mkdir gmp $cd gmp   Configure the package: $ ../../source/gmp-2011.03/configure --prefix=$INSTALL_PREFIX --build=arm-poky-linux-gnueabi CC=arm-poky-linux-gnueabi-gcc CXX=arm-poky-linux-gnueabi-g++  --disable-newlib-supplied-syscalls --disable-libgloss --disable-nls --disable-shared   Build and Install the package $make $make install 3.3.2 MPFR Package   Extract the mpfr files: $ cd ~/gcc_test/arm-2011.03-42-arm-none-eabi/source $ tar –jxvf mpfr-2011.03-42.tar.bz2   Create a new folder in build directory. This folder will contain a generated Makefile that will be used to build and install the package:   $ cd ../build $ mkdir mpfr $cd mpfr   Configure the package: $ ../../source/mpfr-2011.03/configure --prefix=$INSTALL_PREFIX  --build=arm-poky-linux-gnueabi --target=arm-none-eabi CC=arm-poky-linux-gnueabi-gcc CXX=arm-poky-linux-gnueabi-g++ --with-gmp=$INSTALL_PREFIX --disable-shared   Build and Install the package $make $make install   3.3.3 MPC Package   Extract the mpc files: $ cd ~/gcc_test/arm-2011.03-42-arm-none-eabi/source $ tar –jxvf mpc-2011.03-42.tar.bz2   Create a new folder in build directory. This folder will contain a generated Makefile that will be used to build and install the package:   $ cd ../build $ mkdir mpc $cd mpc   Configure the package: $ ../../source/mpc-0.8.1/configure --prefix=$INSTALL_PREFIX --target=arm-none-eabi --build=arm-poky-linux-gnueabi CC=arm-poky-linux-gnueabi-gcc CXX=arm-poky-linux-gnueabi-g++ --with-gmp=$INSTALL_PREFIX --with-mpfr=$INSTALL_PREFIX --disable-shared   Build and Install the package $make $make install   3.3.4 Binutils Package                                                                                 Extract the binutils files: $ cd ~/gcc_test/arm-2011.03-42-arm-none-eabi/source $ tar –jxvf binutils--2011.03-42.tar.bz2   Create a new folder in build directory. This folder will contain configure the package:   $ cd ../build $ mkdir binutils $cd binutils   Configure the package: $ ../../source/binutils-2011.03/configure --prefix=$INSTALL_PREFIX --target=arm-none-eabi --build=arm-poky-linux-gnueabi CC=arm-poky-linux-gnueabi-gcc CXX=arm-poky-linux-gnueabi-g++ --with-gmp=$INSTALL_PREFIX --with-mpfr=$INSTALL_PREFIX --with-mpc=$INSTALL_PREFIX --disable-nls --disable-werror   Build and Install the package $make MAKEINFO=true $make install MAKEINFO=true   3.3.5 GCC Package   Extract the gcc files: $ cd ~/gcc_test/arm-2011.03-42-arm-none-eabi/source $ tar –jxvf    Create a new folder in build directory. This folder will contain configure the package:   $ cd ../build $ mkdir gcc $cd gcc   Configure the package: $ ../../source/gcc-4.5-2011.03/configure --prefix=$INSTALL_PREFIX --target=arm-none-eabi   --build=arm-poky-linux-gnueabi  --host=arm-poky-linux-gnueabi  CC=arm-poky-linux-gnueabi-gcc CXX=arm-poky-linux-gnueabi-g++ --enable-languages="c" --with-gnu-ld --with-gnu-as --with-newlib --disable-nls --disable-libssp --with-newlib --without-headers --disable-shared --disable-threads  --disable-libmudflap --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-libffi  --enable-extra-sgxxlite-multilibs  --with-gmp=$INSTALL_PREFIX --with-mpfr=$INSTALL_PREFIX --with-mpc=$INSTALL_PREFIX   Build and Install the package $make $make install     3.4 Testing the Cross Compiler   To test the Cross compiler it is necessary to add the path of the installation to the PATH variable.   $ export PATH=/opt/arm-none-eabi/bin/:$PATH   To check the version of the cross compiler:   $ arm-none-eabi-gcc –version arm-none-eabi-gcc (GCC) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE   Attached you can find a folder that contains a simple KL25 example that can be compiled in the iMX6 and then flash the Freedom KL25 with the OpenSDA. This means that you have to attach the USB OpenSDA to the OTG port of the iMX6 board.   Type the next in the hello folder (/Kinetis  GNU/KL25_TEST/KL25/hello)   $make clean $make   This will generate a main.srec file that can be copied to the USB MSD device featured by the OpenSDA.   $cp main.srec /meida/sda1 $sync   After this, the RGB LED in the Freedom KL25 will toggle. Original Attachment has been moved to: KL25.tar.zip

For detailed view, please check out the attached file.

Dear all, Below a small howto to get rid of the usual file copy to your rootfs. This is my way of automatically include files to my generated image under yocto. 1. Create a recipe Under source/meta Below in plain text: SUMMARY = "My test videos" DESCRIPTION = "Test Videos" HOMEPAGE = "" LICENSE = "CLOSED" MY_FILES = "/home/freerod/Videos/demo_video_VGA_25fps.MP4" inherit allarch do_install() { install -d ${D}${datadir}/movies install -m 0644 ${MY_FILES} ${D}${datadir}/movies/ } FILES_${PN} += "${datadir}/movies" This aims at creating a movies directory in: /usr/share/movies within the rootfs, with the named demo_video_VGA_25fps.MP4 in it 2. CORE_IMAGE_EXTRA_INSTALL += "myvideos" 3. Check that the video will be put into the generated rootfs: freerod@ubuntu:~/mx6/fsl-yocto-3.14.28_1.0.0/build_mx6dl$ ll tmp/work/all-poky-linux/myvideos/1.0-r0/packages-split/myvideos/usr/share/movies/demo_video_VGA_25fps.MP4 -rw-r--r-- 2 freerod freerod 14076709 Jun  2 01:40 tmp/work/all-poky-linux/myvideos/1.0-r0/packages-split/myvideos/usr/share/movies/demo_video_VGA_25fps.MP4

1 How to build out userdata.img and cache.img The default fsl android  bsp don't support userdata.img and cache.img. You need add the below patch to build  out these images. The hardware for below patch is imx7D. You can adjust your patch according your hardware. diff --git a/imx7/BoardConfigCommon.mk b/imx7/BoardConfigCommon.mk index 14e4881..c207727 100644 --- a/imx7/BoardConfigCommon.mk +++ b/imx7/BoardConfigCommon.mk @@ -61,7 +61,11 @@ BOARD_BOOTIMAGE_PARTITION_SIZE :=  16777216 BOARD_RECOVERYIMAGE_PARTITION_SIZE := 16777216 BOARD_SYSTEMIMAGE_PARTITION_SIZE := 377487360 +BOARD_USERDATAIMAGE_PARTITION_SIZE := 576716800 +TARGET_USERIMAGES_USE_EXT4 := true +BOARD_CACHEIMAGE_PARTITION_SIZE := 69206016 +BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ext4 BOARD_FLASH_BLOCK_SIZE := 4096 TARGET_RECOVERY_UI_LIB := librecovery_ui_imx - +TARGET_USERIMAGES_SPARSE_EXT_DISABLED := true 2  How to add  pre-install apk. I add a content pre-app in device/fsl/imx7. helloworld.apk is the added pre-install apk. diff --git a/imx7/pre-app/AnTutuV2.4.apk b/imx7/pre-app/helloworld.apk new file mode 100755 index 0000000..a96003a Binary files /dev/null and b/imx7/pre-app/AnTutuV2.4.apk differ diff --git a/imx7/sabresd_7d.mk b/imx7/sabresd_7d.mk index d7c5c76..11be86c 100644 --- a/imx7/sabresd_7d.mk +++ b/imx7/sabresd_7d.mk @@ -27,7 +27,8 @@ PRODUCT_COPY_FILES += \         device/fsl/common/input/20b8000_kpp.idc:system/usr/idc/20b8000_kpp.idc \         device/fsl/common/input/20b8000_kpp.kl:system/usr/keylayout/20b8000_kpp.kl \         device/fsl/sabresd_7d/audio_policy.conf:system/etc/audio_policy.conf \ -       device/fsl/sabresd_7d/audio_effects.conf:system/vendor/etc/audio_effects.conf +       device/fsl/sabresd_7d/audio_effects.conf:system/vendor/etc/audio_effects.conf \ +       device/fsl/imx7/pre-app/*:data/. 3 What are userdata.img and cache.img for? userdata.img: we need to integrate some customized APKs which should be preinstalled but should be able removed/updated by end user after product delivery. Which means they cannot be installed as system APPs in /system/app folder but User APPs in /data/app folder. At this point, we need compile userimage by ourself. Cache.img: /cache include the content when apk start running. You may storage some special content which app need. I have not find any advantage to pre-build cache.img. Note:      a. The  userdata.img and cache.img's format is sparse ext4 image. You need convert it through simg2img.           The  tool simg2img located at lp5.1_sabresd_7d_4_20/out/host/linux-x86/bin/simg2img           You can use below command to get raw ext4 userdata.img which can be burned into emmc/sd.           out/host/linux-x86/bin/simg2img userdata.img userdata_raw.img     b. BOARD_USERDATAIMAGE_PARTITION_SIZE BOARD_CACHEIMAGE_PARTITION_SIZE define the size of data and cache partition Reference: https://community.freescale.com/docs/DOC-105215

Two year ago we have developed a 16 bit ETM adaptor to connect our PowerTrace II module with our AUTOFOCUS II preprocessor : TRACE32® Chip Support and Configurations for IMX6QUAD This adaptor is connected on the EDGE connector of the SABRE Automotive Industry board from Freescale and provide a MICTOR 38 connector compatible with 16 bit maximum ETM size. This is the maximum ETM size supported by iMX6. The maximum Trace clock frequency riched is 132 Mhz, which provide enough bandwidth to trace a full ANDROID running on Quad Core iMX6 !!! and it works perfectly. with Lauterbach tools you can debug completely Linux kernel and driver and full ANDROID support using our dalvik awareness that show you the complete call stack from low level system linux call to high level JAVA code. this adaptor is already in use on several customer from us, with perfect result. TRACE32 can now display all the code executed by the iMX6 Quad for each core, with no limitation on time recording. Linux task switch timing, profiling function, MIPS information, Detailed Tree function etc ... more detail here : TRACE32® Trace-based Profiling here below a small example of what you can see : here below the board, and schematic. in case you want the full schematic for this adaptor, please contact me, i can then provide it for free ... if you buy some Lauterbach tools 😉 Jean-Pierre Paradiso Sales Manager http://www.lauterbach.com/frames.html?tutorials.html PS : we are also developping a new ETM adapter compatible with our partner DAVE (DAVE Embedded Systems ) that develop very nice eval board on iMX6 called AXEL EVB will be available soon through the official DAVE  distributor in France : Cynetis

HI, I want to build an Ubuntu Linux operating system with LTIB, but from the user guide the host system is Ubuntu 9.04, but we can't use 'apt-get install' any package due to there are no source lists. What should we do next? Thank you!

By default Linux BSP will work with LVDS screen on i.MX 6SoloX SABRE board. To enable MCIMX28LCD on the board, following need to be modified in u-boot: setenv panel 'MCIMX28LCD' setenv fdt_file 'imx6sx-sdb-lcdif1.dtb' #add video=mxc_lcdif:SEIKO-WVGA,bpp=16 to kernel command line you’re using #For example, when booting from MMC it will be: #  setenv mmcargs 'setenv bootargs console=${console},${baudrate} root=${mmcroot} video=mxc_lcdif:SEIKO-WVGA,bpp=16' saveenv

Hi all, I'm using this patch to get BT656 output on my i.MX6Q: Patch to Support BT656 and BT1120 Output For i.MX6 BSP Now I am looking for a way to clamp the pixel values between 16 to 240. Based on the i.MX6Q Reference Manual (37.4.5.6 IC Task Parameter Memory), this can be done by setting a IC task parameter called SAT_MODE from 0 to 1, but I'm not sure how it should be done. I've inspected the ipu_disp.c code and I guess the right way to do this is calling ipu_dp_write inside __ipu_dp_csc_setup function to set SAT_MODE to 1, but know I don't know which address to give toipu_dp_write since SAT_MODE is not defined in the ipu_regs.h. Looking at other parameters addresses (e.g. DP_CSC_0) and comparing their counterpart in the Reference Manual doesn't get my anywhere either. Bests, Isaac Hi Isaac, the default BSP code doesn't support DP_CSC_YUV_SAT_MODE modification, just used the default value 0. You can reference to the ioctl "MXCFB_SET_GAMMA" to add it into mxcfb_ioctl() of file mxc_ipuv3_fb.c. Bit 11 in IPUx_DP_COM_CONF_SYNC is for DP_CSC_YUV_SAT_MODE. So you can add it in ipu_regs.h: DP_COM_CONF_CSC_DEF_BOTH = 0x00000100, + DP_COM_CONF_CSC_YUV_SAT_MODE = 0x00000800, DP_COM_CONF_GAMMA_EN = 0x00001000, For BT656 display, IC CSC was not used, it used DP CSC. This document was generated from the following discussion: How to change SAT_MODE in BT656 display output for i.MX6

i.CORE M6SX The i.Core M6SX is the latest powerful i.MX6 SoloX based SOM solution provided by Engicam in SODIMM format. The i.MX 6SoloX is the first device utilizing both the ARM Cortex-A9 and ARM Cortex-M4 cores. Its heterogeneous architecture provides a secure and robust implementation to enable concurrent execution of multiple software environments to provide an application-rich system with real-time responsiveness. Optimized for high performance energy efficient processing in general embedded, automotive, industrial and consumer applications i.CORE M6SX Cores Cortex TM -A9 @ 800 MHz core, NEON co-processor. DP FPU, L1 and L2 I/D cache Cortex TM -M4 @ 200 MHz core SP Floating point unit,  I/D chache Memories 256MB 32bit DDR3-800 512MB SLC NAND Flash Graphics and Multimedia 1x Parallel LCD 18bit output 1x LVDS output Hardware 3D/2D engine OpenGL-ES 2.0 and OpenVG1.1 Parallel Camera Interface input Touch screen Peripherals 2x SD Card interface USB OTG HS, USB HS HOST, Uart, I2C, I2S, QSPI,PCI Express SATA ADC and Video ADC input 2x Ethernet 10/100 Dimensions Standard SODIMM footprint 67,4x31.9 mm PCB size Very Low Profile Module

Please make sure design is follow below checking list before checking this guide. HW Design Checking List for i.MX6DQSDL

Hi all !      I found a problem, wiif connection issue .  When I connect to WiFi hotspots, reported a warning ！     <4>RTL871X: assoc success <4>------------[ cut here ]------------ <4>WARNING: at net/wireless/sme.c:482 __cfg80211_connect_result+0x2f4/0x32c() <4>Modules linked in: 8188eu <4>[<c0054044>] (unwind_backtrace+0x0/0x138) from [<c008c1b8>] (warn_slowpath_common+0x4c/0x64) <4>[<c008c1b8>] (warn_slowpath_common+0x4c/0x64) from [<c008c1ec>] (warn_slowpath_null+0x1c/0x24) <4>UpdateHalRAMask8188EUsb => mac_id:0, networkType:0x0b, mask:0x000fffff <4>     ==> rssi_level:0, rate_bitmap:0x000ff015 <4>[<c008c1ec>] (warn_slowpath_null+0x1c/0x24) from [<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) <4>[<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) from [<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) <4>[<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) from [<c0686ec0>] (cfg80211_event_work+0x24/0x54) <4>[<c0686ec0>] (cfg80211_event_work+0x24/0x54) from [<c00a66f0>] (process_one_work+0x12c/0x494) <4>[<c00a66f0>] (process_one_work+0x12c/0x494) from [<c00a6bc8>] (worker_thread+0x170/0x3cc) <4>[<c00a6bc8>] (worker_thread+0x170/0x3cc) from [<c00aacbc>] (kthread+0x80/0x88) <4>[<c00aacbc>] (kthread+0x80/0x88) from [<c004d408>] (kernel_thread_exit+0x0/0x8) <4>---[ end trace 14efbc2d6eba2439 ]---       This document was generated from the following discussion: 

I followed the Yocto Training up until Task #4 - Deploy and test.... and I got stuck here. I am not able to download the .sdcard image to my SD card. Do I need to format it first? It is brand new. Since the sudo dd if=core-image-base-imx6solosabresd.sdcard of=/dev/sdb1 bs=1M did not work for me, I was not able to boot from the SD on my board. The board switches are set to boot from SD4. Is imx6solosabresd the correct MACHINE to use for the solox? I tried setting MACHINE=imx6sxsabersd in the local.conf file but I got an error message (Task #2). This is why I want to try the MFGTool. I have set the board to boot from SD3 so it can go into "download mode". When I go through the MFGTool, it says No Device Connected although HID-compliant vendor-defined device shows up. This document was generated from the following discussion: 

Hi team, My customer is facing the issue of unexpected behavior of i.MX6Q SSI. The customer uses SSI as slave/Network mode. And they want to transfer 4 time-slot data. As for the register setting, RFEN0, RFEN1 and RDMAE is set to 1. And only first time slot data is transferred. Do you have any ideas about the cause of this? Thanks, Miyamoto This document was generated from the following discussion: