Overview This document explains how to use Pulse Width Modulation (PWM) on the iMX93 EVK Board. Attached to this post is a patch to enable this functionality, which can be integrated into either Yocto or a standalone kernel compilation.   This procedure was tested on iMX93 EVK A0 silicon version with BSP 6.1.22 version, this feature should work on A1 silicon version too but is not tested yet.   Kernel Configuration: To enable PWM support, modify the imx_v8_defconfig  file by adding the following line: CONFIG_PWM=y CONFIG_PWM_ADP5585=y CONFIG_PWM_CROS_EC=m CONFIG_PWM_FSL_FTM=m CONFIG_PWM_IMX27=y CONFIG_PWM_RPCHIP=y CONFIG_PWM_SL28CPLD=m + CONFIG_PWM_IMX_TPM=y​ # Add this line   Device Tree Modifications: You will need to add the following nodes to the device tree to configure the TPM (Timer/Pulse Width Modulation) controller:   + &tpm4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tpm4>; + status = "okay"; + }; ... + pinctrl_tpm4: tpm4grp { + fsl,pins = < + MX93_PAD_GPIO_IO05__TPM4_CH0 0x19e //EXP_GPIO_IO05 J1001 29 + >; + };​   Compiling and Flashing: After making the above changes, compile the kernel and device tree. Once the compilation is complete, flash the new image and device tree to the iMX93 EVK Board.  PWM Configuration on the Board After flashing, you can configure the PWM settings on the board. Open a terminal and execute the following commands: $ cd /sys/class/pwm/pwmchip1/ $ echo 0 >> export $ echo echo 2000000 >> pwm0/period # Set period to 2,000,000 ns (2 ms) $ echo echo 1000000 >> pwm0/duty_cycle # Set duty cycle to 1,000,000 ns (1 ms) $ echo 1 >> pwm0/enable   Validation To validate the PWM output signal, check pin 29 of connector J1001 on the iMX93 EVK Board.   Conclusion Following these steps should enable PWM functionality on your iMX93 EVK Board. If you encounter any issues, please refer to the documentation or reach out for assistance. Best Regards! Chavira

share more detailed steps how to bring up stereo capture of basler camera by imx8mp

Overview The purpose of this document is to provide a guide on how to enable UART 4 on i.MX8M Mini on Cortex A53. By default on i.MX-ATF is set on Cortex M4 Domain, i.MX-ATF helps ensure that i.MX processors boot securely. Reference: imx-atf. Requirements: Arm Toolchain: sudo apt-get install gcc-aarch64-linux-gnu 1. Build imx-boot image For a better reference how to build imx-boot image, go to Section 4.5.13 How to build imx-boot image by using imx-mkimage available on i.MX Linux User's Guide.   $ cd ~ $ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2023.04 $ cd uboot-imx/ $ git checkout lf-6.6.23-2.0.0 $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8mm_evk_defconfig $ export ARCH=arm64 $ cd ~ $ git clone https://github.com/nxp-imx/imx-mkimage.git $ cd imx-mkimage/ $ git checkout lf-6.6.23-2.0.0 $ cd ~ $ git clone https://github.com/nxp-imx/imx-atf.git $ cd imx-atf/ $ git checkout lf-6.6.23-2.0.0   The master domain for the UART4 is assigned to the Cortex M4, so, make the following changes to assign it to the A53 processor instead: diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c index 179b6226f..b0427afff 100644 --- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c +++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c @@ -114,10 +114,11 @@ static const struct imx_csu_cfg csu_cfg[] = { #else static const struct imx_rdc_cfg rdc[] = { /* Master domain assignment */ - RDC_MDAn(RDC_MDA_M4, DID1), + RDC_MDAn(RDC_MDA_A53, DID0), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART1, D0R | D0W),   After applying the changes, set your toolchain and then, compile with the following command: $ make PLAT=imx8mm bl31   In case you have the following error: Use this command to unset the flags and compile again: $ unset LDFLAGS   Then, copy the corresponding files to imx-mkimage/iMX8M. For more information, please check section 4.5.13 on i.MX Linux User's Guide. *NOTE: Some of this files are located on a link which you can access with the following command, for more information check the Release Notes, in this case for version 6.6.23-2.0.0 on Embedded Linux for i.MX Applications Processors. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.24-fbe0a4c.bin $ chmod +x firmware-imx-8.24-fbe0a4c.bin $ ./firmware-imx-8.24-fbe0a4c.bin   Finally, copy flash.bin located on: imx-mkimage/iMX8M to a folder to flash your board as follows: You can download the uuu.exe from mfgtools and the .wic file from the prebuild images from: Embeded Linux for i.MX Applications Processors uuu.exe -b emmc_all flash.bin imx-image-full-imx8mmevk.wic   2. Change DTB to enable UART4 First, copy and rename the imx8mm-evk.dts to identify there is a change for enabling UART4: $ cd linux-imx $ cp arch/arm64/boot/dts/freescale/imx8mm-evk.dts arch/arm64/boot/dts/freescale/imx8mm-evk-uart4.dts $ vi arch/arm64/boot/dts/freescale/imx8mm-evk-uart4.dts And make the following changes: &ecspi2 { status = "disabled"; }; &uart4 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart4>; assigned-clocks = <&clk IMX8MM_CLK_UART4>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; &iomuxc { pinctrl_uart4: uart4grp { fsl,pins = < MX8MM_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x140 MX8MM_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x140 MX8MM_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x140 MX8MM_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x140 >; }; }   After applying the changes, set your toolchain and then, compile with the following commands: $ make imx_v8_defconfig $ make freescale/imx8mm-evk-uart4.dtb Finally, copy the DTB to your board, reboot it and change the DTB in the u-boot environment, boot your board and take a look to see if the UART4 is correctly enabled.    

