I am trying to learn the kernel customization and for this I have target OnePlus 6T device. I am able to compile the kernel source code on my Ubuntu 18 with the following steps:
Download latest dtc from https://packages.ubuntu.com/cosmic/a...piler/download and install it.
Clone kernel source code: git clone https://github.com/OnePlusOSS/androi...lus_sdm845.git
Clone ToolChain: git clone -b linaro-4.9-arm-linux-androideabi https://github.com/ArchiDroid/Toolchain prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-linaro-4.8
Open terminal at prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-linaro-4.9 and run: export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-android-
Navigate to kernel source code path in the same terminal.
export ARCH=arm64 && export SUBARCH=arm64
make clean
make mrproper
mkdir Out
make O=Out sdm845_defconfig
make O=Out DTC_EXT=dtc CONFIG_BUILD_ARM64_DT_OVERLAY=y DTC_EXT=dtc -j4
Following are the last lines of compilation:
CC drivers/media/platform/msm/broadcast/tspp.mod.o
CC drivers/media/platform/msm/dvb/adapter/mpq-adapter.mod.o
CC drivers/media/platform/msm/dvb/demux/mpq-dmx-hw-plugin.mod.o
GZIP arch/arm64/boot/Image.gz
CC drivers/soc/qcom/llcc_perfmon.mod.o
CC drivers/video/backlight/lcd.mod.o
CC net/bridge/br_netfilter.mod.o
LD [M] drivers/char/rdbg.ko
LD [M] drivers/media/platform/msm/broadcast/tspp.ko
LD [M] drivers/media/platform/msm/dvb/adapter/mpq-adapter.ko
LD [M] drivers/media/platform/msm/dvb/demux/mpq-dmx-hw-plugin.ko
LD [M] drivers/soc/qcom/llcc_perfmon.ko
LD [M] drivers/video/backlight/lcd.ko
LD [M] net/bridge/br_netfilter.ko
CAT arch/arm64/boot/Image.gz-dtb
make[1]: Leaving directory '/home/.../KernelCustomization/android_kernel_oneplus_sdm845/Out'
Now, the next step is to flash the image. I have rooted OnePlus 6T device and I am confused with the three image files generated after successful compilation i.e.
arch/arm64/boot/Image.gz-dtb
arch/arm64/boot/Image.gz
arch/arm64/boot/Image
I need a favour in:
What image can I use to flash on android device?
Is booting a image with TWRP is enough to flash kernel?
Found Google documentation
https://source.android.com/devices/bootloader/partitions-images
As per following lines from google documentation:
boot: The boot partition contains a kernel image and a RAM disk combined via mkbootimg. In order to flash the kernel directly without flashing a new boot partition, a virtual partition can be used:
kernel: The virtual kernel partition overwrites only the kernel (zImage, zImage-dtb, Image.gz-dtb) by writing the new image over the old one. To do this, it determines the start location of the existing kernel image in eMMC and copies to that location, keeping in mind that the new kernel image may be larger than the existing one. The bootloader can either make space by moving any data following it or abandoning the operation with an error. If the development kernel supplied is incompatible, you may need to update the dtb partition if present, or vendor or system partition with associated kernel modules.
I think I have to use arch/arm64/boot/Image.gz-dtb for flashing the kernel. My understanding is that Image.gz-dtb is a virtual image that can be used to flash only kernel on android.
Still, I am not able to figure out the correct step to flash it. I am wondering if I will do something wrong then I will break my device so I want to be sure before flashing that it will work.
Any help or guidance will be very helpful at this moment.
I found the steps that are needed to flash the custom kernel on android device i.e.
First we need to get the boot image of stock firmware we can get it by running following commands:
adb shell "ls -la /dev/block/platform/soc/1d84000.ufshc/by-name/" > MoreInfo\msm_partitions.txt
Note the boot partition name e.g. boot_a -> /dev/block/sde11 boot_b -> /dev/block/sde39
Missing steps to make boot.img with command dd command.
Download the latest Android Image Kitchen from this thread.
Run the following with the boot image: unpackimg.sh .img
Locate the zImage file and replace it with your kernel image (rename it to what came out of the boot image)
Run the following to repack: repackimg.sh
Flash the new boot image with fastboot or TWRP!
I need some more information on the missing steps. Actually the process written above is working on devices that has only one boot partition. Does any one know how can I flash my single kernel image on a device that has a/b partitioning?
Update:
I searched over the internet for A/B partitioning and I found that these are used for seamless updates i.e. One partition is active at a time and another partition which is inactive can be used to flash the update. On reboot, another partition will become active and One partition will become inactive. More Info: https://www.xda-developers.com/how-a...opment-on-xda/
If my understanding is true then I just need to follow following steps to find the correct image to be used at the first step of flashing the kernel:
fastboot getvar all | grep “current-slot”
dd if="path to boot of active slot" of=/sdcard/boot.img
Continue with boot.img and flash the kernel with above written steps for flashing a kernel.
Anyone who has this knowledge, please confirm. I will be very thankful to you.
A/B OTA update
Firstly, you need to confirm whether your phone is A/B OTA update or not by following command
fastboot getvar slot-count
If the command returns '2', then your phone supports A/B OTA update which means you have two boot
partitions 'boot_a' and 'boot_b', otherwise, there should only be one partition 'boot'
boot image
The images you built (Image.gz-dtb) are just kernel images with device tree. They
are not enough for flashing to boot partition since there should be ramdisk and boot arguments combined.
The ramdisk content contains normal boot binaries for non-A/B OTA system or recovery binaries for
A/B OTA system. You need to find official ramdisk images and combine with your kernel image. Normally
mkbootimg will be used to create boot image in AOSP android.
Flashing
fastboot flash boot boot.img
This works on both A/B and non-A/B system since image will be flashed to default active partition (boot_a
is by default if you do not have OTA or using 'fastboot set_active' to change it)
On A/B system, you can also use 'fastboot getvar current-slot' to get active slot and specific flash
partition 'fastboot flash boot_a boot.img' or 'fastboot flash boot_b boot.img'
XDA provides scripts to flash kernel images (Image.gz-dtb) with following steps:
a. Dump boot.img from your phone
b. Extract ramdisk.img from boot.img
c. Combine Image.gz-dtb with ramdisk.img to new boot.img
d. Flash new boot.img to boot partition
https://forum.xda-developers.com/oneplus-6t/development/kernel-holydragon-t3878107
provides customized kernel and flash scripts, you should check and find your suitable way to flash your kernel image.
Related
I am trying to run Docker on Android, using a Pixel 3a XL rooted, running stock rom but flashed a custom kernel. I need to enable cpu, cpuset, memory, io, and pid controllers in cgroupv2. After enabling them in menuconfig and flashing the kernel, the script used to check shows only pid available under cgroupv2 controllers.
What do I need to do besides enabling these options in the kernel’s menuconfig? Did I maybe not enable all the necessary options?
If I run
cat /sys/fs/cgroup/cgroup.controllers
it only returns "pids".
With the current state, when I run docker I get a warning for each item,
WARN: Unable to find cpu controller”
and
error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE)
As I understand it, these options may be mounted with cgroupv1 and this is why they do not show up?
I am using this guide: https://gist.github.com/FreddieOliveira/efe850df7ff3951cb62d74bd770dce27
and these are the options I enabled in my kernel using menuconfig: https://wiki.gentoo.org/wiki/Docker
From the config I flashed in my kernel:
CONFIG_CGROUPS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_CGROUP_CPUACCT=y
I flash the kernel by flashing the Image.lz4-dtb file that is created after building the kernel.
Here is a photo after running the script to check if kernel options are all enabled. Am trying to change these from missing to available/enabled.
photo
The solution was to run: sudo mount -t tmpfs cgroup_root /sys/fs/cgroup which created directories for each of the cgroup resources and allowed Docker to run.
Useful is section 2.1:
https://android.googlesource.com/kernel/common/+/android-trusty-3.10/Documentation/cgroups/cgroups.txt
Background: I am working with a Pixel 4, build QQ2A.200501.001.B2, which is Android 10. When I build the kernel from the official sources and flash it, the touchscreen, wlan and other features do not work. I tracked this down to the fact that the kernel modules in /vendor/lib/modules do not get updated, thus the new kernel can't load any of them. I tried flashing both only boot.img and the entire AOSP, same issue, they don't get updated. I can workaround this by manually pushing the kernel modules I built to the device and manually insmoding them in the right order.
So my questions are:
Why don't they get updated in the first place?
How can I update them along with the kernel when I flash?
Alternatively, how can I permanently update them after flashing?
Surely there must be an "official" way to do this? How are the kernel modules normally deployed?
Some notes:
I can't push them to /vendor/lib/modules because I can't remount /vendor writable:
flame:/ # mount -o rw,remount /vendor
'/dev/block/dm-5' is read-only
Disabling dm-verity doesn't seem to help.
I noticed that the AOSP source contains all the modules that are in /vendor/lib/modules, in the same place where it takes the kernel image form (in my case that's device/google/coral-kernel). So naturally, I tried replacing the modules there with the ones I built, but after building and flashing, I see that /vendor/lib/modules still contains the old modules.
The AOSP docs say that boot.img does not contain the ramdisk anymore, it's now in the system partititon. Also, OverlayFS is used and one should use a "vendor overlay" to update files there, if I read it right. However, on my device, there is no product/vendor_overlay directory like the docs say, only product/overlay/. I'm also not sure if this is the right way to tackle this or how I would go about creating such an overlay in my case.
Thanks
Ok. Several questions, several answers:
Why don't they get updated in the first place?
Because they are expected to be in /vendor/lib/modules, and when you recompile a kernel you're only creating the kernel binary which goes into the boot.img.
How can I update them along with the kernel when I flash?
You could compile the modules into the kernel. That makes your kernel a bit bigger, but relieves you from the need to insert these modules.
Alternatively, how can I permanently update them after flashing?
You can indeed modify /vendor like you've tried - but not the DM-verity block device (/dev/block/dm-5 in your case) - the underlying partition (/dev/block/sd?#, something, which you can see if you look at the links from /dev/block/by-name/vendor).
CAVEAT: This will cause dm-verity to fail mounting /vendor unless you correctly disable dm-verity!
Another avenue to try for testing: Linux kernel modules have a strict vermagic requirement (in simpler terms, the module string must match the 'uname -r' of the kernel, to ensure that critical kernel structures have not been modified). If you don't change the kernel magic (VERSION, PATCHLEVEL, SUBLEVEL and EXTRAVERSION from Makefile) (or "fake" them to the original kernel version your device came with) the modules should load.
Alternatively, how can I permanently update them after flashing?
You can use below command to disable verity :
adb root
adb disable-verity
adb shell sync
adb reboot
then push the .ko(s) to /vendor/lib/modules/ :
adb root
adb remount
adb push *.ko /vendor/lib/modules/
adb shell sync
adb reboot
We have an development board that has been run Yocto system. and we want it to run android system, we already has compiled android image with Yocto kernel that has android's some patch.
We don't know how to flash the android image (such as system.img boot.img and recovery.img and so on) to the development board because of the Yocto system partition different with android system.
we can use fastboot tool to flash Yocto system to EVB.and we want to know:
How to partition eMMC that we can use fastboot tool to flash android system. Do we need to modify Little Kernel code ? and how to modify it in Yocto system.
How to we boot the android system up?
It would be appreciated if you offer any useful information.
Thanks
How to partition eMMC that we can use fastboot tool to flash android system.
You'll need a tool that can partition the eMMC. Considering you are using yocto your best bet is gptfdisk package. gptfdisk recipe is at path poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.0.bb. gptfdisk provides following text-mode partitioning tools
gdisk,
cgdisk,
sgdisk,
fixparts
You can use one of these tools to recreate the partitions in the partition table.
and how to modify it in Yocto system.
Do IMAGE_INSTALL_append = " gptfdisk " in conf file to make the tools of this package part of your image.
How to we boot the android system up?
You'll need 3 partitions
system.img - goes in partition named system
boot.img - goes in system named boot
and recovery.img - goes in system named recovery
Each tool has a man page on Linux. You can read the manuals using man sgdisk, man gdisk, man cgdisk and man fixparts. Some example usages of sgdisk
sgdisk -p </dev/sda> - To print all partitions on the disk
sgdisk --delete=partnum </dev/sda> - Delete a partition. This action deletes the entry from the partition table
There is a lot of way to partition the eMMC, it depends on your system: via USB, sdcard, nfs, uboot...
I think you can have a look at the meta-variscite, especially in the scripts folder. They have flash scripts for Yocto poky images, and android image (on the same boards). They flash from the SDcard to the eMMC.
I ported these scripts for a use with uboot: I run the command ums mmc 0 to start mass storage mode via USB OTG, and on my PC I run an install script which use dd for erasing partitions, fdisk for creating partitions, mkfs to format my device connected by USB.
You can also use mmc part in uboot, but I never tested this option.
I've selected several of the trace tags and when I run the trace (from DDMS) I get the following output:
Unexpected error while collecting system trace. Unable to find trace start marker 'TRACE:':
error opening /sys/kernel/debug/tracing/options/overwrite:
No such file or directory (2)
error openi(cuts off the error here)
indeed there is no debug file in the kernel directory, but which mechanism will generate the necessary path?
It looks like your cellphone is running a boot(kernel) image that does not support systrace.
"error opening /sys/kernel/debug/tracing/options/overwrite: No such file or directory (2)"
This error message means adb daemon (the adb module running on device side) could not find /sys/kernel/debug/tracing/options/overwrite on your device's file system. systrace works over adb and communicates with kernel though sysfs nodes under /sys/kernel/debug/tracing. If these nodes are not exposed on you phone for whatever reason, systrace just will not work.
So you should first get a shell on your device using:
adb shell
Then browse to confirm if /sys exists at all and if /sys/kernel/debug/tracing exists.
If they are there which is extremely unlikely, you have to debug systrace.py to figure out how come systrace think the nodes were not there. Otherwise, you need to flash a different boot image which has systrace support, because sysfs is controlled by kernel(mostly by configurations at compile time) and init.rc , both of which are part of boot image.
Flashing a different boot image might involve unlocking/rooting the device. You probably have to go to fan sites like xdadeveloper for information and image. Another option is to download the source of kernel for your device, compile kernel and make the boot image yourself. Linux is under GPL thus manufacturer of your device is obligated to release the source code of the specialized kernel they use.
-NAM
http://www.willpromo.com
You may need to slightly modify the kernel image(boot.img). The following work find for me, just for your reference.
open terminal and enter: $adb shell
(1) $su (2) $mount -t debugfs none /sys/kernel/debug. Now you should be able to see many directories under /sys/kernel/debug/. (You may cd into /sys/kernel/debug to confirm this)
Enter: $dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/sdcard/boot.img to generate the boot.img kernel image from your device.
Use AndroidImageKitchen to unpack the boot.img and find the default.prop within Ramdisk folder. Then change ro.debuggable=0 to ro.debuggable=1. Repack the boot.img and flash boot it to your device.
Once the device boot, under terminal, enter: $adb root and message like: $restarting adbd as root may pop up. Disconnect the USB and connect again.
cd to the systrace folder, e.g. ~/androidSDK/platform-tools/systrace and use:
python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
Now you may able to generate your own systrace files.
I am not familiar with a Android kernel compile process.
But I encountered a problem recently, and it troubled me so much.
Here is the problem descrition:
Based on Android, I build customed images including boot.img, system.img and so on.
Then I need to flash those images to physical device in order to boot to Android Home Screen.
Before compiling those images files, I have set a new kernel command line:
CONFIG_CMDLINE="root=/dev/mtdblock2 rw init=/init console=ttyS0, 115200 mem=128M uard_dma android"
After compiling those images, I opened boot.img in vim and saw the following string in it:
"root=/dev/mtdblock2 rw init=/init console=ttyS0, 115200 mem=128M uard_dma android"
But when I flashed the boot.img into device, I got the different output like this:
**Kernel command line: console=ttyO2,115200n8 earlyprintk**
In other word, I set the kernel command line value, and it was wrote into boot.img, but when
flash boot.img into device, I got a different kernel command line value.
Has anybody ever encountered this problem and got it fixed?
Really appreciating your help.
Thanks advanced!
The bootloader will be passing a command line to the kernel.
For example if u-boot bootloader is used,
it will be contained in the u-boot variable bootargs
This can be verified at the bootloader prompt.
For example if the device is using u-boot bootloader.
Connect the device to your PC over a serial prompt.
Launch a serial emulator on your PC (minicom, teraterm, hyper-terminal).
Power-on the device.
Press any key to halt the device boot at the bootloader stage itself.
Now on the u-boot prompt enter the following command:
u-boot# printenv
This will list all the uboot-variables. Note the value of variable bootargs.
This can be modified by using the following command:
u-boot# setenv bootargs ''
To save this value across reboots use the following commmand:
u-boot# saveenv
Similar functionality is available in other bootloaders as well.