搜索到
51
篇与
的结果
-
Android dtbo(8) dtbo使用问题 1. fdt_overlay_apply报错FDT_ERR_NOSPACE问题之前在芯片A上实现dtbo功能，经测试后功能是正常的。但把同样的实现思路移植到芯片B上之后，一开始使用功能是正常的，但过了一段时间后，再添加时功能出现了一些异常。报错如下：dtbos to be applied: 1 Apply dtbo 1 0x262 (610) failed on fdt_overlay_apply(): FDT_ERR_NOSPACE Loading Kernel Image ERROR: image is not a fdt - must RESET the board to recover. FDT creation failed! hanging...### ERROR ### Please RESET the board ###报错FDT_ERR_NOSPACE，也就是fdt_overlay_apply时失败了。最终发现是要在fdt overlay前需要使用fdt resize命令重新调整下fdt的大小，然后再overlay就成功了。。。 -
-
-
-
在Android中使用kdump 1. 简介内核核心转储又成为 core dump，在 Unix/Linux 中，将主内存 “Main Memory” 称为核心 core, 这是因为在半导体作为内存材料前，便使用核心 “core” 表示内存。另外核心镜像 “core image” 就是内核作为一个内核线程执行时在内存中的内容。当内核线程发生错误或者收到特定信号而终止执行时，系统在借助某些工具的情况下，可以将核心镜像写入一个文件，以便后期调试问题之用，这个过程就是所谓的核心转储 “core dump”.目前主流的方法获得 core dump 是通过 kexec 工具，该工具当内核核心转储时，其他 CPU 夯住，kexec 工具会在一个预留 CPU 上重启一个精简的内核。当精简内核启动之后，可以通过一定的命令将 core 写入到指定的文件，该文件就是核心转储文件。当获得核心转储文件之后，可以使用 CRASH 等工具进行问题分析。1.当第一内核（生产内核）启动时预留一定大小的内存空间（reserved memory），第一内核启动完成后使用kexec工具将第二内核（捕获内核）和一个简易的initrd rootfs加载到预留的内存中，如下图。2.当生产内核发生crash时，会自动引导捕获内核启动，捕获内核只占用预留的内存，并且在捕获内核中可以通过/proc/vmcore文件获取到发生crash之前的所有内存数据，此时只需要拷贝vmcore到磁盘，便可完成内存转储工作。目前已知Kdump可以覆盖到的情况：系统发生crash系统发生Soft lockup注：由硬件导致的系统hang住，kdump目前没法覆盖到。2. 实现步骤下面主要记录一些流程，不会写的很细2.1 下载并编译kexec-tools在调试过程中，经常需要重启内核以还原现场，进而复现某些问题予以追踪解决. 由于每一次的内核启动，都会伴随着一次的 boot 自检. 但是，对于已经启动过的同一内核，重复的 boot 自检完全没有必要，且造成了资源浪费. 此外，有时候需要使用一个小内核来启动一个大内核. 在这两种需求下，kexec 应运而生，kexec 是一款可以让您重新启动到一个新 Linux 内核的快速重新引导功能部件，不再必须通过固件和引导装载程序阶段，从而跳过序列中最长的部分，大大减少了重启时间. 对企业级系统而言，Kexec 大大减少了重启引起的系统宕机时间. 对内核和系统软件开发者而言，Kexec 帮助您在开发和测试成果时可以迅速重新启动系统，而不必每次都要再经历耗时的固件阶段. 通用 linux 系统中可用通过源码编译的方式安装 kexec-tools 工具，开发者可以参考如下步骤:源码下载wget http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools.tar.gz编译（以ARM64为例）cd kexec-tools-VERSION ./configure ARCH=arm64 --build=x86_64-unknown-linux-gnu --host=aarch64-linux LDFLAGS=-static make make install2.2 修改当前内核配置正常运行的kernel，需要下面的config配置CONFIG_KEXEC=y CONFIG_SYSFS=y CONFIG_DEBUG_INFO=Y2.3 制作捕获内核和initramfs2.3.1 编译最小文件系统编译busybox，注意编译的时候进入menuconfig配置成静态编译，如何下载编译从网上找个就好了。编译完成后，在busybox根目录下会有一个_install的目录，该目录是编译好的文件系统需要的一些命令的集合。进入_install目录，先创建etc、dev等目录。#mkdir etc #mkdir dev #mkdir mnt #mkdir -p etc/init.d在_install/etc/init.d目录下新创建一个rcS文件，并写入如下内容：#! /bin/sh mkdir -p /proc mkdir -p /tmp mkdir -p /sys mkdir -p /mnt /bin/mount -a echo /sbin/mdev > /proc/sys/kernel/hotplug mdev -s将rcS文件的权限改为可执行权限，比如：chmod +x _install/etc/init.d/rcS在_install/etc目录新创建一个fstab文件，并写入以下内容：proc /proc proc defaults 0 0 tmpfs /tmp tmpfs nodev,nosuid 0 0 sysfs /sys sysfs defaults 0 0 debugfs /sys/kernel/debug debugfs defaults 0 0 在_install/etc目录新创建一个inittab文件，并写入以下内容：::sysinit:/etc/init.d/rcS ::respawn:-/bin/sh ::askfirst:-/bin/sh ::ctrlaltdel:/bin/umount -a -r在_install/dev目录下创建如下设备节点，需要root权限：$cd _install/dev $sudo mknod console c 5 1 $sudo mknod null c 1 32.3.2 编译kernel将上面的_install目录复制到kernel源码目录下面。通过menuconfig，配置initramfs，在initramfs source file中填入_install。制作捕获kernel可以裁掉一些不必要的配置，以减少内存的占用，但最好保留usb driver,以方便拷贝vmcore文件。必须包含下面两个配置：CONFIG_CRASH_DUMP=y CONFIG_PROC_VMCORE=y注意：1.关闭这两个configCONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=32 2.确保usb driver是编译进kernel的2.4 在uboot中添加bootargs使用下面的命令或者修改kernel command line，在kernel启动时为捕获内核预留内存，预留太少可能导致捕获内核启动有问题，根据自己的实际情况预留即可。可以通过开机log来判断预留内存是否成功。setenv bootargs $bootargs 'crashkernel=128M' saveenv2.5 加载捕获内核到预留内存使用kexec工具，首先要通过adb push,将编译好的kexec,Image,dtb文件push 到开发板中，然后使用下面的命令 kexec -p /vendor/etc/Image --dtb="/vendor/etc/xxx8421.dtb" --append="console=ttyS0,115200n8 earlycon init=/init rootfstype=ramfs rootwait 1 maxcpus=1 reset_devices"2.6 验证与测试使用 echo c > /proc/sysrq-trigger 命令触发kernel panic，打印完Call trace信息之后会引导捕获kernel启动.如果启动没成功，就根据log来解决就好了。ps:本人遇到的一个问题是，当时捕获内核有个默认的CMA配置，会reserve 32M内存，导致的启动失败。解决办法：在config把这个配置去掉就好了启动后，生成的vmcore文件在/proc/vmcore，将/proc/vmcore拷贝保存到其他地方以供后期分析，也可压缩后再进行拷贝。例如，拷贝到u盘/ # fdisk -l Disk /dev/mmcblk0: 7456 MB, 7818182656 bytes, 15269888 sectors 946 cylinders, 256 heads, 63 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/mmcblk0p1 0,0,2 1023,255,63 1 4294967295 4294967295 2047G ee EFI GPT Partition 1 has different physical/logical end: phys=(1023,255,63) logical=(266305,4,4) Disk /dev/sda: 29 GB, 30943995904 bytes, 60437492 sectors 3762 cylinders, 255 heads, 63 sectors/track Units: sectors of 1 * 512 = 512 bytes Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type /dev/sda1 * 0,32,33 1023,254,63 2048 60436479 60434432 28.8G c Win95 FAT32 (LBA) / # mount /dev/sda1 /mnt/ / # cp /proc/vmcore /mnt/ / # umount /mnt/关于分析该文件可以使用crash工具，这个后面还需要继续研究。参考：内核核心转储: Kdump with kexec and crash
-
-
-
-
-
