An i.MX50 customer encountered such kernel bug recently. Android UI has no response, because the suspend work queue is blocked:     suspend       pm_suspend         enter_state           suspend_prepare / suspend_finish             pm_prepare_console / pm_restore_console               vt_move_to_console                 vt_waitactive                   vt_event_wait                     wait_event_interruptible Confimed the same bug can also happen on imx6SL which is running linux 3.0.35. e.g. by echo standby/mem > /sys/power/state It takes over thousand suspend/resume cycles to reproduce the problem. The bug fix has been merged since linux 3.6: commit a7b12929be6cc55eab2dac3330fa9f5984e12dda

This document simply introduce how to change uboot for porting new PHY on imx7D customized board   Background: Current imx7D Sabresd board uses BCM54220B0KFBG PHY, the customized board wants to use KSZ9031 as PHY on the yocto 4.9.88 version, the customized board uses only one ethernet port on ENET2 port according to the imx7D Sabresd board   Requirement: Refer to the yocto user guide of 4.9.88 version, built your own image, for simple, you can built core-image-minimal, and download the 4.9.88 mfgtool to program        The document of 4.9.88: https://www.nxp.com/webapp/Download?colCode=L4.9.88_2.0.0_LINUX_DOCS        mfgtool for downloading: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX6_L4.9.88_2.0.0_MFG_TOOL&appType=file2&location=null&DOWNLOAD_ID=null&lang_cd=en        Design files: https://www.nxp.com/webapp/sps/download/license.jsp?colCode=iMX7D-SABRE-DESIGNFILES&appType=file1&DOWNLOAD_ID=null&lang_cd=en     adding customized code in u-boot head file： refer to the customized board schematic as below:     This board use eth2 as ethernet port, the code mx7dsabresd.h(path: yocto-L4.9.88_2.0/build-x11/tmp/work/imx7dsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/include/configs) /* Network */ #ifdef CONFIG_DM_ETH #define CONFIG_FEC_MXC #define CONFIG_MII #define CONFIG_FEC_XCV_TYPE             RGMII #define CONFIG_FEC_ENET_DEV       0   #define CONFIG_PHYLIB #define CONFIG_PHY_BROADCOM /* ENET1 */ #if (CONFIG_FEC_ENET_DEV == 0) #define IMX_FEC_BASE              ENET_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x0 #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth0" #else #define CONFIG_ETHPRIME                 "FEC0" #endif #elif (CONFIG_FEC_ENET_DEV == 1) #define IMX_FEC_BASE              ENET2_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x1 #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth1" #else #define CONFIG_ETHPRIME                 "FEC1" #endif #endif     Change the source code as below, add two macro definition and change the PHY address according to the schematic: /* Network */ #define CONFIG_PHY_MICREL #define CONFIG_PHY_MICREL_KSZ9031   #ifdef CONFIG_DM_ETH #define CONFIG_FEC_MXC #define CONFIG_MII #define CONFIG_FEC_XCV_TYPE             RGMII   #define CONFIG_FEC_ENET_DEV       0     #define CONFIG_PHYLIB #define CONFIG_PHY_BROADCOM /* ENET1 */ #if (CONFIG_FEC_ENET_DEV == 0) #define IMX_FEC_BASE              ENET_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x1 #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth0" #else #define CONFIG_ETHPRIME                 "FEC0" #endif #elif (CONFIG_FEC_ENET_DEV == 1) #define IMX_FEC_BASE              ENET2_IPS_BASE_ADDR #define CONFIG_FEC_MXC_PHYADDR          0x2   #ifdef CONFIG_DM_ETH #define CONFIG_ETHPRIME                 "eth1" #else #define CONFIG_ETHPRIME                 "FEC1" #endif #endif       adding customized code in u-boot source file： the source code named mx7dsabresd.c (path: yocto-L4.9.88_2.0/build-x11/tmp/work/imx7dsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/board/freescale/mx7dsabresd)         Don’t forget include the micrel.h file        Focus on the setup_fec fuction   Imx7d Sabresd board uses gpio_spi 5 as reset pin so the source code as below: ret = gpio_lookup_name("gpio_spi@0_5", NULL, NULL, &gpio)                if (ret) {               printf("GPIO: 'gpio_spi@0_5' not found\n");     The customized board uses GPIO1_IO03 as reset pin, so the source code was changed to : imx_iomux_v3_setup_pad(MX7D_PAD_GPIO1_IO03__GPIO1_IO3 | MUX_PAD_CTRL(NO_PAD_CTRL)); ret = gpio_request(IMX_GPIO_NR(1, 3), "enet_phy_rst"); gpio_direction_output(IMX_GPIO_NR(1, 3), 0);        mdelay(20);        gpio_direction_output(IMX_GPIO_NR(1, 3), 1);       udelay(100);         Focus on the function board_phy_config fuction Use this function to set the phy rx, tx data pad skew and clock pad skew, for ksz9031, can refer to the UDOO board, then change the setting source code as below: /* control data pad skew - devaddr = 0x02, register = 0x04 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);        /* rx data pad skew - devaddr = 0x02, register = 0x05 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);        /* tx data pad skew - devaddr = 0x02, register = 0x05 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x0000);        /* gtx and rx clock pad skew - devaddr = 0x02, register = 0x08 */        ksz9031_phy_extended_write(phydev, 0x02,                                MII_KSZ9031_EXT_RGMII_CLOCK_SKEW,                                MII_KSZ9031_MOD_DATA_NO_POST_INC, 0x03FF);       Build the uboot source code then program to the customized board, the log file as below: U-Boot 2017.03-imx_v2017.03_4.9.88_2.0.0_ga+gb76bb1b (Apr 20 2019 - 17:51:51 +0800)   CPU:   Freescale i.MX7D rev1.3 996 MHz (running at 792 MHz) CPU:   Commercial temperature grade (0C to 95C) at 32C Reset cause: POR Model: Freescale i.MX7D SabreSD Board Board: i.MX7D SABRESD RevC in secure mode DRAM:  1 GiB PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11 MMC:   FSL_SDHC: 0, FSL_SDHC: 1 Display: TFT43AB (480x272) Video: 480x272x24 In:    serial Out:   serial Err:   serial switch to partitions #0, OK mmc1(part 0) is current device Net:   Error: ethernet@30bf0000 address not set. eth0: ethernet@30be0000 Error: ethernet@30bf0000 address not set.   Ending： Don’t worry about this error message, because you don’t set correct mac address, one has two option to set this, For one, you can add mac address in the uboot manually, like setenv ethaddr 00:11:22:33:44:55     another option is add CONFIG_NET_RANDOM_ETHADDR=y in the configure file, then you don’t need to set mac address manually, would get a random mac address   this document just simply introduce how to change the source code in the u-boot, you also need to change the kernel dts file and kernel file to support the new PHY, the kernel has the same process, the phy address, the phy settings, and the gpio pins, hope this document give you some hints to port the new PHY

If anyone else has been frustrated by the lack of RT1050 support or is new to NXP products, the MCU On Eclipse blog has been a great help.  For example, see the MCUXpresso IDE V10.1.0 with i.MX RT1052 Crossover Processor article for a very clear overview/quickstart on getting the MIMXRT1050-EVK up and running. This document was generated from the following discussion: RT1050 Developer Resource