Since U-Boot can read/write/update nodes inside the device tree blob before booting the kernel, the idea is to have a generic display node in the device tree which U-Boot will populate with the proper values. You can see in our source tree that all our device trees contain: fb_hdmi alias to setup HDMI configuration fb_lcd alias to setup LCD displays fb_lvds and t_lvds to setup LVDS1 display fb_lvds2 and t_lvds2 to setup LVDS2 display (when available) So U-Boot is now is charged to setup those nodes which will configure your display(s) easily. First of all it requires the U-Boot, Once you have a recent U-Boot, you can have a look at the supported display for your board by issuing: => fbpanel clock-frequency hactive vactive hback-porch hfront-porch vback-porch vfront-porch hsync-len vsync-len hdmi: 1280x720M@60:m24x1,50:74161969,1280,720,220,110,20,5,40,5 74161969 1280 720 220 110 20 5 40 5 hdmi: 1920x1080M@60:m24x1,50:148500148,1920,1080,148,88,36,4,44,5 148500148 1920 1080 148 88 36 4 44 5 ... Since the list is actually pretty long and not always easy to read, you can also filter by type of display (hdmi, lcd or lvds) => fbpanel lcd clock-frequency hactive vactive hback-porch hfront-porch vback-porch vfront-porch hsync-len vsync-len lcd: fusion7:m18x2,10:33264586,800,480,96,24,31,11,136,3 33264586 800 480 96 24 31 11 136 3 lcd: CLAA-WVGA:m18x2,48:27000027,800,480,40,60,10,10,20,10 27000027 800 480 40 60 10 10 20 10 ... => fbpanel lvds clock-frequency hactive vactive hback-porch hfront-porch vback-porch vfront-porch hsync-len vsync-len lvds: hannstar7:18x2,38:71108582,1280,800,80,48,15,2,32,6 71108582 1280 800 80 48 15 2 32 6 ... The above command just lists the available displays, when you want to set one, you need will to set the following variables: fb_hdmi controls HDMI display selection fb_lcd controls LCD display selection fb_lvds controls LVDS display selection fb_lvds2 controls LVDS2 display selection Also, when a display isn't used, you need to set it to off. Here is an example on how to setup the HDMI to display at 1080P and LVDS display to be the Hannstar 10' => setenv fb_lvds hannstar => setenv fb_hdmi 1920x1080M@60 => setenv fb_lcd off => saveenv Saving Environment to SPI Flash... SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB Erasing SPI flash...Writing to SPI flash...done => reset Once rebooted, you can have a look at the cmd_hdmi, cmd_lcd and cmd_lvds that U-Boot will have set => print cmd_hdmi cmd_hdmi=fdt set fb_hdmi status okay;fdt set fb_hdmi mode_str 1920x1080M@60; => print cmd_lvds cmd_lvds=fdt set fb_lvds status okay;fdt set fb_lvds interface_pix_fmt RGB666;fdt set ldb/lvds-channel@0 fsl,data-width ;fdt set ldb/lvds-channel@0 fsl,data-mapping spwg;fdt set t_lvds clock-frequency ;fdt set t_lvds hactive ;fdt set t_lvds vactive ;fdt set t_lvds hback-porch ;fdt set t_lvds hfront-porch ;fdt set t_lvds vback-porch ;fdt set t_lvds vfront-porch ;fdt set t_lvds hsync-len ;fdt set t_lvds vsync-len ; => print cmd_lcd cmd_lcd=fdt set fb_lcd status disabled Do not try to set those cmd_* variables yourself, they will be overwritten by U-Boot at bootup anyway. That's it, you should now be able to list, select and setup the displays the way you want. For another type of display, It depends on the type of display: LVDS: yes, since all the timings are inside the device tree node you can change them. Here is an example for our latest 7"1280x800 display, although only the latest U-Boot binary lists it, you can have it running by entering: => setenv fb_lvds tm070jdhg30:24:68152388,1280,800,5,63,2,39,1,1 => saveenv Note that it goes like this: setenv fb_xxx mode_str:connection-type:clk-frequency,hactive,vactive,hback-porch,hfront-porch,vback-porch,vfront-porch,hsync-len,vsync-len The connection-type is very important since it allows to specify: The data mapping: default is SPWG, need to add "j" to switch to JEIDA The split mode: for dual LVDS channels operations (for 1080P display for instance) need to add "s" The data width: can be 18 or 24 For instance, here is a fb_lvds setup for a dual channel JEIDA LVDS display with 24-bit witdth: => setenv fb_lvds 1080P60:js24:148500148,1920,1080,148,88,36,4,44,5 LCD: yes for U-Boot display, no for the kernel You can set the fb_lcd like it is done for LVDS above, however the timings will only be used to setup U-Boot, only the mode_str will be passed on to the kernel. This means that the kernel needs to know about the LCD beforehand. Here is an example for the ASIT500MA6F5D display: => setenv fb_lcd ASIT500MA6F5D:m24:32341861,800,480,88,40,32,13,48,3 => saveenv HDMI: yes (well more or less) Same as the LCD setting, only the mode_str is passed on to the kernel. The difference is that it can work out of the box on the kernel side if you ask for a standard resolution and standard refresh rate. For instance, setting fb_hdmi to 1920x1080M@30 will work automatically since the kernel is smart enough to recognize a known resolution (1080P) with a standard refresh rate (30fps).    

This is an example for user to transfer files between i.MX8MP Linux platform and other devices via Bluetooth. Environment : Hardware : i.MX8MP LPDDR4 EVK Board, Android Phone Software : L6.6.23-2.0.0   Step1 : Build Yocto image and burnt to the SD card or EMMC repo init -u https://github.com/nxp-imx/imx-manifest.git -b imx-linux-scarthgap -m imx-6.6.23-2.0.0.xml repo sync DISTRO=fsl-imx-xwayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b build-xwayland Add the following code to "conf/local.conf"          IMAGE_INSTALL:append = " glibc-gconv-utf-16" bitbake imx-image-full uuu -b emmc_all imx-image-full-imx8mp-lpddr4-evk.rootfs-20240919015845.wic Step2 : Test steps Boot board with "imx8mp-evk-usdhc1-m2.dtb" file. load Wi-Fi Firmware           root@imx8mp-lpddr4-evk:~# modprobe moal mod_para=nxp/wifi_mod_para.conf Load BT firmware and enable BT          root@imx8mp-lpddr4-evk:~# modprobe btnxpuart          root@imx8mp-lpddr4-evk:~# hciconfig                    root@imx8mp-lpddr4-evk:~# hciconfig hci0 up connect  the BT of Android Phone          root@imx8mp-lpddr4-evk:~# bluetoothctl          [bluetooth]# default-agent          [bluetooth]# agent on          [bluetooth]# discoverable on          [bluetooth]# scan on          [bluetooth]# scan off                    [bluetooth]# pair 90:F0:52:92:A6:6C          we need to type Yes on board and click 配对 on phone.                           [bluetooth]# connect 90:F0:52:92:A6:6C                 [Meizu16m]# quit          Transfer file          1). Android Phone-> i.MX8MP EVK Board          root@imx8mp-lpddr4-evk:~# /usr/libexec/bluetooth/obexd -a -n -r /root/ & obexctl                   Then select a file on your phone ad choose transfer by Bluetooth.                   2).i.MX8MP EVK Board -> Android Phone          [obex]# connect 90:F0:52:92:A6:6C                   [90:F0:52:92:A6:6C]# send /home/root/test.txt          Note :  1. Do not suggestion use IOS phone. 2. If your i.MX8MP board can not scan your BT device, Suggest change the device BT name and run on "scan on" command again.  

We are pleased to announce that Config Tools for i.MX v16.1 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) • Clocks – Disabling enabled clock outputs that have settings with shared bit-fields after reopening the configuration is fixed. – Clock slices with multiple outputs are supported. • TEE – An incorrect number of the MPU region attributes shown for the configuration of RT1180 is fixed. – An incorrect domain visibility and tab names when DAC is disabled on RT1180 is fixed.

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        

The purpose of this article is to show how to reduce the boot time on i.MX 8QXP using U-Boot Falcon Mode. The general technique is presented in the AN14093. This article was tested on LF-6.6.23-2.0.0 BSP. How to do it 1. Follow the steps in the i.MX Yocto Project User's Guide and prepare your Yocto building environment. We will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-imx-fastboot directory.  3. Add the meta-imx-fastboot layer to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-imx-fastboot 4. If you've previously built an image in the same tree, clean the u-boot-imx and imx-boot packages using the following command: bitbake -c clean u-boot-imx imx-boot 5. Build the new image. Out of the box, this package is configured for core-image-minimal. We will show you below how to adapt it for other images: bitbake core-image-minimal 6. Write the resulted image on eMMC/SD using your preferred method and boot the board. 7. By default, the board will boot normally. To enable fast boot, stop the board in U-Boot, and run the following command: u-boot => run prepare_fdt 8. Reboot the board. From this point on, the board should boot in fast mode. Far less messages will be printed by the kernel or systemd during boot. You may further optimize the boot time by removing unnecessary features from the kernel and/or removing unnecessary services started by systemd. Please refer to AN14093. 9. If you ever want to re-enter U-Boot, please keep the 'c' key pressed in the serial console during board power-on. It's easiest if you press and keep the 'c' key pressed before powering on/pressing the reset button. How it works The layer we've added contains patches for U-Boot, ATF and imx-mkimage. In addition, it modifies the core-image-minimal recipe. In U-Boot, the necessary options for Falcon Mode are added in a new configuration file, named imx8qxp_mek_falcon_defconfig, as well as an implementation of the spl_start_uboot() function. In ATF, the device tree load address is added in the correct parameter. In mkimage, two new targets are created: kernel-atf-container.img (to be deployed in the boot partition) and uImage (to be deployed in the rootfs). The change in the core-image-minimal recipe ensures that the new files are copied in the resulting image. If you want to build a different image, you need to copy the content of core-image-minimal.bbappend in a new file, named according to the image you want to build. For example, if you want to build imx-image-full, you could use the following command: cp ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/core-image-minimal.bbappend ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/imx-image-full.bbappend       *** DISCLAIMER *** Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

