Procrank can be used to check if a process has memory leakage. Procrank will list four types of memory usage. For details refer to: http://elinux.org/Android_Memory_Usage Vss = virtual set size Rss = resident set size Pss = proportional set size Uss = unique set size Uss can be used to check if a process has memory leakage. If the Uss increases when some operations start and stop, this means there could be memory leakage. Procrank can get from: <myandroid>/out/target/product/<product_name>/system/xbin/procrank and also needs to push to the library you target: <myandroid>/out/target/product/< product_name >/system/lib/libpagemap.so

Dumping the pipeline elements into a image file # On target, run the pipeline $ export GST_DEBUG_DUMP_DOT_DIR=<folder where dot files are created> $ gst-launch playbin2 uri=file://${avi} $ # Move the .dot files to a host machine (scp, etc) # On Host dot <dot file> -Tpng -o out.png # dot command is part the the graphviz package Querying which elements are being used on a gst-launch command GST_DEBUG=GST_ELEMENT_FACTORY:3 gst-launch playbin2 uri=file://`pwd`/<media file> Interrupting a gst-launch process running in the background kill -INT $PID # where $PID is the process ID Using only SW codecs # Backup and remove $ find /usr/lib/gstreamer-0.10 -name "libmfw*" | grep -v sink | xargs tar cvf /libmfw_gst.tar $ find /usr/lib/gstreamer-0.10 -name "libmfw*" | grep -v sink | xargs rm # Run your pipeline. This time SW codecs are used $ gst-launch playbin2 uri=file://`pwd`/media_file # To 'install' FSL plugins again, just untar the file $ cd / && tar xvf libmfw_gst.tar && cd - # then run your pipeline. This time HW codecs are used $ gst-launch playbin2 uri=file://`pwd`/media_file