i.MX_Android_FAQ i.MX Android FAQ 1 Sync project and Build 1.1 How can I download AOSP repo from mirror server? By default, all aosp repo in the Android project will be downloaded from google server directly. But some may have issues to access the google server, if you have server which has mirrored the aosp repo then you can redirct the aosp repo download link. In i.MX android project, all aosp repo will be included in the ${MY_ANDROID}/.repo/manifests/aosp*.xml, you can redirect the aosp repo remote by changing the "fetch" for remote "aosp", below is an example to redirect the remote link to <your-mirror-server-address>: @@ -2,7 +2,7 @@ <manifest> <remote name="aosp" - fetch="https://android.googlesource.com/" + fetch="<your-mirror-server-address>/" review="https://android-review.googlesource.com/" /> <default revision="refs/tags/android-10.0.0_r32" remote="aosp" 1.2 How do I configure the build information? BUILD_ID and BUILD_NUMBER are two makefile variables that can be used in Android core build system to specify build information if they are defined. In our release package, we define the BUILD_ID as the internal release build number, and define the BUILD_NUMBER as the internal release date. You can customize the value of these two variables in the file of ${MY_ANDROID}/device/fsl/{product}/build_id.mk. "${MY_ANDROID}" represents a the root directory of Android source code. "{product}" is related to specific chips and boards, for example, it can be "imx8m/evk_8mq". Below is an example to update the BUILD_ID for i.MX 8MQuad EVK diff --git a/imx8m/evk_8mq/build_id.mk b/imx8m/evk_8mq/build_id.mk index 257b500..b177202 100644 --- a/imx8m/evk_8mq/build_id.mk +++ b/imx8m/evk_8mq/build_id.mk @@ -18,5 +18,5 @@ # (like "CRB01"). It must be a single word, and is # capitalized by convention. -export BUILD_ID=1.0.0-ga-rc2 +export BUILD_ID=1.0.0-ga-rc3 export BUILD_NUMBER=20190114 1.3 How do I change boot command line in boot.img? After using boot.img, we stored the default kernel boot command line inside of this image. It will package together during android build. You can change this by changing BOARD_KERNEL_CMDLINE's definition in ${MY_ANDROID}/device/fsl/{product}/BoardConfig.mk file. NOTE: Replace {product} with your product, eg, imx8m/evk_8mq. 1.4 How to fix Python2 incompatible with latest git-repo? You might meet below exception when you execute "repo init" or "repo sync": haoran@pentakill:~/ssd/imx_5.4.y$ repo sync -c repo: warning: Python 2 is no longer supported; Please upgrade to Python 3.6+. Traceback (most recent call last): File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/main.py", line 56, in <module> from subcmds.version import Version File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/subcmds/__init__.py", line 38, in <module> ['%s' % name]) File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/subcmds/upload.py", line 27, in <module> from hooks import RepoHook File "/home/ssd-1/haoran/imx_5.4.y/.repo/repo/hooks.py", line 472 file=sys.stderr) ^ In Android repository, the "repo" tool which used to work actually is from ${MY_ANDROID}/.repo/repo/repo. This Python script is from Google's https://gerrit.googlesource.com/git-repo by default. Google pushed the change for this git-repo.git and removed the Python2 support of the repo tool after Dec 2020. So the Python2 cannot execute the repo sub command any more based on latest repo tools. For older Android release, some build scripts of Android cannot support Python 3. So that it is not convenient to switch Python tool always between "repo sync" and images builts. A way to reslove this is that we can follow below instructions to fallback your git-repo version which work for Python 2 for older Android releases:  $cd ${MY_ANDROID}/.repo/repo $git checkout -b python2_repo 58ac1678e8438fd029a22365741fc57276eda404 $git branch python2_repo --set-upstream-to=origin/master 2 Connectivity 2.1 How do I setup a computer to support ADB? To setup a computer to support ADB, see Android web site for more details. There is one thing not clear in the page mentioned above about "setup the system to detect the device" on Ubuntu Linux, an udev rules file need to be created and well edited, please follow below steps:     1. Create the file of "/etc/udev/rules.d/90-android.rules" with root permission and add the vendors of the device to the file with below format SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev" SUBSYSTEM=="usb", ATTR{idVendor}=="1fc9", MODE="0666", GROUP="plugdev" the id value of "18d1" is USB VID of google, which is used in our USB HAL code. the id value of "1fc9" is the USB VID of NXP.     2. now execute blow command on the host chmod a+r /etc/udev/rules.d/90-android.rules 2.2 How do I setup a computer to support ADB In Recovery mode? NXP i.MX 6/7 series support applying system update from ADB's. Linux OS supports this feature by default. For Windows OS, follow the steps below: Install the Google usb driver. Apply the patch below to the USB driver from Google. Connect the USB cable to the board and install the driver according to the instructions provided. --- android_winusb.inf 2013-06-04 13:39:40.344756457 +0800 +++ android_winusb.inf 2013-06-04 13:43:46.634756423 +0800 @@ -23,6 +23,8 @@ [Google.NTx86] +;adb sideload support +%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_D001 ;Google Nexus One %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02 @@ -59,7 +61,8 @@ [Google.NTamd64] - +;adb sideload support +%SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_D001 ;Google Nexus One %SingleAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02 %CompositeAdbInterface% = USB_Install, USB\VID_18D1&PID_0D02&MI_01 2.3 How do I enable USB tethering? We support the USB tethering feature, and upstream device can be WIFI or Ethernet. USB tethering can be enabled in the Settings UI after your OTG USB cable is connected to PC: Settings -> Network & internet -> Hotspot & tethering -> USB tethering. On linux and Windows 7 PC, when USB tethering is enabled, you can easily get a usb network device with host driver installed automatically. The IP and DNS server is automatically configured. On Windows XP PC, when you have connected the board with the PC and you can see an unknown device named "Android" in the device manager, you have to manually install the tethering driver file of tetherxp.inf. After it is successfully installed, you can see "Android USB RNDIS device" in the device manager. By this time, you can use USB rndis network device to access the network. 2.4 How do I use MTP? The Media Transfer Protocol is a set of custom extensions to the Picture Transfer Protocol (PTP). Whereas PTP was designed for downloading photographs from digital cameras, Media Transfer Protocol supports the transfer of music files on digital audio players and media files on portable media players, as well as personal information on personal digital assistants. Starting with version 4.0, Android supports MTP as default protocol transfer files with PC, instead of the USB Mass Storage. By default, as Google suggested, we disabled the UMS and enabled MTP. NOTE: Please make sure you disable the USB Tethering when using MTP. Under WinXP, you can not make MTP work with ADB enabled, but under Win7, MTP can work together with ADB in most of the cases. When connecting the board to PC by USB cable, a USB icon will be shown in the notification bar. Then you can click on the notification area, and select "Connected as a media device" to launch the USB computer connection option UI. There, MTP and PTP can be chosen as current transfer protocol. You can also launch the option UI by Settings -> Storage -> MENU -> USB computer connection. MTP on Windows XP Windows XP supports PTP protocol by default. In order to support MTP protocol, you must install Windows Media Player (Version >= 10). When connecting to the PC, you can see MTP devices in windows explorer. Since Windows XP only supports copy/paste files in the explorer, you cannot directly open the files in MTP device. MTP on Windows 7 Windows 7 supports MTP(PTP) protocol by default. When connecting to the PC, you can see MTP devices in windows explorer. You can do any operations just as you would on your hard disk. MTP on ubuntu Ubuntu supports PTP protocol by default. To support MTP protocol, you must install the following packages: libmtp, mtp-tools by $ sudo apt-get install mtp-tools If your default libmtp version is not 1.1.1 (current latest libmtp on ubuntu is 1.1.0), you must upgrade it manually by: $ sudo apt-get install libusb-dev $ wget http://downloads.sourceforge.net/project/libmtp/libmtp/1.1.1/libmtp-1.1.1.tar.gz $ tar -xvf libmtp-1.1.1.tar.gz $ cd libmtp-1.1.1 $ ./configure --prefix=/usr $ make -j4 $ sudo make install After you have done the steps outlined above, you can transfer the files between PC and Device by the following commands: mtp-detect: find current connected MTP device mtp-files: list all the files on MTP device 2.5 How do I set networking proxy for Wi-Fi? To configure the proxy settings for a Wi-Fi network, you have to: Tap and hold a network from the list of added Wi-Fi networks Now choose "Advanced options", and scroll down to "Proxy". Choose "Manually". Then enter the proxy settings provided by the network administrator. Finally tap on the button denoted as "CONNECT". 2.6 How to adapt the "wifi country code" for a specific country and/or region? In i.MX Android Software, "CN" is used as default code while it's mainly for mainland of China. Some other countries and/or regions are listed in below table for convenience. If the target country/region is not in below table,  Search on the internet with the keyword of "ISO 3166" for the result. Code Country/Region name CA Canada JP Japan DE Germany NL Netherlands IT Italy PT Portugal LU Luxembourg NO Norway FI Finland DK Denmark CH Switzerland CZ Czech Republic ES Spain GB United Kingdom KR Republic of Korea (South Korea) FR France SG Singapore BR Brazil IL Israel AT Austria AU Australia BE Belgium CY Cyprus EE Estonia GR Greece HU Hungary ID Indonesia IE Ireland ID India IS Iceland LT Lithuania LV Latvia MY Malaysia NZ New Zealand PH Philippines PL Poland SE Sweden SI Slovenia SK Slovak Republic TH Thailand US United States ZA South Africa   2.7 How to switch the Power role of USB Power Delivery through USB Type-C? Several i.MX 8 board support the USB Power Delivery(PD) through USB Type-C port.The board can be acted as Power Sink or Power Source. Check corresponding Android Release Notes to see whether board support USB Power Delivery(PD) or not. Below are the steps to switch the Power role: 1.Connect a reference device with i.MX board: Use a Type-C to Type-C cable to connect i.MX board with the reference device(support Usb Power Delivery). 2.Check i.MX board device's role If i.MX board connects as host , and the reference device is a device(has a usb Drop-down menu to choose transfer files, ptp), then do step 3 on the reference device. If i.MX board connects as device(has a usb Drop-down menu to choose transfer files, ptp), and the reference device is a host, then do step 3 on i.MX board. 3.Power role switch If i.MX board is host: To make i.MX board as Power Source to charge the reference device, choose "Charging this device" on the reference device's usb Drop-down menu. To make i.MX board as Power Sink to be charged by the reference device, choose "Supplying power" on the reference device's usb Drop-down menu. If i.MX board is device: To make i.MX board as Power Source to charge the reference device, choose "Supplying power" on i.MX board's usb Drop-down menu. To make i.MX board as Power Sink to be charged by the reference device,choose "Charging this device" on i.MX board's usb Drop-down menu. NOTE: 1.Below command can check current power role for the i.MX board cat /sys/class/typec/port0/power_role source [sink] : means this i.MX board is been charged by the reference device, [source] sink : means this i.MX board is charging the reference device, 2.The reference device should support the USB Power Delivery(PD). You can check whether the reference device support it or not by below command when it is connected with i.MX board's USB Type-C port: cat /sys/class/typec/port0/port0-partner/supports_usb_power_delivery, If this value is yes, then this reference device supports usb power delivery. Google pixel phone meets this requirement, but Google nexus 6 does not. 3 Core 3.1 How do I enter Android Recovery mode manually? When the system is running, press "VOLUME DOWN" and "Power" to enter Recovery mode if board has these keys. This check is in u-boot.git board support file, where you can change your preferred combo keys. Also, you can input this command in the console: reboot recovery # the board reset to recovery mode. to enter recovery mode. 3.2 How do I enter the text menu in recovery mode? NOTE: This function only works on boards with POWER / VOLUME UP / VOLUME DOWN keys. When the system completes booted up into recovery mode, you will see an Android Robot Logo Press the POWER KEY(keep pressed), and then VOLUME UP KEY going to the text menu like this: Move the menu item by VOLUME UP and VOLUME DOWN button. Select the menu item by Power Key. Select the required option using the direction keys on the keypad or keyboard. reboot system now apply update from ADB, you may update the software from update.zip by adb sideload command. Only NXP i.MX 6/7 series support this feature. wipe data/factory reset. /data and /cache partitions are formatted. wipe cache partition. /cache partition is formatted. Reboot the system. 3.3 How do I upgrade system by ADB? NXP i.MX 6/7 series support applying system update from ADB. Before upgrade the system with ADB tool, please install adb driver first, see "2 Connectivity->2.2 How do I setup a computer to support ADB In Recovery mode?" section. After the installation and setup of the driver is complete, follow the steps below: Download the OTA update package to your computer, and connect the board to your PC with USB cable. Ensure that the system has entered recovery mode. See "3.1 How do I enter Android Recovery mode manually" section. Toggle the text Menu, move the cursor to "apply update from ADB", the UI is displayed as follows: On your computer, execute below command adb sideload $YOUR_UPDATE_PACKAGE.zip After the package is sent, the system starts updating the firmware with the update file. 3.4 How do I use android fastboot? Fastboot is an utility which can be used to download images from Windows/Linux PC to the target storage device. This utility is released by Google, which can be downloaded from Android official site. Android release implements part of the fastboot commands in the U-Boot, such as: flash, reboot, getvar. Before using the fastboot, Google usb driver should be installed on windows HOST and the target board should boot up to bootloader fastboot mode. NOTE: the size of images downloaded by fastboot must be less than the related partition size. Target side: Power on the board with USB OTG connected. Make sure board enter fastboot mode. There are several ways to enter fastboot mode. Option1: Input  reboot bootloader  in console after boot. Option2: Connect power to the board. You'll see the following output from the console. U-Boot ... ... Fastboot: Normal Hit any key to stop autoboot: 3 Hit any key before the countdown completes to access the bootloader prompt. Type fastboot usb and hit Enter: Fastboot: Normal Hit any key to stop autoboot: 0 => fastboot usb NOTE: 1.On HOST PC, it will prompt you that a new device was found and that you need to install the driver. Please install it. 2.After board enter U-Boot mode, type mmc part on target side to get detail partition name defined in partition table image. Some partitions are hardcoded in u-boot, it will not be listed here. Host side: Make sure fastboot is contained by the system environment variable of "PATH". Go to image folder. Below is an example to use fastboot to flash images for NXP imx8 series. Make sure your board is in unlock state before flashing images with fastboot. bootloader0/bootloader and gpt partitions is hardcoded in u-boot, it's not in partition table file. names and number of partitions defined in partition table file may change as time goes on and new features are enabled. $ fastboot flash gpt partition-table.img $ fastboot flash bootloader0 u-boot.imx $ fastboot flash dtbo dtbo.img $ fastboot flash boot boot.img $ fastboot flash system system.img $ fastboot flash vendor vendor.img $ fastboot flash vbmeta vbmeta.img $ fastboot reboot Below is an example to use fastboot to flash images for NXP i.MX 6/7 series. $ fastboot flash gpt partition-table.img $ fastboot flash bootloader u-boot.imx $ fastboot flash dtbo dtbo.img $ fastboot flash boot boot.img $ fastboot flash system system.img $ fastboot flash vendor vendor.img $ fastboot flash vbmeta vbmeta.img $ fastboot flash recovery recovery.img $ fastboot reboot 3.5 How to do incremental OTA update for imx6/7?      3.5.1 Check the definition of "IncrementalOTA_InstallEnd" function i.MX6/7 code released before Android10(not include Android10) does not support to build incremental OTA package. need to define a function named "IncrementalOTA_InstallEnd" in releasetools.py for a specific platform, this is a file under ${MY_ANDROID}/device/fsl. take i.MX 7ULP EVK as an example, this file is ${MY_ANDROID}/device/fsl/imx7ulp/releasetools.py. if the function is not defined, make below changes on the code. Other platforms have their own releasetools.py, modify the file based on you own requirement.                                                   diff --git a/imx7ulp/releasetools.py b/imx7ulp/releasetools.py index 8c40905d..d557b23e 100644 --- a/imx7ulp/releasetools.py +++ b/imx7ulp/releasetools.py @@ -38,3 +38,25 @@ def FullOTA_InstallEnd(info): # emit the script code to trigger the dtbo updater on the device info.script.WriteRawImage("/dtbo", "dtbo.img") + +def IncrementalOTA_InstallEnd(info): + # copy the vbmeta and dtbo into the package. + try: + vbmeta_img = common.GetBootableImage( + "vbmeta.img", "vbmeta.img", OPTIONS.input_tmp, "VBMETA") + dtbo_img = common.GetBootableImage( + "dtbo.img", "dtbo.img", OPTIONS.input_tmp, "DTBO") + except KeyError: + print "no vbmeta or dtbo images in target_files; skipping install" + return + # copy the vbmeta into the package. + common.ZipWriteStr(info.output_zip, "vbmeta.img", vbmeta_img.data) + + # emit the script code to trigger the vbmeta updater on the device + info.script.WriteRawImage("/vbmeta", "vbmeta.img") + + # copy the dtbo into the package. + common.ZipWriteStr(info.output_zip, "dtbo.img", dtbo_img.data) + + # emit the script code to trigger the dtbo updater on the device + info.script.WriteRawImage("/dtbo", "dtbo.img")                                                   The variable "BOARD_PREBUILT_DTBOIMAGE" in ${MY_ANDROID}/device/fsl  is used to specify the dtbo images to be built into the OTA package. modify the value of this variable based on your requirement. Take i.MX7ULP EVK as an example, you may need to made below change to make the OTA package suitable for boards with MIPI panel display                                                   diff --git a/imx7ulp/evk_7ulp/BoardConfig.mk b/imx7ulp/evk_7ulp/BoardConfig.mk index 0c023ecc..ec1c695f 100644 --- a/imx7ulp/evk_7ulp/BoardConfig.mk +++ b/imx7ulp/evk_7ulp/BoardConfig.mk @@ -103,7 +103,7 @@ TARGET_BOARD_DTS_CONFIG := imx7ulp:imx7ulp-evkb.dtb imx7ulp-evk:imx7ulp-evk.dtb TARGET_BOARD_DTS_CONFIG += imx7ulp-mipi:imx7ulp-evkb-rm68200-wxga.dtb imx7ulp-evk-mipi:imx7ulp-evk-mipi.dtb TARGET_KERNEL_DEFCONFIG := imx_v7_android_defconfig # TARGET_KERNEL_ADDITION_DEFCONF := imx_v7_android_addition_defconfig -BOARD_PREBUILT_DTBOIMAGE := out/target/product/evk_7ulp/dtbo-imx7ulp.img +BOARD_PREBUILT_DTBOIMAGE := out/target/product/evk_7ulp/dtbo-imx7ulp-mipi.img # u-boot target used by uuu for imx7ulp_evk TARGET_BOOTLOADER_CONFIG += imx7ulp-evk-uuu:mx7ulp_evk_defconfig                                                   3.5.2 Build target package file                You can use below command to generate target package file under android environment: $ cd ${MY_ANDROID} $ source build/envsetup.sh $ lunch evk_7ulp-userdebug $ make target-files-package -j4 After the build finish, you can find target package file in the following path: . ${MY_ANDROID}/out/target/product/evk_7ulp/obj/PACKAGING/target_files_intermediates/evk_7ulp-target_files-**.zip Copy the target file to ${MY_ANDROID} directory, let's rename it as evk_7ulp-target.a.zip. then execute below command to generate the full OTA package. $ ./build/tools/releasetools/ota_from_target_files evk_7ulp-target.a.zip evk_ota_full.zip Apply this OTA package evk_ota_full.zip to the board. for example, with adb, execute below commands on the host which is connected to the board via the USB cable: $ sudo adb root $ sudo adb reboot sideload # wait a while until the system reboot into sideload mode $ sudo adb sideload evk_ota_full.zip After preceding commands finished, the reboot the system. the images running on the board is the same as images in "evk_7ulp-target.a.zip"    3.5.3 Build incremental update package An incremental update contains a set of binary patches to be applied to the data already on the device. This can result in considerably smaller update packages. Incremental OTA package is also build from target package file, the difference with full OTA package is that two target package files are needed to generate on incremental OTA package. one target package has the images already running on the board, one has the image to be updated to. For example, we've update the i.MX 7ULP EVK board with images running on it the same as images in "evk_7ulp-target.a.zip". After this, some development work is done on the code. we can build the target package file again and generate full OTA package just as described in "3.5.2 Build target package file", We can also use this new generated target package file together with evk_7ulp-target.a.zip to generate a incremental OTA package. Assume that we've generated a target file, copied to ${MY_ANDROID} directory and rename it as evk_7ulp-target.b.zip. execute below command on the host to generate incremental OTA package: $ ./build/tools/releasetools/ota_from_target_files -i evk_7ulp-target.a.zip evk_7ulp-target.b.zip evk_7ulp_ota_diff.zip An incremental OTA package is generated with preceding command. it should be applied on device running the same images as in target file evk_7ulp-target.a.zip. This incremental OTA package can also be updated to the board with adb, just as described for full OTA package. After this OTA package is applied. next time if another incremental OTA is needed, a new generated target package file and the old evk_7ulp-target.b.zip is used to generate it. 4 A/V 4.1 How do I check frame drop statistic while video playback? Input below commands from console while video playback to get the real-time frame drop statistics. dumpsys media.player | grep "num" Then check the output,frame drop statistic will be showed like: numFramesTotal(1892), numFramesDropped(0), percentageDropped(0.00%) numFramesTotal: The total frames of the video file. numFramesDropped: The dropped frame count as AV synchronization. percentageDropped: The total dropped frame percentage. 5 Graphics 5.1 How to set GPU Minimal clock to balance performance and power consumption? Normally GPU works at full speed. When thermal driver report chip too hot, the GPU driver will adjust internal clock to reduce the power consumption to cool the chip down quickly. In theory we should set the GPU clock to 1/64 so that chip can be cool down more quickly, but you may see the black screen or flicker issue when GPU work at so slow clock especially in large resolution. There is below way to customize the threshold of GPU minimal clock based the chip and the resolution of their product. Customer can set the minimal GPU clock by change below line in ${MY_ANDROID}/device/fsl/{product}/init.rc file, the value can be set to any value from 1 to 64. write /sys/module/galcore/parameters/gpu3DMinClock 3 Current default value is 3. Customer should tune and set the suitable value based on their test. 5.2 How to disable GPU acceleration? There are three parts using GPU acceleration on android. Customer may need to disable some of them separately to narrow down issue. Below are the steps to do it. 1.Disable HWComposer: You can disable HWComposer in Setting apk, Settings->System-> {} Developer options ->Disable HW overlays 2.Disable OpenGL Renderer You can disable OpenGL Renderer and force use SKIA to draw by set "setprop sys.viewroot.hw false" and kill surfaceflinger thread. 3.Disable OpenGL 3D draw Disable OpenGL 3D draw can only be done after Disable OpenGL Renderer as this operation will totally disable all 3D OpenGL acceleration. You can do it by "mv /system/lib/egl/libGLES_android.so /system/lib/egl/libGLES.so" and kill surfaceflinger thread. NOTE: below example tell you how to kill surfaceflinger root@sabresd_6dq:/ # ps | grep surfaceflinger system 159 1 168148 7828 ffffffff b6f05834 S /system/bin/surfaceflinger root@sabresd_6dq:/ # kill 159 6 Boot 6.1 How to boot form different paritions of eMMC for boards with i.MX 8QuadXPlus b0 chips? i.MX 8QuadXPlus MEK with silicon revision b0 chips can boot from eMMC boot partition 32KB offset, but this is not a behaviour specified in the Reference Manual, it is not guaranteed to work fine on your boards. As the Reference manual shows that the first image container offset is 0 if the bootloader image is in eMMC boot partition or 32KB if the bootloader image is in eMMC User data area partition. If boot from eMMC boot partition 32KB offset does not work on your boards, some changes can be made to comply with the description in the Reference Manual: 1. bootloader image at eMMC boot partition with 0 offset with this scenario, eMMC fast boot mode should be used for i.MX 8QuadXPlus silicon revision b0 chips. eMMC fast boot mode is not enabled by default, and enabling it is irreversible. fastboot command "fuse prog -y 0 0x13 0x1" can be used to enable eMMC fastboot mode, this can be add to the uuu_imx_android_flash scripts. an example on uuu_imx_android_flash.sh: diff --git a/common/tools/uuu_imx_android_flash.sh b/common/tools/uuu_imx_android_flash.sh index da45518cb..49ee53555 100755 --- a/common/tools/uuu_imx_android_flash.sh +++ b/common/tools/uuu_imx_android_flash.sh @@ -145,6 +145,9 @@ function uuu_load_uboot if [[ ${target_dev} = "emmc" ]]; then echo FB: ucmd mmc partconf ${target_num} 1 1 1 >> /tmp/uuu.lst fi + if [[ ${soc_name} = "imx8qxp" ]] && [[ ${uboot_feature} != *"c0"* ]]; then + echo FB: ucmd fuse prog -y 0 0x13 0x1 >> /tmp/uuu.lst + fi if [[ ${intervene} -eq 1 ]]; then echo FB: done >> /tmp/uuu.lst Also, the "bootloader0" partition offset for i.MX 8QuadXPlus silicon revision b0 should change to 0 from 32K. diff --git a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c index 92c978e6c8..7e3679b19a 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c @@ -55,7 +55,7 @@ static ulong bootloader_mmc_offset(void) { if (is_imx8mq() || is_imx8mm() || ((is_imx8qm() || is_imx8qxp()) && is_soc_rev(CHIP_REV_A))) return 0x8400; - else if (is_imx8qm() || (is_imx8qxp() && !is_soc_rev(CHIP_REV_B))) { + else if (is_imx8qm() || is_imx8qxp()) { if (MEK_8QM_EMMC == fastboot_devinfo.dev_id) /* target device is eMMC boot0 partition, bootloader offset is 0x0 */ return 0x0; 2. bootloader image at eMMC User data area partition with 32KB offset. with this scenario, code in uboot should be modified to make the "bootloader0" partition in eMMC User data area partiton. Below patch can work for i.MX 8QuadXPlus MEK with b0 chips, but it obviously will impact other platforms, apply below path with caution. diff --git a/drivers/fastboot/fb_fsl/fb_fsl_dev.c b/drivers/fastboot/fb_fsl/fb_fsl_dev.c index f1c116bea2..c23f0a3e01 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_dev.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_dev.c @@ -124,7 +124,7 @@ static int get_fastboot_target_dev(char *mmc_dev, struct fastboot_ptentry *ptn) printf("Flash target is mmc%d\n", dev); if (target_mmc->part_config != MMCPART_NOAVAILABLE) sprintf(mmc_dev, "mmc dev %x %x", dev, /*slot no*/ - FASTBOOT_MMC_BOOT_PARTITION_ID/*part no*/); + FASTBOOT_MMC_USER_PARTITION_ID/*part no*/); else sprintf(mmc_dev, "mmc dev %x", dev); } @@ -559,4 +559,4 @@ void process_erase_mmc(const char *cmdbuf, char *response) sprintf(response, "OKAY"); return; -} \ No newline at end of file +} diff --git a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c index 92c978e6c8..4629060402 100644 --- a/drivers/fastboot/fb_fsl/fb_fsl_partitions.c +++ b/drivers/fastboot/fb_fsl/fb_fsl_partitions.c @@ -231,7 +231,7 @@ static int _fastboot_parts_load_from_ptable(void) bootloader_mmc_offset() / dev_desc->blksz; ptable[PTN_BOOTLOADER_INDEX].length = ANDROID_BOOTLOADER_SIZE / dev_desc->blksz; - ptable[PTN_BOOTLOADER_INDEX].partition_id = boot_partition; + ptable[PTN_BOOTLOADER_INDEX].partition_id = user_partition; ptable[PTN_BOOTLOADER_INDEX].flags = FASTBOOT_PTENTRY_FLAGS_UNERASEABLE; strcpy(ptable[PTN_BOOTLOADER_INDEX].fstype, "raw"); eMMC also need to be set to boot from User data area partition, set this in uuu_imx_android_flash scripts. An example on uuu_imx_android_flash.sh is as below, note that this will have impact on flashing other platforms, apply it with caution. diff --git a/common/tools/uuu_imx_android_flash.sh b/common/tools/uuu_imx_android_flash.sh index da45518cb..d98844d84 100755 --- a/common/tools/uuu_imx_android_flash.sh +++ b/common/tools/uuu_imx_android_flash.sh @@ -143,7 +143,7 @@ function uuu_load_uboot echo FB: ucmd mmc erase ${uboot_env_start} ${uboot_env_len} >> /tmp/uuu.lst if [[ ${target_dev} = "emmc" ]]; then - echo FB: ucmd mmc partconf ${target_num} 1 1 1 >> /tmp/uuu.lst + echo FB: ucmd mmc partconf ${target_num} 1 7 1 >> /tmp/uuu.lst fi if [[ ${intervene} -eq 1 ]]; then 7 Misc 7.1 How to enable Developer options on Android Jelly Bean and later version? Google has hidden the Developer options since the version Jelly Bean - here's how to get them back: Go to the Settings menu, and scroll down to "System". Tap it. Then Tap "About tablet" menu. Scroll down to the bottom again, where you see "Build number." Tap it seven times. After the third tap, you'll see a playful dialog that says you're four taps away from being a developer. Keep on tapping, until you've got the developer settings back. 7.2 How do I enable or disable bus frequency feature? The Bus Frequency driver is used to low down the DDR, AHB and AXI bus frequency in the SoC when the IPs who needs high bus frequency is not working. This saves the power consumption in Android earlysuspend mode significantly (playing audio with screen off). The bus frequency driver is enabled by default, if you want to enable or disable it, please do the following command in the console: Disable:    $ echo 0 > sys/bus/platform/drivers/imx_busfreq/busfreq/enable Enable:    $ echo 1 > sys/bus/platform/drivers/imx_busfreq/busfreq/enable Please note that if you're using ethernet, the up operation will enable the FEC clock and force bus frequency to be high. That means you can not go into low bus mode anymore, no matter the ethernet cable is plugged or unplugged. So if you want to system going to low bus mode, you must do 'netcfg eth0 down' to shutdown the FEC manually. If you want to use FEC again, please do 'netcfg eth0 up' manually, when FEC is shutdown with clock gated, the PHY can not detect your cable in/out events. 7.3 How do I use memtool?    7.3.1 build memtool in Android environment git clone https://source.codeaurora.org/external/imx/imx-test/ -b imx_5.4.24_2.1.0 cp -r imx-test/test/memtool ${MY_ANDROID}/external  cd ${MY_ANDROID} source build/envsetup.sh lunch evk_8mm-userdebug mmm external/memtool             The built binaries stores at ${MY_ANDROID}/out/target/product/evk_8mm/vendor/bin/memtool_32 and ${MY_ANDROID}/out/target/product/evk_8mm/vendor/bin/memtool_64    7.3.2 rebuild boot image             Add below patch to enable CONFIG_DEVMEM, then rebuild boot.img and flash it on board: fastboot flash boot_a boot.img diff --git a/arch/arm64/configs/imx_v8_android_defconfig b/arch/arm64/configs/imx_v8_android_defconfig index ee40b9aa67e6..cdc9a1d56849 100644 --- a/arch/arm64/configs/imx_v8_android_defconfig +++ b/arch/arm64/configs/imx_v8_android_defconfig @@ -477,7 +477,6 @@ CONFIG_INPUT_ISL29023=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_AMBAKMI=y # CONFIG_LEGACY_PTYS is not set -# CONFIG_DEVMEM is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_EXTENDED=y    7.3.3 use memtool on board Push memtool to board's disk: adb push ${MY_ANDROID}/out/target/product/evk_8mm/vendor/bin/memtool_32 /data/local/tmp Run memtool_32 to get help info: evk_8mm:/ # /data/local/tmp/memtool_32 Usage: Read memory: memtool [-8 | -16 | -32] <phys addr> <count> Write memory: memtool [-8 | -16 | -32] <phys addr>=<value>   7.4 How do I use systrace? The systrace tool can be used to analyze Android device performance. Please refer to below links about what is systrace and how to use it: https://source.android.com/devices/tech/debug/systrace  https://developer.android.com/topic/performance/tracing/command-line  The systrace tool will require the "CONFIG_DEBUG_FS" config to be enabled or you may have below error when generating the report: Starting tracing (stop with enter) Tracing completed. Collecting output... /system/bin/sh: <stdin>[2]: can't create /sys/kernel/debug/tracing/trace_marker: No such file or directory Outputting Systrace results... In some new Android releases, the "CONFIG_DEBUG_FS" config is disabled by default, you will need to enable it by yourself to enable the systrace function. For example: diff --git a/arch/arm64/configs/imx_v8_android_car2_defconfig b/arch/arm64/configs/imx_v8_android_car2_defconfig index 9e38bb17d640..bf35ce161d6d 100644 --- a/arch/arm64/configs/imx_v8_android_car2_defconfig +++ b/arch/arm64/configs/imx_v8_android_car2_defconfig @@ -509,3 +509,4 @@ CONFIG_PANIC_TIMEOUT=5 CONFIG_DEBUG_LIST=y CONFIG_ENABLE_DEFAULT_TRACERS=y # CONFIG_UPROBE_EVENTS is not set +CONFIG_DEBUG_FS=y   8 Port ISP camera to Android It’s a quick guide for developers to port ISP camera from Linux to Android on evk_8mp. Assume you have already got the Android source code and know how to build and flash image. Those can be got from Android release docs. Below just focus on porting ISP camera. Also assume the camera works ok on Linux.   8.1 Driver code path vendor/nxp-opensource/verisilicon_sw_isp_vvcam   8.2 Driver compile 8.2.1 compile command Under Android root path, follow below commands. 1) source build/envsetup.sh 2) lunch evk_8mp-userdebug 3) ./imx-make.sh kernel -j8     // Just run once is ok 4) ./imx-make.sh vvcam -j8  If build ok, will generate ko under below path. fanghui@aps001:~/share_home2/android-11-5.10/out/target/product/evk_8mp$ ls obj/VVCAM_OBJ/ basler-camera-driver-vvcam.ko  kernelenv.sh  os08a20.ko  ov2775.ko  vvcam-dwe.ko  vvcam-isp.ko  vvcam-video.ko   8.2.2 compile arrangement Below are the related files vvcam/vvcam.mk If a new sensor is added. You need add copy script in vvcam.mk, such as cp $(VVCAM_SRC_PATH)/sensor/ov2775/ov2775.ko $(VVCAM_OUT);   vvcam/v4l2/Kbuild It’s copied from vvcam/v4l2/Makefile, just some necessary changes to make it build ok on Android. If there are changes for a new sensor in Makefile, should be aligned to Kbuild.   device/nxp/common/build/Makefile FYI. It’s where vvcam is added to the android build system. You should never change it. fanghui@aps001:~/share_home2/android-11-5.10/device/nxp$ grep -rn vvcam.mk common/build/Makefile:20:-include ${VVCAM_PATH}/vvcam/vvcam.mk   8.3 Driver update    On 8mp, GKI (genera kernel image) is used. ISP related KOs are built into vendor_boot.img, then flash to the board. Follow below command. cd ANDROID_ROOT    // assume “ANDROID_ROOT” is the root path of android code. ./imx-make.sh vendorbootimage -j8 adb reboot bootloader sudo fastboot flash vendor_boot out/target/product/evk_8mp/vendor_boot.img. sudo fastboot reboot After reboot, the updated KOs will be loaded   Note: If add new KO, need first add to device/nxp/imx8m/evk_8mp/SharedBoardConfig.mk as below. ifeq ($(IMX8MP_USES_GKI),true) BOARD_VENDOR_RAMDISK_KERNEL_MODULES +=     \     ……     $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/basler-camera-driver-vvcam.ko \     $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/vvcam-video.ko \     $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/vvcam-dwe.ko \     $(TARGET_OUT_INTERMEDIATES)/VVCAM_OBJ/vvcam-isp.ko \   8.4 DTB update 8.4.1 DTB arrangement In device/nxp/imx8m/evk_8mp/BoardConfig.mk, change below to your dtb.     # Default dual basler     TARGET_BOARD_DTS_CONFIG := imx8mp:imx8mp-evk-dual-basler.dtb  Related dts file should be under     vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale  8.4.2 Build DTB image On ANDROID root path, run ./imx-make.sh kernel -j8 ./imx-make.sh dtboimage -j8 8.4.3 Update DTB image 1) adb reboot bootloader 2) sudo fastboot flash dtbo dtbo-imx8mp.img 3) sudo fastboot reboot   8.5 New sensor lib update 8.5.1 Build sensor lib      The default sensor is basler. If use new sensor, you need build your own libMySensor.so to implement interfaces in isi_iss.h.       You should got ISP code package by "wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/isp-imx-4.2.2.15.0.bin". Note: the "isp-imx-4.2.2.15.0.bin" should be replaced the version you used.        Follow appshell/readme_android.txt to build the lib. 8.5.2 Update sensor lib       1) adb root       2) adb remount       3) adb pull /vendor/etc/configs/isp/Sensor0_Entry.cfg       4) Change "drv ="/vendor/lib64/DAA3840_30MC_1080P.drv""           to "drv ="/vendor/lib64/libMySensor.so"".           Change xml and dwe to related files.       5) adb push Sensor0_Entry.cfg /vendor/etc/configs/isp/     Also, you may push related xml/dwe files. Note:     "/vendor/etc/configs/isp" may still read only even after "adb remount", it's due to overlay system. Ref "overlay" in "/vendor/etc/init/hw/init.nxp.rc".     On default image, "/vendor/etc/configs/isp" is overlaid by "/vendor/vendor_overlay_sensor/os08a20/vendor/etc/configs/isp".      So need update files under "/vendor/vendor_overlay_sensor/os08a20/vendor/etc/configs/isp", then reboot.     After reboot, "/vendor/etc/configs/isp" is updated. 9 Security 9.1 How to enhance IOMUX security? The IOMUX module on i.MX 8M serials SoCs enables flexible I/O multiplexing, allowing users to configure each IO pad as one of selectable functions. The CSU (Central Security Unit) module on i.MX 8M can be used to configure some devices as secure only accessible to protect the security of these devices. But as the IOMUX is Non-Secure accessilbe and thus the pad function can be configured dynamicaly, there is one risk if hackers reconfigure the IO pad to make the device connected to other controller which is accessible to Non-Secure world. One solution for this issue is configuring the CSU to limit Non-Secure access to IOMUX, all IOMUX registers write operations are routed to Trusty OS. In the Trusty OS, add all sensitive IO resources to one blacklist, the IOMUX driver in Trusty OS should check and deny any write attemption to sensitive registers from Non-Secure world. One example patch set is attached to show how to assign the IOMUX to secure world and how to route the IOMUX write operations to Trusty OS. In this example, the USB Host pinctrl PAD on i.MX8MP EVK was assigned to secure world. The layout of the example codes are:         . ├── atf │ └── 0001-config-iomux-to-secure-write.patch --> ${MY_ANDROID}/vendor/nxp-opensource/arm-trusted-firmware ├── kernel │ └── 0001-Use-Trusty-OS-to-handle-iomux-registers-written-oper.patch --> ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/ ├── trusty │ └── 0001-Add-iomux-pinctrl-TEE-handler.patch --> ${MY_TRUSTY}/trusty/hardware/nxp └── u-boot └── 0001-Use-Trusty-OS-to-handle-IOMUX-operation.patch --> ${MY_ANDROID}/vendor/nxp-opensource/uboot-imx        