This knowledge base add imx8ulp swupdate support based on AN13872. Uboot patch: add_swupdate_support_for_imx8ulp_in_uboot.patch swupdate-scripts patch: 0001-add-imx8ulp-support-in-swupdate-scripts.patch Note You must generate new key referring  5.4.3.3 Generating a key before build. Commands 1. base image build command   ./assemble_base_image.sh -b imx8ulp -e emmc -d doublecopy -m   2. update image build command   ./swu_update_image_build.sh -e -s ./priv.pem -b imx8ulp -g   3. flash command:   uuu -b emmc_all .\imx-boot-imx8ulp-lpddr4-evk-sd.bin-flash_singleboot_m33 .\swu_doublecopy_rescue_imx8ulp_emmc_20240914.sdcard       Useful links: https://sbabic.github.io/swupdate/building-with-yocto.html#automatic-sha256-in-sw-description https://sbabic.github.io/swupdate/sw-description.html?highlight=hwrevision   

This article describes how to use the Preempt-RT Linux kernel in the i.MX Linux BSP 6.6.23_2.0.0. This is particularly useful for platforms such as i.MX 95, for which there is not yet a Real-Time Edge Software release.    How to do it    1. Follow the steps in the i.MX Yocto Project User's Guide and build your preferred image, for example core-image-minimal. Will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-otherkernels directory. This archive will work out of the box for i.MX 95 and i.MX 93, and may require some modifications for other platforms, as described below. 3. Add the meta-otherkernels to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-otherkernels 4. Add the OVERRIDES .= ":preempt-rt" to ~/imx-yocto-bsp/build/conf/local.conf file using the following command: echo 'OVERRIDES .= ":preempt-rt"' >> ~/imx-yocto-bsp/build/conf/local.conf This enables the Preempt-RT kernel for your build. You can always go back to your regular kernel by removing this line from ~/imx-yocto-bsp/build/conf/local.conf. 5. Build again your image. After booting this image, you can check the kernel version using: uname -a      How it works    The meta-otherkernels layer contains a .bbappend  for the linux-imx kernel recipe which replaces the sources URL with the Real-Time Edge kernel when the "preempt-rt" override is active. In addition, due to the fact that the current real-time kernel does not support all the board configurations, the layer config file (meta-otherkernels/conf/layer.conf) removes from the build the device tree files that are not supported (when "preempt-rt" override is active).   If you use this layer for other SoCs (other than i.MX 93/i.MX 95), you may need to edit the meta-otherkernels/conf/layer.conf and add the unsupported device trees. If an  unsupported device tree is left, Yocto will give an error during build.        *** DISCLAIMER *** Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

