i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
Platform: i.MX8QXP/8QM OS: Linux Supported Camera Modules: Max9286 + Max9271 + OV10635, Default BSP Max9286 + Max96705 + AR0144, patch Max9286 + Max96705 + OV9284, patch Max9286 + Max96705 + AP0101 + AR0132, patch NVP6324 + NVP2431 + IMX225, patch TP2855 + TP3812 + IMX307, patch ISL7998x + NTSC/PAL Sensor, patch adv7180 + NTSC/PAL Sensor, patch Detailed description in the attachment.
View full article
    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK.     You need git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-4.19.35-1.1.0-20200818 (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitbake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000  -l 100000😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36   //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min:      0 Act:    0 Avg:    0 Max:      42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min:      0 Act:    1 Avg:    0 Max:      36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min:      0 Act:    1 Avg:    1 Max:      42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min:      0 Act:    1 Avg:    1 Max:      45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min:      0 Act:    1 Avg:    1 Max:      22   //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C:   66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C:   50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C:   40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C:   33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C:  666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C:  499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C:  399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C:  333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C:  824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C:  618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C:  494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C:  412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// Update for Yocto L5.4.47 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git,  and git checkout xenomai-5.4.47-2.2.0. You need to add the following variable in conf/local.conf before build xenomai by command bitbake imx-image-multimedia.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release  for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.0. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time   //////////////////////////////////////// update for Yocto L5.4.70 2.3.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-5.4.70-2.3.2. Updating: 1, Enable Xenomai RTDM driver in Linux Kernel 2, Currently CAN, UART, GPIO,  SPI and Ethernet (in debug for RTNet)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf to enable relative device in Xenomai domain, for example rt-imx8mp-flexcan.   //////////////////////////////////////// Update for Yocto L5.4.70 2.3.4  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.4. You need to git clone  https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.4. Updating: 1, Enable RTNet FEC driver 2, Currently CAN, UART, GPIO,  SPI and Ethernet ( FEC Controller)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf and KERNEL_DEVICETREE += " freescale/imx8mm-rt-ddr4-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mmddr4evk.conf to enable rt_fec device in Xenomai domain. Verifying the network connection by RTnet Ping Between i.MX8M Mini EVK and i.MX8M Plus EVK a, Setup test environment 1, Connect ENET1 of  i.MX8M Plus EVK (used as a master) and  ENET of i.MX8M Mini EVK (used as a slave) of  to a switch or hub 2, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Plus EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.101" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -65,7 +65,7 @@ TDMA_MODE="master" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 3, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Mini EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.102" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -59,13 +59,13 @@ STAGE_2_CMDS="" # TDMA mode of the station ("master" or "slave") # Start backup masters in slave mode, it will then be switched to master # mode automatically during startup. -TDMA_MODE="master" +TDMA_MODE="slave" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 4, rename imx8mm-rt-ddr4-evk.dtb to imx8mm-ddr4-evk.dtb in /run/media/mmcblk1p1,  rename imx8mp-rt-evk.dtb to imx8mp-evk.dtb in /run/media/mmcblk1p1, and reboot board. 5, Run the below command on i.MX8M Mini EVK board. cd /usr/xenomai/sbin/ ./rtnet start & 5, Run the below command on i.MX8M Plus EVK board. cd /usr/xenomai/sbin/ ./rtnet start & When you see the log (rt_fec_main 30be0000.ethernet (unnamed net_device) (uninitialized): Link is Up - 100Mbps/Full - flow control rx/tx) and you can run command "./rtroute" to check route table if the slave IP (192.168.100.102) is in route.. b, Verify the network connection using the command below: ./rtping -s 1024 192.168.100.102 //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.  Latency testing of Xenomai3.2+Dovetail with isolating CPU 2,3 ( Xenomai 3.2 on 8MM DDR4 EVK with GPU test case (GLES2/S08_EnvironmentMappingRefraction_Wayland) + iperf3 + 2 ping 65000 size + stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief )😞 The following is test result by the command (/usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000) root@imx8mmddr4evk:~# /usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 5.96 6.04 6.03 7/155 1349 T: 0 ( 615) P:50 I:1000 C:63448632 Min: 0 Act: 0 Avg: 0 Max: 55 T: 1 ( 616) P:50 I:1500 C:42299087 Min: 0 Act: 0 Avg: 1 Max: 43 T: 2 ( 617) P:50 I:2000 C:31724315 Min: 0 Act: 0 Avg: 1 Max: 51 T: 3 ( 618) P:50 I:2500 C:25379452 Min: 0 Act: 0 Avg: 1 Max: 53 T: 4 ( 619) P:50 I:3000 C:21149543 Min: 0 Act: 0 Avg: 1 Max: 47 //////////////////////////////////////// Update for Yocto L5.10.72 2.2.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.72 2.2.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.72-2.2.2. Updating: 1, Upgrade Xenomai to v3.2.1 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai"   //////////////////////////////////////// Update for Yocto L6.1.55 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L6.1.55 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.1.x Updating: 1, Upgrade Xenomai to v3.2.4 and support i.MX93 2, Enable EVL (aka Xenomai 4) for i.MX93 and legacy i.MX(6/7D/8X/8M) Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"   //////////////////////////////////////// Update for Yocto L6.6.52 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L6.6.52 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.6.52 Updating: 1, Upgrade Xenomai to v3.3 and support i.MX91/93/95 2, Upgrade EVL (aka Xenomai 4),  libevl to r50 and support i.MX91/93/95 Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"    
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.
View full article
The iMX8QM LVDS has followed work mode, (There are two LVDS modules in IMX8QM): Single mode (LVDS panel connects to one channel) panel 1 and panel 2 can be different panels: Dual channel split mode (The panel needs two LVDS channels, CH0 for 1,3,5,7,... pixels and CH1 for 2,4,6,8,... pixels): Mirror dual mode (The two panels on same LDB PHY should be same panels on pixel clock and resolution, panel 1 and panel 2 are same; panel 3 and panel 4 are same): The reference patch is based on L5.4.3_GA1.0.0 BSP. LVDS single mode and dual channel split mode are supported in default Linux BSP. Patch 0002 can be used to test this dual mode on MEK board, some rework is needed on MEK board:     R194, R195, R208, R209, R213, R214 should be mounted. And the I6263 board can't be connected to LVDS0_CH0 and LVDS0_CH1 at the same time. The I6263 board can't be connected to LVDS1_CH0 and LVDS1_CH1 at the same time too. Note: for iMX8QXP, there is no mirror dual mode support, because its two LVDS ports are from two different LDB modules, there are no CH1 for them: Note: for iMX8QXP dual channel split mode (The pixel order can be switched: LDB1_CH0 for 1,3,5,7,... pixels and LDB2_CH0 for 2,4,6,8,... pixels; or LDB2_CH0 for 1,3,5,7,... pixels and LDB1_CH0 for 2,4,6,8,... pixels), iMX8QM LVDS has no such feature.
View full article
The document to descript change the u-boot environment variables under the Linux rootfs.  Also provide a demo on i.MX6ull evk of sdcard mirror.  Linux fw_printenv fw_setenv to access U-Boot's environment variables.pdf  --- the document fw_printenv_fw_setenv_demo_iMX6ullevk_L4.14.98_2.0.0_ga.sdcard  --- demo sdcard mirror
View full article
When working with an evaluation kit you will be provided with a System Controller Firmware (SCFW) binary included in your BSP. This scfw binary has been tailored for that specific board and you might need to modify some board dependencies to fit your specific hardware. This document aims to provide an overview on the SCFW porting process, for detailed information please refer to the System Controller Porting guide (sc_fw_port.pdf).   Setting up the system The SCFW is built on a Linux host. The steps to set-up your system are the following: Download the GNU ARM Embedded Toolchain: 6-2017-q2-update June 28, 2017 from the ARM website: Select a directory to untar the file unto, for instance: mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   Set TOOLS environment variable to the directory containing the tool chain, "~/gcc_toolchain" on the example above, .bash_profile can also be modified to export this environment variable: export TOOLS=~/gcc_toolchain/ srec_cat is also necessary for the build, this is usually contained in the srecord package, on ubuntu you can do: sudo apt-get update sudo apt-get install srecord Now you can change to the porting kit directory (e.g. scfw_export_mx8qm) and build the scfw. System Controller Firmware Porting kit  The SCFW porting kit contains source files and object files that will allow you to modify the SCFW to work with your board. You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: Once you obtain the porting kit untar it: tar xvzf imx-scfw-porting-kit-1.1.tar.gz‍ You will see the following file structure: The porting kit is contained under packages, the README contains the instructions to extract the porting kit, basically: cd packages/ chmod a+x imx-scfw-porting-kit-1.1.bin ./imx-scfw-porting-kit-1.1.bin‍‍‍ You will be prompted to accept an End User License Agreement: Once you accept the agreement the porting kit will be extracted in a new folder, the folder structure is as follows: All documentation regarding SCFW is under doc/pdf or in html format if preferred, it is recommended to go over sc_fw_port.pdf. The porting kits for different SoC variants (QM A0, QM B0 and QXP B0) are under src packaged as tar.gz, all other files are SCFW libraries for different software packages, such as Linux, QNX, FreeRTOS, U-boot, ARM Trusted Firmware, etc...   If you will be working with several SoC variants (working with both QXP and QM) it is recommended to extract all porting kits into a single directory, that way you will be able to build for any variant from this directory, the command to do this is: cd imx-scfw-porting-kit-1.1/ cd src/ find scfw_export_mx8*.gz -exec tar --strip-components 1 --one-top-level=scfw_export_mx8 -xzvf {} \;‍‍‍ A scfw_export_mx8 folder will be created, from here you will be able to build SCFW for any supported variant. Or you can just extract the package for the variant you are interested on and use that. cd scfw_export_mx8/‍ All the build folders contain the results of building the SCFW and platform is where the source of the SCFW is stored.   All the code that is specific to a board configuration is under "platform/board/mx8<derivative>_<board_name>" where derivative is the i.MX8 silicon family such as QXP or QM, and board name is the name of the board the SCFW package is for. The first step in porting the SCFW to your board is to create a folder for your i.MX8 derivative and board, you can take one of the available board examples and rename the folder, that will provide you a project to get started with, for instance: cp -r platform/board/mx8qm_val/ platform/board/mx8qm_myBoard/‍‍‍‍‍‍‍‍‍‍ The board in this example will be called "myBoard" and it is for an i.MX8QM B0 device. To build a SCFW for this board simply call: make qm R=B0 B=myBoard‍‍‍‍‍‍‍‍‍‍‍‍ If the target is an i.MX8QXP simply take a board based on this device and change the call to "make qx". Additional information such as build options and in detailed boot information can be found in the SCFW porting guide (sc_fw_port.pdf), chapter 2 of this document is a great introduction to the porting process.   Overview and useful information Configuring the PMIC overview and board.c common modifications The main file that needs to be altered (if not the only) is the "board.c" file, it is located at "platform/board/mx8X_board/". The board.c file contains most of the board related information such as SCU UART ports, PMIC initialization routines, PMIC temperature alarms settings and you can also modify it to configure LDOs voltages and communicate with the PMIC in general. All functions in the board.c file are executed by the SCU itself and this gives you access to the I2C interface that is used to communicate with the PMIC. SoC resources that are powered by an external supply (PMIC LDO for instace) such as AP cores and GPUs are powered off/on by board_set_power_mode, the mapping of the resource to an specific PMIC supply happens in board_get_pmic_info, for instance in our i.MX8QM validation board using the A53 subsystem is powered by SW2 of the third PMIC (PMIC_2_ADDR addresses start at PMIC_0) on the PF100 PMIC card and by SW5 of the first PMIC (PMIC_0_ADDR) on the PF8100 PMIC card. case SC_SUBSYS_A53: pmic_init(); if (pmic_card == PF100) { pmic_id[0] = PMIC_2_ADDR; pmic_reg[0] = SW2; *num_regs = 1; } else {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1; } break; ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The voltages of SoC resources that are powered by an external supply (AP cores, GPUs, etc...) are managed by board_set_voltage in the board.c file. The mapping of resource to power supply occurs in board_get_pmic_info as in the example above. Eight "board resources" (SC_R_BOARD_R0, ... SC_R_BOARD_R7) are available, these resources allow you to define components in your board that the SCU can manage, for instance a sensor on your board powered by one of the PMIC LDOs can be mapped to a board resource and the board.c file can be modified to power on/off the sensor as well as modifying its voltage. Modifying the voltage on a board resource can be either be done by modifying the voltage at board_trans_resource_power (see below) or if the voltage needs to change at run time the function board_set_control can be modified to change the voltage whenever a miscellaneous call (more details in the Miscellaneous Service 101) is made on that resource. For instance to change the voltage on SC_R_BOARD_R7 you would have the following case to board_set_control: case SC_R_BOARD_R7: if (ctrl == SC_C_VOLTAGE) { /* Example only PMIC_X_ADDR and PMIC_SUPPLY need to match an actual device */ pmic_interface.pmic_set_voltage(PMIC_X_ADDR, PMIC_SUPPLY, val, step); } else return SC_ERR_PARM; break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The case above will be executed by the SCU every time the application calls the function below: sc_misc_set_control( ipc, SC_R_BOARD_R7, SC_C_VOLTAGE, voltage_val);‍‍‍‍‍‍‍‍ Powering on/off a board resource happens at board_trans_resource_power in the board.c file. For instance in NXP's validation board the PTN5150 on the board is managed through a board resource 0, and the power on/off is managed as follows: case BRD_R_BOARD_R0 : /* PTN5150 (use SC_R_BOARD_R0) */ if (pmic_ver.device_id == PF100_DEV_ID) { if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_2_ADDR, VGEN6, 3300, SW_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_ON); } else { pmic_interface.pmic_set_mode(PMIC_2_ADDR, VGEN6, VGEN_MODE_OFF); } } else {/* PF8100_dual Card */ if (to_mode > SC_PM_PW_MODE_OFF) { pmic_interface.pmic_set_voltage(PMIC_1_ADDR, PF8100_LDO1, 3300, REG_RUN_MODE); pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_EN_STBY_EN); } else { pmic_interface.pmic_set_mode(PMIC_1_ADDR, PF8100_LDO1, RUN_OFF_STBY_OFF); } } break;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Whenever the function below is called from the application side the SCU will execute the code above: sc_pm_set_resource_power_mode(ipc, SC_R_BOARD_R0, SC_PM_PW_MODE_ON/OFF);‍‍‍‍‍‍‍‍ board_config_sc is used to mark resources that the SCU needs, such as the I2C module and pads used to communicate with the PMIC, any resource needed by the board.c functions to work should be marked in this function as not movable, for instance to keep the SCU I2C module the following line is added: rm_set_resource_movable(pt_sc, SC_R_SC_I2C, SC_R_SC_I2C, false);‍‍‍‍‍‍‍‍‍ The following pads are part of the SCU and the application will not be able to access them: - SC_P_SCU_PMIC_MEMC_ON - SC_P_SCU_WDOG_OUT - SC_P_PMIC_EARLY_WARNING - SC_P_PMIC_INT_B - SC_P_SCU_BOOT_MODE0 through SC_P_SCU_BOOT_MODE5 board_system_config is where early resource management occurs, this function is only called when the alt_config flag is set in the image, and it can create partitions and allocate resources to it. More details are found in the resource management service 101. board_get_pcie_clk_src defines the clock that the PCIe uses, it can be either BOARD_PCIE_PLL_EXTERNAL or BOARD_PCIE_PLL_INTERNAL. board_print is very useful to debug your changes the syntax is as follows: board_print(3, "Debug printout %d\n", val);‍‍‍‍‍‍‍ Where the first parameter is the Debug Level and from there on it works as a standard printf. The output will only be visible on the SCU debug output whenever the SCU is built with the corresponding debug level, in the case above the SCFW needs to be built as follows in order to see the output: make qm B=myBoard‍‍‍‍ DL=3 or higher (debug level goes from 0 to 5)‍‍‍‍‍‍‍   Usage examples The following utility shows how to make System Controller Firmware requests and provides a way to make such requests through command line interface on both QNX and Linux System Controller Firmware Command Line Utility for Linux and QNX   System Controller Firmware 101  
View full article
I²C is a communication protocol used to exchange information between cores. To see more about I²C, please follow this link Wikipedia:I²C. Enable I2C-tools in LTIB into Package List: Reboot your file system, there are three new I²C commands: i2cdetect, i2cdump and i2cset. All examples below were tested in a iMX27ADS, but this programs seems to have the same behavior to all platforms. Detecting busses This command lists all installed bus. mx27# i2cdetect -l i2c-0   unknown         MXC I2C Adapter                         Algorithm unavailable There is one installed bus with address 0. Installed Chips I2cdetect shows the installed chips too. mx27# i2cdetect 0     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will probe file /dev/i2c/0.     I will probe address range 0x03-0x77.         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX 2d XX XX 30: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX XX 70: XX XX XX XX XX XX XX XX There are several cores installed into bus i2c-0. If you received an error message like this: # i2cdetect 0 Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory You will need to create the special file /dev/i2c-0 : # mknod /dev/i2c-0 c 89 0 Chip Registers i2cdump shows a list of all registers for a core. For example, the command above shows registers for core with address 0x6a: mx27# i2cdump 0 0x6a No size specified (using byte-data access)     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will probe file /dev/i2c/0, address 0x6a, mode byte         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef 00: 00 00 28 00 00 03 15 03 00 00 00 00 00 00 03 01    ..(..???......?? 10: 04 01 00 00 04 01 00 00 17 41 1d 00 09 09 1f 03    ??..??..?A?.???? 20: 00 00 40 00 08 00 0c 00 0f 01 00 00 00 00 08 11    ..@.?.?.??....?? 30: 00 0f 05 fe 0b 00 00 00 82 00 0c 02 00 00 01 00    .????...?.??..?. 40: 21 f0 7c 1f 00 00 01 00 7a 40 80 38 00 01 47 00    !?|?..?.z@?8.?G. 50: 3c 00 17 21 1b 1b 24 9f 00 3e 0f 0f 60 05 cd 03    <.?!??$?.>??`??? 60: 89 04 89 01 02 00 0a 05 00 19 ff 03 24 0f 78 00    ?????.??.?.?$?x. 70: 00 b2 06 14 04 08 00 a3 c8 15 05 15 3c 00 00 20    .?????.?????<.. 80: 07 2f 07 00 00 00 00 00 00 00 00 ff 03 1a 1a 1a    ?/?.........???? 90: 1a 1a 40 03 00 00 00 00 00 00 00 00 00 00 e4 00    ??@?..........?. a0: 00 02 4d 00 96 00 1d 00 a0 00 db 00 7e 00 00 00    .?M.?.?.?.?.~... b0: 00 00 00 00 00 00 f0 00 00 00 00 00 00 00 00 00    ......?......... c0: 00 00 00 00 48 9c 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ....H??????????? d0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? e0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? f0: 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a 1a    ???????????????? Setting a register To change some register value, use i2cset like in example below: mx27# i2cset 0 0x6a 01 0x0008 w     WARNING! This program can confuse your I2C bus, cause data loss and worse!     I will write to device file /dev/i2c/0, chip address 0x6a, data address     0x00, data 0x08, mode word. Value 0x8 written, readback matched Where: 0 is the bus address 0x6a is the slave address 01 is the register address 0x0008 is the new value for register w is the word mode for the setting
View full article
This documents describes the neceesary steps to set up Qt Creator with the Qt5 toolchain that is available as part of the 3.14.28 BSP Release. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release L3.14.28 or higher. For this example we'll use the Freescale BSP Release L3.14.28 but you may use future BSP releases that include the Qt toolchain. - Freescale BSP Release Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=gz&WT_ASSET=Documentation&fileExt=.gz&Parent_nodeId=1337637154535695831062&Parent_pageType=product&Parent_nodeId=1337637154535695831062&Parent_pageType=product 3) Qt5 Meta Toolchain (Poky 1.7 qt5 / L3.14.28 for our example but you may use the qt toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document but with the following command: $ bitbake meta-toolchain-qt5 https://community.freescale.com/docs/DOC-95122 Task #7 - Create the toolchain Then run the script. fsl-release-bsp/<BUILD_DIR>/tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-vfp-neon-toolchain-1.7.sh Installing Qt Creator We will use the Open Source version of Qt Creator. Please make sure that your application does comply with the requirements of Open Source Software before installing. You may download Qt Creator Open Source for Linux from the following link: http://www.qt.io/download-open-source/ Once you downloaded the installer you will need to make sure that the file has permission to be executed. You can add this with the following command: $ chmod +x qt-unified-linux-x64-2.0.2-2-online.run Then run the installer $ ./ qt-unified-linux-x64-2.0.2-2-online.run After the information from the repositories has been fetched you will be asked where to install Qt Creator. Then you will be asked which components to install. We will install Qt 5.4 which is the one supported on the 3.14.28 BSP release. You will need to accept the License Agreement and then the installer will fetch and install the necessary files. Configuring Qt Creator Once it’s finished downloading, launch Qt Creator. You can do this with the following command: cd <INSTALATION_DIR>/Tools/QtCreator/bin $./qtcreator.sh Under the Tools top bar menu, chose Options… On the Options window’s left menu chose Build & Run and then the Compilers tab and select Add GCC. On the next screen chose a name for this Compiler (i.e. i.MX Qt5) and then select the Compiler path, which may vary depending on where you have it installed but by default should be in: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ It should then be detected as arm-linux on the ABI section. Next select the Qt Versions tab and click on Add… Look for the qmake on the toolchain path, which is by default: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake Finally, on the Kits tab add a new kit and select the sysroots from the toolchain, which is by default located in: /opt/poky/<VERSION>/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi Qt Creator is now configured for building for the i.MX6.
View full article
When working on the IOMUX settings of an i.MX processor for our design it’s always good to make use of the IOMUX Tool provided by Freescale on the Download Page of most i.MX processors. We’ll focus on the latest release of the IOMUX tool for i.MX6. The IOMUX tool provides a Graphic User Interface to easily assign internal signals to external pins/balls and resolve any potential pin conflict and muxing options for the different modules available on the i.MX processors. IOMUX Tool Download (Will request to log in) Freescale’s Boards IOMUX settings. On the IOMUX tool package you’ll find the User’s Manual and also a folder containing the muxing options for Freescale’s Reference Boards, which may be of help when working with the Reference Designs as a starting point. You may load these settings files using the file/open option. MMDC pins Since the Multi-mode DDR controller MMDC pins are not muxed these cannot be changed on the IOMUX tool. This because the memory interfaces are much more sensitive to interference and thus have dedicated pins that do not share pad with other signals. The registers are also set on the default value so it’s good to keep this in mind when working with the code provided by the IOMUX tool. Considerations when using generated code The tool can generate code to be used as reference of the IOMUX configuration but still requires manual tweaking and the header files available on the i.MX Processor’s BSP in order to be implemented in an actual application code. It’s important to review the register settings on the Register tab in order to export the desired values; otherwise the code will have the default values for the registers according to the IOMUX tool. This is especially true for the Daisy Chain settings, always manually review these. Import function limitations There is an import function available so IOMUX configuration files saved in previous versions of the IOMUX tool can be loaded on the newest version. However, this feature should be used carefully. When importing a design it’s recommended to save the imported design on the new version of the IOMUX tool as imported.xml; then opening a new configuration and saving it as new.xml and comparing register value differences to manually correct the imported.xml values. In small projects it might be recommended to manually load the IOMUX information on the new IOMUX tool version to avoid register conflicts from version to version. For more information please refer to the documentation available within the IOMUX tool package. An advanced example is also included in that document.
View full article
Guide for Accessing GPIO From UserSpace Summary for Simple GPIO Example - quandry https://community.freescale.com/message/598834#598834
View full article
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        
View full article
Several customers met problem on audio codec porting. In order to figure out cpu dai setting problem or codec dai problem. Create the dummy codec for test purpose.  What this dummy codec can do This dummy codec can play up to 8 channels and record up to 6 channels. Connect SAI1 TX data pin with SAI1 RX data pin for loopback test. Environment Verified with i.MX8MM EVK  Based on Linux BSP L4.14.78 Files Kernel patch 0001-multiple-channels-dummy-audio-codec 0002-Add-capture-for-multiple-channels User space setting /etc/asound.conf /usr/share/alsa/cards/aliases.con /usr/share/alsa/cards/DUMMY.conf Audio test content PCM_48_16_8_160000_1_29_jazzshort.wav The alsa command for loopback test with multiple channels  aplay -D surround51:CARD=dummyaudio PCM_48_16_8_160000_1_29_jazzshort.wav | arecord -D surround51:CARD=dummyaudio --disable-channels --disable-format --disable-resample -f S16_LE -r 48000 -c 6 -d 5 -v test.wav
View full article
How to change Linux Kernel configuration file in Yocto Project metalayer Preparing the requirements Download the metalayer Git clone the Linux Kernel source code Customize the configuration Copy the configuration to the metalayer Install the patch in the Linux Kernel recipe Build the new image with the different Linux Kernel configuration How to change Linux Kernel configuration file in Yocto Project metalayer It is common that the metalayer providing a Linux Kernel recipe includes a default configuration file for the Linux Kernel source code (the defconfig file). There are several approaches to customize the Linux Kernel source code and defconfig file. This article presents the option to patch the defconfig from the Linux Kernel source code and is a good approach to be used with meta-fsl-bsp-release or meta-imx . Preparing the requirements The list of requirements: the target metalayer (in this example, it's meta-imx:imx-5.4.3-2.0.0 ) the same Linux Kernel source code, but git cloned Download the metalayer For example, take BSP release imx-5.4.3-2.0.0 for meta-imx $ mkdir <BSP_DIR> $ cd <BSP_DIR> $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-2.0.0.xml $ repo sync $ MACHINE=imx8mnevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Git clone the Linux Kernel source code Use the very same Linux Kernel source code from the metalayer. In this example, open the file sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb to get the git repository, and git commit. $ cd ~ $ git clone git://source.codeaurora.org/external/imx/linux-imx.git $ cd linux-imx $ git checkout fd263a3edd95dfe812397fabf1059b5f99bba2ab -b change_defconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Customize the configuration Using the default defconfig as a base, configure the Linux Kernel, and then use make menuconfig to change the configuration as desired. After the customization, generate a new defconfig file and replace the default one. The step by step with all the commands can be see in next snippet: $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- $ make defconfig $ make menuconfig $ make savedefconfig $ cp defconfig arch/arm64/configs/defconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ The customization can be highlighted by git, in this example the result is show in next log: $ git status On branch change_defconfig Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: arch/arm64/configs/defconfig Untracked files: (use "git add <file>..." to include in what will be committed) defconfig no changes added to commit (use "git add" and/or "git commit -a")‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Review the change and create a commit, with that commit, create a patch. TIP: The defconfig file can also be directly changed. The make menuconfig can be skipped in that case. $ git add arch/arm64/configs/defconfig $ git commit -s -m "defconfig: Customize defconfig" $ git format-patch -1 0001-defconfig-Customize-defconfig.patch‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Copy the configuration to the metalayer Now that the Linux Kernel configuration is customized, and a patch to the kernel is created, copy over that patch to the metalayer, and install it to the Linux Kernel recipe file. $ mkdir <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/ $ cp 0001-defconfig-Customize-defconfig.patch <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/‍‍ Install the patch in the Linux Kernel recipe The Linux Kernel recipe for this example is linux-imx_5.4.bb . Edit the file to install the patch. $ gedit <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb‍ Add the following line: SRC_URI += "file://0001-defconfig-Customize-defconfig.patch "‍ The resultant change is show above: $ cd <BSP_DIR>/sources/meta-imx/ $ git diff diff --git a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb index 214647abb..3f926314c 100644 --- a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb +++ b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb @@ -16,6 +16,7 @@ KERNEL_BRANCH ?= "imx_5.4.3_2.0.0" LOCALVERSION = "-2.0.0" KERNEL_SRC ?= "git://source.codeaurora.org/external/imx/linux-imx.git;protocol=https" SRC_URI = "${KERNEL_SRC};branch=${KERNEL_BRANCH}" +SRC_URI += "file://0001-defconfig-Customize-defconfig.patch " SRCREV = "fd263a3edd95dfe812397fabf1059b5f99bba2ab"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Build the new image with the different Linux Kernel configuration Remember to change the current directory to the metalayer. Build the image again. The new image binary reflects the changes in Linux Kernel, and in case the change removes some kernel module, the rootfs also reflects the change. $ cd <BSP_DIR>/bld-xwayland $ bitbake‍ <image-name>‍‍‍‍‍‍‍‍‍‍
View full article
Brief introduction on i.MX Android
View full article
This document shows the necessary steps to configure the Eclipse IDE for development of Yocto applications. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release or Freescale Community BSP. For this example we'll use the Freescale BSP Release L3.14.28 but you may use the FSL Community BSP. - Freescale Community BSP FSL Community BSP - Freescale BSP Release  Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… 3) Poky Meta Toolchain (Poky 1.7 / L3.14.28 for our example but you should use the toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document. Task #7 - Create the toolchain 4) Eclipse Luna. We’ll use the Luna SR2 (4.4.2) version of the Eclipse IDE. You may find it on the following website: http://www.eclipse.org/downloads/packages/release/luna/sr2 Look for the “Eclipse IDE for C/C++ Developers”, which contains the Eclipse Platform, the Java Development Tools (JDT), and the Plug-in Development Environment. Once you have downloaded the tarball extract it. The following command unpacks and installs the downloaded Eclipse IDE tarball into a clean directory using the default name eclipse:      $ cd ~      $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz Configuring the Eclipse IDE Once with Eclipse Luna installed you may run the Eclipse IDE with the following command: $ cd eclipse $ ./eclipse Select a new workspace. Chose "Install New Software" from the "Help" pull-down menu. Select the "Luna - http://download.eclipse.org/releases/luna" Find and expand the Linux Tools option and select: Linux Tools LTTng Tracer Control Linux Tools LTTng Userspace Analysis LTTng Kernel Analysis If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Find and expand the Mobile and Device Development and select the following:   C/C++ Remote Launch (Requires RSE Remote System Explorer)   Remote System Explorer End-user Runtime   Remote System Explorer User Actions   Target Management Terminal (Core SDK)   TCF Remote System Explorer add-in   TCF Target Explorer If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Expand Programming Languages and select:   C/C++ Autotools Support   C/C++ Development Tools Chose Next and accept the necessary EULA Clck on the Finish button. The selected packages will be downloaded and installed. You will be asked to restart Eclipse IDE to finish the installation. Adding the Yocto Plug-in to the Eclipse IDE Next step is to install the Eclipse Yocto Plug-in into the Eclipse IDE. We'll show how to install the pre-built plug in. Start the Eclipse IDE In Eclipse, select "Install new Software" from the "Help" menu Click the "Add..." button to add a repository and enter: Name: Any name, we will use Yocto Fio Location: http://downloads.yoctoproject.org/releases/eclipse-plugin/1.8/luna Click "Ok" and then chose this new repository on the "Work with" drop-down menu and select the following plug-ins from the list:   Yocto Project ADT Plug-in   Yocto Project Bitbake Commander Plug-in   Yocto Project Documentation plug-in Install these plug-ins and click "OK" when prompted about installing software that contains unsigned content. You may be asked to restart the Eclipse IDE. Configuring the Eclipse Yocto Plug-in With all the necessary packages installed we'll now configure the Eclipse Yocto Plug-in. In this steps we will configure the Cross Compiler options and the Target options. These will then be used as default for your projects from within your working workspace. Select "Preferences" from the "Window" menu. Click on Yocto Project ADT from the left options and then under Cross Compiler Options select the Standalone pre-built toolchain radio button. We need to point to the Toolchain Root location of our installed toolchain. This is covered on the following community document: Task #7 - Create the toolchain In this case we'll be using poky 1.7 tollchain which has the following default location: /opt/poky/1.7 As fo the Sysroot Location this would correspond to your build directory sysroot folder, which is located on the following path: <YOCTO_BSP_DIR>/<BUILD_DIR>/tmp/sysroots/<MACHINE> In our case our Tartget architecture would be the Cortex-A9, which correspond to the i.MX6 and which is also the only option installed on the chosen directory. For Target Options we would be using the actual HW in order to test our application so keep the External HW option selected. Creating a Hello World Project We are now ready to create our project. Just to test our configuration we'll create a Hello World project.We can do so by selecting File->New->C Project or C++ Project We must then select a Project name and in project type we can chose either an Empty project or as in our case a Hello World Project, all this under the Yocto Project ADT Autotools Project folder. We will have the GNU Autotools Tolchain selected. The next screen will show some of the Basic Properties for our project, including the GNU license. Fill these as required. You may clock on Finish at this point. We should see that the HelloWorld project was created. We should right-click on the project folder and then chose Reconfigure Project in order to fill the necessary libraries. After this is completed we can build our project either by choosing the hammer icon or in the Build Project option inside the Project menu. We can look for correct competition or any errors or warning on the Console tab. Further Application Development After this basic setup you may work on more complex examples like a GPU and a Gstreamer Application examples on the following nicely written document: Yocto Application Development Using Eclipse IDE
View full article
Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response. These are detailed programming aids for the registers associated with DRAM initialization (LPDDR3 and LPDDR2). The last work sheet tab in the tool formats the register settings for use with the ARM DS5 debugger. It can also be used with the windows executable for the DDR Stress Test (note the removal of debugger specific commands in this tab). These programming aids were developed for internal NXP validation boards.   This tool serves as an aid to assist with programming the DDR interface of the i.MX 7ULP and is based on the DDR initialization scripts developed for NXP boards and no guarantees are made by this tool.   The following are some general notes regarding this tool: The default configuration for the tool is to enable bank interleaving. Refer to the "How To Use" tab in the tool as a starting point to use this tool. The tool can be configured for one of the two memory types supported by the i.MX 7ULP.  Nevertheless, two separate programming aids are provided based on the DRAM type: LPDDR3 and LPDDR2.  Therefore, you may use the tool pre-configured for your desired memory type as a starting point. Some of the CCM programming at the beginning of the DRAM initialization script (in the "DStream .ds file" tab) were automatically generated and in very few cases may involve writing to reserved bits, however, these writes to reserved bits are simply ignored. Note that in the "DStream .ds file" tab there are DS5 debugger specific commands that should be commented out or removed when using the DRAM initialization for non-debugger specific applications (like when porting to bootloaders). This tool may be updated on an as-needed basis for bug fixes or future improvements.  There is no schedule for aforementioned maintenance. For questions or additional assistance using this tool, please contact your local sales or FAE.
View full article
Many times I came across one issue while using Redlib in MXUXpresso IDE project. I like to provide some guidance here to match the proper solution that can help others. Problem Statement : printf or sprintf doesn't print anything or printing random characters while using Redlib library. Reason : When you are creating your project you may ask to choose the c/c++ library setting to select either of the c libray provided by IDE in Advanced project setting wizard. If you have not checked the option "Redlib: Use floating point version of printf" (which will use the floating-point variant of printf) have tried to print the floating point value, You will end up with the problem mentioned above. Solution : You need to enable the floating support by modifying some preprocessor directives in "Defined symbols (-D)" wizard of your project. Path :  Your Project > properties > C/C++ Build > Setiings > Tool Settings > MCU C Compiler > Preprocessor. These are: PRINTF_FLOAT_ENABLE - keep the directive value to "1" SCANF_FLOAT_ENABLE - keep the directive value to "1" CR_INTEGER_PRINTF - Undefine/Remove this directive Click on Apply and close. That is it. Now you will have your expected prints for floating point values in your debugger console.
View full article