Wir laden Sie zum i.MX 6 Workshop in Mainz recht herzlich ein. Bei diesem Workshop wird Ihnen der Controller von Freescale im Detail erklärt. Neben der Vorstellung der Entwicklungsumgebungen steht der Gedankenaustausch mit den Referenten und Entwicklern ganz weit oben. Melden Sie sich jetzt an! Zielgerichtet aus der Praxis für die Praxis phyFLEX i.MX 6 Workshop Schulungen sind Investitionen, die sich durch Zeitgewinn und sichere Designs in kürzester Zeit amortisiert haben. Sie sichern vorhandenes Wissen und passen Arbeitsweisen an Weiterentwicklungen des Marktes an. Neue Controller mit erweiterten Fähigkeiten und neuen Hardwareansätzen erfordern erweitertes Wissen. Betriebssysteme und moderne Entwicklungsumgebungen bieten andere Arbeitsweisen, die der Komplexität heutiger Projekte gerecht werden. Ihre Weiterbildung ist uns wichtig. Termine: 07.11.2013 in Mainz Zeit: 9:00 Uhr bis 18:00 Uhr Begrüßung unserer Gäste ab 8:30 Uhr in der Robert-Koch-Straße 37 in 55129 Mainz. Workshopinhalt: Agenda Ab 8:30          Empfang in der Robert-Koch- Str. 37, 55129 Mainz 09:00 – 09:15 Begrüßung der Gäste und Vorstellung der Referenten 09:15 – 10:30 Vorstellung des Prozessors, Herr Rodrigue Simonneau, Freescale 10:30 – 10:45 Kaffeepause 10:45 – 11:45 Vorstellung Hardware (Modul & Carrier Board)                         - der i.MX 6 in unseren Produktfamilien                         - verfügbare Features des phyFLEX-i.MX 6 Moduls                        - Applikationsplatine: Welche Schnittstellen stehen schon im Kit zur Verfügung?                        - Mögliche Bestückungsvarianten des Serienmoduls 11:45 – 12:15 Zeit für Fachgespräche mit den Entwicklern 12:15 – 13:00 Mittagspause 13:00 – 14:00 Führung durch die Produktion 14:00 – 15:00 Digital Imaging mit i.MX 6 - Einführung in die Kameraschnittstellen des i.MX 6 - Konzepte zum Anschluss von Kameramodulen - Überblick über das Software-Interface 15:00 – 16:15 Vorstellung der Linux Entwicklungsumgebung bis hin zum Erarbeiten eines Beispiels                       - LiveDVD mit Eclipse                        - Beispiel-Programm unter Eclipse zur Ansteuerung der GPIO Platine              - Grafik Demos mit OpenGL und Mpeg Decoder               - Benchmark zum Anzeigen der Leistung einzelner Cores 16:15 – 16:45       Zeit für Fachgespräche mit den Entwicklern 16:45 – 17:00     Kaffeepause 17:00 – 18:15        Vorstellung Windows Embedded Compact 7              - Welche neuen Features stehen unter WEC7 zur Verfügung?                - Erste Schritte in WEC7 auf der phyFLEX-i.MX6              - Applikations-Debugging über USB Active Sync               - Verwendung der Remote Tools des Plattform Builders 18:15           Zeit für Fachgespräche mit den Entwicklern Am Tag des Workshops besteht die Möglichkeit ein Phytec i.MX 6 Kit (Linux oder WEC7) käuflich zu erwerben. Geben Sie gleich bei Ihrer Anmeldung an, ob an einem Kauf gernerelles Interesse besteht. Nutzen Sie diese Möglichkeit und melden Sie sich gleich zum i.MX 6 Workshop in Mainz an: Anmeldung Für nähere Fragen und Anmeldung steht Ihnen unser Vertriebsteam gerne zur Seite: Telefon: + 49 (0) 6131/ 9221-32 Unsere Produkte zum i.MX 6 finden Sie hier.