This article describe i.MX8MP normal HAB security boot, and server/client mode. For server/client mode, it is based on customer requirement, because private is stored in server can't be accessed.

  This guide assumes that the developer has knowledge of the V4L2 API and has worked or is familiar with sensor drivers and their operation within the Linux kernel. This guide does not focus on the details of the sensor driver development that you want to port. It is assumed that you already have an existing driver for your sensor, before making the port. The version of the ISP's was 6.6.36 Linux BSP. If a different version is used, it is the developer's responsibility to review the API documentation for the corresponding version, since there may be changes that affect what is indicated in this guide. To port the camera sensor, the following steps must be taken as described in the following sections: Define sensor attributes and create instances. ISS Driver and ISP Media Server. Sensor Calibration Files. VVCAM Driver Creation. Device Tree Modifications. Define Sensor Attributes and Create Instances The following three steps are already implemented in CamDevice and are included for reference only. Step 1: Define the sensor attributes in the IsiSensor_s data structure. Step 2: Define the IsiSensorInstanceConfig_t configuration structure that will be used to create a new sensor instance. Step 3: Call the IsiCreateSensorIss() function to create a new sensor instance. ISS Driver and ISP Media Server Step 0 - Use a driver template as base code: Drivers can be found in $ISP_SOURCES_TOP/units/isi/drv/. For example, the ISP sources, come with the OV4656 and OS08a20 drivers. $ISP_SOURCES_TOP indicates the path of your working directory, where the respective sources are located. Step 1 - Add your <SENSOR> ISS Driver: Create the driver entry for your sensor in the path $ISP_SOURCES_TOP/units/isi/drv/<SENSOR>/source/<SENSOR>.c. Change all occurrences of the respective sensor name within the code, for instance, OV4656 -> <SENSOR>, respecting capital letters where applicable. Step 2 - Check the information on the IsiCamDrvConfig_s data structure: Data members defined in this data structure include the sensor ID (CameraDriverID) and the function pointer to the IsiSensor data structure. By using the address of the IsiCamDrvConfig_s structure, the driver can then access the sensor API attached to the function pointer. The following is an example of the structure: /***************************************************************************** * Each sensor driver needs to declare this struct for ISI load *****************************************************************************/ IsiCamDrvConfig_t IsiCamDrvConfig = {     .CameraDriverID = 0x0000,     .pIsiHalQuerySensor = <SENSOR>_IsiHalQuerySensorIss,     .pfIsiGetSensorIss = <SENSOR>_IsiGetSensorIss, };   Important Note: Modify the CameraDriverID according to the chip ID of your sensor. Apply this change to any Chip ID occurrence within the code. Step 3 - Check sensor macro definitions: In case there is any macro definition in the ISS Driver code, which involves specific properties of the sensor, you should modify it according to your requirements. For example: #define <SENSOR>_MIN_GAIN_STEP         (1.0f/16.0f)   Step 4 - Modify ISP Media Server build tools: Changes required in this step include: Add a CMakeLists.txt file in $ISP_SOURCES_TOP/units/isi/drv/<SENSOR>/ that builds your sensor module. Modify the CMakeLists.txt located at $ISP_SOURCES_TOP/units/isi/drv/CMakeLists.txt to include and reference your sensor directory. Modify the $ISP_SOURCES_TOP/appshell/ and $ISP_SOURCES_TOP/mediacontrol/ build tools, since by default they refer to the construction of a particular sensor, for example, the OV4656, so it is necessary to change the name of the corresponding sensor. Modify the $ISP_SOURCES_TOP/build-all-isp.sh script to reference the sensor modules and generate the corresponding binaries when building the ISP media server instance.   Step 5 - ISP Media Server run script: You need to add the operation modes defined for your sensor in the script. Each operating mode is associated with an order (mode 0, mode 1 ... mode N), a name used to execute the command in the terminal (e.g <sensor>_custom_mode_1), a resolution, and a specific calibration file for the sensor. The script is located at $ISP_SOURCES_TOP/imx/run.sh .   Step 6 - Sensor<X> config: At $ISP_SOURCES_TOP/units/isi/drv/ you can find the files to configure each sensor entry to the ISP, called Sensor0_Entry.cfg and Sensor1_Entry.cfg. There, the associated calibration files are indicated for each sensor operating mode, including the calibration files in XML format and the Dewarp Unit configuration files in JSON format. In addition, the .drv file generated for your sensor is referenced, creating the association between the respective /dev/video<X> node and the sensor driver module outputted from the ISP Media Server. In case you are using only one ISP channel, just modify Sensor0_Entry.cfg. In case you require both instances of the ISP, you will need to modify both files. Sensor Calibration Files It is a requirement for using the ISP, to have a calibration file in XML format, specific to the sensor you are using and according to the resolution and working mode. To obtain the calibration files in XML format, there are 3 options: Use the NXP ISP tuning tool for this you will need to ask for access or sign a NDA document. Pay NXP professional services to do the tune. Pay a third-party vendor to do the tune   VVCAM Driver Creation The changes indicated below are based on the assumption that there is a functional sensor driver in its base form, and that it is compatible with the V4L2 API. From now on we focus on applying the changes suggested in the NXP documentation, specifically to establish the communication of the VVCAM Driver (kernel side) and the ISI Layer. Step 0 - Create the sensor driver entry: Developers must add the driver code to the file located at $ISP_SOURCES_TOP/vvcam/v4l2/sensor/<sensor>/<sensor>_xxxx.c, along with a Makefile for the sensor driver module. In the same way, as indicated in the ISS Driver section, you can refer to one of the sample drivers that are included as part of the ISP sources, to review details about the implementation of the driver and the structure of the required Makefile.   Step 1 - Add the VVCAM mode info data structure array: This array stores all the supported modes information for your sensor. The ISI layer can get all the modes with the VVSENSORIOC_QUERY command. The following is an example of the structure, please fill in the information using the attributes of your sensor and the modes it supports. #include "vvsensor.h" . . .   static struct vvcam_mode_info_s <sensor>_mode_info[] = {         {         .index = 0,         .width = ... ,         .height = ... ,         .hdr_mode = ... ,         .bit_width = ... ,         .data_compress.enable = ... ,         .bayer_pattern = ... ,         .ae_info = {                        .                        .                        .                        },         .mipi_info = {                        .mipi_lane = ... ,                        },         },         {         .index = 1,         .         .         .         }, }; Step 2 - Define sensor client to i2c : Define the client_to_sensor macro (in case you don't have any already) and check the segments of the driver code that require this macro. #define client_to_<sensor>(client)\         container_of(i2c_get_clientdata(client), struct <sensor>, subdev)   Step 3 - Define the V4L2-subdev IOCTL function: Define and implement the <sensor>_priv_ioctl, which is used to receive the commands and parameters passed down by the user space through ioctl() and control the sensor. long <sensor>_priv_ioctl(struct v4l2_subdev *subdev, unsigned int cmd, void *arg) {         struct i2c_client *client = v4l2_get_subdevdata(subdev);         struct <sensor> *sensor = client_to_<sensor>(client);         struct vvcam_sccb_data_s reg;         uint32_t value = 0;         long ret = 0;           if(!sensor){                return -EINVAL;         }           switch (cmd) {         case VVSENSORIOC_G_CLK: {                ret = custom_implementation();                break;         }         case VIDIOC_QUERYCAP: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_QUERY: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_G_CHIP_ID: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_G_RESERVE_ID: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_G_SENSOR_MODE:{                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_SENSOR_MODE: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_STREAM: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_WRITE_REG: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_READ_REG: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_EXP: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_POWER:         case VVSENSORIOC_S_CLK:         case VVSENSORIOC_RESET:         case VVSENSORIOC_S_FPS:         case VVSENSORIOC_G_FPS:         case VVSENSORIOC_S_LONG_GAIN:         case VVSENSORIOC_S_GAIN:         case VVSENSORIOC_S_VSGAIN:         case VVSENSORIOC_S_LONG_EXP:         case VVSENSORIOC_S_VSEXP:          case VVSENSORIOC_S_WB:         case VVSENSORIOC_S_BLC:         case VVSENSORIOC_G_EXPAND_CURVE:                break;         default:                break;         }           return ret; }   As you can see in the example, some cases are implemented but others are not. Developers are free to implement the features they consider necessary, as long as a minimum base of operation of the driver is guaranteed (query commands, read and write registers, among others). It is the developer's responsibility to implement each custom function, for each case or scenario that may arise when interacting with the sensor. In addition to what was shown previously, a link must be created to make the ioctl connection with the driver in question. Link your priv_ioctl function on the v4l2_subdev_core_ops struct, as in the example below: static const struct v4l2_subdev_core_ops <sensor>_core_ops = {         .s_power       = v4l2_s_power,         .subscribe_event = v4l2_ctrl_subdev_subscribe_event,         .unsubscribe_event = v4l2_event_subdev_unsubscribe,      // IOCTL link         .ioctl = <sensor>_priv_ioctl, };   Step 4 - Verify your sensor's private data structure: After performing the modifications suggested, it would be a good practice to double-check your sensor's private data structure properties, in case there is one missing, and also check that the properties are initialized correctly on the driver's probe.   Step 5 - Modify VVCAM V4L2 sensor Makefile : At $ISP_SOURCES_TOP/vvcam/v4l2/sensor/Makefile, include your sensor object as follows: ... obj-m += <sensor>/ ... Important Note: There is a very common issue that appears when working with camera sensor drivers in i.MX8MP platforms. The kernel log message shows something similar to the following: mxc-mipi-csi2.<X>: is_entity_link_setup, No remote pad found! The link setup callback is required by the Media Controller when performing the linking process of the media entities involved in the capture process of the camera. Normally, this callback is triggered by the imx8-media-dev driver included as part of the Kernel sources. To make sure that the problem is not related to your sensor driver, verify the link setup callback is already created in the code, and if is not, you can add the following template: /* Function needed by i.MX8MP */ static int <sensor>_camera_link_setup(struct media_entity *entity,                                    const struct media_pad *local,                                    const struct media_pad *remote, u32 flags) {     /* Return always zero */         return 0; }   /* Add the link setup callback to the media entity operations struct */ static const struct media_entity_operations <sensor>_camera_subdev_media_ops = {         .link_setup = <sensor>_camera_link_setup, };     /* Verify the initialization process of the media entity ops in the sensor driver's probe function*/ static int <sensor>_probe(struct i2c_client *client, ...) {         /* Initialize subdev */         sd = &<sensor>->subdev;         sd->dev = &client->dev;         <sensor>->subdev.internal_ops = ...         <sensor>->subdev.flags |= ...         <sensor->subdev.entity.function = ...     /* Entity ops initialization */         <sensor->subdev.entity.ops = &<sensor>_camera_subdev_media_ops; } In most cases, adding the link setup function will solve the media controller issue, or at least it discards problems on the driver side. Device Tree Modifications On the Device Tree side, it is necessary to enable the ISP channels that will be used. Likewise, it is necessary to disable the ISI channels, which are normally the ones that connect to the MIPI_CSI2 ports to extract raw data from the sensor (in case the ISP is not used). A MIPI_CSI2 port can be mapped to either an ISI channel or an ISP channel, but not both simultaneously. In this guide, we focus on using the ISP, so any other custom configuration that you want to implement may vary from what is shown. In the code below, ISP channel 0 is enabled, and the connection is made to the port where the sensor is connected (mipi_csi_0). &mipi_csi_0 {         status = "okay";         port@0 {         // Example endpoint to <sensor>_ep                mipi0_sensor_ep: endpoint@1 {                        remote-endpoint = <&<sensor>_ep>;                };         }; };   &cameradev {         status = "okay"; };   &isi_0 {         status = "disabled"; };   &isi_1 {         status = "disabled"; };   &isp_0 {         status = "okay"; };   &isp_1 {         status = "disabled"; };   &dewarp {         status = "okay"; }; What is shown above does not represent a complete device tree file, is only a general skeleton of the points you should pay attention to when working with ISP channels. For simplicity, we omitted all the attributes that are normally defined when working with camera sensor drivers and their respective configurations in the i2c port of the hardware.   Note: Due to hardware restrictions when using ISP channels, it is recommended to use the isp_0 channel, when working with only one sensor. In case you need to use two sensors, you can enable both channels, taking into account the limitations regarding the output resolutions and the clock frequency when both channels are working simultaneously. What is not recommended is to use the isp_1 channel when working with a single sensor.   References ISP Independent Sensor Interface (ISI) API reference, I.MX8M Plus Camera Sensor Porting User guide: https://www.nxp.com/webapp/Download?colCode=IMX8MPCSPUG Sensor Calibration tool: https://www.nxp.com/webapp/Download?colCode=AN13565 i.MX8M Plus reference manual: https://www.nxp.com/webapp/Download?colCode=IMX8MPRM  

