Introduction Hardware Connections Device Tree Configuration Rebuilding Image Requirements Kernel Device Tree Application Driver Main Init Driver Write Read Building and Run the SPI Application Driver Conclusion   Introduction   This document describes how to interface and use Xtrinsic FXLS8471Q digital accelerometer with IMX6Q processor. For this purpose, UDOO Quad board is used with NXP Linux image for IMX6QSABRE-SD board with Kernel 3.14.56 (not with Udoobuntu) to simulate working with a custom board, the process to customize and build such image for UDOO Quad board is described here: Building Linux Image with QT5 for UDOO Quad    On the sensor side FRDM-FXS-MULTI(-B) sensor expansion board which features many of the Xtrinsic sensors introduced in 2013 including the FXSL8471Q is used.   Hardware Connections    The SPI signals from FRDM-FXS-MULTI are routed to SPI1 module of UDOO Quad. FXLS8471Q provides an INT pin which is indicated on image below, however on this implementation polling method is used. Please note that Chip Select is not controlled automatically by SPI module, therefore this pin is configured as GPIO. Besides these signals, reset and power source pins were also connected.   The following figure shows the pins used in FRDM-FXS-MULTI which are connected with UDOO Quad board.           The pins used on the UDOO Quad side are shown in the images below. You can find UDOO Quad pinout diagram here Index of /download/files/pinout.                             Device Tree Configuration   As mentioned at the beginning of this document, a NXP Linux image for IMX6Q-SABRESD is used. In order to customize this image to be used with the UDOO Quad board it is necessary to build a .dtb that matches with it. This task was accomplished obtaining dts and dtsi source files listed below from Kernel Linux Repository for UDOO at UDOOboard (UDOOboard) · GitHub.   imx6qdl-udoo.dtsi imx6qdl-udoo-externalpins.dtsi imx6q-udoo-hdmi.dts   These files were copied into the IMX6Q-SABRESD build source folder and a imx6q-udoo.dtb was generated. This process is described on Building Linux Image with QT5 for UDOO Quad    The following snippets show how the nodes involved on the SPI configuration were set for UDOO Quad board. Please note that each device tree should match your custom board.   In imx6qdl-udoo-externalpins.dtsi verify that ecspi1 node matches with the one shown below.   &ecspi1 {     fsl,spi-num-chipselects = <1>;     cs-gpios = <&gpio5 17 0>;     pinctrl-0 = <&pinctrl_ecspi1>;     pinctrl-names = "default";     status = "disabled";     spidev0: spi@0 {         #address-cells = <1>;         #size-cells = <1>;         compatible = "spidev";         reg = <0>;         spi-max-frequency = <2000000>;     }; };     As you can see on snippet above, ecspi1 node uses pinctrl_ecspi1 as the pin configuration node which is defined in the same file and it looks as follows.          pinctrl_ecspi1: ecspi1grp {             fsl,pins = <             MX6QDL_PAD_DISP0_DAT22__ECSPI1_MISO  0x100b1             MX6QDL_PAD_DISP0_DAT20__ECSPI1_SCLK  0x100b1             MX6QDL_PAD_DISP0_DAT21__ECSPI1_MOSI  0x100b1             MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17   0x80000000             >;         };   However, as you may know each pin on i.MX devices has up to 8 potential functions, and on the other side, one function can be available in different pins.   For example, ECSPI1_MISO can be mapped to 4 different pins     and each pin can have different functions. From all the available functions in a pin one is chosen to be the pad (pin) name. In the image below DISP0_DATA22 was chosen to be the pad name.       Now, back to pinctrl_ecspi1 node, the macros used here are defined in imx6q-pinfuc.h, as you can see DISP0_DAT20 - DISP0_DAT23 are the pads used with the ECSPI signals.   It is necessary to check it that there are no other configurations for DISP0_DAT20 - DISP0_DAT23 and if they are it is necessary to comment out them or delete them. In this case there were other configurations for these pins in imx6qdl-udoo-externalpins.dtsi and they were commented out.     &iomuxc {     imx6q-udoo {         // External Pinout GPIOs         external_hog: hoggrp-2 {         fsl,pins = <             MX6QDL_PAD_CSI0_DAT11__GPIO5_IO29    0x80000000  // {{external-gpio-0}}             MX6QDL_PAD_CSI0_DAT10__GPIO5_IO28    0x80000000  // {{external-gpio-1}}             MX6QDL_PAD_SD1_CLK__GPIO1_IO20       0x80000000  // {{external-gpio-2}}             MX6QDL_PAD_SD1_DAT0__GPIO1_IO16      0x80000000  // {{external-gpio-3}}             MX6QDL_PAD_SD1_DAT1__GPIO1_IO17      0x80000000  // {{external-gpio-4}}             MX6QDL_PAD_SD1_CMD__GPIO1_IO18       0x80000000  // {{external-gpio-5}}             MX6QDL_PAD_SD4_DAT1__GPIO2_IO09      0x80000000  // {{external-gpio-6}}             MX6QDL_PAD_SD4_DAT2__GPIO2_IO10      0x80000000  // {{external-gpio-7}}             MX6QDL_PAD_SD1_DAT3__GPIO1_IO21      0x80000000  // {{external-gpio-8}}             MX6QDL_PAD_SD1_DAT2__GPIO1_IO19      0x80000000  // {{external-gpio-9}}             MX6QDL_PAD_GPIO_1__GPIO1_IO01        0x80000000  // {{external-gpio-10}}             MX6QDL_PAD_GPIO_9__GPIO1_IO09        0x80000000  // {{external-gpio-11}}             MX6QDL_PAD_GPIO_3__GPIO1_IO03        0x80000000  // {{external-gpio-12}}             MX6QDL_PAD_SD4_DAT0__GPIO2_IO08      0x80000000  // {{external-gpio-13}}             MX6QDL_PAD_CSI0_DAT4__GPIO5_IO22     0x80000000  // {{external-gpio-14}}             MX6QDL_PAD_CSI0_DAT16__GPIO6_IO02    0x80000000  // {{external-gpio-15}}             MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00    0x80000000  // {{external-gpio-16}}             MX6QDL_PAD_CSI0_DAT15__GPIO6_IO01    0x80000000  // {{external-gpio-17}}             MX6QDL_PAD_CSI0_DAT12__GPIO5_IO30    0x80000000  // {{external-gpio-18}}             MX6QDL_PAD_CSI0_DAT13__GPIO5_IO31    0x80000000  // {{external-gpio-19}}             MX6QDL_PAD_EIM_D28__GPIO3_IO28       0x80000000  // {{external-gpio-20}}             MX6QDL_PAD_EIM_D21__GPIO3_IO21       0x80000000  // {{external-gpio-21}}             MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27    0x80000000  // {{external-gpio-22}}             MX6QDL_PAD_DISP0_DAT7__GPIO4_IO28    0x80000000  // {{external-gpio-23}}             MX6QDL_PAD_DISP0_DAT8__GPIO4_IO29    0x80000000  // {{external-gpio-24}}             MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30    0x80000000  // {{external-gpio-25}}             MX6QDL_PAD_DISP0_DAT10__GPIO4_IO31   0x80000000  // {{external-gpio-26}}             MX6QDL_PAD_DISP0_DAT11__GPIO5_IO05   0x80000000  // {{external-gpio-27}}             MX6QDL_PAD_DISP0_DAT12__GPIO5_IO06   0x80000000  // {{external-gpio-28}}             MX6QDL_PAD_DISP0_DAT13__GPIO5_IO07   0x80000000  // {{external-gpio-29}}             MX6QDL_PAD_DISP0_DAT14__GPIO5_IO08   0x80000000  // {{external-gpio-30}}             MX6QDL_PAD_DISP0_DAT15__GPIO5_IO09   0x80000000  // {{external-gpio-31}}             MX6QDL_PAD_DISP0_DAT16__GPIO5_IO10   0x80000000  // {{external-gpio-32}}             MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11   0x80000000  // {{external-gpio-33}}             MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12   0x80000000  // {{external-gpio-34}}             MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13   0x80000000  // {{external-gpio-35}}             //MX6QDL_PAD_DISP0_DAT20__GPIO5_IO14   0x80000000  // {{external-gpio-36}}             //MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15   0x80000000  // {{external-gpio-37}}             MX6QDL_PAD_EIM_A16__GPIO2_IO22       0x80000000  // {{external-gpio-38}}             MX6QDL_PAD_GPIO_18__GPIO7_IO13       0x80000000  // {{external-gpio-39}} (KEY_VOL_UP)             MX6QDL_PAD_NANDF_D0__GPIO2_IO00      0x80000000  // {{external-gpio-40}} (HOME)             MX6QDL_PAD_NANDF_D3__GPIO2_IO03      0x80000000  // {{external-gpio-41}} (SEARCH)             MX6QDL_PAD_NANDF_D2__GPIO2_IO02      0x80000000  // {{external-gpio-42}} (BACK)             MX6QDL_PAD_NANDF_D1__GPIO2_IO01      0x80000000  // {{external-gpio-43}} (MENU)             MX6QDL_PAD_GPIO_19__GPIO4_IO05       0x80000000  // {{external-gpio-44}} (KEY_VOL_DOWN)            // MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16   0x80000000  // {{external-gpio-45}}             //MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17   0x80000000  // {{external-gpio-46}}             MX6QDL_PAD_EIM_D25__GPIO3_IO25       0x80000000  // {{external-gpio-47}}             MX6QDL_PAD_KEY_ROW1__GPIO4_IO09      0x80000000  // {{external-gpio-48}}             MX6QDL_PAD_KEY_COL1__GPIO4_IO08      0x80000000  // {{external-gpio-49}}             MX6QDL_PAD_EIM_OE__GPIO2_IO25        0x80000000  // {{external-gpio-50}}             MX6QDL_PAD_EIM_CS1__GPIO2_IO24       0x80000000  // {{external-gpio-51}}             MX6QDL_PAD_EIM_CS0__GPIO2_IO23       0x80000000  // {{external-gpio-52}}             MX6QDL_PAD_EIM_D24__GPIO3_IO24       0x80000000  // {{external-gpio-53}}             MX6QDL_PAD_GPIO_8__GPIO1_IO08        0x80000000  // {{external-gpio-54}}             MX6QDL_PAD_GPIO_7__GPIO1_IO07        0x80000000  // {{external-gpio-55}}             >;         };     Finally, in imx6q-udoo-hdmi.dts enable ECSPI by including an ecspi1 node reference and setting the status property to "okay".   dts-v1/; #include "imx6q.dtsi" #include "imx6qdl-udoo.dtsi" #include "imx6qdl-udoo-externalpins.dtsi" / {     model = "UDOO Quad Board";     compatible = "udoo,imx6q-udoo", "fsl,imx6q";        mxcfb1: fb@0 {         compatible = "fsl,mxc_sdc_fb";         disp_dev = "hdmi";         interface_pix_fmt = "RGB24";         mode_str ="1920x1080M@60";         default_bpp = <32>;         int_clk = <0>;         late_init = <0>;         status = "okay";     }; }; &ecspi1 {     status = "okay"; };   Note: This could be done in .dtsi but the side effect is that any configuration including the dtsi will have ECSPI1 enabled by default.   Finally it is necessary to rebuild the device tree and copy it to the FAT partition of the sdcard. This process is explained in next section.   Rebuilding Image   Requirements In order to build an image as well as an application it is necessary to install a tool to cross-compile code, this way we will be able to generate executable files for ARM architecture in our host machine. This tool is called meta-toolchain, the following commands are used to install it.   In the following instructions it is considered that the build directory is ~/fsl-release_bsp/build_imx6qsabresd_qt5/   $ cd ~/fsl-release_bsp $ source setup-environment build_imx6qsabresd_qt5 $ bitbake meta-toolchain $ sh tmp/deploy/sdk/fsl-imx-x11-glibc-x86_64-meta-toolchain-cortexa9hf-vfp-neon-toolchain-<kernel>.sh Kernel   In order to enable the kernel SPI driver it is necessary to set it in the menuconfig and rebuild zImage.   Go to kernel directory within the Yocto build directory that we created. $ cd <build_directory>/tmp/work-shared/imx6qsabresd/kernel-source$   Launch menuconfig for imx $ source /opt/fsl-imx-x11/<kernel version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ make imx_v7_defconfig $ make menuconfig   Enable SPI Driver by going to Device Drivers --> SPI Support and seting '*' to SPI device Driver, save changes and then exit.     And build zImage $ make zImage   The generated file is located in <build_directory>/tmp/work-shared/imx6qsabresd/kernel-source/arch/arm/boot$ and it must be copied to the FAT partition of the SD card.   Device Tree   To build the device tree go to kernel directory within the Yocto build directory that we created. $ cd <build_directory>/tmp/work-shared/imx6qsabresd/kernel-source$   Build dtb file $ source /opt/fsl-imx-x11/<kernel version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ make imx_v7_defconfig $ make imx6q-udoo-hdmi.dtb   The generated file is located in <build_directory>/tmp/work-shared/imx6qsabresd/kernel-source/arch/arm/boot/dts$ and it must be renamed as imx6q-udoo.dtb and copied to the FAT partition of the SD card.   Application Driver   The SPI kernel driver uses a structure named spi_ioc_transfer which describes a single SPI transfer. It holds pointers to userspace buffers with transmit and receive data, length of buffers, speed, bits per word among other configurations. For further details you can refer to /include/uapi/linux/spi/spidev.h on your kernel source. In the next section the application driver is explained.   The source files of the application driver as well as the device tree sources can be found in the attached.zip file.   Main   The following code shows function main where the SPI driver is initialized driver using "/dev/spidev0.0" which is listed under /dev (in the target root file system) after SPIdev driver is enabled in menuconfig and kernel is rebuilt as indicated in previous section. Then it reads who am i register just for sanity check purpose and initializes and calibrates the sensor and enters in an endless loop where it reads the sensor whenever there is new data ready. Raw data is returned in 6 bytes, so it is managed to get X, Y and Z values and finally these values are converted to G's values and it waits until a key is pressed to continue to read the following value.     /****************************************************************************** * Main ******************************************************************************/ int main(){      //enableGPIO(); //In case of using interrupt instead of polling      file = spi_init("/dev/spidev0.0"); //dev      who();      FXLS8471Q_Init();      FXLS8471Q_Calibration();      while(1)      {          checkData();          if (DataReady) // Is a new set of data ready?          {              buffer = (unsigned char *)spi_read(OUT_X_MSB_REG, 6, file); // Read data output registers 0x01-0x06              printf("AccData[0] = 0x%X \n AccData[1] = 0x%X \n AccData[2] = 0x%X \n AccData[3] = 0x%X \n AccData[4] = 0x%X \n AccData[5] = 0x%X \n", AccData[0], AccData[1], AccData[2], AccData[3], AccData[4], AccData[5]);              Xout_14_bit = ((short) (AccData[0] << 8 | AccData[1])) >> 2; // Compute 14-bit X-axis output value              Yout_14_bit = ((short) (AccData[2] << 8 | AccData[3])) >> 2; // Compute 14-bit Y-axis output value              Zout_14_bit = ((short) (AccData[4] << 8 | AccData[5])) >> 2; // Compute 14-bit Z-axis output value              Xout_g = ((float) Xout_14_bit) / SENSITIVITY_2G; // Compute X-axis output value in g's              Yout_g = ((float) Yout_14_bit) / SENSITIVITY_2G; // Compute Y-axis output value in g's              Zout_g = ((float) Zout_14_bit) / SENSITIVITY_2G; // Compute Z-axis output value in g's              //printf(" X = %d Y = %d Z = %d \n\n", AccData[0], AccData[2], AccData[4]);              //printf("Xval = %d Yval = %d Zval = %d \n", Xout_14_bit, Yout_14_bit, Zout_14_bit);              printf(" XG = %f YG = %f ZG = %f \n\n", Xout_g, Yout_g, Zout_g);              getchar();         }      }      close(file); } Init Driver   The spi_init function opens a file for the driver "/dev/spidev0.0" which is passed as a parameter from main(), then the SPI configuration parameters are read just for informative purpose. Finally struct xfer which is of type spi_ioc_transfer is initialized.   /********************************* SPIdev Init **********************************************/ int spi_init(char filename[40]) { int file; unsigned char mode, lsb, bits; unsigned int baudrate = 524250, speed; printf("SPI Init \n"); if ((file = open(filename,O_RDWR)) < 0) { printf("Failed to open the bus."); /* ERROR HANDLING; you can check errno to see what went wrong */ com_serial=0; exit(1); } if (ioctl(file, SPI_IOC_RD_MODE, &mode) < 0) { perror("SPI rd_mode"); return -1; } if (ioctl(file, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) { perror("SPI rd_lsb_fist"); return -1; } if (ioctl(file, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) { perror("SPI bits_per_word"); return -1; } if (ioctl(file, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) { perror("SPI max_speed_hz"); return -1; } printf("%s: spi mode %d, %d bits %s per word, %d Hz max\n",filename, mode, bits, lsb ? "LSB first" : "MSB first", baudrate); xfer[0].len = 3; /* Length of command to write*/ xfer[0].cs_change = 0; /* Keep CS activated */ xfer[0].delay_usecs = 0; //delay in us xfer[0].speed_hz = 524250; //speed xfer[0].bits_per_word = 8; // bites per word 8 xfer[1].len = 4; /* Length of Data to read */ xfer[1].cs_change = 0; /* Keep CS activated */ xfer[1].delay_usecs = 0; xfer[1].speed_hz = 524250; xfer[1].bits_per_word = 8; printf("SPI Init Finished \n"); return file; }     Write   The SPI communication is started with the  falling edge on chip select pin. A write operation is initiated by transmitting a 1 for the R/W bit. Then the 8-bit register address, ADDR[7:0] is encoded in the first and second serialized bytes. Data to be written starts in the third serialized byte. The order of the bits is as follows:   Byte 0: R/W, ADDR[6], ADDR[5], ADDR[4], ADDR[3], ADDR[2], ADDR[1], ADDR[0] Byte 1: ADDR[7], X, X, X, X, X, X, X Byte 2: DATA[7], DATA[6], DATA[5], DATA[4], DATA[3], DATA[2], DATA[1], DATA[0]   The SPI communication is finished with the  falling edge on chip select pin.   A you can see below array buf keeps the destination address and the data to be transferred, then xfer structure is configured to point to buf as the transfer buffer and the length of the data es set to 2 + data size (the first 2 bytes are for the destination address which is splitted in 2 bytes). Finally the transfer is started by the ioctl command.   /******************** Write a byte to the FXLS8471Q *************************** * Byte 0: 1,ADDR[6],ADDR[5],ADDR[4],ADDR[3],ADDR[2],ADDR[1],ADDR[0] * Byte 1: ADDR[7],0,0,0,0,0,0,0 * Byte 2: DATA[7],DATA[6],DATA[5],DATA[4],DATA[3],DATA[2],DATA[1],DATA[0] ******************************************************************************/ void spi_write(int registerAddress, int nbytes, char data, int file) { unsigned char buf[32]; int status; memset(buf, 0, sizeof buf); buf[0] = 0x80 | registerAddress; buf[1] = 0x80 & registerAddress; buf[2] = data; xfer[0].tx_buf = (unsigned long)buf; xfer[0].len = nbytes + 2; /* Length of command to write*/ status = ioctl(file, SPI_IOC_MESSAGE(1), xfer); if (status < 0) { perror("SPI_IOC_MESSAGE"); return; } com_serial=1; failcount=0; }     Below is the write operation which writes the value 0x3D to the CTRL_REG1 (0x2A).     Read   Similarly a read operation is initiated by transmitting a 0 for the R/W bit. Then the 8-bit register address, ADDR[7:0] is encoded in the first and second serialized bytes. The data is read from the MISO pin (MSB first).   In this case the array buf keeps the address that is going to be read and the third byte is just a dummy byte to be transferred. Structure xfer keeps transfer buffer pointer which in this case is buf and receive buffer which is AccData, the lenght of the command to write and the length of data to read is also specified and finally the read command is executed with ioctl call.     /********************** Read a byte from the FXLS8471Q *********************** * Byte 0: 0,ADDR[6],ADDR[5],ADDR[4],ADDR[3],ADDR[2],ADDR[1],ADDR[0] * Byte 1: ADDR[7],0,0,0,0,0,0,0 * Byte 2: 0,0,0,0,0,0,0,0 ******************************************************************************/ char * spi_read(int registerAddress, int nbytes, int file) { int status; memset(buf, 0, sizeof buf); memset(AccData, 0, sizeof AccData); buf[0] = 0x7F & registerAddress; buf[1] = 0x80 & registerAddress; buf[2] = 0x00; xfer[0].tx_buf = (unsigned long)buf; xfer[0].len = 2; /* Length of command to write*/ xfer[1].rx_buf = (unsigned long) AccData; xfer[1].len = nbytes; /* Length of Data to read */ xfer[1].speed_hz = 524250; status = ioctl(file, SPI_IOC_MESSAGE(2), xfer); if (status < 0) { perror("SPI_IOC_MESSAGE"); return 0; } com_serial=1; failcount=0; return AccData; }     The screenshot below shows the read operation which reads the correct value 0x6A from the WHO_AM_I register (0x0D).     Building and Run the SPI Application Driver   In order to build the application please save the source files and the Makefile (attached) on any place on your host machine and go to that directory where you saved them. Then build the application with the Meta-toolchain using the Make file with the following commands.   Build application driver $ cd <folder wher spi device driver source is saved> $ source /opt/fsl-imx-x11/<kernel version>/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ make   A spi_test file will be created in the same folder, copy this file into the sdcard on the Root File System partition in /home/root. Finally when booting the target execute the application. You must see the following output.       Conclusion   This document summarizes the steps to create a SPI application driver. As you saw it is necessary to rebuild the device tree and the kernel, and to do this it is necessary to install metatoolchain. The application driver uses the SPI kernel driver and its main functions are next: Init SPI Driver Read Write Init sensor Callibrate Sensor Polling data ready function   I would say that the core of the application driver are the read and write functions which configure the SPI kernel driver and pass data to it in the format required by the sensor.   For specific details on the driver please see the attached .zip file which contains the application driver code, the Makefile with the one it is build and the device tree sources.   I hope you find this document useful.     Carlos

To disable the Android dm-verity in the new devices you should have the below. A Window/Linux computer The Android SDK platform-packages tools. Download the Android Packages tool. To use the Android kernel or give root access to your Android device, it is needed to have some tools from the Android SDK like ADB or fastboot. To download those tools just go to below web-page: https://developer.android.com/studio#downloads Go to the “command line tools only” part and download the sdk-tools-windows-4333796.zip package. Note: Is recommended to store the content of the zip file in path that you could find without any problem since the Android SDK tools can only be run by the terminal console.   Unlock your Android device. On the Android GUI go to Settings -> systems -> About Phone At the bottom, you should see the build number of your Android device. Tap it multiple times until appears on the screen that you are a developer now. Go to the developer options and search for the OEM unlock option. You need to activate that option. Open the power-shell terminal and go to the path where you stored the zip file.   Example for Windows: cd C:\users\diego\Documents\platform-tools‍ Then you will use the ADB tool (Adroid Debug Bridge). To use it you need to run adb.exe in your power-shell terminal. To run an executable in the Windows terminal is just with ".\". Connect the serial download cable to the host computer (the Type C for the i.MX8M and i.MX8MM. The OTG for the i.M6 SabreSD boards). Open the adb server. .\adb.exe start-server‍ See your connected devices. .\adb.exe devices‍ You should see your device and the serial number that is assigned to the device. Then, enter into Bootloader mode. .\adb.exe reboot bootloader‍       Note to see if your board successfully entered to Bootloader mode. In your serial terminal, you should see that you are in Bootloader mode. Once inside the Bootloader mode, using fastboot you can unlock your phone. First, see if your computer recognizes your board once inside the Bootloader mode. .\fastboot.exe devices‍ If you do not see any device, go to Appendix A of the document. Finally, Unlock and reboot the board. .\fastboot.exe oem-unlock .\fastboot.exe reboot‍‍         Unlock the dm-verity option. After the board rebooted. Start again the adb server .\adb.exe start-server .\adb.exe devices‍‍ Then root the board .\adb.exe root ‍ After rooting the board, disable the dm-verity option .\adb.exe disable-verity‍ After disabling the verity option, it will request you to reboot your board. Just reboot your board. .\adb.exe reboot ‍ With that, you should have successfully disabled the verity option on your board.   Appendix A Update the USB driver (For Windows only) If your computer does not recognize once you are inside the bootloader mode. What you need to do is update the USB driver. To update the driver, follow the below steps. First, open your device manager and locate the Universal Serial Bus devices -> USB download gadget. Then press the right-click and select the Update driver option. Select the “Browse my computer for driver software” option. Select the “Let me pick from a list of available drivers on my computer” option.     Select the ADB Device Model.   And accept to install the driver. After that, your computer should recognize the board being into Bootloader mode.   Appendix B connects your Android device to a Linux computer through ADB.   You could face some adb problems if you want to connect your Android device to a Linux computer. If you want to use adb, the Android image does not allow you due to a permission problem. To make it work, you need to create a new rule for a plug device. To make the new rule, create a document inside the /etc/udev/rules.d named 51-android.rules. Inside the document write the following:   SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="d002", MODE="0660",  GROUP="plugdev", SYMLINK+="android%n"‍‍   Where the ATTR{idVendor} and ATTR{idProduct} is the USB id for the board. To know that information. Write lsusb and your Android device is the one named Google Inc. Then reboot your computer. With this new rule, ADB should work as usual. Hope this document could be useful to someone. Best regards, Diego.

First upload the U-Boot firmware using Network (Transferring file over network) or Serial (Transferring file over serial) This is a common serial transfer output: => loady ## Ready for binary (ymodem) download to 0xa0800000 at 115200 bps... CCmode, 1359(SOH)/0(STX)/0(CAN) packets, 9 retries ## Total Size      = 0x0002a388 = 172936 Bytes Unprotect the bootloader flash area: protect off C0000000 C003FFFF Erase the flash blocks: erase C0000000 C003FFFF Copy from RAM to Flash: If firmware has been thansfered over serial: cp.b A0800000 C0000000 2a388 If firmware has been transfered over tftp: cp.b 100000 C0000000 2a388 Installing U-Boot using BDI3000 You can use a BDI2000/3000 to write to the S71WS256 pSRAM: Get this config file. Thanks to the folks at Ultimate Solutions for being such a nice people and writing an almost ready file! Edit the [FLASH] section to this: [FLASH] CHIPTYPE              S29M32X16 CHIPSIZE                0x2000000 BUSWIDTH             16 FILE                        /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin ; change to you path FORMAT                 BIN 0xC0000000 ERASE                   0xC0000000 ERASE                   0xC0008000 ERASE                   0xC0018000 ERASE                   0xC0010000 ERASE                   0xC0020000 Don't forget to edit the [HOST] section to your machine's IP address. Telnet to the BDI - CONFIG: loading configuration file passed - CONFIG: loading register definition passed - TARGET: processing reset request - TARGET: BDI asserts TRST and RESET - TARGET: BDI removes TRST - TARGET: Bypass check 0x00000001 => 0x00000002 - TARGET: JTAG exists check passed - Core#0: ID code is 0x07926121 - TARGET: All ICEBreaker access checks passed - TARGET: BDI removes RESET - TARGET: BDI waits for RESET inactive - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed Erase the first 128 KiB ADS>erase Erasing flash at 0xc0000000 Erasing flash at 0xc0008000 Erasing flash at 0xc0018000 Erasing flash at 0xc0010000 Erasing flash at 0xc0020000 Erasing flash passed Write the flash ADS>prog Programming /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin , please wait .... Programming flash passed Check everything went really well ADS>verify Verifying /home/lsantos/work/i.mx27/u-boot/u-boot-v2/uboot.bin , please wait .... Verifying target memory passed Now you can unplug the BDI and reset the board U-Boot 2.0.0-rc9-00136-gbf725a2-dirty (Jun 17 2009 - 15:45:23)  Board: Freescale i.MX27 ADS cfi_probe: cfi_flash base: 0xc0000000 size: 0x02000000  chip id: [2,882,1,01d] mpll:     265999329 Hz spll:     239999725 Hz arm:      177332886 Hz perclk1:    8866644 Hz perclk2:   17733288 Hz perclk3:   44333221 Hz perclk4:   17733288 Hz clkin26:   26000000 Hz ahb:       44333221 Hz ipg:       22166610 Hz Malloc space: 0xa7b00000 -> 0xa7f00000 (size  4 MB) Stack space : 0xa7af8000 -> 0xa7b00000 (size 32 kB) envfs: wrong magic on /dev/env0 no valid environment found on /dev/env0. Using default environment running /env/bin/init...  Hit any key to stop autoboot:  2  type update_kernel [<imagename>] to update kernel into flash type udate_root [<imagename>] to update rootfs into flash  uboot:/ Of course, this setup works with Redboot, just change the FILE entry at the [FLASH] section or use the prog command: ADS>prog 0xc0000000 /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin BIN Programming /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin , please wait .... Programming flash passed ADS>verify Verifying /home/lsantos/work/i.mx27/redboot/build/install/bin/redboot.bin , please wait .... Verifying target memory passed Rebooting ++... Read from 0x07ee0000-0x07f00000 at 0xc1fe0000: . ... Read from 0x07ed3000-0x07ed4000 at 0xc1fff000: . **Warning** FLASH configuration checksum error or invalid key Use 'fconfig -i' to [re]initialize database PMIC ID: 0x0000009b [Rev: 3.3] Ethernet FEC MAC address: is not set  Board Type: ADS Clock input: 26 MHz Booting from [NOR flash]  PHY ID 22 @ 1 FEC: [ HALF_DUPLEX ] [ disconnected ] [ 10M bps ]: Ethernet eth0: MAC address 00:04:9f:00:af:7a Can't get BOOTP info for device!  RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version FSL 200749 - built 19:37:28, Jun 17 2009  Platform: MX27 ADS/EVB (Freescale i.MX27 based) PASS 2.1 [x32 SDR] Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.  RAM: 0x00000000-0x07f00000, [0x00025260-0x07ed1000] available FLASH: 0xc0000000 - 0xc2000000, 256 blocks of 0x00020000 bytes each. RedBoot>

About this document This document describe the setup detail for Interfacing, Installing, programming (basis) and testing depth cameras with MX6QDL based boards using the Robotic Operating System (ROS). If you are not using ROS you can also install the proper drivers and compile, in your Ubuntu system as explained on document:  https://community.freescale.com/docs/DOC-330278 1. Software & Hardware requirements Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board Depth sensors tested: Microsoft Kinect, ASUS Xtion. Software:   Gcc, Ubuntu 14.04v, OpenCV, Openni, Python, ROS. 2. Installation on ROS For installation steps of ROS on iMX6 boards in your board, please follow up: https://community.freescale.com/docs/DOC-3301478 Before you can use ROS, you will need to initialize rosdep. It enables you to easily install system dependencies for source you want to compile and is required to run some core components in ROS. $ sudo rosdep init $ rosdep update There are many different libraries and tools in ROS - not all compile fully on ARM. In this case we already have installed the ROS Base, however any other packages need to be installed individually. First install the following dependencies, which will take some time and space (~1.4 GB): $ sudo apt-get install --no-install-recommends freeglut3-dev libfreenect-dev libusb-1.0-0-dev libudev-dev ros-indigo-camera-info-manager ros-indigo-dynamic-reconfigure ros-indigo-image-transport ros-indigo-image-proc ros-indigo-depth-image-proc ros-indigo-tf ros-indigo-openni-launch ros-indigo-freenect-* ros-indigo-depthimage-to-laserscan ros-indigo-image-view ros-indigo-camera-info-manager ros-indigo-dynamic-reconfigure libudev-dev doxygen graphviz openjdk-6-jdk ros-indigo-openni2-camera ros-indigo-openni2-launch ros-indigo-rqt-common-plugins ros-indigo-rqt-graph There is no any additional installation to run kinect with ROS, If you are using kinect you can pass to part 4. However the packages used to run the PrimeSense / Asus Xtion on the i.Mx6 are not available over apt yet, so they need to be compiled from source. To use OpenNI2 with ROS, we only need the shared OpenNI2 libraries and the Drivers. Clone OpenNI2 $ git clone https://github.com/OpenNI/OpenNI2 $ cd OpenNI2 Edit ThirdParty/PSCommon/BuildSystem/Platform.Arm $ nano ThirdParty/PSCommon/BuildSystem/Platform.Arm and replace CFLAGS += -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp #-mcpu=cortex-a8 with CFLAGS += -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard Add support for pthread library: $ nano ThirdParty/PSCommon/BuildSystem/CommonCppMakefile Search the line 95 and add the code between the two lines: OUTPUT_NAME = $(EXE_NAME)                                                   # We want the executables to look for the .so's locally first:     LDFLAGS += -Wl,-rpath ./ +   ifneq ("$(OSTYPE)","Darwin") +       LDFLAGS += -lpthread +   endif     OUTPUT_COMMAND = $(CXX) -o $(OUTPUT_FILE) $(OBJ_FILES) $(LDFLAGS) endif Save the file and exit Then run make to compile the OpenNI2 drivers and libraries $ PLATFORM=Arm make ALLOW_WARNINGS=1 Once the compilation is done, run the linux install script $ cd Packaging/Linux $ sudo ./install.sh Copy libraries and includes to the system paths $ cd ../../ $ sudo cp -r Include /usr/include/openni2 $ sudo cp -r Bin/Arm-Release/OpenNI2 /usr/lib/ $ sudo cp Bin/Arm-Release/libOpenNI2.* /usr/lib/ Create a package config file $ sudo nano /usr/lib/pkgconfig/libopenni2.pc and fill it with this: prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include/openni2 Name: OpenNI2 Description: A general purpose driver for all OpenNI cameras. Version: 2.2.0.0 Cflags: -I${includedir} Libs: -L${libdir} -lOpenNI2 -L${libdir}/OpenNI2/Drivers -lDummyDevice -lOniFile -lPS1080.so This will enable ubuntu to find the location of the drivers, libraries and include files. To make sure it is correctly found, run $ pkg-config --modversion libopenni2 Which should give the same version as defined in the file above (2.2.0.0). Now the Xtion is ready to be used. Plug it in (if it is already, unplug it first), then run the sample program $ ./Bin/Arm-Release/SimpleRead Then create a catkin workspace as described here, and check out the following packages in the src folder of the catkin workspace: $ cd ~/catkin_ws/src $ git clone https://github.com/ros-drivers/openni2_camera $ git clone https://github.com/ros-drivers/openni2_launch $ git clone https://github.com/ros-drivers/rgbd_launch Now the ros packages checked out above to the catkin workspace can be compiled with catkin_make $ cd ~/catkin_ws $ catkin_make Once the packages are compiled, the Xtion is ready for use with ROS with 3. Testing The Installation Kinect. Open at least 3 bash terminals: Terminal 1: Run ROS $ roscore Terminal 2:  launch the Freenect $ roslaunch freenect_launch freenect.launch Terminal 3: run the image capture $ rosrun image_view image_view image:=camera/rgb/image_color or: $ rosrun image_view image_view image:=camera/rgb/image_rect_mono or: $ rosrun image_view disparity_view image:=camera/depth/disparity It will open a new terminal with the rgb points, mono  and depth images  from the Kinect. Xtion.  Terminal 1: Run ROS $ roscore Terminal 2:  launch Openni2 $ roslaun openi2_launch openni2.launch Terminal 3: you can use rqt or Rviz session to visualize the sensor e.g: $ rqt or $ rosrun rqt_graph rqt_graph In the “rqt” window select “Plugins” -> “Visualization” -> “Image View“                                                             (optional) Install PySide, in any case you get an error with python rqt graph: $ pip install PySide $ cd ~/ Note: rqt and Rviz demand a lot of i.MX GPU work, so general graphic functionality will be affected. For this case is suggested to run rviz in a remote Network ROS session. References: -       www.ros.org -     https://dobots.nl/2014/05/05/asus-xtion-using-openni2-and-ros-on-udoo/

If your target system does not have an Ethernet port it is possible to transfer files, such as the kernel image over serial port, using ymodem. On minicom: RedBoot> load -r -b 0x100000 -m ymodem zImage Where "zImage" is the file to be transferred. On minicom press "CTRL + a" and "s", choose ymodem and select the file to be transferred.

This tutorial will explain how to compile a Linux distro and the pingpong MQX application to test the communication between ARM Cortex-A9 and ARM Cortex-M4 cores on the SABRE Board for Smart Devices Based on the i.MX 6SoloX. INITIAL SETUP All of the steps were executed on an Ubuntu 14.04 64 bits machine, but should work on other distributions with minimal or no changes. The first step is to install the required tools and applications in the host: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev xterm picocom You also need to install the repo tool that will be used to download the Freescale's BSP: $ mkdir ~/bin $ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=${PATH}:~/bin Create an environment variable to store the directory name that will be used to download and compile all required software and applications (do no forget to redefine this variable if you close the current terminal or open a new one). $ export IMX6SOLOX=~/imx6solox $ mkdir -p $IMX6SOLOX LINUX DISTRIBUTION Download the Freescale's BSP source code: $ cd $IMX6SOLOX $ mkdir -p fsl-release-bsp && cd fsl-release-bsp $ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.10.53-1.1.0_ga $ repo sync And compile a minimal image for the SABRE Board: $ MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build $ bitbake core-image-minimal After the compilation, a sdcard image should be available. Write it to the sdcard (do not forget to change the device name /dev/sdX in the command below). $ cd tmp/deploy/images/imx6sxsabresd/ $ sudo dd if=core-image-minimal-imx6sxsabresd.sdcard of=/dev/sdX bs=1M && sync To test the image you need to connect the board to your host machine using the USB cable. Two TTY ports will be created. Open your favorite terminal application (minicom, putty, screen, picocom) in the first one and check the Linux boot process. You should be able to login with the root user. FIRMWARE MQX Download the last MQX source code from Freescale's website at http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX#. I have used the 4.1.0 version in the tests. Do not forget to download the Linux version (*.gz). Create a directory and decompress the source code: $ cd $IMX6SOLOX $ mkdir -p mqx && cd mqx $ tar xfv ~/Downloads/Freescale\ MQX\ RTOS\ 4.1.0\ for\ i.MX\ 6SoloX\ Linux\ Base.gz $ ls build config doc mcc mqx tools Download and install the required toolchain to compile the MQX application: $ cd $IMX6SOLOX $ mkdir -p toolchain && cd toolchain $ wget https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 $ tar xfv gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 && rm gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 Now compile the MQX and related libraries: $ cd $IMX6SOLOX/mqx/build/imx6sx_sdb_m4/make $ export TOOLCHAIN_ROOTDIR=$IMX6SOLOX/toolchain/gcc-arm-none-eabi-4_8-2014q1 $ ./build_gcc_arm.sh And compile the pingpong application: $ cd $IMX6SOLOX/mqx/mcc/examples/pingpong/build/make/pingpong_example_imx6sx_sdb_m4 $ ./build_gcc_arm.sh Convert the ELF application to a binary format: $ arm-none-eabi-objcopy -O binary gcc_arm/extflash_release/pingpong_example_imx6sx_sdb_m4.elf m4_qspi.bin The U-Boot bootloader will be responsible to read the MQX firmware from the SDCARD, write in the NOR flash and start the application on the Cortex-M4. Save the m4_qspi.bin file in the first sdcard partition and access the U-Boot's prompt. Run the following command to write the firmware image to the NOR flash: > run update_m4_from_sd And setup U-Boot environment variables so the application will start automatically at boot: > setenv fdt_file imx6sx-sdb-m4.dtb > setenv mmcargs "${mmcargs} uart_from_osc" > setenv bootcmd "run m4boot;${bootcmd}" > saveenv Open another terminal application on the second TTY to have access to the MQX console e reboot the board. You should see the message below: ***** MCC PINGPONG EXAMPLE ***** Please wait : 1) A9 peer is ready Then press "S" to start the demo ******************************** Press "S" to start the demo : Wait for the Linux boot process to finish and press "S" to start the demo application. In the Linux terminal, start the communication with the pingpong application: # echo 1 > /sys/devices/soc0/soc.1/2200000.aips-bus/mcctest.17/pingpong_en & You should see the log of messages sent and received on both terminals. Please let me know if you have any question. Best regards, Sergio Prado [email protected] http://e-labworks.com

D1 Capture - kernel 2.6.22 diff --exclude CVS -uNr linux-2.6.22/include/asm-arm/arch-mxc/memory.h linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h --- linux-2.6.22/include/asm-arm/arch-mxc/memory.h     2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h     2009-07-15 15:38:34.000000000 -0300 @@ -28,6 +28,7 @@     /* Size of contiguous memory for DMA and other h/w blocks */     #define CONSISTENT_DMA_SIZE     SZ_16M    +     /*!      * @defgroup Memory_MX27 Memory Map      * @ingroup MSL_MX27 @@ -48,7 +49,7 @@     #ifdef CONFIG_DMA_ZONE_SIZE     #define MXC_DMA_ZONE_SIZE     ((CONFIG_DMA_ZONE_SIZE * SZ_1M) >> PAGE_SHIFT)     #else    -#define MXC_DMA_ZONE_SIZE     ((12 * SZ_1M) >> PAGE_SHIFT)   +#define MXC_DMA_ZONE_SIZE     ((20 * SZ_1M) >> PAGE_SHIFT)     #endif      static inline void __arch_adjust_zones(int node, unsigned long *zone_size, diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c ---    linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c     2009-07-16 16:29:43.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c     2009-07-16 16:08:02.000000000 -0300 @@ -1650,9 +1650,9 @@                  /* setup cropping */                 cam->crop_bounds.left = 0; -             cam->crop_bounds.width = 640; +             cam->crop_bounds.width = 800;                 cam->crop_bounds.top = 0; -             cam->crop_bounds.height = 480; +             cam->crop_bounds.height = 600;                 cam->crop_current = cam->crop_defrect = cam->crop_bounds;                 ipu_csi_set_window_size(cam->crop_current.width,                                                       cam->crop_current.height); @@ -1663,7 +1663,7 @@                 cam->standard.id = V4L2_STD_UNKNOWN;                 cam->standard.frameperiod.denominator = 30;                 cam->standard.frameperiod.numerator = 1; -             cam->standard.framelines = 480; +             cam->standard.framelines = 600;                 cam->streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;                 cam->streamparm.parm.capture.timeperframe =                 cam->standard.frameperiod; cam->streamparm.parm.capture.capability = V4L2_CAP_TIMEPERFRAME; diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c ---    linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c     2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c     2009-07-16 16:07:03.000000000 -0300 @@ -698,12 +698,12 @@     #endif                            g_cam->streamparm.parm.capture.capturemode = 1;                 } else { -          out_width = 640; -          out_height = 480; +          out_width = 800; +          out_height = 600;                 g_cam->crop_bounds.left = 0; -          g_cam->crop_bounds.width = 640; +          g_cam->crop_bounds.width = 800;                 g_cam->crop_bounds.top = 0; -          g_cam->crop_bounds.height = 480; +          g_cam->crop_bounds.height = 600;                 g_cam->crop_current = g_cam->crop_defrect = g_cam->crop_bounds;     #ifdef CONFIG_ARCH_MX3                              ipu_csi_set_window_size(g_cam->crop_current.width ,

Gingerbread (GB) Prepare the SD Card root/ : root file system (including init, init.rc, etc). Mounted at / system/:  Android system binary/libraries. Mounted at /system data/: Android data area. Mounted at /data recovery/: root file system when booting in "recovery" mode. Not directly used. Partition Description Type Size Header 8 BOOT raw area for bootloader and MEDIA DATA CACHE RECOVERY An example of partition a 4 GB SD card: Copy the system to SD card # sudo dd if=u-boot.bin of=/dev/sdx bs=1K skip=1 seek=1; sync # sudo dd if=u-boot-no-padding.bin of=/dev/sdx bs=1K seek=1; sync # sudo dd if=uImage of=/dev/sdx bs=1M seek=1; sync # sudo dd if=uramdisk.img of=/dev/sdx bs=1M seek=6; sync # sudo dd if=system.img of=/dev/sdx2; sync # sudo dd if=recovery.img of=/dev/sdx4; sync Ice Cream Sandwich (ICS)

i.MX27 PDK Board Flashing This tutorial teaches how to flash bootloader using ATK. To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. Using ATK ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board. Set red and cream switches as below: Switch SW5 -> 00000 Switch SW4 -> 10000001 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. PS: On SW5 and SW4, "1" means the keys selected towards the edge of the board. 3 - Run ATK by clicking Start -> Programs -> AdvancedToolKit -> AdvancedToolKit       Set the options:    Device memory -> DDR; Custom Initial File -> (keep it unmarked)    Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO. Flash Erasing 1 - To erase Flash memory, select the parameters as shown in the figure below: 2 - Turn on the board and press Erase. 3 - ATK shows this message when flash is erased Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NAND, Address: 0x00000000 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot.

Quick Steps Four quick steps to build and flash a UBIFS image on i.MX35 NAND (K9LBG08U0D-PCB0), for information on how to you another memory, please see next section. Enable MTD_UBI and UBIFS_FS on kernel Create UBI image from rootfs (used for NFS) - ON PC mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg Format NAND using UBI image - ON TARGET ubiformat -f ubi.img /dev/mtd8 Load UBI file system load -r -b 0x100000 zImage fis create -f 0x300000 kernel fis load kernel exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none" How To First of all, install mtd-utils on both target and host: Target: ./ltib -c Package list [*] mtd-utils Host sudo aptget install mtd-utils 1. Enable MTD_UBI and UBIFS_FS on kernel MTD_UBI -> Device Drivers     -> Memory Technology Device (MTD) support (MTD [=y])           -> UBI - Unsorted block images                   <*> Enable UBI                    (4096) UBI wear-leveling threshold (NEW)                    (1) Percentage of reserved eraseblocks for bad eraseblocks handling (NEW)                 < > MTD devices emulation driver (gluebi) (NEW)                    ** UBI debugging options **                    [ ] UBI debugging (NEW) UBIFS_FS -> File systems         ->Miscellaneous filesystems             <*> UBIFS file system support                 [ ] Extended attributes support (NEW)                 [ ] Advanced compression options (NEW)                 [ ] Enable debugging (NEW) 2. Create UBI image On TARGET Collect some information needed in order to create the UBI image according to your NAND device root@freescale \~$ cat /proc/mtd dev:   size   erasesize name mtd0: 00080000 00020000 "Bootloader" mtd1: 00400000 00020000 "nor.Kernel" mtd2: 01e00000 00020000 "nor.userfs" mtd3: 01c00000 00020000 "nor.rootfs" mtd4: 00003000 00020000 "FIS directory" mtd5: 02001000 00020000 "Redboot config" mtd6: 00300000 00040000 "nand.bootloader" mtd7: 00500000 00040000 "nand.kernel" mtd8: 10000000 00040000 "nand.rootfs" mtd9: 00800000 00040000 "nand.configure" mtd10: 6f000000 00040000 "nand.userfs" I will use mtd8, because I want the NAND rootfs MTD partition. More on [1] root@freescale ~$ ubiattach /dev/ubi_ctrl -m 8 UBI: attaching mtd8 to ubi0 UBI: physical eraseblock size:   262144 bytes (256 KiB) UBI: logical eraseblock size:    258048 bytes UBI: smallest flash I/O unit:    2048 UBI: VID header offset:          2048 (aligned 2048) UBI: data offset:                4096 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd8 to ubi0 UBI: MTD device name:            "nand.rootfs" UBI: MTD device size:            256 MiB UBI: number of good PEBs:        979 UBI: number of bad PEBs:         45 UBI: max. allowed volumes:       128 UBI: wear-leveling threshold:    4096 UBI: number of internal volumes: 1 UBI: number of user volumes:     0 UBI: available PEBs:             966 UBI: total number of reserved PEBs: 13 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 0/0 UBI: image sequence number: 0 UBI: background thread "ubi_bgt0d" started, PID 2098 UBI device number You will need: -p = physical eraseblock size = 256KiB -e = logical eraseblock size = 258048 -m = smallest flash I/O unit = 2048 -s = VID header offset = 2048 -c = available PEB = 966 Values only for iMX35 PDK NAND - K9LBG08U0D-PCB0 3. ON HOST - Now, create the images (two steps) You need to create ubinize.cfg file! ubinize.cfg [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=237MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize $ mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img mkfs.ubifs      root:                rootfs/      min_io_size:    2048      leb_size:         258048      max_leb_cnt:   966      output:            ubifs.img      jrn_size:          8388608      reserved:         0      compr:            lzo      keyhash:         r5      fanout:            8      orph_lebs:       1      super lebs:      1      master lebs:    2      log_lebs:         4      lpt_lebs:          2      orph_lebs:       1      main_lebs:       132      gc lebs:           1      index lebs:       2      leb_cnt:           142      UUID:              CC2057F9-B20F-46D1-A399-1FCA95DCAFF7 Success\! $ ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg $ ls -lh u* -rw-r--r-- 1 daiane daiane 35M 2010-11-26 15:21 ubifs.img -rw-r--r-- 1 daiane daiane 36M 2010-11-26 15:22 ubi.img -rw-r--r-- 1 daiane daiane 113 2010-11-26 15:22 ubinize.cfg $ sudo cp ubi.img rootfs/home/ 4. Format NAND using UBI image - ON TARGET Turn on target (or reset it) and format MTD partition $ cd /home $ ubiformat -f ubi.img /dev/mtd8 5. Load UBI file system Reset and change redboot script: .. fis load kernel .. exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none"

i.MX evaluation board can be a simple solution to program i.MX boards in a factory for instance. i.MX evaluation board are not for industrial usage, but you can find plenty of cheap i.MX insdustrial boards on the web. Here I am using an i.MX8QXP rev B0 MEK board and I will program an i.MX6Q SABRE SD board. The first step is to generate your image. Follow the documentation steps to generate the "validation" image. You will have to customize a little bit the local.conf file (in conf/local.conf) to have git, cmake, gcc and other missing package. edit local.conf and add the following lines at the end of the file: IMAGE_INSTALL_append = " git cmake htop packagegroup-core-buildessential xz p7zip rsync"‍‍‍‍‍ I have added rsync package in local, it can replace cp (copy) but with the --progress option you can see the copy progression. P7zip replace unzip for our images archives avaialable on nxp.com as unzip as issues with big files. then rebake your image: bitbake -k fsl-image-validation-imx‍‍‍‍‍ When it is done, go in tmp/deploy/image/<your image generated> and use uuu to program your board (I use a sd card; thus I can increase the partition esily): sudo ./uuu -b sd_all imx-boot-imx8qxpmek-sd.bin-flash fsl-image-validation-imx-imx8qxpmek.sdcard.bz2/*‍‍‍‍‍ As the rootfs can be too small, use gparted under Linux for instance to increase the size of the partition. Put the SD card and start your board. Here here the dirty part... You may know archlinux|ARM websitesite (Arch Linux ARM ), you have a lots of precompiled packages. Thus on the board you can download it, and copy the file in /usr folder (you can use it to have the latest openSSL for  instance!). Plug an ethernet cable on the board and check if it is up: ifconfig -a ifconfig eth0 up‍‍‍‍‍‍‍‍‍‍ Now you should have access to the internet. On uuu webpage you can find all the packages you need (here I am using a 4.14.98_2.0.0 Linux): mkdir missinglibs cd missinglibs wget http://mirror.archlinuxarm.org/aarch64/core/bzip2-1.0.8-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/nettle-3.5.1-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/libusb-1.0.22-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/libzip-1.5.2-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/zlib-1:1.2.11-3-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/p7zip-16.02-5-aarch64.pkg.tar.xz cd ..‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Wait all the archives are downloaded (otherwise you'll decompress before the archive is downloaded) as wget is running in background! Now untar the archives and copy it in the rootfs (dirty): tar -xJf libzip-1.5.2-2-aarch64.pkg.tar.xz tar -xJf libusb-1.0.22-1-aarch64.pkg.tar.xz tar -xJf nettle-3.5.1-1-aarch64.pkg.tar.xz tar -xJf bzip2-1.0.8-2-aarch64.pkg.tar.xz cp zlib-1:1.2.11-3-aarch64.pkg.tar.xz zlib tar -xJf zlib tar -xJf p7zip-16.02-5-aarch64.pkg.tar.xz cd usr sudo cp -R . /usr cd ../../ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download and compile uuu: git clone git://github.com/NXPmicro/mfgtools.git cd mfgtools/ cmake . make‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download an image on nxp.com for instance. I have downloaded on the i.MX6 4.14.98_2.0.0 image and put it on a usb key. then unzip it in the uuu folder: 7z e L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip‍‍‍‍ As mentionned before unzip cannot hadle big files... so use 7z as me plug the i.MX6Q SABRE SD to the i.MX8X and program your i.MX6 board: ./uuu uuu.auto-imx6qsabresd‍ uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.74-0-g64eeca1 Success 1 Failure 0 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Configuring RedBoot The configuration is made using a Minicom session that need to be established between host and target through serial port. To have an operational system been executed just on the power on, configure the right for Boot script. The chooses are shown in Boot Script section. To avoid the start of operational system, power on the board and press CTRL-C immediately. Wait until RedBoot> prompt appears. Overview The main command for beginners is fconfig -l that can be abbreviated as fc -l    This command shows the actual configuration of Redboot, like: RedBoot> fc -l Run script at boot: true Boot script: .. load -r -b 0x100000 /tftpboot/zImage .. exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/n" 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 RedBoot> Run script at boot: set true for booting with a script or false to always enter on prompt directly Boot script: define what commands to execute as script at the startup Boot script timeout: how many time to wait before execute boot script Use BOOTP for network configuration: set true for getting configuration from BOOTP or false for manually configuring gateway and IP address Gateway IP address: The IP address of the gateway Local IP address: The board IP address Local IP address mask: The board IP mask address Default server IP address: The host IP address when NFS and TFTP server are running Configuring Network Execute the command to configure network parameters: RedBoot> fc This step guarantee the possibilities to load images from some server previously connected and configured. For Use BOOTP for network configuration: answer false. For Gateway IP address: type the gateway IP address of your network; For Local IP address: type an IP address to your board, it needs to be a valid IP in your network; For Local IP address mask: type the IP mask address; For Default server IP address: type the IP of your host server where are running TFTP and NFS. Pay special attencion for Update RedBoot non-volatile configuration - continue (y/n)?. Answer y to have your configuration saved in the flash. To verify if your configuration is working use ping, be patient this command is very slow: RedBoot" ping -h 10.29.244.99 Network PING - from 10.29.241.6 to 10.29.244.99 PING - received 10 of 10 expected Use the "-n" option to change the number of pings and the "-r" option to speed things up, such as: ping -n 3 -h 10.29.244.99 -r 10. The boot script configuration is done in the next section. Boot Script NFS Boot In NFS Boot mode, a kernel image and a root file system image are loaded from a configured server through TFTP and NFS that can be executed doing the development more easy. To configure RedBoot for NFS Boot reset the board and press CTRL-C immediately. In a Minicom session type fc to modify the configuration boot. Enter the script boot below: RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> load -r -b 0x100000 /tftpboot/zImage >> 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" >> 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> The script is composed by two lines. The first line load the kernel image (zImage) by TFTP from /tftpboot, the directory configured in TFTP.\ The second line executes the kernel and mount the root file system using NFS. The path /tftpboot/ltib indicates the path that should be exported in the host machine. (It's the path in the /etc/exports) 10.29.244.99 is the host IP address 10.29.241.6 is the target IP address Flash Boot For flash boot the Boot Script differs a little bit: fis init kernel exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=none" The value for root can be different for each board type.

Before QT5 Qt3D was a separate project and was maintained separately.  Now it is offered along with other official plugins. QT3D supports the addition of 3D elements. In order to install it this is needed: Clone the git Qt3D repository $ git clone git://gitorious.org/qt/qt3d.git Using the Qmake that you already created when installing Qt5, this will setup the Makefile in order to cross compile the plugin. $ qmake $ make $ sudo make install Ready to play with Qt3D! This is the HelloWorld of 3D,  teapot.bez  is a bezier curves file with the forms of the famous teapot. import QtQuick 2.0 import Qt3D 1.0 Viewport{    width: 640; height: 480    Item3D{    id: teapot    mesh: Mesh { source: "teapot.bez" }    effect: Effect {}   } }

Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.

This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.

Introduction This is a brief guide showing how to integrate the driver for the WF111 module to the i.MX6 BSP Release. In this case the WF111 driver is available on a repository and it’s in accordance with the Yocto Project, which allows to easily customize a linux distribution for your board. Requirements WF111 Documentation – Silicon Labs have made a great job of documenting the steps to add the WF111 driver to a Linux distribution and have created Application Note 996 (link below), which we will use as reference. http://www.silabs.com/documents/login/application-notes/AN996.pdf WF111 Driver - We will also be using the Yocto layer included on the following repository: https://github.com/engicam-stable/meta-engicam i.MX6 3.14.52 BSP Release – In out scenario the WF111 layer that will be imported includes a driver that it’s compatible with Linux Kernel 2.6.24 up to 4.1., which it’s important to keep in mind.   Installing the 3.14.52 BSP Release First, setup the 3.14.52 BSP as described on the i.MX Yocto Project User’s Guide.   Adding the WF111 Driver Layer Clone the WF111 Driver Layer to your sources folder inside the BSP Release directory. Since the 3.14.52 BSP Release is based on Fido we will clone the Fido branch of the driver repository. $ cd <BSP_RELEASE_DIR>/sources $ git clone https://github.com/engicam-stable/meta-engicam -b fido‍‍  Once the layer is cloned you would need to add the new later editing the bblayers.conf file located the following path: <BSP_RELEASE_DIR>/<BUILD_DIR>/conf/bblayers.conf By adding the following line to add the new layer.   BBLAYERS += " ${BSPDIR}/sources/meta-engicam "‍   This should make the wf111-driver available through bitbake since bitbake will now look into this layer for all available recipes. You can then add the driver to your image by adding the following line to the <BUILD_DIR>/conf/local.conf   IMAGE_INSTALL_append += "wf111-driver"‍ Or you may create a new image recipe that includes the wf111-driver package. However, there are certain kernel options that must be enabled for the driver to work.   Creating an append to configure the kernel options Before we can bake an image with the WF111 driver we would need to edit the kernel options as mentioned on Silabs AN996. The following kernel options must be enabled:   CONFIG_WIRELESS_EXT CONFIG_MODULES CONFIG_FW_LOADER We would need to add the CONFIG_WIRELESS_EXT as the other two options are enabled on the BSP by default.   This involves adding an addendum to the kernel recipe to change its configuration. You may either add this append to any layer. The best way to handle it would be using a new layer for all your customization. You can find how to create a new layer on the following document: https://community.nxp.com/docs/DOC-331917 We’ll use a new layer called meta-newlayer for this example. It’s important that this layer has a high priority so the changes from the bbappend are not overridden. The following alternative was suggested by Chris Hossack on the following thread: https://community.nxp.com/thread/376369 First, run the menuconfig tool on the bitbake environment: bitbake linux-imx -c menuconfig Enable the necessary options: Networking Support > Wireless > cfg80211 wireless extensions compatibility   Save the configuration and exit. Then run the following bitbake command, which will create a config fragment file that contains the changed made to the default kernel options. bitbake linux-imx -c diffconfig We’ll make an append file that adds the required options.  Content of the config fragment:   CONFIG_WIRELESS_EXT=y CONFIG_WEXT_CORE=y CONFIG_WEXT_PROC=y CONFIG_WEXT_SPY=y CONFIG_WEXT_PRIV=y CONFIG_CFG80211_WEXT=y CONFIG_LIB80211=y CONFIG_LIB80211_CRYPT_WEP=y CONFIG_LIB80211_CRYPT_CCMP=y CONFIG_LIB80211_CRYPT_TKIP=y # CONFIG_LIB80211_DEBUG is not set CONFIG_HOSTAP=y # CONFIG_HOSTAP_FIRMWARE is not set‍‍‍‍‍‍‍‍‍‍‍‍‍    Since we are appending the kernel layer we need to add the addendum on the same path as that of the original kernel recipe but within our layer and create the append file there. Also add the WF111.cfg file to the linux-imx directory:   We would need to copy (and you may rename it as well) to the folder where are will be creating the append recipe for the kernel. Copy:  <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg To: <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg You can do so suing the following command: cp <BSP_RELEASE>/<BUILD_DIR>/tmp/work/<MACHINE>-poky-Linux-gnueabi/linux-imx/<KERNEL_VERSION>/fragment.cfg <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx/WF111.cfg‍ (Please note that the file was renamed for ease, but you may use any name for the config fragment)   We need to create the bbappend file on the following path (as it must be the same relative path as the original recipe it is appending) <BSP_RELEASE>/sources/meta-newlayer/recipes-kernel/linux/linux-imx_3.14.52.bbappend   The linux-imx_3.14.52.bbappend file would contain the following:   SRC_URI += "file://WF111.cfg"  do_configure_append() {          #this is run from         #./tmp/work/<MACHINE>-poky-linux-gnueabi/linux-imx/3.14.52-r0/git          cat ../*.cfg >> ${B}/.config  }‍‍‍‍‍‍    After creating this recipe you should be able to bake any image from the BSP and see the driver there. I tested with the core-minimal-image and found that the files were indeed added to /lib/firmware. $ bitbake core-image-minimal ‍‍‍

Copy Redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND or MMC flash media for Redboot. In this case, NAND is beeing used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate Copy redboot binary to /tftpboot. In this case: redboot.bin Load binary file to i.MX ram memory: RedBoot> load -v -r -b 0x100000 /tftpboot/redboot.bin Run the loaded image RedBoot> run 0x100000 Enable NOR, NAND, or MMC flash media for Redboot. In this case, NAND is being used. RedBoot> factive nand Update Redboot in the flash with currently running image RedBoot> romupdate

For Fedora Users: Open a terminal as root Edit tftp file -> #gedit /etc/xinetd.d/tftp Add these lines: service tftp     {   socket_type = dgram   protocol = udp   wait = yes   user = root   server = /usr/sbin/in.tftpd   server_args = /tftpboot   disable = no   per_source = 100 2   flags = IPv4 } Restart the service: # /etc/init.d/xinetd restart OR # service xinetd restart

This document explains the pad implementation and its relationship with the System Controller Firmware pad configuration service. There are two components to pad configuration in the SCFW, there are the modules that generate the signals that will ultimately appear on the physical pad, let's say GPIO/Ethernet/I2C/UART etc... and then there is the part that configures the muxing of the pad (what signal is going to be outputted through the specific pad), the drive strength of the pad, pull selection, etc, this is the part that the SCFW pad service configures. Introduction‌ The i.MX8 has three types of I/Os: 1.8V only I/Os 3.3V only I/Os 1.8V / 3.3V I/Os Dual Voltage I/Os Note: USB High Speed Inter-Chip (HSIC) and Ethernet interfaces have specific integration schemes with dedicated features. They are a modified versions of the above I/O types. HSIC are a special kind of I/O modified to sustain 480Mbps data rates ENET I/Os are modified versions of Dual Voltage I/Os to support 2.5V operations All of these I/Os have "common features" and "technology specific features" which depend on the type of I/O and the chip manufacturing process (FDSOI in the i.MX8QM case) I/O common features Muxing capability of up to 4 signals Each Pad can have up to 4 signals, only one signal can be present in the pad. To select the signal that will output on the pad simply look at the Pinmux spreadsheet and use the desired alternative, for instance in the following image SCU_GPIO0_00 has 3 options, SCU_GPIO (ALT0 - GPIO controlled directly by the SCU), SCU_UART0_RX (ALT1 - SCU UART receiver) or LSIO_GPIO0_IO28 (ALT3 - Low speed I/O GPIO).   Pads without GPIO functionality (i.e. without the GPIO option in the pinmux spreadsheet) are implemented for one purpose only, these pins are connected directly to the module that drives them and they feature their own physical interface. Examples are XTAL pins, DDR pins and SCU PMIC interface (shown above). Mode of operation All GPIO types support four modes of operation: Normal mode Data is being driven directly to the pad (an internal signal of 1 shows in the pad as a 1 and vice-versa) and the pad works either as an output or as an input but not both at the same time. The output buffer while on this mode looks like this: Open drain Data is being driven through an open drain configuration, the output on the pad switches between 0 and high-z. The pad works either as an output or as an input but not both at the same time, e.g. if the Output Buffer is enabled the Input Buffer is disabled. This is how the output buffer looks like on Open drain mode: Open drain and input Output buffer acts as in open drain mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to simultaneously read the signal at the pad while driving it. Output and input Output buffer acts as in normal mode but with the input buffer enabled regardless of the output buffer state (enabled/disabled), this allows to read the signal at the pad while driving it. Wake-up capability Each I/O can be configured to wake-up the device, the following configuration options are available: OFF I/O cannot wake-up the system Low detect Generate wake-up event when the pad remains in low-level High detect Generate wake-up event when the pad remains in high-level Rising edge Generate wake-up event on rising edge detection Falling edge Generate wake-up event on falling edge detection Technology specific features Some of the available features for each pad depend on two factors: Chip manufacturing process (FDSOI or LPP) I/O type (1.8V, 3.3V or Dual Voltage) The i.MX8QM is manufactured using FDSOI technology and it features all of the three available I/O types. Drive strength Drive strength options vary within I/O types and chip manufacturing options. The available options for a FDSOI chip are: 1.8V Drive strength options 3.3V Drive strength options Dual Voltage drive strength options Drive strength of 1mA Drive strength of 2mA Low drive strength (50 ohms) Drive strength of 2mA Drive strength of 4mA High drive strength (33 ohms) Drive strength of 4mA Drive strength of 8mA Drive strength of 6mA Drive strength of 12mA Drive strength of 8mA Drive strength of 10mA Drive strength of 12mA High-speed drive strength Pull Select The pull select available options are almost the same for all I/O types (1.8V being the exception) and they also depend on chip manufacturing process. The available options for a FDSOI chip are: Pull select options for FDSOI Bus-keeper (only available for 1.8V) Pull-up Pull-down No Pull (Disabled) A bus-keeper or bus-holder is used to keep the last state on the bus. In normal operation it makes no difference, but once the bus is tri-stated it keeps the last logic level in the bus to prevent the bus from floating. Compensation The compensation feature is only available on Dual Voltage I/Os. Dual Voltage I/Os have a different implementation, they require: Voltage reference generator - which provides a voltage reference to the supply detector and compensation cell Supply detector - detects automatically whether the I/O is being supplied with 1.8V or 3.3V and broadcasts this information to compensation cell and I/O  Compensation cell - adjusts drive strength of dual voltage I/Os depending on Process Voltage and Temperature (PVT) conditions. The default configuration takes care of adjusting this parameters and no further modifications are required. Pad configuration service SCFW API Mux selection The very first function that needs to be called to configure a pad is: sc_err_t sc_pad_set_mux(sc_ipc_t ipc, sc_pad_t pad, uint8_t mux, sc_pad_config_t config, sc_pad_iso_t iso);‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the muxing alternative and setting the common features, its parameters are: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. mux - The mux setting that you require, basically Alt0 -> 0, Alt1 -> 1, Alt2 -> 2 and Alt3-> 3, the pinmux spreadsheet contains the required information (take a look at I/O common features above). config - Used to select the desired mode of operation (take a look at I/O common features above), the available options are declared under sc_pad_config_t Normal mode - SC_PAD_CONFIG_NORMAL Open Drain mode - SC_PAD_CONFIG_OD Open Drain and input - SC_PAD_CONFIG_OD_IN Output and input - SC_PAD_CONFIG_OUT_IN iso - This is the low-power isolation configuration (take a look at I/O common features above). The available options are declared under sc_pad_iso_t ISO_OFF - SC_PAD_ISO_OFF ISO_EARLY - SC_PAD_ISO_EARLY ISO_LATE - SC_PAD_ISO_LATE ISO_ON - SC_PAD_ISO_ON For instance to configure M40_I2C0_SCL with its UART alternative in normal mode with low-power isolation off, the call would look like this: sc_pad_set_mux(ipc, SC_P_M40_I2C0_SCL, 1, SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);‍‍‍‍‍‍‍‍‍‍ Pad configuration To configure drive strength and pull select options the technology specific functions need to be used (FDSOI for i.MX8QM): sc_pad_set_gp is being used by our Linux team because it admits the passing of the configuration parameters as a single value and this eases the handling on the device tree, but you should aim to use the technology specific functions. sc_err_t sc_pad_set_gp_28fdsoi(sc_ipc_t ipc, sc_pad_t pad, sc_pad_28fdsoi_dse_t dse, sc_pad_28fdsoi_ps_t ps);‍‍‍‍‍‍‍‍‍‍‍ This function takes care of configuring the drive strength (DSE) and pull select settings (PS) for the specified pad, here is a break down of the parameters it uses: ipc - The Inter Processor Communication (IPC) channel that you will use to communicate with the SCU. You need to call sc_ipc_open to obtain it. pad - The pad you want to configure, the different pad definitions are in imx8qm_pads.h, this is basically the same list that is included in the scfw_api_qm.pdf document (page 27 Chapter 5 Pad List) and it also mimics the Pinmux excel sheet. dse - The desired drive strength configuration (see Technology specific features above). DSE settings depend on the I/O type being used, the available options for each I/O type are defined under sc_pad_28fdsoi_dse_t: ENET pads capable of operating at 2.5V are a subset of dual voltage I/Os, the dse options available for these pads are the same as normal dual voltage I/Os. i.e. High drive and low drive. ps - The desired pull select configuration (see Technology specific features above). The available options are defined under sc_pad_28fdsoi_ps_t: To determine whether a GPIO pad is 1.8V, 3.3V or Dual Voltage one can look at the pinmux spread sheet, the supply for the pad will indicate what implementation of the GPIO is used. For instance: pads under VDD_SIM_1P8_3P3 are Dual voltage I/Os pads under VDD_SCU_1P8 are 1.8V I/Os pads under VDD_ADC_3P3 are 3.3V I/Os taking the same example as above we could configure the M40_I2C0_SCL as follows: sc_pad_set_gp_28fdsoi(ipc, SC_P_M40_I2C0_SCL, SC_PAD_28FDSOI_DSE_DV_LOW, SC_PAD_28FDSOI_PS_NONE);‍‍‍‍‍‍‍‍‍‍‍‍‍ Configuration under Linux Linux configures pads through the device tree, the full documentation of the binding is under Documentation/devicetree/bindings/pinctrl/fsl,imx8qxp-pinctrl.txt. but here is an extract: * Freescale i.MX8QXP IOMUX Controller Required properties: - compatible: "fsl,imx8qxp-iomuxc" - fsl,pins: each entry consists of 2 integers. Its format is <pin_id pin_config>. pin_config definition: - i.MX8QXP have different pad types, please refer to below pad register definitions, the pinctrl driver will just write the pin_config into the hardware register.‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The driver uses the following API: sc_err_t sc_pad_set_gp (sc_ipc_t ipc, sc_pad_t pad, uint32_t ctrl) ‍‍‍ Instead of configuring each parameter individually as done with sc_pad_set_gp_28fdsoi it configures the pad as if writing to a register, the bitfield format is under the binding documentation but it is as follows: struct _hw_pad_iomux_bitfields0 { uint32_t GP : 19; /*!< [18:0] GP controls. */ uint32_t WAKEUP : 3; /*!< [21:19] Wakeup controls. */ uint32_t WAKEUP_ENB : 1; /*!< [22] Wakeup write enable. */ uint32_t LPCONFIG : 2; /*!< [24:23] Low-power config. */ uint32_t CONFIG : 2; /*!< [26:25] Config. */ uint32_t IFMUX : 3; /*!< [29:27] Mux. */ uint32_t GP_ENB : 1; /*!< [30] GP write enable. */ uint32_t IFMUX_ENB : 1; /*!< [31] Mux write enable. */ } B; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ All the configurations mentioned above can be configured, but they are done in a single pass, e.g. Muxing, Configuration (Norma, Open Drive, etc...), Wakeup control, and GP controls are for Pull Select Drive Strenght etc... Check the Reference Manual Chapter for IOMUXD for the register definition for each pad. References For more details refer to the sc_fw_api.pdf document: Chapter 1.3.3 Pad Configuration Service Chapter 6 Pad List Chapter 9.3 (SVC) Pad Service System Controller Firmware 101 

Play MPEG4 Video only gst-launch filesrc location=test.mpeg ! mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink H.264 Video only gst-launch filesrc location=test.avi ! mfw_avidemuxer ! mfw_vpudecoder codec-type=std_avc ! mfw_v4lsink AVI(H264+MP3) gst-launch filesrc location=test.avi ! mfw_avidemuxer name=demux demux. !  mfw_vpudecoder \     codec-type=std_avc ! mfw_v4lsink demux. ! queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink MP4(H264+MP3) gst-launch filesrc location=test.mp4 ! mfw_mp4demuxer name=demux demux. ! \    mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink demux. ! \    queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink <mp3_decoder_plugin> can be replaced by mad RAW Video Test gst-launch videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420 !  mfw_v4lsink