Unpack the kit Boards CPU board Debug board Personality board Cables RS-232 serial cable Ethernet straight cable High-speed USB cables with mini AB connectors for OTG High-speed cable with standard A to mini B connectors Mini-USB adaptor Jack to RCA audio/video cable Power Supply 5.0V/2.4A universal power supply kit Paperwork CD-ROMs: Content CD End-User License Agreement Quick Start Guide (this document) Warranty card Freescale Support card Build the platform Connect the Personality board to Debug board. The personality board connects to the Debug board using a 500-pin connector. The connector is keyed to avoid misconnection, so there is only one way to connect these boards. Then, connect the CPU board to the underside of Debug board. Certify the version of bootloader When updating the BSP files of a system, it's recommended to rewrite a right version of bootloader in the target. Connect platform to PC To connect the 3-Stack platform to your host PC: Connect one end of an RS-232 serial cable (included in the kit) to a serial port connector (CON4) on the Debug board and connect the other end to a COM port on the host PC. Configure SW4-1 to ON. Make sure that SW4-8 is ON, to supply power to all three boards. Configure SW4-2 to OFF. Confirm that the Bootstrap switches (SW5–SW10) are set for external NAND boot (see more here) Connect the regulated 5V power supply to the appropriate power adapter. Plug the power adapter into an electrical outlet and the 5V line connector into the J2 (5V POWER JACK) connector on the Debug board. Start a serial console application on your host PC with the following configuration: Baud Rate 115200 Data Bits 8 Parity None Stop Bits 1 Flow Control None On the Debug board, switch the power switch (S4) to 1. The OS image pre-loaded in the 3-Stack board will boot and the debug messages from the bootloader should now appear on the serial console application on your PC See Also For a setting without the Debug board see Demonstration Platform.