The Gui-guilder doesn't provide remote debug function in IDE and we still need use Yocto to build project or copy binary to board rootfs. This knowledge base will provide a solution about how to use VSCode to remote debug LVGL project on i.MX93 EVK board.    Yocto toolchain: L6.6.x GUI GUILDER: v1.8.0   Need to open GUI GUILDER project in VSCode.   1.Scripts in VScode   1.1 build.sh Modify build.sh in <LVGL project>/ports/linux     #!/bin/sh toolchain=$1 if [ -z "$toolchain" ];then toolchain=/opt/fsl-imx-xwayland/6.1-mickledore/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake if [ ! -r $toolchain ];then toolchain=/opt/fsl-imx-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake fi fi toolchain_path=$(echo $toolchain |sed -E 's,^(.*)/sysroots/.*,\1,') toolchain_arch=armv8a-poky-linux if [ ! -r $toolchain -o ! -r "$toolchain_path/environment-setup-$toolchain_arch" ];then echo "ERROR: Yocto Toolchain not installed?" exit 1 fi if [ -n "$BASH_SOURCE" ]; then ROOTDIR="`readlink -f $BASH_SOURCE | xargs dirname`" elif [ -n "$ZSH_NAME" ]; then ROOTDIR="`readlink -f $0 | xargs dirname`" else ROOTDIR="`readlink -f $PWD | xargs dirname`" fi BUILDDIR=$ROOTDIR/../build rm -fr $BUILDDIR mkdir $BUILDDIR . "$toolchain_path/environment-setup-$toolchain_arch" echo "start build..." cd $ROOTDIR/linux/lv_drivers/wayland/ cmake . make cd $BUILDDIR toolchain_path=/opt/fsl-imx-wayland/6.6-scarthgap/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake cmake -G 'Ninja' .. -DCMAKE_TOOLCHAIN_FILE=$toolchain_path -Wno-dev -DLV_CONF_BUILD_DISABLE_EXAMPLES=1 -DLV_CONF_BUILD_DISABLE_DEMOS=1 -DCMAKE_CXX_FLAGS="-ggd3 -O0" -DCMAKE_BUILD_TYPE=Debug ninja if [ -e gui_guider ];then echo "Binary locates at $(readlink -f gui_guider)" ls -lh gui_guider fi # Copy binary to board scp $BUILDDIR/gui_guider root@192.168.31.243:/opt     1.2 tasks.json     { "version": "2.0.0", "tasks": [ { "label": "Build", "type": "shell", "command": "./build.sh /opt/fsl-imx-wayland/6.6-scarthgap", "options": { "cwd": "${workspaceFolder}/ports/linux" }, "problemMatcher": [ "$gcc" ], } ] }       1.3 launch.json   miDebuggerServerAddress is board ip address.     { "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", "preLaunchTask": "Build", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/gui_guider", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}/", "environment": [], "externalConsole": false, "MIMode": "gdb", "logging": { "engineLogging": true, "trace": true, "traceResponse": true }, "debugStdLib":true, "miDebuggerPath":"/usr/bin/gdb-multiarch", //DO NOT USE GDB IN SDK!!!! "miDebuggerServerAddress": "192.168.31.243:12345", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true, "text": "set remotetimeout 100", } ] }] }       2. Launch gdbserver on board     export SHELL=/opt/gui_guider gdbserver 192.168.31.243:12345 /opt/gui_guider       3. Debug in VSCode   Click (gdb)launch, the source code will be compiled. Then you will see the breakpoint in program. Enjoy your debug~    