Here is a summary including kdump + crash porting in i.mx, the tool is very useful in crash issue. Overview What is Kdump + Crash Preconditions kernel kexec Step actions Crash tool Analysis of use cases   Besides that, I summary the dumper tools including kdump and pstore, the respective patches shown as below: Kdump: Customer can apply below patch in config and cmdline, which has been confirmed on linux os. As memory is very precious to android, so kdump is not worth adopting. Config:        First kernel:       CONFIG_KEXEC=y       CONFIG_SYSFS=y       CONFIG_DEBUG_INFO=Y        Capture kernel:       CONFIG_CRASH_DUMP=y       CONFIG_PROC_VMCORE=y Cmdline:        crashkernel=512M Pstore: Customer can apply below patch in config and dts showing as below, which has been confirmed on linux and android os. Config: CONFIG_PSTORE_PMSG=y Dts: +               ramoops@0x91f00000 { +                       compatible = "ramoops"; +                       reg = <0 0x91f00000 0 0x00100000>; +                       record-size     = <0x00020000>; +                       console-size    = <0x00020000>; +                       ftrace-size     = <0x00020000>; +                       pmsg-size       = <0x00020000>; +               }; +                 decoder_boot: decoder-boot@84000000 {                         reg = <0 0x84000000 0 0x2000000>;                         no-map;   Reproduce steps Reboot the system by enter below command:       $ reboot Check the related log by enter below command:       $ ls /sys/fs/pstore/          console-ramoops-0 pmsg-ramoops-0

Overview In this doc, I will try to give you a brief of the Linux kernel changes between 4.x and 5.4 (5.0/5.1/5.2/5.3/5.4), which related to i.MX users/developers: Important bug fix and improvements according to my experiences New features you should keep an eye on Interfaces changes may impact applications i.MX up-streaming I cannot make sure every single change's description is 100% correct. Either, I cannot list all of the impacts to the i.MX platform due to my limited knowledge and experiences. I hope this doc can help you on developing kernel drivers, user applications or debugging issues of 5.x i.MX kernel release. Changes Subsystem/Modules Detail changes Comments References Kernel Cores binder: new binderfs, a pseudo-filesystem for the Android Binder IPC driver which can be mounted per-ipc namespace allowing to run multiple instances of Android Hmm... that may imply we can run multi-instance Android without Hypervisor? sysctl: add panic_print sysctl to configure which information to print at panic time, w/ replay option So we can define the panic information for better debugging the crash issue. Also option for users to configure the "panic_print" to replay all dmesg in buffer, some of which they may have never seen due to the loglevel setting, which will help panic debugging How to use boot: Add boot option ( driver_async_probe=... ) to specify drivers to be async probed Asynchronous driver probing can help much on kernel fastboot, and this option can provide a flexible way to optimize and quickly verify async driver probe. Asynchronous device/driver probing support [LWN.net]  swiotlb: add debugfs to track swiotlb buffer usage The device driver will not be able to do dma operations once swiotlb buffer is full, either because the driver is using so many IO TLB blocks inflight, or because there is memory leak issue in device driver. Export buffer usage in debugfs can help. Please note, almost all of the dma buffers on i.MX8 platform comes from swiotlb. aarch64 Linux Kernel Memory Management  New mount syscall API The kernel supports a wide variety of filesystem types, and each has its own, often extensive set of options. As a result, the mount() system call is complex. This makes application code who need mount FS more clear. Six (or seven) new system calls for filesystem mounting [LWN.net]  New APIs to support pidfs clone return pidfs, new syscall pidfd_send_signal(2), which uses file descriptors from /proc/<pid> as stable handles on struct pid.  Toward race-free process signaling [LWN.net]  locking: rwsem improvement unification and simpler micro-optimizations, performance improvement of this locking primitive. Preparations for PREEMPT_RT It's excited that community decided to merge the PREEMPT_RT kernel changes into mainline. It's well known as rt-patch for hard real-time use cases like industry. Index of /pub/linux/kernel/projects/rt/  Memory management KASAN: Improved the KASAN performance for arm64 KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides a fast and comprehensive solution for finding use-after-free and out-of-bounds bugs. It's useful when debugging kernel drivers and modules memory issue. The Kernel Address Sanitizer (KASAN) — The Linux Kernel documentation  Fragmentation avoidance improvements, reducing fragmentation events by over 90%. With this change, the page allocator would spread allocations across zones before introducing fragmentation.  We can always found customer's product memory fragment in some use cases in old kernel. Which would cause kmalloc or cma alloc failure and system stop. Balance between zones (i.MX8 we have DMA/NORMAL zones) to avoid fragment is very helpful. patch intro One of customer case(fixed by not using kmalloc): https://jira.sw.nxp.com/browse/MLK-23220  Increase success rates and reduce latency of compaction (physical memory defragmentation) Memory compaction is the way to avoid memory fragment. Memory compaction [LWN.net]  Improve Out Of Memory (OOM) reports, include victim's memcg More clear kernel OOM report may help lot Remove the ancient OOM killer heuristic that preferred to kill children of the "worst" process rather than the process itself Improve the OOM efficiency zram improvements, which can help estimate wasted memory, and perform writeback that will free it zram is actually used very widely in the Android system as backup swap for physical memory. Swap performance is very important. Low RAM Configuration  |  Android Open Source Project  Simplify some of the early memory allocations by replacing usage of older memblock APIs with newer and shinier ones memblock API changes. If you used memblock in your drivers, then need to check. Boot time memory management — The Linux Kernel documentation  psi: Improves the Pressure Stall Information resource monitoring With this mechanism, Android can monitor for, and ward off, mounting memory shortages before they cause problems for the user. For example, using memory stall, monitors in userspace like the low memory killer daemon (lmkd) can detect mounting pressure and kill less important processes. Supported in Android10, replace the vmpressure. Low Memory Killer Daemon (lmkd)  |  Android Open Source Project  Pressure stall monitors [LWN.net]  Improve vmap allocation Speed up the vmalloc https://lkml.org/lkml/2018/10/19/786  Introduce madvise() flags MADV_COLD, MADV_FREE, MADV_PAGEOUT MADV_COLD marks pages as inactive (thus more easily reclaimed under memory pressure), but doesn't discard the contents like MADV_FREE does, and MADV_PAGEOUT , which reclaims pages immediately. Android would use this flags for better memory management kernel/git/torvalds/linux.git - Linux kernel source tree  memcg: from v1->v2 shrink all memcg caches for the slab cache Throttle allocators when reclaim cannot keep up with v2 memory.high limit Introduce gradual reclaim pressure..... Control Group v2 — The Linux Kernel documentation  Block layer Boot to a device-mapper device without initramfs DM is widely used, you can not bootup to DM rootfs directly. Android 10 would use dynamic partition by creating super partition for /system, /vendor of dm-linear Implementing Dynamic Partitions  |  Android Open Source Project  Tracing and Perf Perf: lots of improvement TBD Security security: Create "kernel hardening" config area Help mitigate kernel vulnerabilities and find bugs in kernel drivers, like Stack buffer overflow mitigation, Hardened usercopy Kernel Hardening  |  Android Open Source Project  LSM: Add kernel lockdown functionality When enabled, the new "lockdown" feature will restrict some kernel functionality, even for the root user, making it harder for compromised root accounts to compromise the rest of the OS Kernel lockdown in 4.17? [LWN.net]  Networking Enable MSG_ZEROCOPY for udp sockets Improve the UDP sending performance. Pay attention that the zero copy UDP sockets only limit to the send operations, not receive. Also require application code change, not efficient at small MTU. Zero-copy networking [LWN.net]  ARM/ARM64 New SoCs: i.MX7ULP with EVK i.MX8MQ with EVK i.MX8MM  i.MX8QXP perf vendor events: Add Cortex-A57 and Cortex-A72 events  support all ARMv8 recommended events Make CONFIG_ZONE_DMA32 configurable commit Which means you can remove the DMA zone, and use only one single normal zone in kernel. Drivers drm: Initial merge of timeline sync objects Timeline syncobj gives user more flexibility and convenience to do sychronization. Android does not used. Staging driver: i.MX7 MIPI CSI subdev NXP QuadSPI driver Introduce Sound Open Firmware (SOF) for audio DSP devices Big changes to the current HiFi4 DSP (in i.MX8QM/QXP) infrastructure. The SOF is an open source audio DSP firmware and SDK that provides audio firmware infrastructure and development tools. Also integrated with current kernel alsa subsystem.  Home - Sound Open Firmware  Firmware - AlsaProject  How to build i.MX8 HiFi4 firmware Add NXP SJA1105 DSA network driver with ptp support Used for networking switch Add TJA11xx PHY driver Add lpspi driver support fsl_lpuart: add imx8qxp support Add SCU watchdog/RTC support regmap: add i3c bus support commit Means we can have i3c bus support in regmap now. References Linux_Kernel_Newbies - Linux Kernel Newbies  Welcome to LWN.net [LWN.net]  kernel/git/torvalds/linux.git - Linux kernel source tree 

This document describes the i.MX 8QXP MEK mini-SAS connectors features on Linux and Android use cases, covering the supported daughter cards, the process to change Device Tree (DTS) files or Boot images, and enable these different display options on the board.

  Platform & BSP : i.MX8MPlus EVK , L6.12.3， uboot lf_v2024.04   The attachments enable the i.MX8MPlus pci function in uboot. lspci in Linux root@imx8mpevk:~# lspci -nn 00:00.0 PCI bridge [0604]: Synopsys, Inc. DWC_usb3 / PCIe bridge [16c3:abcd] (rev 01) 01:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. Device [1b4b:2b42] (rev 11) pci test results in uboot:  u-boot=> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x16c3 0xabcd Bridge device 0x04 01.00.00 0x1b4b 0x2b42 Network controller 0x00 u-boot=> pci bar 00.00.00 ID Base Size Width Type ---------------------------------------------------------- 0 0x0000000018000000 0x0000000000100000 32 MEM u-boot=> pci regions 00 Buses 00-01 # Bus start Phys start Size Flags 0 0x0000000000000000 0x000000001ff80000 0x0000000000010000 io 1 0x0000000018000000 0x0000000018000000 0x0000000007f00000 mem 2 0x0000000040000000 0x0000000040000000 0x0000000016000000 mem sysmem 3 0x0000000058000000 0x0000000058000000 0x00000000a8000000 mem sysmem 4 0x0000000100000000 0x0000000100000000 0x00000000c0000000 mem sysmem u-boot=> pci header 00.00.00 vendor ID = 0x16c3 device ID = 0xabcd command register ID = 0x0007 status register = 0x0010 revision ID = 0x01 class code = 0x06 (Bridge device) sub class code = 0x04 programming interface = 0x00 cache line = 0x08 latency time = 0x00 header type = 0x01 BIST = 0x00 base address 0 = 0x18000000 base address 1 = 0x00000000 primary bus number = 0x00 secondary bus number = 0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x10 IO limit = 0x00 secondary status = 0x0000 memory base = 0x1820 memory limit = 0x1810 prefetch memory base = 0xfff0 prefetch memory limit = 0x0000 prefetch memory base upper = 0x00000000 prefetch memory limit upper = 0x00000000 IO base upper 16 bits = 0x0000 IO limit upper 16 bits = 0x0000 expansion ROM base address = 0x18100000 interrupt line = 0xff interrupt pin = 0x01 bridge control = 0x0000 u-boot=> pci header 01.00.00 vendor ID = 0x1b4b device ID = 0x2b42 command register ID = 0x0006 status register = 0x0010 revision ID = 0x11 class code = 0x02 (Network controller) sub class code = 0x00 programming interface = 0x00 cache line = 0x08 latency time = 0x00 header type = 0x00 BIST = 0x00 base address 0 = 0x1810000c base address 1 = 0x00000000 base address 2 = 0x1820000c base address 3 = 0x00000000 base address 4 = 0x00000000 base address 5 = 0x00000000 cardBus CIS pointer = 0x00000000 sub system vendor ID = 0x0000 sub system ID = 0x0000 expansion ROM base address = 0x00000000 interrupt line = 0xff interrupt pin = 0x01 min Grant = 0x00 max Latency = 0x00

1. Increasing the number of threads. Make sure the Parallelism variables located on conf/local.conf BB_NUMBER_THREADS: indicating how many task bitbake should run in parallel PARALLEL_MAKE: indicating how many processes make should run in parallel are not commented and with correct values. The script  setup-enviroment  automatically sets these equal to the number of CPU cores. You can double this value if you want but there is no significant speed's gain. 2. Having a local repository on the server. When baking an image, one of the first steps for each recipe is to fetch the source code (from git repos, tarballs, etc); it makes sense to reuse this data for future builds and also share it with other server's users. You can indicate bitbake to look first at a local repo (file://) on your conf/local.conf file SOURCE_MIRROR_URL ?= "file:///opt/yocto/download/" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" # BB_NO_NETWORK = "1" Just make sure the download folder has read access for all users (chmod a+r /opt/yocto/download/)

  IMX6 SL boot process is described in Chapter 8 (System Boot) of the Reference Manual. Shortly, the loading boot data from boot SD card is performed in two stages : first read IVT, DCD, then read executable code, using the Boot Data Structure.    At first, boot ROM copies 4K byte (containing IVT and DCD ) from sector 0 of the boot SD card to internal buffer in OCRAM, located in reserved area (0x00900000 - 0x00907000). This area must not be used by user application.   Then, “after checking the Image Vector Table header value (0xD1) from Program Image, the ROM code performs a DCD check. After successful DCD extraction, the ROM code extracts from Boot Data Structure the destination pointer and length of image to be copied to RAM device from where code execution occurs”.   The IVT contains field entry - absolute address of the first instruction to execute from the image.   Note : according to Figure 8-3 (Internal ROM and RAM memory map), only OCRAM Free Area (68KB) from 0x00907000 till 0x00918000 may be used by user’s application.   The attachment contains SD-bootable example.

    Gigabit Ethernet should be one of most beautiful features in our imx6 platform which will bring more colorful dreams to many customers. But recently,many people responsed that there were great performance gaps between using Android and Linux. Now let me give an exploration here.     Same hardware, same kernel, different performance,why?     In linux, its data throughput can reach 400Mbps.In JB, it can only get to 200Mbps.     From the below info, we can see it should be related with frames dropping.      root@android:/ # busybox ifconfig eth0      eth0      Link encap:Ethernet  HWaddr 00:04:9F:02:6C:E1                inet addr:192.168.0.100  Bcast:192.168.0.255  Mask:255.255.255.0                inet6 addr: fe80::204:9fff:fe02:6ce1/64 Scope:Link                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                RX packets:7382672 errors:71828 dropped:789 overruns:71828 frame:71828                TX packets:4147006 errors:0 dropped:0 overruns:0 carrier:0                collisions:0 txqueuelen:1000                RX bytes:2568845018 (2.3 GiB)  TX bytes:284789020 (271.5 MiB)      In TCP stack, there are three buffers involved in iperf test case:tcp_mem; tcp_rmem; tcp_wmem.      All of them are described by three variables which will influence a lot for iperf test result.      In linux,I got a snapshot for them:      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_mem      18240      24320     36480      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_rmem      4096       87380     778240      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_wmem      4096       16384     778240      In Android,I also got them to compare to:      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_mem      9285      12380     18570      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_rmem      4096       87380     396160      root@sabresd_6dq:/# cat /proc/sys/net/ipv4/tcp_wmem      4096       16384     396160      The tcp_mem varibles define how the TCP stack should behave in kernel memory management.The first value tells the kernel the low threshold. The second value tells the kernel at which point to start pressuing memory usage down. The third one tells the kernel how many memory pages it may use maximally. If it is reached,TCP streams and packets start geting dropped until to a safe level.      In tcp_rmem, the first value defines the minimum receive buffer for each TCP connection and this buffer is always allocated to a TCP socket.The second one defines the default receive buffer size. The third one specifies the maximum receive buffer that can be allocated for a TCP socket.      In tcp_wmem, three varibles also be given to describle the TCP send buffer for each TCP socket.      We can check how these values come from in kernel code.There is an algorithm in kernel_imx/net/ipv4/sysctl_net_ipv4.c +450.     limit = nr_free_buffer_pages() / 8;     limit = max(limit, 128UL);     sysctl_tcp_mem[0] = limit / 4 * 3;     sysctl_tcp_mem[1] = limit;     sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2;     /* Set per-socket limits to no more than 1/128 the pressure threshold */     limit = ((unsigned long)sysctl_tcp_mem[1]) << (PAGE_SHIFT - 7);     max_wshare = min(4UL*1024*1024, limit);     max_rshare = min(6UL*1024*1024, limit);     sysctl_tcp_wmem[0] = SK_MEM_QUANTUM;     sysctl_tcp_wmem[1] = 16*1024;     sysctl_tcp_wmem[2] = max(64*1024, max_wshare);     sysctl_tcp_rmem[0] = SK_MEM_QUANTUM;     sysctl_tcp_rmem[1] = 87380;     sysctl_tcp_rmem[2] = max(87380, max_rshare);      From the above algorithm, we can see tcp_mem,tcp_wmem[2],tcp_rmem[2] all related with nr_free_buffer_pages() which stands for amount of free RAM allocatable within ZONE_DMA and ZONE_NORMAL.      So here, we can find the root cause of performance gap between Android and Linux. There is big gaps in free RAM while running different OS. In fact, in android, Google has introduced one mechanism to tune these values through propertity. Now we are using default AOSP's values, you can refer to them in device/fsl/imx6/etc/init.rc.For wifi and Ethernet, they are both using net.tcp.buffersize.wifi. # Define TCP buffer sizes for various networks #   ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax,     setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208     setprop net.tcp.buffersize.wifi    524288,1048576,2097152,262144,524288,1048576     setprop net.tcp.buffersize.lte     524288,1048576,2097152,262144,524288,1048576     setprop net.tcp.buffersize.umts    4094,87380,110208,4096,16384,110208     setprop net.tcp.buffersize.hspa    4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hsupa   4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hsdpa   4094,87380,262144,4096,16384,262144     setprop net.tcp.buffersize.hspap   4094,87380,1220608,4096,16384,1220608     setprop net.tcp.buffersize.edge    4093,26280,35040,4096,16384,35040     setprop net.tcp.buffersize.gprs    4092,8760,11680,4096,8760,11680     setprop net.tcp.buffersize.evdo    4094,87380,262144,4096,16384,262144 I tried to change the above values but unfortunately got no obvious improvement.Hi,why???? so another topic,how tcp_mem and tcp_rmem cowork in kernel? In android, we only have way to tuning tcp_rmem or tcp_wmem settings but not tc_mem. Take "iperf -c" for example, tcp_rmem will be filled up according to the frequency of Gigabit ethernet clock. And then it will be repacked acoording to the size of tcp_mem.If tcp_mem is smaller, more times will be triggered and if it has exceeds the max value dropping frames will be triggered. Then retransport will be launched in TCP. At last, performance will downgrade. It is just like go surfing using Gigabit but with a rubbish notebook. You still can't enjoy good performance of Gigabit ethernet. Why kernel calculate tcp_mem like this in ipv4? Maybe they consider the balance between single high-bandwidth and multiple connections. You can imagine if we change the tcp_mem to use a solid big value, it may cause the board deny connections because of a lack of memory allocation in tcp init. Here I will give out several method to improve our android ethernet performance. Enlarge your memory size in board design phase.      I have double checked it by testing in our SabreAuto board whose memory is 2G whose download speed can reach to 270 Mbps about 50Mbps over Sabresd. Try to use older version android, if you can use ICS, you can abandon JB4.3. Compared with newer android version, old version will take less memory and there will leave more free memory to use. Using ICS, we can reach 380 Mbps downloading while in JB4.3, it can only get to 210 Mbps. If you are using sabresd's Gigabit ethernet for a very important case, you can balance it if you can throw other memory eaters like GPU. I have checked it if we disable GPU, the performance can reached to 340 Mbps in JB4.3 with about 50% improvement. Change tcp_mem algorithm to enlarge its max value threshold. Like you can change  "sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 2" to "sysctl_tcp_mem[2] = sysctl_tcp_mem[0] * 3" above. You can see there won't be framedropping any more. Or you can also refer to How To: Network / TCP / UDP Tuning to hard code it. But like its author said in it, it is not recommended for those support multiple users or multiple connections. for it maybe cause the board to deny connections because of a lack of memory allocation. Tune tcp_rmem and tcp_wmem through the following patches in android. you will get bidirectional 320Mbps. But if you use ifconfig tool to set static ip you will not get these parameters set. For AOSP's framework only support DHCP now. For this case, you can manually echo these parameters in console before doing test.                Gerrit Code Review                Gerrit Code Review Change kernel's scheduler policy config.      Disable CONFIG_FAIR_GROUP_SCHED and only enable CONFIG_RT_GROUP_SCHED will contribute some enhancement.      With the above changes, I have tested on Sabresd RevC1 using android4.3GA, the bidirection speed can both reach 390~400Mbps.

some customers doesn't have any issue on old bsp, but have bring up issue on new 6.1 bsp, this article is about this and how to fix this

  NXP的OpenWRT方案：连接未来的智能网络体验   在数字化时代，智能家居、物联网等概念正不断演进，而要实现这些愿景，一个强大而高效的网络基础设施变得至关重要。OpenWRT以其开源自由、高度可定制和卓越稳定性，成为引领未来网络发展的关键一环。NXP作为全球领先的半导体技术创新公司，以其在嵌入式系统和通信领域的卓越技术积累，推出的基于OpenWRT的智能网络解决方案，为蓬勃发展的智能家居、物联网赋能。本文将介绍NXP公司芯片对OpenWRT方案支持的现状及获取途径，为读者应用OpenWRT去构建全新的下一代网络构建坚实的基础。 1、OpenWRT的独特特性 1.1、开源自由的崇高价值 OpenWRT以其开放源代码的本质脱颖而出。用户享有无限的自由，可以自由获取、修改和分享源代码，释放出创新的巨大潜力。这种开放性既推动了技术的不断进步，也使用户能够更主动地掌控网络的方向，也节约了用户的成本。 1.2、稳定可靠的网络基石 建立在成熟的Linux内核之上，OpenWRT经过长时间的演化和精细调整，确保系统的出色稳定性。这意味着更少的网络故障、更长的设备使用寿命，为各类网络需求提供了坚实的支撑。这一特性使得OpenWRT成为构建可靠家庭网络的理想选择，用户不用担心网络不稳定或崩溃的问题。 1.3 强大的软件包管理 OpenWRT引以为傲的软件包管理系统给用户带来了极大的灵活性。用户可以根据需求自由安装、更新和卸载各类应用程序和服务，从而实现网络环境的高度个性化，实现更智能的网络体验。OpenWRT允许用户安装各种网络服务和应用程序，如VPN、代理服务器等，以满足特定的网络需求。这为用户提供了更大的自由度，使他们能够创建符合个人或家庭需求的网络环境。 1.4 强大的社区支持 OpenWRT庞大的社区是其强大动力的源泉。用户可以在社区中交流心得、解决问题，甚至参与到项目的开发中。这种协作精神推动了OpenWRT的不断创新和进步。   2、NXP OpenWRT方案的应用 2.1 智能家居生态系统的构建 NXP OpenWRT方案与NXP Matter方案无缝结合为用户提供了构建智能家居生态系统的理想平台。通过其强大的定制能力，用户可以轻松连接、管理和控制各类智能设备，打造一个高度智能化的家居环境。该方案完整集成了NXP的Bluetooth和WIFI的芯片驱动，如：IW612， 88W9098， 88W8997等。 用户只需勾选相应的驱动即可轻松构建一个基于OpenWRT的Matter的OpenThread Border Router （OTBR）或者Zigbee Bridge。   2.2 定制化的网络服务 NXP OpenWRT方案支持各类网络服务和应用程序的定制安装。用户可以根据个人需求，轻松创建个性化的网络服务，如VPN、代理服务器，家庭路由器或网关等，实现更灵活的网络体验。 2.3 高清晰度视频流的传输 智能家居中高清晰度视频流的传输对网络性能提出了更高的要求。NXP OpenWRT方案通过其卓越的网络性能，结合NXP的工业级IP Camera方案， 确保用户能够流畅地享受高清视频流，为家庭娱乐带来更为优质的体验。 2.4 智能安防系统的构建 安防系统是不可或缺的一部分。NXP OpenWRT方案通过其高级网络安全功能，为用户打造了更可靠、更智能的安防系统，提高家庭的安全性。 3、NXP对OpenWRT的支持现状 基于OpenWRT众多优点及广阔的应用场景，NXP也很早就对OpenWRT实现了适配。不但实现了全部Layerscape系列处理器对OpenWRT的支持，目前主流的IMX处理器也得到了支持。具体支持的IMX平台及细节如下所示： Processor and Board Support ARMv8                                             ARMv7       I.MX93EVK                                •      I.MX6ULL       I.MX8MPlus       I.MX8MMini       I.MX8MNano       I.MX8MQuad OpenWrt Version       Based on OpenWrt v23.05 from mainline (tag: v23.05.0-rc1) Toolchain: ARMV8: gcc-11.3, binutils-2.37 ARMV7: gcc-12.3, binutils-2.40 U-Boot Boot Loader       IMX LF release, tag: lf-5.15.71-2.2.1 v2022.04 Linux Kernel       OpenWrt kernel 5.15.114 based on IMX SDK release kernel v5.15.71_2.2.1 Firmware       firmware-imx-8.18       firmware-sentinel-0.5.1 Main Features       Squashfs rootfs support on SD card.       Supported CLI and web configuation.       U-Boot Boot Loader - U-Boot: lf-5.15.71-2.2.1. - Arm Trusted firmware (TF-A) integration. - Boot from SDHC       Linux Kernel Core - Linux kernel 5.15.114 - Cortex-A53 (AARCH64), little endian for imx8m platform - Cortex-A55 (AARCH64), little endian for imx93 platform - Cortex-A7, little endian for imx6ull platform - 64-bit effective kernel addressing [Cortex-A53/A55]       Linux Kernel Drivers - SDIO 3.0 / eMMC5.1 - USB 3.0/2.0 Dual-Role with PHY type C - 32-bit LPDDR4 - 2x Gigabit Ethernet with AVB, IEEE 1588, EEE   and 1x w/ TSN - PCIe Gen 3 + WIFI - CAN FD - Dual-ch. QuadSPI (XIP) or 1x OctalSPI(XIP) - RTC Licensing       The majority of the software included in the OpenWrt release is licensed under a form of open source license (e.g. GPL, BSD).       Some software is licensed under the NXP EULA license. 4、如何开始部署和使用OpenWRT？ 如果想体验Layerscape系列芯片的OpenWRT强大功能，请从OpenWRT官方下载，即：https://git.openwrt.org/openwrt/openwrt.git。Layerscape的OpenWRT支持代码已经全部集成到了OpenWRT官方代码库。 此处以IMX8MMini-EVK为例说明OpenWRT在IMX平台的部署步骤，编译环境为Ubuntu22.04。 4.1 从github.com上获取源码 https://github.com/nxp-imx/imx_openwrt Tag: imx_v23.05_v5.15.114 4.2 编译，安装，配置OpenWRT $ ./scripts/feeds update -a; ./scripts/feeds install -a; cp config.default .config; make -j $ sudo dd if=/mnt/tftpboot/imx8/matter_20230908/openwrt-imx-imx8-imx8mmini-squashfs-sdcard.img of=/dev/sdX bs=1M && sync 这样就有生成了一个可以SD卡启动的OpenWRT了启动盘了。 可以直接用SD卡来启动体验OpenWRT. 更多的编译帮助请参考源代码中的README文件：target/linux/imx/README。 4.3 配置和个性化 用户可通过Web界面或SSH访问OpenWRT设备，开始配置和个性化网络环境。包括设置网络规则、安装软件包等，确保设备按照个人需求运行。下图为安装删除软件的界面。是不是很简单，很方便！       4.4 遇到问题怎么办？ 首先可以到OpenWRT社区这个充满活力的地方获得支持。 当然也可以分享自己的开发或使用经验，甚至参与到项目的开发中。这个开放的社区为用户提供了更多学习和发展的机会，共同推动OpenWRT不断向前。 还可以参与到NXP官方社区https://community.nxp.com/t5/i-MX-Processors/bd-p/imx-processors 进行提问和技术分享。有专业的工程师为您排忧解难。NXP OpenWRT期待您的参与！   免责声明 此OpenWRT发布是NXP系统工程倡议的一部分，不属于NXP为其MPU平台的Linux基础支持策略。NXP不对本发布及其后续版本的质量负责，包括添加对新平台的支持，这完全由系统工程团队自行决定。对于具体需求或问题，请通过以下电子邮件地址联系NXP的系统工程团队：“[email protected]”.

Environment BSP: L6.1.22_2.0.0​ Platform: i.MX93 Links:  https://github.com/NXP/swupdate-scripts https://github.com/nxp-imx-support/meta-swupdate-imx   The AN13872 provides us the swupdate yocto layer, swupdate-scripts and test steps, but there is still much to add. The purpose of this knowledge base is to provide customized advice. 1.How to port meta-swupdate-imx to any yocto version you want? As meta-swupdate-imx only provide kirkstone version, we can upgrade or degrade it based on this version. We will take L6.1.22_2.0.0​ porting steps as an example. 1.1 Download Yocto layer  cd imx-yocto-bsp/sources git clone https://github.com/sbabic/meta-swupdate.git -b mickledore git clone https://github.com/nxp-imx-support/meta-swupdate-imx.git 1.2 Modify  Yocto layer  imx-yocto-bsp/sources/meta-swupdate-imx/conf/layer.conf   You can find swupdate version in imx-yocto-bsp/sources/meta-swupdate/recipes-support/swupdate/ 1.3 Handle patches in meta-swupdate-imx/recipes-bsp/u-boot/files/ About patchs in sources/meta-swupdate-imx/recipes-bsp/u-boot/files/ and imx-yocto-bsp/sources/meta-swupdate-imx/recipes-support/swupdate/files/, you need use devtool to unpack uboot and swupdate into workspace and add changes manunally for development. CONFIG_ENV_OFFSET_REDUND=CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE   sources/meta-swupdate-imx/recipes-bsp/u-boot/u-boot-imx_%.bbappend 2.How to flash base image? Use uuu or dd command, just like common imx-image-xxx 3.swupdate-scripts porting suggestions 3.1 Partition table You can modify partition table refer the size of images. For different soc, the first offset is different. If you are porting i.MX8MP based on iMX8MM, the offset should be 32K.   3.2 Some errors 3.2.1 This error indicates that you need enlarge size of rootfs. e2fsck 1.45.5 (07-Jan-2020) The filesystem size (according to the superblock) is 887599 blocks The physical size of the device is 768000 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?    3.2.2 You need upgrade e2fsck verison. e2fsck 1.46.5 (30-Dec-2021) /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4 has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4: ********** WARNING: Filesystem still has errors ********** resize2fs 1.46.5 (30-Dec-2021) resize2fs: Filesystem has unsupported feature(s) (/home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_ass  solution: wget https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.47.0/e2fsprogs-1.47.0.tar.xz tar -xf e2fsprogs-1.47.0.tar.xz cd e2fsprogs-1.47.0/ ./configure make -j16 sudo make install   3.2.3 mtools /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 58: mdir: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 68: mdir: command not found solution: sudo apt-get install mtools

LTIB does not support X11 acceleration, since the packages are too old. Ubuntu 11.10 prebuilt image part of i.MX6 BSP has Xorg version 1.10.4. Yocto 1.4 has Xorg version 1.11.4. This document is based on Yocto 1.4.1 yocto and Freescale BSP 3.5.7 Alpha release. Few simple steps to enable 1.14.0. 1. Let us consider your Yocto directory is  $(rootfs_builder) 2. Edit vi sources/meta-fsl-arm/conf/machine/include/imx-base.inc      PREFERRED_VERSION_xserver-xorg_mx6 = "2:1.14.0" 3.Edit vi sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_3.5.7-1.0.0.bb      SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-viv-${PV}.tar.gz \            file://Makefile-fix-cross-compile.patch \                    file://0001-add-compat.h.patch" 4. Copy the attached Makefile-fix-cross-compile.patch into sources/meta-fsl-bsp-release/imx/meta-fsl-arm/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/. 5. In the build directory, delete the tmp directory. Otherwise there will be build errors (I did not found easy way) 6. bitbake fsl-image-x11 7. Now the image is ready to flash. 8. Boot the board with the newly built image. 9. Check the Xorg version log in /var/log/Xorg.0.log. It will be 1.14.0. 10. Before executing any of the X11-EGL application, export VIV_DESKTOP=0 to the terminal. You can see the application running. There are some known issues related to performance in 3.5.7 Alpha release.

ADB ADB is a tool for Android debugging. With ADB, you can install applications from you PC, copy files to/from your device, access console. You can access your device using an USB Cable, or through network (using an IP address). You can take ADB from SDK [1] or inside <my_android>/out/host/linux-x86/bin/adb I cannot see my device First checkpoint must be for ADBD. It´s the ADB daemon, and if it´s not running on your device, you will not be able to access it. Install and configure any USB driver [2] [3] Double check connection (USB cable, ethernet) Double check if debugging is on Double check if USB config is right (see how on User Guide) Tips and Tricks Turning on Remember to turn debugging mode on: Settings->Applications->Development->USB debugging No Permission When you get "no permissions" from ADB, you need to start server with your root user: $ sudo /usr/share/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions $ sudo /usr/share/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device $ sudo /usr/share/android-sdk-linux_86/tools/adb kill-server $ sudo /usr/share/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo /usr/share/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device $ sudo /usr/share/android-sdk-linux_86/tools/adb shell # ls dev etc

The document in attachment describes how to learn System Boot Flow of Linux by code using Trace32. The hardware platform is i.MX6Q SABRE and the software in PC is Trace32. Contents 1. Introduction 2. Hardware Connection 3. Serial Connection Setup 4. U-boot Directory Setup 5. Trace32 Installation & U-boot Debugging

gst-launch is the tool to execute GStreamer pipelines. Task Pipeline Looking at caps gst-launch -v  <gst elements> Enable log gst-launch --gst-debug=<element>:<level> gst-launch --gst-debug=videotestsrc:5 videotestsrc ! filesink location=/dev/null

The i.MX Android N7.1.1_1.0.0 release is now available on Web Site (i.MX6 BSP Updates and Releases -> Android).   Files available: # Name Description 1 android_N7.1.1_1.0.0_docs.tar.gz i.MX Android N7.1.1_1.0.0 BSP Documentation 2 android_N7.1.1_1.0.0_source.tar.gz Source Code of Android N7.1.1_1.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo  i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.1_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.1_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.1_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.1_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.1_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.1_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 android_N7.1.1_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.1_1.0.0   Supported Hardware SoC/Boards: MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform MX 6SoloLite EVK platform MX 6SoloX SABRE-SD board and platforms MX 6SoloX SABRE-AI board and platforms MX 7Dual SABRE-SD board and platform   Changes: Compared to the M6.0.1_2.1.0 release, this release has the following major changes: Upgraded the Android platform version to Android 7.1. Upgraded the U-Boot and Linux Kernel Code base from the L4.1.15_1.0.0 release to the L4.1.15_1.2.0-ga release. Added support for the i.MX 7Dual SABRE-SD board. Upgraded the GPU driver from 5.0.11p8 to 6.2.0.p2.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.

ccache is a C compiler cache. ccache can save a large amount of compilation time on recurring builds and builds restarted from a clean repository after make clean or git clean. It is well suited for e.g. u-boot and Linux compilation. Caching the host compiler Caching "native" builds is easily done by adding in the beginning of your $PATH a special directory, which contains links to ccache to override the usual compiler. On e.g. Debian this directory is readily available as /usr/lib/ccache, So you can do:   $ export PATH="/usr/lib/ccache:$PATH" Typical links found in this folder are:   c++ -> ../../bin/ccache   cc -> ../../bin/ccache   g++ -> ../../bin/ccache   gcc -> ../../bin/ccache etc... Caching the cross compiler Caching cross-compiled builds can be done in the same way as native builds, provided you create links of the form e.g. arm-linux-gnueabihf-gcc pointing to ccache. But there is an even more convenient way for those projects, which rely on a $CROSS_COMPILE environment variable (as is the case for e.g. u-boot and Linux). You can prefix the cross compiler with ccache there in e.g. the following way:   $ export CROSS_COMPILE="ccache arm-linux-gnueabihf-" Monitoring efficiency Now that your builds are cached, you might want to see how much is "spared" with this technique. ccache -s will tell you all sorts of statistics, such as:   cache directory                     /home/vstehle/.ccache   cache hit (direct)                 10852   cache hit (preprocessed)            3225   cache miss                         19000   called for link                    33267   called for preprocessing            9463   compile failed                         3   preprocessor error                     1   couldn't find the compiler           117   unsupported source language          921   unsupported compiler option         2167   no input file                      31681   files in cache                     51694   cache size                           1.3 Gbytes   max cache size                       4.0 Gbytes Here you see a somewhat typical 50%/50% hit/miss ratio. Enjoy! See Also ccache is usually supported natively by build systems, such as Buildroot or Yocto.

This documents describes how to add the NFC support to i.MX8M mini evk running Android Pie. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 VEN signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on Android P9.0.0 Pie (P9.0.0_1.0.0, 4.14 kernel) i.MX software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/docs/en/supporting-information/android_p9.0.0_1.0.0-ga_docs.zip. Just flash the demo image (downloaded from here:https://www.nxp.com/lgfiles/updates/NFC/ANDROID_P9-0-0_PN7150_IMAGE_8MMEVK.zip) following guidelines from i.MX_Android_Quick_Start document (part of Android P9.0.0_1.0.0 Documentation package mentioned above). The NFC support is then included in the device settings, as shown in below screenshot of the device: Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger a sound notification: Unfortunately the Android demo image doesn't embed a web browser, so it won't be automatically open when the NFC tag content (an URL to the demo kit web page) is read. Otherwise (if a web browser is installed) you could see such page opening on the device: Adding PN7150 support to imx-android-pie release: If you wish to add PN7150 support to your imx-android-pie environment, just apply the patches (imx-p9.0.0_1.0.0-ga_pn7150_patches.tar.gz file attached) from the ${MY_ANDROID} source code root folder (refer to i.MX_Android_User_Guide document part of Android P9.0.0_1.0.0 Documentation package mentioned above).  $ patch -p1 -d device/fsl/ <device_fsl.patch  $ patch -p1 -d packages/apps/Nfc <packages_apps_Nfc.patch  $ patch -p1 -d hardware/nxp/nfc <hardware_nxp_nfc.patch  $ patch -p1 -d vendor/nxp <vendor_nxp.patch  $ patch -p1 -d vendor/nxp-opensource/kernel_imx/ <vendor_nxp-opensource_kernel_imx.patch When building, the PN7150 support will then be included to the android image, as shown in the demo image described above. Reference: This porting have been done (demo image and patches creation) following guidelines provided in AN11690_NXP-NCI_Android_Porting_Guidelines document.