This package is a OTA upgrade implementation for smartlocker in i.MX7ULP kernel. The bootaux command for i.MX7ULP can also be applied to other projects. File description: smartlocker OTA upgrade user manual. Modified u-boot. Modification involves: Add bootaux command. To use this command, the M4 image will be read out from boot partition to TCM_L. (Or DDR and then it will be copied to TCM_L in the command) It took 19ms to read M4 image. Change u-boot default env. If M4 image and zImage read failed, recovery M4 image and zImage will be loaded. patch of u-boot changes. u-boot defconfig for bootaux change. sh script, updater.sh. Example for upgrade package. Power shutdown in copying upgrade files may cause file broken. So currently, we use below copy strategy: Copy upgrade file to target directory as tmp file. Delete target file. Rename tmp file to target file.

Introduction Even though we have provided MQX OS support for imx6SX M4 core, we don’t need such complex operation system running on M4 core in some cases. For users who want to simplify and accelerate their M4 application development, bare metal codes without OS support is also a good choice. This demo will show how to develop bare metal codes for i.MX SoloX. Verified Platform imx6sx sabresd Application Notes How to develop bare metal codes running on M4 core .pdf Demo files a9_launch_m4: Run at A9 core and launch M4 core m4_apps: Run at M4 core

prebuilt image: image_imx-android-13.4.1_6qsabresd u-boot variables: bootcmd=booti mmc2 bootargs=console=ttymxc0,115200 init=/init androidboot.console=ttymxc0 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

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