Introduction Time Synchronization stands for the alignment of time within distributed nodes, pretty critical for real-time applications, control and measurement systems as voice and video networks; all of them being embedded applications. It needs the synchronization of frequency, phase and time between all the nodes and offers action coordination, high precision triggers and event reference or timestamping. [1] A Time Synchronization resource it's the ethernet standard for time PTP or IEEE 1588 standard, its study begin with the physical representation of time information: PPS; Pulse Per Second. An squared wave timed by the capable MACs, in i.MX families we have two MACs of which. Background Customers are interested in this signal, we have an i.MX 8M Plus kernel 5 resource but there is a new processor family using the next major kernel version; 6. [2] We will go through demonstrating PPS on i.MX 93 EVK in both MACs; FEC and EQOS. HW setup i.MX 93 EVK boot over eMMC. Connect power and debug receptacles. Hands-on for FEC or eth0 MAC uSDHC2 pin group conflicts with the pps output pin and you are ought to remove the uSDHC2 nodes and assign the event0 out pin to the FEC pin group as shown below. --- imx93-11x11-evk.dts 2024-08-23 18:19:56.344798901 +0200 +++ imx93-11x11-evk-pps.dts 2024-09-02 21:31:46.569477421 +0200 @@ -100,18 +100,6 @@ regulator-max-microvolt = <1800000>; }; - reg_usdhc2_vmmc: regulator-usdhc2 { - compatible = "regulator-fixed"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>; - regulator-name = "VSD_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>; - off-on-delay-us = <12000>; - enable-active-high; - }; - reg_vdd_12v: regulator-vdd-12v { compatible = "regulator-fixed"; regulator-name = "reg_vdd_12v"; @@ -770,21 +766,6 @@ status = "okay"; }; -&usdhc2 { - pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; - pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>; - pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>; - cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>; - fsl,cd-gpio-wakeup-disable; - vmmc-supply = <&reg_usdhc2_vmmc>; - bus-width = <4>; - status = "okay"; - no-sdio; - no-mmc; -}; - &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>; @@ -860,14 +842,15 @@ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x57e MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e + MX93_PAD_SD2_DATA0__ENET1_1588_EVENT0_OUT 0x31e >; }; @@ -887,6 +870,7 @@ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e + MX93_PAD_SD2_DATA0__GPIO3_IO03 0x31e >; }; @@ -998,75 +982,6 @@ >; }; - pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp { - fsl,pins = < - MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e - >; - }; - - pinctrl_usdhc2_gpio: usdhc2gpiogrp { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e - >; - }; - - pinctrl_usdhc2_gpio_sleep: usdhc2gpiogrpsleep { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2: usdhc2grp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582 - MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382 - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382 - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382 - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382 - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382 - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e - MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe - MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - pinctrl_usdhc2_sleep: usdhc2grpsleep { - fsl,pins = < - MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e - MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e - MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e - MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e - MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e - MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e - MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e - >; - }; - /* need to config the SION for data and cmd pad, refer to ERR052021 */ pinctrl_usdhc3: usdhc3grp { fsl,pins = < The driver also needs the following rework. --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -184,7 +184,8 @@ static int fec_ptp_enable_pps(struct fec_enet_private *fep, uint enable) val |= (1 << FEC_T_TF_OFFSET | 1 << FEC_T_TIE_OFFSET); val &= ~(1 << FEC_T_TDRE_OFFSET); val &= ~(FEC_T_TMODE_MASK); - val |= (FEC_HIGH_PULSE << FEC_T_TMODE_OFFSET); + // val |= (FEC_HIGH_PULSE << FEC_T_TMODE_OFFSET); + val |= (FEC_TMODE_TOGGLE << FEC_T_TMODE_OFFSET); writel(val, fep->hwp + FEC_TCSR(fep->pps_channel)); /* Write the second compare event timestamp and calculate After booting the board, run these commands: $ ptp4l -A -4 -H -m -i eth0 & $ echo 1 > /sys/class/ptp/ptp0/pps_enable These will get the SD2_DATA0 or TP1009 running a square wave at 0.5 Hz through setting the ptp0 port with: -A    Select the delay mechanism automatically. Start with E2E and switch to P2P when a peer delay request is received. -4    Select the UDP IPv4 network transport. This is the default transport. -H    Select the hardware time stamping. -m    Print messages to the standard output. Run the next command to set the pps (1 Hz signal): $ echo "0 $(date +%s) 100000000 1 0" > /sys/class/ptp/ptp0/period The last because the current driver needs the actual date and a future start; in this case the signal will start within 100 ms, in order to work. You can try with different start times until the optimal value is found. [3]   Hands-on for EQOS or eth1 MAC This is reduced to the proper devicetree changes, and it does not have driver rework nor pps_enable control file. It uses SD2_CLK or TP1008, so DTS need this adjustment: --- imx93-11x11-evk.dts 2024-08-23 18:19:56.344798901 +0200 +++ imx93-11x11-evk-pps.dts 2024-09-02 21:31:46.569477421 +0200 @@ -100,18 +100,6 @@ regulator-max-microvolt = <1800000>; }; - reg_usdhc2_vmmc: regulator-usdhc2 { - compatible = "regulator-fixed"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>; - regulator-name = "VSD_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>; - off-on-delay-us = <12000>; - enable-active-high; - }; - reg_vdd_12v: regulator-vdd-12v { compatible = "regulator-fixed"; regulator-name = "reg_vdd_12v"; @@ -770,21 +766,6 @@ status = "okay"; }; -&usdhc2 { - pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; - pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>; - pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>; - cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>; - fsl,cd-gpio-wakeup-disable; - vmmc-supply = <&reg_usdhc2_vmmc>; - bus-width = <4>; - status = "okay"; - no-sdio; - no-mmc; -}; - &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>; @@ -822,14 +802,15 @@ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e + MX93_PAD_SD2_CLK__ENET_QOS_1588_EVENT0_OUT 0x31e >; }; @@ -849,6 +830,7 @@ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e + MX93_PAD_SD2_CLK__GPIO3_IO01 0x31e >; }; @@ -998,75 +982,6 @@ >; }; - pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp { - fsl,pins = < - MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e - >; - }; - - pinctrl_usdhc2_gpio: usdhc2gpiogrp { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e - >; - }; - - pinctrl_usdhc2_gpio_sleep: usdhc2gpiogrpsleep { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2: usdhc2grp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582 - MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382 - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382 - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382 - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382 - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382 - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e - MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe - MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - pinctrl_usdhc2_sleep: usdhc2grpsleep { - fsl,pins = < - MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e - MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e - MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e - MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e - MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e - MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e - MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e - >; - }; - /* need to config the SION for data and cmd pad, refer to ERR052021 */ pinctrl_usdhc3: usdhc3grp { fsl,pins = < After boot, issue these commands: $ ptp4l -A -4 -H -m -i eth1 & $ echo "0 $(date +%s) 1000000000 1 0" > /sys/class/ptp/ptp1/period You will have an squared wave of 1 Hz running within 1 s with the same settings as the FEC setup.   Conclusion Both PPS can run in the same image changes and DTS changes, proven in imx-linux-nanbield branch, with the manifest imx-6.6.3-1.0.0.xml. And it's the start of testing IEEE 1588 and syncing capabilities of this i.MX 9 series processors. Sources [1] http://events17.linuxfoundation.org/sites/events/files/slides/elc_insop_2015.pdf [2] https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-serials-IEEE1588-1pps-test-procedure/ta-p/1490634 [3] https://github.com/nxp-imx/linux-imx/blob/b586a521770e508d1d440ccb085c7696b9d6d387/Documentation/ABI/testing/sysfs-ptp#L2

