i.MX Android FAQ
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"
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
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.
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
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
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:
--- 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.
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.
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.
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.
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:
To configure the proxy settings for a Wi-Fi network, you have to:
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 |
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.
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.
NOTE: This function only works on boards with POWER / VOLUME UP / VOLUME DOWN keys.
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:
adb sideload $YOUR_UPDATE_PACKAGE.zip
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:
reboot bootloader
in console after boot.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:
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
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
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"
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.
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.
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.
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
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.
eMMC also need to be set to boot from User data area partition, set this in uuu_imx_android_flash scripts.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");
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.lstif [[ ${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
fiif [[ ${intervene} -eq 1 ]]; then
Google has hidden the Developer options since the version Jelly Bean - here's how to get them back:
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.
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
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
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>
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
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.
vendor/nxp-opensource/verisilicon_sw_isp_vvcam
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
Below are the related files
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);
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.
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
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.
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 \
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
On ANDROID root path, run
./imx-make.sh kernel -j8
./imx-make.sh dtboimage -j8
1) adb reboot bootloader
2) sudo fastboot flash dtbo dtbo-imx8mp.img
3) sudo fastboot reboot
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.
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.
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