Question: In a single uImage to contain the compressed kernel and rootfs, if the uImage is greater than 16MB, the system will not boot and reports errors. Is there a size limitation on uImage?  If so, is there a work around? Answer: uImage should only contains kernel compressed. rootfs should be read through a linux partition after the kernel boots up. Regarding the uImage's size, there is no limitation. In the other hand, a single uImage with kernel and filesystem is needed; in other words, kernel (alias uImage) needs a filesystem to work, and these are two independent systems in that sense. If u-boot, kernel and filesystem are in a single device (SD Card), the filesystem must be mounted in the first partition (SD, eMMC, etc) starting somewhere > 16M/512 sectors. But in cases where: * A fast boot is needed with  very small rootfs * As a intermediate (temporal) rootfs  before switching  to the real rootfs. The usage (actually used when flashing with the MFG tool) of this intermediate system is to load heavy modules, keeping the uImage small. This mechanism is called initramfs and the uImage will contain the kernel and the this mini rootfs compressed as cpio archive. But there appears to be a 16MB limitation. See here:  http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/ It seems to be related to alignment suggesting that 24-bit addressing is used instead of 32-bit.  I did notice Thumb mode is used, which seems odd to me.

THE CONTENTS •Background Knowledge −Kernel Introduction −Linux Kernel Directory Structure of the Source Code •Kernel Loading Procedure −Linux OS Boot Process −First Stage of Loading Sequence(Assembly Language) −Second Stage of Loading Sequence(C Language)