Note: This guide is specifically for use with VS Code. For standalone with Segger software please refer to this guide. (How to Use Segger J-Link Plus with i.MX 8M Process... - NXP Community) In this guide we will describe the process to start using VS Code to debug an SDK application. The board used for this guide specifically is the i.MX 8M Nano EVK, but it also applies to all processors of the i.MX 8M Family. This guide covers the following topics: Hardware requirements Software requirements How to find, build, and download the i.MX SDK Debug Probe and i.MX 8M Nano EVK connection Create an SDK Application with MCUXpresso for VS Code Run and debug your SDK Application with MCUXpresso for VS Code Hardware requirements Evaluation Kit for the i.MX8M Nano Applications Processor (i.MX 8M Nano Evaluation Kit | NXP Semiconductors) Quick Start Guide for i.MX8M Nano (I.MX 8M Nano EVK Quick Start Guide (nxp.com)) J-Link Plus JTAG/SWD debug probe with USB interface (SEGGER J-Link PLUS) Features Download speed up to 1MB/s Unlimited breakpoints in flash memory Supports direct download into RAM and flash memory Supported NXP Devices Supported Devices - Search results "nxp" (segger.com) 9 Pin Cortex-M Adapter (9-Pin Cortex-M Adapter (segger.com)) Description Adapts from the 20-pin 0.1'' JTAG connector to a 9-pin 0.05'' Samtec FTSH connector as defined by Arm. Software requirements Windows 10 OS (host) J-Link Software and Documentation Pack for Windows (https://www.segger.com/products/debug-probes/j-link/models/j-link-plus/) i.MX 8M Nano SDK (Welcome | MCUXpresso SDK Builder (nxp.com)) VS Code for Windows (Installation Guide: Running Visual Studio Code on Windows) MCUXpresso Extension for VS Code (Installation Guide: Training: Walkthrough of MCUXpresso for VS Code - NXP Community)   How to find, build, and download the i.MX 8M Nano SDK Enter Welcome | MCUXpresso SDK Builder (nxp.com) Click on "Select Development Board"  Select EVK-MIMX8MN (MIMX8MN6xxxJZ) from Boards -> i.MX -> EVK-MIMX8MN Click on the Build MCUXpresso SDK button Click on Download SDK, you'll be redirected to the MCUXpresso SDK Dashboard Look for the i.MX 8M Nano SDK and click on Download SDK Click on Download SDK archive and documentation, accept the Software Terms and Conditions and the .zip file for the SDK will be downloaded. Debug Probe and i.MX 8M Nano EVK connection Connect the debug cable (USB-UART) to the board and the other end to your PC. Connect the power cable to the second USB-C port and to a wall socket. Don't turn on the board yet. Connect the JLink Plus to your PC with the USB cable. Connect the JLink Plus to the JTAG of the i.MX 8M Nano EVK board In this part we will need to identify pin number 1 from the 9 Pin Cortex-M adapter and from the i.MX 8M Nano EVK board. For the first one identifies pin 7 identifiable by a "non-connect pin". For the i.MX 8M Nano, you can identify easily with a number 1 in one corner of the connectors.    The whole setup should look similar to this:   Create an SDK Application with MCUXpresso for VS Code Before delving into the details of creating an SDK Application it is important to recognize the sections of VS Code User Interface. This will help us to describe accurately the buttons' position. Click on MCUXpresso for VS Code extension icon from the Activity Bar.  In the section “Quickstart Panel” located in the Side Bar click on “Import Repository.” On this window, go to “Local” and select your previously downloaded SDK folder location. Then, click on “Import.” Expand the section “Installed Repositories” from Side Bar and verify your selected SDK. Expand the section “Projects” from Side Bar and click on “Import Example from Repository” and complete the options: Choose a toolchain Choose a board Choose a template Name Location Finally, click on the "Create" button. Click on the gear icon located in the project folder to build the code. In “Projects” expand the “Settings” options and select “mcuxpresso-tools.json.” Here you will find a JSON file with different parameters. Defines the device that will be used to connect with the J-Link Plus. Code: “segger”: { “device”: “MIMX8MN6_M7” } Expand the section “Debug Probes” and verify that your J-Link Plus debug probe appears. Start SEGGER J-Link GDB Server. On section “Target Device” select MIMX8MN6_M7 and click “OK”. You will see the following window. Run and debug your SDK Application with MCUXpresso for VS Code Click on “Debug” located in the project folder, to start with the debugging session. In the Panel click on “Serial Monitor,” set it to the serial debug port with the lowest numbered port with the following settings: Baud rate: 115200 Line ending: None Click on "Start Monitoring" Use the debug controls to run the code. Verify your code output in the “Serial Monitor.”

P3T1755 Demo   In this space I want to show you the things that you can create usign our products.   In  this demo I demostrate a use case creating a GUI for a Temperature Sensor.   We can create modern GUIs and more with LVGL combined with our powerful processors.               CPU USAGE As we can see  the CPU usage for this demo is around 2%   Pictures         This demo is based on the previous publused articles.   References: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Adding-support-to-P3T1755-on-Linux/ta-p/1855874 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-run-LGVL-on-iMX-using-framebuffer/ta-p/1853768  

Customer proposed to debug code on A core during development stage.  HW: i.MX93/i.MX8MP SW: L6.1.36, Real-time edge Feature: Besides debugging code, enabled compiling image by eclipse. cpu0 boot, then kick off/halt other secondary cpu, debug code on secondary cpu core. Auto reset board and connect jlink to be convenient for restarting debugging.  

  Some customers want to expose their i3c device on the /dev, In order to develop their i3c APP or operation the i3c device like I2C. But in our default BSP code, we do not support this feature for I3C device, This article will introduce how to make the i3c device expose to the user space. Board : i.MX 93 EVK BSP Version : lf-6.1.55-2.2.0 I3C device : LSM6DSOXTR Step 1 : Rework the i.MX93 EVK Board, Install the R1010.      Step 2 : Apply the add_i3c_device_to_dev.patch file to the linux kernel code              Command : git apply add_i3c_device_to_dev.patch Step 3 : Re-compile the kernel Image file.              Command : make imx_v8_defconfig                                  make Step 4 : Boot your board with "imx93-11x11-evk-i3c.dtb" file and see if you can see the I3C device on the /dev directory. Result : We can see the i3c device is appeared in /dev directory, The i2c-8 is an i2c device mounted to the i3c bus. The i3c is backward compatible with i2c device. It will simulate the I2C signal loading i2c device.                 PS : You can also use the i2ctool detect i2c-8 device. As shown in the following picture:   Note : If you need the patch file, Please contact me any time for free.

Ftrace is powerful tracing utility embedded in Linux kernel. It provides a very good method for kernel developer to get insights of the kernel behavior. While official kernel doc for ftrace is somehow long and complex, this document provides a quicker and simpler way to get start with ftrace.

This guide is a continuation from our latest Debian 12 Installation Guide for iMX8MM, iMX8MP, iMX8MN and iMX93. Here we will describe the process to install the multimedia and hardware acceleration packages, specifically GPU, VPU and Gstreamer on i.MX8M Mini, i.MX8M Plus and i.MX8M Nano. The guide is based on the one provided by our colleague Build Ubuntu For i.MX8 Series Platform - NXP Community, which requires to previously build an image using Yocto Project with the following distro and image name. Distro name - fsl-imx-wayland Image name – imx-image-multimedia For more information please check our BSP documentation i.MX Yocto Project User’s Guide.   Hardware Requirements Linux Host Computer (Ubuntu 20.04 or later) USB Card reader or Micro SD to SD adapter SD Card Evaluation Kit Board for the i.MX8M Nano, i.MX8M Mini, i.MX8M Plus   Software Requirements Linux Ubuntu (20.04 tested) or Debian for Host Computer BSP version 6.1.55 built with Yocto Project   After built the image we can start the installation by following the steps below:   GPU Installation The GPU Installation consists of copy the files from packages imx-gpu-g2d, imx-gpu-viv, libdrm to the Debian system. As our latest installation guide, we will continue naming “mountpoint” to the directory where Debian system is mounted on our host machine. Regarding the path provided on each step, we put labels <build-path> and <machine> that you will need to change based on your environment. These are the paths that Yocto Project uses to save the packages. However, this could change on your environment and you can find the work directory from each package using the following command: bitbake -e <package-name> | grep ^WORKDIR= This command will show you the absolute path of the package work directory. 1. Install GPU Packages $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-gpu-g2d/6.4.11.p2.2-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-gpu-viv/1_6.4.11.p2.2-aarch64-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/libdrm/2.4.115.imx-r0/image/* mountpoint   2. Install Linux IMX Headers and IMX Parser $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/linux-imx-headers/6.1-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-poky-linux/imx-parser/4.8.2-r0/image/* mountpoint   3. Use chroot $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash   4. Install Dependencies $ apt install libudev-dev libinput-dev libxkbcommon-dev libpam0g-dev libx11-xcb-dev libxcb-xfixes0-dev libxcb-composite0-dev libxcursor-dev libxcb-shape0-dev libdbus-1-dev libdbus-glib-1-dev libsystemd-dev libpixman-1-dev libcairo2-dev libffi-dev libxml2-dev kbd libexpat1-dev autoconf automake libtool meson cmake ssh net-tools network-manager iputils-ping rsyslog bash-completion htop resolvconf dialog vim udhcpc udhcpd git v4l-utils alsa-utils git gcc less autoconf autopoint libtool bison flex gtk-doc-tools libglib2.0-dev libpango1.0-dev libatk1.0-dev kmod pciutils libjpeg-dev   5. Create a folder for Multimedia Installation. Here we will clone all the multimedia repositories.  $ mkdir multimedia_packages $ cd multimedia_packages   6. Build Wayland $ git clone https://gitlab.freedesktop.org/wayland/wayland.git $ cd wayland $ git checkout 1.22.0 $ meson setup build --prefix=/usr -Ddocumentation=false -Ddtd_validation=true $ cd build $ ninja install   7. Build Wayland Protocols IMX $ git clone https://github.com/nxp-imx/wayland-protocols-imx.git $ cd wayland-protocols-imx $ git checkout wayland-protocols-imx-1.32 $ meson setup build --prefix=/usr -Dtests=false $ cd build $ ninja install   8. Build Weston $ git clone https://github.com/nxp-imx/weston-imx.git $ cd weston-imx $ git checkout weston-imx-11.0.3 $ meson setup build --prefix=/usr -Dpipewire=false -Dsimple-clients=all -Ddemo-clients=true -Ddeprecated-color-management-colord=false -Drenderer-gl=true -Dbackend-headless=false -Dimage-jpeg=true -Drenderer-g2d=true -Dbackend-drm=true -Dlauncher-libseat=false -Dcolor-management-lcms=false -Dbackend-rdp=false -Dremoting=false -Dscreenshare=true -Dshell-desktop=true -Dshell-fullscreen=true -Dshell-ivi=true -Dshell-kiosk=true -Dsystemd=true -Dlauncher-logind=true -Dbackend-drm-screencast-vaapi=false -Dbackend-wayland=false -Dimage-webp=false -Dbackend-x11=false -Dxwayland=false $ cd build $ ninja install   VPU Installation To install VPU and Gstreamer please follow the steps below: 1. Install firmware-imx $ sudo cp -Pra <build-path>/tmp/work/all-poky-linux/firmware-imx/1_8.22-r0/image/lib/* mountpoint/lib/   2. Install VPU Driver $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-vpu-hantro/1.31.0-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-vpuwrap/git-r0/image/* mountpoint   3. Use chroot $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash   4. Install dependencies for Gstreamer Plugins $ apt install libgirepository1.0-dev gettext liborc-0.4-dev libasound2-dev libogg-dev libtheora-dev libvorbis-dev libbz2-dev libflac-dev libgdk-pixbuf-2.0-dev libmp3lame-dev libmpg123-dev libpulse-dev libspeex-dev libtag1-dev libbluetooth-dev libusb-1.0-0-dev libcurl4-openssl-dev libssl-dev librsvg2-dev libsbc-dev libsndfile1-dev   5. Change directory to multimedia packages. $ cd multimedia-packages   6. Build gstreamer $ git clone https://github.com/nxp-imx/gstreamer -b lf-6.1.55-2.2.0 $ cd gstreamer $ meson setup build --prefix=/usr -Dintrospection=enabled -Ddoc=disabled -Dexamples=disabled -Ddbghelp=disabled -Dnls=enabled -Dbash-completion=disabled -Dcheck=enabled -Dcoretracers=disabled -Dgst_debug=true -Dlibdw=disabled -Dtests=enabled -Dtools=enabled -Dtracer_hooks=true -Dlibunwind=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   7. Build gst-plugins-base $ git clone https://github.com/nxp-imx/gst-plugins-base -b lf-6.1.55-2.2.0 $ cd gst-plugins-base $ meson setup build --prefix=/usr -Dalsa=enabled -Dcdparanoia=disabled -Dgl-graphene=disabled -Dgl-jpeg=disabled -Dopus=disabled -Dogg=enabled -Dorc=enabled -Dpango=enabled -Dgl-png=enabled -Dqt5=disabled -Dtheora=enabled -Dtremor=disabled -Dvorbis=enabled -Dlibvisual=disabled -Dx11=disabled -Dxvideo=disabled -Dxshm=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   8. Build gst-plugins-good $ git clone https://github.com/nxp-imx/gst-plugins-good -b lf-6.1.55-2.2.0 $ cd gst-plugins-good $ meson setup build --prefix=/usr -Dexamples=disabled -Dnls=enabled -Ddoc=disabled -Daalib=disabled -Ddirectsound=disabled -Ddv=disabled -Dlibcaca=disabled -Doss=enabled -Doss4=disabled -Dosxaudio=disabled -Dosxvideo=disabled -Dshout2=disabled -Dtwolame=disabled -Dwaveform=disabled -Dasm=disabled -Dbz2=enabled -Dcairo=enabled -Ddv1394=disabled -Dflac=enabled -Dgdk-pixbuf=enabled -Dgtk3=disabled -Dv4l2-gudev=enabled -Djack=disabled -Djpeg=enabled -Dlame=enabled -Dpng=enabled -Dv4l2-libv4l2=disabled -Dmpg123=enabled -Dorc=enabled -Dpulse=enabled -Dqt5=disabled -Drpicamsrc=disabled -Dsoup=enabled -Dspeex=enabled -Dtaglib=enabled -Dv4l2=enabled -Dv4l2-probe=true -Dvpx=disabled -Dwavpack=disabled -Dximagesrc=disabled -Dximagesrc-xshm=disabled -Dximagesrc-xfixes=disabled -Dximagesrc-xdamage=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   9. Build gst-plugins-bad $ git clone https://github.com/nxp-imx/gst-plugins-bad -b lf-6.1.55-2.2.0 $ cd gst-plugins-bad $ meson setup build --prefix=/usr -Dintrospection=enabled -Dexamples=disabled -Dnls=enabled -Dgpl=disabled -Ddoc=disabled -Daes=enabled -Dcodecalpha=enabled -Ddecklink=enabled -Ddvb=enabled -Dfbdev=enabled -Dipcpipeline=enabled -Dshm=enabled -Dtranscode=enabled -Dandroidmedia=disabled -Dapplemedia=disabled -Dasio=disabled -Dbs2b=disabled -Dchromaprint=disabled -Dd3dvideosink=disabled -Dd3d11=disabled -Ddirectsound=disabled -Ddts=disabled -Dfdkaac=disabled -Dflite=disabled -Dgme=disabled -Dgs=disabled -Dgsm=disabled -Diqa=disabled -Dkate=disabled -Dladspa=disabled -Dldac=disabled -Dlv2=disabled -Dmagicleap=disabled -Dmediafoundation=disabled -Dmicrodns=disabled -Dmpeg2enc=disabled -Dmplex=disabled -Dmusepack=disabled -Dnvcodec=disabled -Dopenexr=disabled -Dopenni2=disabled -Dopenaptx=disabled -Dopensles=disabled -Donnx=disabled -Dqroverlay=disabled -Dsoundtouch=disabled -Dspandsp=disabled -Dsvthevcenc=disabled -Dteletext=disabled -Dwasapi=disabled -Dwasapi2=disabled -Dwildmidi=disabled -Dwinks=disabled -Dwinscreencap=disabled -Dwpe=disabled -Dzxing=disabled -Daom=disabled -Dassrender=disabled -Davtp=disabled -Dbluez=enabled -Dbz2=enabled -Dclosedcaption=enabled -Dcurl=enabled -Ddash=enabled -Ddc1394=disabled -Ddirectfb=disabled -Ddtls=disabled -Dfaac=disabled -Dfaad=disabled -Dfluidsynth=disabled -Dgl=enabled -Dhls=enabled -Dkms=enabled -Dcolormanagement=disabled -Dlibde265=disabled -Dcurl-ssh2=disabled -Dmodplug=disabled -Dmsdk=disabled -Dneon=disabled -Dopenal=disabled -Dopencv=disabled -Dopenh264=disabled -Dopenjpeg=disabled -Dopenmpt=disabled -Dhls-crypto=openssl -Dopus=disabled -Dorc=enabled -Dresindvd=disabled -Drsvg=enabled -Drtmp=disabled -Dsbc=enabled -Dsctp=disabled -Dsmoothstreaming=enabled -Dsndfile=enabled -Dsrt=disabled -Dsrtp=disabled -Dtinyalsa=disabled -Dtinycompress=enabled -Dttml=enabled -Duvch264=enabled -Dv4l2codecs=disabled -Dva=disabled -Dvoaacenc=disabled -Dvoamrwbenc=disabled -Dvulkan=disabled -Dwayland=enabled -Dwebp=enabled -Dwebrtc=disabled -Dwebrtcdsp=disabled -Dx11=disabled -Dx265=disabled -Dzbar=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   10. Build imx-gst1.0-plugin $ git clone https://github.com/nxp-imx/imx-gst1.0-plugin -b lf-6.1.55-2.2.0 $ cd imx-gst1.0-plugin $ meson setup build --prefix=/usr -Dplatform=MX8 -Dc_args=-I/usr/include/imx $ cd build $ ninja install   11. Exit chroot $ exit   Verify Installation For verification process, boot your target from the SD Card. (Review your specific target documentation) 1. Verify Weston For this verification you will need to be root user. # export XDG_RUNTIME_DIR=/run/user/0 # weston   2. Verify VPU and Gstreamer Use the following Gstreamer pipeline for Hardware Accelerated VPU Encode. # gst-launch-1.0 videotestsrc ! video/x-raw, format=I420, width=640, height=480 ! vpuenc_h264 ! filesink location=test.mp4   Then you can reproduce the file with this command: # gplay-1.0 test.mp4   Finally, you have installed and verified the GPU, VPU and Multimedia packages. Now, you can start testing audio and video applications.