RedBoot is a bootloader, which contains support for some i.MX SoCs. Compiling RedBoot All Boards Compiling RedBoot Configuring RedBoot Configuring RedBoot All Boards Configuring RedBoot Loading Redboot Binary Directly to RAM Minicom Updating RedBoot Updating RedBoot Through RedBoot All Boards Updating RedBoot Through RedBoot IMX27 PDK NAND Flashing RedBoot i.MX31 PDK NAND Flashing RedBoot i.MX35 PDK NAND Flashing Kernel and Root File System Using RedBoot RedBoot Utilities All Boards Transfer Serial RedBoot Fixing Redboot RAM Bug Fixing Redboot RAM bug (CSD1 not activated)

Product Family Features Freescale's i.MX family of applications processors has demonstrated leadership in the portable handheld market. The i.MX21 multimedia applications processor is the latest addition to this family and builds on its low-power, high-performance heritage. Freescale has shipped more than 60 million chips of our industry-founding applications processors. That means you can start smart by picking products with a technology pedigree to handle all the creativity you can pump into them. The i.MX21 features the advanced and power-efficient ARM926EJ-S core operating at speeds starting at 266 MHz and is part of a growing family of Smart Speed products that offer high performance processing optimized for lowest power consumption. ARM926EJ-S™ core (16 KB I-Cache, 16 KB D-Cache) Smart Speed Switch 16/18-bit color LCD controller up to SVGA USB On-The-Go (two-host port) MPEG-4 and H.263 encode/decode acceleration up to CIF 30 fps Additional Resources IMX21-ADS I.MX21 ADS Board Flashing IMX21-and-iMXL-Lite-Kit

Flash a full SD Card Android Image (4GB) using Linux on VMWare Flash a full SD card image (4GB) using Flashnul in Windows Flash a full SD Card Android Image (4GB) using Linux on VMWare Note: It is preferred that SanDisk 4G SD card be used rather then Kingston. Kingston seemed to enumerate slightly smaller then SanDisk which actually inhibited us from flashing the image onto Kingston.    Within VMWare player, go to places/filesystems/dev to see what the SD card is called. When plugging in or removing the SD card from an external reader, you should see within the dev folder files called sdx…etc. [x= some letter]. That will help you specify which card to program with your image. Make note of the file [which is really a drive] name. For example in my VMWare player, it turns out that my SD card that I want to program was sdb. Also, if windows asks to format the drive, allow it and use Fat32. And, if you notice the drive is only 1GB instead of 3-4GB its because you only formatted the windows structure of the disk, the Linux portion that might reside on it does not show up in Windows. For distribution, the entire image which includes the *.bin file {this is the one you are trying to get onto the SD card} can be downloadable from a Freescale FTP site or some other media. It is a large file which is between 1-2GB. In this Android example, the file is called MasterA.gz. GZ is a linux based zip application which runs circles around winzip or 7-zip. The Android image, MasterA.gz, was 1.08 GB. The file you want to see in this example is MasterA.bin. Open a terminal window in VMWare. Within VMWare, unzip the file. If you select the file, then right mouse click it it will give you the option to uncompress using GZ. Before moving forward, make sure the SD card is unmounted. To do this type sudo umount /dev/sdX {note: sdb was the SD card we previously found enumerated}.           If you don’t know if it is mounted, in places/filesystems/dev on the left side of the screen you will see names with shown next to it. That means it’s          mounted. To copy Android image to sd card, type sudo dd if=masterA.bin of=/dev/sdX bs=10M X is the sd card (like /sdb, /sdc etc.) This will take some time, so if you have to stop this process hit <ctrl C> or close the terminal window. This will take some time but that’s all that it takes. Use the bottom task bar of the VMware screen, to attach the USB removable drive to Linux. Flash a full SD card image (4GB) using Flashnul in Windows  The tool you will use to flash the content is FlashNul in windows. This is available at http://shounen.ru/soft/flashnul/flashnul-1rc1.zip Steps Insert your flash media Run flashnul -p (from the dir that has flashnul) Note the physical device number for flash media Run flashnul <number obtained in prior step> -L \path\to\downloaded.img Answer "yes" if the selected destination device is correct Remove your flash media when the command completes Be careful what drive you erase. There are warnings presented before you commit: Disk PhysicalDrive2 (UNC name: \\.\PhysicalDrive2)         ------------------------------------------------------------[Drive geometry]--         Cylinders/heads/sectors = 482/255/63         Bytes per sector = 512         CHS size = 3964584960 (3780 Mb)         ---------------------------------------------------------------[Device size]--         Device size = 3965190144 (3781 Mb)         delta to near power of 2 = 329777152 (314 Mb), 8%         Surplus size = 605184 (591 kb)         -----------------------------------------------[Adapter & Device properties]--         Bus type = (7) USB         Removable device = Yes         Command Queue = Unsupported         Device vendor = Generic         Device name = USB SD Reader         Revision = 0.00         --------------------------------------------------------------[Hotplug info]--         Device hotplug = Yes         Media hotplug = No Selected operation: load file content Selected drive: PhysicalDrive2, 3965190144b (3781 Mb)</pre>         THIS OPERATION IS DESTRUCTIVE!!!         Type 'yes' to confirm operation. All other text will stop it. Really destroy data on drive PhysicalDrive2? :yes         -----------------------------------------------------------------------[Log]-- Runing operation [load file content] for drive PhysicalDrive2 Writing 0x36110000 (865 Mb), 3362893 b/s      

i.MX6UL/ULL extend uart port and integrate SIP I2C device. Contents 1 硬件设计说明 ............................................................. 2 硬件框图 ........................................................................ 2 硬件模块设计 ................................................................. 4 IOMUX 表 ....................................................................... 8 2 编译环境搭建 ............................................................. 8 编译环境文档及镜像下载。 ............................................ 8 编译环境搭建 ............................................................... 11 3 移植BSP 到扩展串口板 ........................................... 15 Uboot 中支持新的DTB ................................................ 15 Uboot 中调试串口改成UART6 ..................................... 16 去除掉无用的驱动及其IOMUX .................................... 18 增加i.MX6UL/ULL 本身串口支持 ................................. 18 增加GPIO 输出支持（GPIO_LED） ............................ 26 增加GPIO 输入支持（GPIO_KEY） ........................... 30 增加PWM支持 ............................................................ 34 增加i.MX6UL 本身ADC 支持 ....................................... 38 修改网口驱动仅支持一个网口 ...................................... 41 增加NXP PCF8591 I2C 转ADC 芯片支持 ................... 44 增加NXP PCA9555A I2C 转GPIO 芯片支持(rework 支持) 47 增加NXP PCT2075 I2C 温度传感器芯片支持(rework 支持) 55 增加NXP PCF8563 I2C RTC 支持(rework 支持) ......... 58 增加NXP PCA9632 I2C LED控制器芯片支持(rework 支持) 65 增加CH438 EIM 转串口芯片支持(delay) ..................... 70

MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

All Boards Creating App MP3 OpenEmbedded