Related
Hi all,
I so wish I knew how to develop because I hate to ask, I would much rather do and share. But man Asus has posted the Kernel for JB and I would love for a good tweaked OC'ed Kernel. Sooooo, please!
Sadly there are no kernel developers for the 300t at the moment. Asus had all the kernel sources on the Asus website and i guess nobody tried to build their own.
Sent from my ASUS Transformer Pad TF300T using xda app-developers app
ASUS has removed the proprietary code from the kernel, you can download it
but it wont build until you remove references to the missing code then some
of the tablet hardware does not work. so you are left to reverse engineer the
missing code from the chip spec's and manual probing of the hardware.
EDIT: NVM finely got it to build, time to see what's not working.
untermensch said:
ASUS has removed the proprietary code from the kernel, you can download it
but it wont build until you remove references to the missing code then some
of the tablet hardware does not work. so you are left to reverse engineer the
missing code from the chip spec's and manual probing of the hardware.
Click to expand...
Click to collapse
Really ?
As far as I can tell the V10.4.2.9 kernel source from Asus website builds just fine (with one minor correction).
But perhaps I'm missing your point, sorry in that case.
My biggest problem so far is to successfully flash a custom kernel on JB custom ROM (ASU-JellyBean-Hydro 1.4.6).
This leads me to my actual question:
Anyone managed to successfully flash seanzscreams' modded kernel (Asu-JellyBean-HYDROKernel.zip)
on his excellent ROM ASU-JellyBean-Hydro 1.4.6 ?
As far as I can tell the entire kernel flash process seems to finish successfully (using TWRP 2.2.2.0)
but when checking kernel version in Settings it seems to be the same (stock) version as previously,
3.1.10-00003-g6293ea6 [email protected] #1 SMP PREEMPT Thu Aug 9 15:59:38 CST 2012
Looking forward for any ideas/tips.
(I know question better belongs in the Dev forum, but as I just registered at XDA I'm not allowed to post there.)
I got it to build using, tegra3_android_defconfig was trying the cardhu_defconfig before.
builds but does not boot :-<
untermensch said:
I got it to build using, tegra3_android_defconfig was trying the cardhu_defconfig before.
builds but does not boot :-<
Click to expand...
Click to collapse
OK, this indicates at least you have managed to get your custom kernel to run/load, very interesting.
Do you flash an update.zip using CWM/TWRP or using fastboot method sending blob to boot partition (LNX) ?
Care to share more details how you get from resulting zImage from build to something flashable ?
Something like this...
1. cp arch/arm/boot/zImage kernel.gz
2. repack-bootimg.pl kernel.gz ramdisk boot.blob.lnx
3. blobpack boot.blob LNX boot.blob.lnx
?
I am using the same scripts that I use to build the CWM-Touch.blob, I just replace
the stock kernel with the on I have built, then use fastboot to install the new recovery
it just stalls.
untermensch said:
I am using the same scripts that I use to build the CWM-Touch.blob, I just replace
the stock kernel with the on I have built, then use fastboot to install the new recovery
it just stalls.
Click to expand...
Click to collapse
Thanks, but I'm a bit confused...
How does kernel and recovery (CWM-Touch.blob) relate ?
I was of the impression that a recovery image is to be flashed to the recovery partition (SOS), e.g.,
fastboot.exe -i 0x0B05 flash recovery <blob>
...while kernel+ramdisk to boot partition (LNX), e.g.,
fastboot.exe -i 0x0B05 flash boot <blob>
Are the build scripts you mention publicly available and directions of where to look if that's the case ?
a recovery is just a kernel and ramdisk with the recovery executable.
the stock LNX and SOS kernel have the same md5 sum so it does not matter
which partition I test the kernel on, it was just convenient for me to test it on
the SOS partition.
I got most of the tools to pack a SOS blob here
https://github.com/skirata/android-utils
I had to build a newer version of the blob tools
https://github.com/AndroidRoot/BlobTools
gaze57 said:
Thanks, but I'm a bit confused...
How does kernel and recovery (CWM-Touch.blob) relate ?
I was of the impression that a recovery image is to be flashed to the recovery partition (SOS), e.g.,
fastboot.exe -i 0x0B05 flash recovery <blob>
...while kernel+ramdisk to boot partition (LNX), e.g.,
fastboot.exe -i 0x0B05 flash boot <blob>
Are the build scripts you mention publicly available and directions of where to look if that's the case ?
Click to expand...
Click to collapse
Probably I can answer some of my questions myself...
Obviously both recovery and boot partition each contain a kernel+ramdisk of their own.
The difference is probably that,
- in the recovery partition the ramdisk actually contains the complete filesystem, including
the recovery application (e.g. TWRP) and everything is just meant to run from RAM.
while,
-in the boot partition there is only a minimal ramdisk enabling proper loading of the
system partition (called APP if not mistaken).
Perhaps my problem is just that kernel command line is not correct or simething similar.
Also I just discovered that fastboot.exe has a command called "boot" which actually might
be a much faster way to test custom kernels. Have to try it out...
I tried the fastboot boot commands wont even boot the stock kernel, it kinda seems like ASUS does not
want custom kernels to be run on the tablet.
Has ASUS ever wanted custom kernels running on there stuff? Anyway, the did give us a unlock for the boot loader, so looks to me like they are taking the, can't beat make sure they can return'em approach.
untermensch said:
I tried the fastboot boot commands wont even boot the stock kernel, it kinda seems like ASUS does not
want custom kernels to be run on the tablet.
Click to expand...
Click to collapse
gaze57 said:
Really ?
As far as I can tell the V10.4.2.9 kernel source from Asus website builds just fine (with one minor correction).
But perhaps I'm missing your point, sorry in that case.
My biggest problem so far is to successfully flash a custom kernel on JB custom ROM (ASU-JellyBean-Hydro 1.4.6).
This leads me to my actual question:
Anyone managed to successfully flash seanzscreams' modded kernel (Asu-JellyBean-HYDROKernel.zip)
on his excellent ROM ASU-JellyBean-Hydro 1.4.6 ?
As far as I can tell the entire kernel flash process seems to finish successfully (using TWRP 2.2.2.0)
but when checking kernel version in Settings it seems to be the same (stock) version as previously,
3.1.10-00003-g6293ea6 [email protected] #1 SMP PREEMPT Thu Aug 9 15:59:38 CST 2012
Looking forward for any ideas/tips.
(I know question better belongs in the Dev forum, but as I just registered at XDA I'm not allowed to post there.)
Click to expand...
Click to collapse
I unpacked the Asu-JellyBean-HYDROKernel.zip kernel looks like the stock kernel, any changes
have probably been made to the initrd so the kernel version would not change.
Code:
43538fd617c95623ce71fa39897f4a94 zImage
43538fd617c95623ce71fa39897f4a94 ../boot.blob.lnx-kernel.gz
zImage is the stock kernel I use for the touch recovery and boot.blob.lnx-kernel.gz is
the unpacked Asu-JellyBean-HYDROKernel.zip kernel the md5 sums are the same.
Just for ****s and giggles, I unpacked the stock kernel zImage found the string
Code:
[email protected]
and changed it to
Code:
[email protected]
repacked to a zImage with a md5 sum of
Code:
727525cb198a130dfd532cfbde713d29
made a recovery and flashed via fastboot, and it booted fine. This proves that
the new bootloader is not checking the signature of the kernel against a stored
value so custom kernels are possible and I'm just not smart enough to build
a working kernel form the ASUS source.
That's funny, someone out there is, Man just an OC'ed Kernel would be awesome. Since EzOverclock doesn't work with JB you I can really tell the difference in speed on JB.
untermensch said:
Just for ****s and giggles, I unpacked the stock kernel zImage found the string
Code:
[email protected]
and changed it to
Code:
[email protected]
repacked to a zImage with a md5 sum of
Code:
727525cb198a130dfd532cfbde713d29
made a recovery and flashed via fastboot, and it booted fine. This proves that
the new bootloader is not checking the signature of the kernel against a stored
value so custom kernels are possible and I'm just not smart enough to build
a working kernel form the ASUS source.
Click to expand...
Click to collapse
I pulled the config from my tf300 and and managed to build the zImage
I get warning notices about the one of the mpu sensors
if you get it to flash that might be something that may not work
as for myself, I'll be looking into some UMS features, we'll see how far I get
it appears all the needed code is already included in the kernel download from asus,
just need to configure it
Seems I finally managed to build and flash my own JB kernel for the TF300T ! :good:
This will just be a quick and dirty wrap-up of what I did as my spare time is somewhat limited.
Hope to be able to make it more structured and with proper credits in the near future.
Anyone feel free to compile a better structured how-to with correct references and credits.
Quick credits/thanks:
seanzscreams
untermensch
Stuff needed:
- Asus kernel source (10_4_2_9_kernel.zip)
- Android NDK R8B (I'm using Linux version, android-ndk-r8b-linux-x86.tar.bz2)
- Asu-JellyBean-HYDROKernel.zip (to get a proper update package structure with update binary/script and META-INF directory)
- signing-tools.zip, BlobTools and re/unpack-bootimg.pl (can't remember where I found these will have to update post later...)
Preparations:
- Unpack kernel source, e.g. to $HOME/TF300/stock_kernel
- Unpack Android NDK, e.g. to $HOME/android-ndk-r8b
- Unzip Asu-JellyBean-HYDROKernel.zip, e.g. to $HOME/my_kernel
- Setup/install BlobTools and the other scripts
Step-by-step instructions:
1. Build kernel (zImage)
a) Fix minor issue in kernel source
> cd $HOME/TF300/stock_kernel
Change line 11 in file drivers/ril/ril.c
from,
#include <../../arch/arm/mach-tegra/include/mach/board-cardhu-misc.h>
to,
#include "../../arch/arm/mach-tegra/include/mach/board-cardhu-misc.h"
b) Setup build environment for cross compilation
> export PATH=$HOME/android-ndk-r8b/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin:$PATH
> export ARCH=arm
> export CROSS_COMPILE=arm-linux-androideabi-
c) Fetch /proc/config.gz from your TF300 and copy/gunzip to $HOME/TF300/stock_kernel/.config
d) Build
> make
If everything went fine you should have a new kernel under,
$HOME/TF300/stock_kernel/arch/arm/boot/zImage
2. Repack kernel
> cd $HOME/my_kernel
a) Create a 28 byte file using a hex editor for the signblob header (I named the file signblob_magic)
It should have the following contents when checked with hexdump:
> hexdump -C signblob_magic
00000000 2d 53 49 47 4e 45 44 2d 42 59 2d 53 49 47 4e 42 |-SIGNED-BY-SIGNB|
00000010 4c 4f 42 2d 00 00 00 00 00 00 00 00 |LOB-........|
0000001c
b) Unpack the boot.blob from Asu-JellyBean-HYDROKernel.zip (unzipped earlier under Preparations)
This step is just to get a proper blob directory structure and the initramfs.
> blobunpack boot.blob
> unpack-bootimg.pl boot.blob.lnx
c) Pack new kernel
Might as well post the script I made to perform this task, check comments.
#!/bin/sh
SRC_HOME=$HOME/TF300/stock_kernel
KERNEL_NAME=my_kernel
# replace kernel
cp ${SRC_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
# repack
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# add signblob header
cat signblob_magic out.blob > boot.blob
# create zip package
zip -9 -r ${KERNEL_NAME}.zip boot.blob META-INF/
# Sign zip package using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
3. Flash kernel
From previous steps you should now have a signed kernel called,
my_kernel-signed.zip
Flash it using TWRP and reboot.
If flash was OK a blue status bar should appear during boot and then your TF300 will reboot again.
Confirm you have a custom kernel by checking Kernel-version under Settings once system has completed the bootup.
Confirmed! I have built a working kernel from ASUS source not sure if it was the
NDK or pulling the config from the device.
good work gaze57!
Code:
~ # uname -a
Linux localhost 3.1.10 #2 SMP PREEMPT Sat Sep 15 16:49:52 PDT 2012 armv7l GNU/Linux
link to my recovery build setup with source built kernel
http://www.mediafire.com/?hnstxi9so5970y0
EDIT:
it was the config that was causing my previous attempts to fail, I have an Android build setup
with this as the path
Code:
/home/untermensch/Android/android-4.1.1_r4/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/
then these exports
Code:
export ARCH=arm
export SUBARCH=armv7-a-neon
export CROSS_COMPILE=arm-eabi-
then pull the config from the tablet and got a working kernel.
EDIT:
I opened a source repository with the fix to ril.c and the device config saved to arch/arm/configs/tf300t_defconfig
https://github.com/untermensch/tf300t_kernel
Linux kernel
Congratulations guys!
Thanks for sharing your work.
Since you've been keeping your hands busy with the kernel for some time now, I was wondering if you have ever tried to build a Linux system (kernel + working environment) for the TF300, and whether you know it's possible or not.
I've downloaded the kernel from Asus and trying to get tegra3_defconfig to build (currently having problems with "make[1]: *** [arch/arm/mach-tegra/board-cardhu-sensors.o] Error 1". Am I using the right defconfig? Is it possible to build an Android kernel but have it boot a GNU/Linux environment.
I appreciate your help
EDIT: Regarding the error message, it was a bad reference. The file was expected to be in another folder. I fixed the reference and it went on building.
Congratulations Could you try to enable to overclock?
AnyKernel3 -- Flashable Zip Template for Kernel Releases with Ramdisk Modifications
"AnyKernel is a template for an update.zip that can apply any kernel to any ROM, regardless of ramdisk." - Koush
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allowed a device-specific kernel zImage to be flashed over device-specific ROM and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this was that some kernels require modifications to the ramdisk to enable/set up kernel features, and in the old AnyKernel format there was no way to do this. Enter AnyKernel2.
AnyKernel2 pushed the format even further by allowing kernel developers to modify the underlying ramdisk for kernel feature support easily using a number of included command methods along with properties and variables to customize the installation experience to their kernel. AnyKernel3 adds the power of topjohnwu's magiskboot for wider format support by default.
A script based on Galaxy Nexus (tuna) is included for reference. An example of ramdisk-only changes can be seen in my GN Synapse Injector repo. For an example that also modifies ROM and properly injects init.d support using busybox run-parts and sepolicy-inject see CosmicDan's CosmicTweaks project. For a multi-partition example and an example of how to handle a device which only has a ramdisk when rooted see my N5X/6P BLOD Workaround Injector. Other working AK2/3 examples for more recent devices may be found on eng.stk's blu_spark device repos under Releases.
Please see the linked posts here for instructions on enabling full AVBv1 (Pixel), AVBv1, A/B slot and/or system-as-root (SAR) or 2-stage init (2SI) device support, and further guidelines for system-as-root/2-stage init (/system/system in recovery) modifications in general.
Please also see the post here for important notes about the current state of AOSP vendor_boot v4 support and AVBv2 flag options.
Magisk root is automatically detected and retained by patching the new Image.*-dtb as Magisk would!
My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!
Source: https://github.com/osm0sis/AnyKernel3/
Download: https://github.com/osm0sis/AnyKernel3/archive/master.zip
Instructions
1) Place final kernel build product, e.g. Image.gz-dtb or zImage to name a couple, in the zip root (any separate dt, dtb, recovery_dtbo, dtbo and/or vendor_dlkm should also go here for devices that require custom ones, each will fallback to the original if not included)
2) Place any required ramdisk files in /ramdisk (/vendor_ramdisk for simple multi-partition vendor_boot v3 support) and module files in /modules (with the full path like /modules/system/lib/modules)
3) Place any required patch files (generally partial files which go with AK3 file editing commands) in /patch (/vendor_patch for simple multi-partition vendor_boot v3 support)
4) Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for any added ramdisk files, and use methods for any required ramdisk modifications (optionally, also place banner and/or version files in the root to have these displayed during flash)
5) `zip -r9 UPDATE-AnyKernel3.zip * -x .git -x .github README.md *placeholder`
The LICENSE file must remain in the final zip to comply with licenses for binary redistribution and the license of the AK3 scripts.
If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
[DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
Not required, but any tweaks you can't hardcode into the source (best practice) should be added with an additional init.tweaks.rc or bootscript.sh to minimize the necessary ramdisk changes. On newer devices Magisk allows these within /overlay.d - see examples.
It is also extremely important to note that for the broadest AK3 compatibility it is always better to modify a ramdisk file rather than replace it.
If running into trouble when flashing an AK3 zip, the suffix -debugging may be added to the zip's filename to enable creation of a debug .tgz of /tmp for later examination while booted or on desktop.
Staying Up-To-Date
Now that you've got a ready zip for your device, you might be wondering how to keep it up-to-date with the latest AnyKernel commits. AnyKernel2 and AnyKernel3 have been painstakingly developed to allow you to just drop in the latest update-binary and tools directory and have everything "just work" for beginners not overly git or script savvy, but the best practice way is as follows:
1) Fork my AnyKernel3 repo on GitHub
2) `git clone https://github.com/<yourname>/AnyKernel3`
3) `git remote add upstream https://github.com/osm0sis/AnyKernel3`
4) `git checkout -b <devicename>`
5) Set it up like your <devicename> zip (i.e. remove any folders you don't use like ramdisk or patch, delete README.md, and add your anykernel.sh and optionally your Image.*-dtb if you want it up there) then commit all those changes
6) `git push --set-upstream origin <devicename>`
7) `git checkout master` then repeat steps 4-6 for any other devices you support
Then you should be able to `git pull upstream master` from your master branch and either merge or cherry-pick the new AK3 commits into your device branches as needed.
Enjoy!
Questions, comments and feedback welcome.
Credits & Thanks: All authors of the included binaries and the tools I used to port them over for their amazing work. koush for the original AnyKernel concept.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
Script Commands Reference
Everything to edit is self-contained in anykernel.sh. A quick-reference for the commands and properties included are as follows.
Properties / Variables
These are some values that will be read during the install process, allowing you to customize your installation, e.g. block= is a shell variable to specify the kernel/boot block partition that the dump_boot command method will copy and unpack.
Code:
kernel.string=KernelName by YourName @ xda-developers
do.devicecheck=1
do.modules=1
do.systemless=1
do.cleanup=1
do.cleanuponabort=0
device.name1=maguro
device.name2=toro
device.name3=toroplus
device.name4=tuna
supported.versions=6.0 - 7.1.2
supported.patchlevels=2019-07 -
block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
is_slot_device=0;
ramdisk_compression=auto;
patch_vbmeta_flag=auto;
do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device, ro.build.product, ro.product.vendor.device or ro.vendor.product.device from the build.prop files for your device. There is support for as many device.name# properties as needed. You may remove any empty ones that aren't being used.
do.modules=1 will push the .ko contents of the modules directory to the same location relative to root (/) and apply correct permissions. On A/B devices this can only be done to the active slot.
do.systemless=1 (with do.modules=1) will instead push the full contents of the modules directory to create a simple "ak3-helper" Magisk module, allowing developers to effectively replace system files, including .ko files. If the current kernel is changed then the kernel helper module automatically removes itself to prevent conflicts.
do.cleanup=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) - this can be useful if trying to debug in adb shell whether the patches worked correctly.
do.cleanuponabort=0 will keep the zip from removing its working directory in /tmp/anykernel (by default) in case of installation abort.
supported.versions= will match against ro.build.version.release from the current ROM's build.prop. It can be set to a list or range. As a list of one or more entries, e.g. 7.1.2 or 8.1.0, 9 it will look for exact matches, as a range, e.g. 7.1.2 - 9 it will check to make sure the current version falls within those limits. Whitespace optional, and supplied version values should be in the same number format they are in the build.prop value for that Android version.
supported.patchlevels= will match against ro.build.version.security_patch from the current ROM's build.prop. It can be set as a closed or open-ended range of dates in the format YYYY-MM, whitespace optional, e.g. 2019-04 - 2019-06, 2019-04 - or - 2019-06 where the last two examples show setting a minimum and maximum, respectively.
block=auto instead of a direct block filepath enables detection of the device boot partition for use with broad, device non-specific zips. Also accepts any partition filename (from by-name), e.g. boot, recovery, or vendor_boot.
is_slot_device=1 enables detection of the suffix for the active boot partition on slot-based devices and will add this to the end of the supplied block= path. Also accepts auto for use with broad, device non-specific zips.
ramdisk_compression=auto allows automatically repacking the ramdisk with the format detected during unpack. Changing auto to gz, lzo, lzma, xz, bz2, lz4, or lz4-l (for lz4 legacy) instead forces the repack as that format, and using cpio or none will (attempt to) force the repack as uncompressed.
patch_vbmeta_flag=auto allows automatically using the default AVBv2 vbmeta flag on repack, and use the Magisk configuration (Canary 23016+). Set to 0 forces keeping whatever is in the original AVBv2 flags, and set to 1 forces patching the flag (only necessary on few devices).
customdd="<arguments>" may be added to allow specifying additional dd parameters for devices that need to hack their kernel directly into a large partition like mmcblk0, or force use of dd for flashing.
slot_select=active|inactive may be added to allow specifying the target slot. If omitted the default remains active.
no_block_display=1 may be added to disable output of the detected final used partition+slot path for zips which choose to include their own custom output instead.
Command Methods
Code:
ui_print "<text>" [...]
abort ["<text>" [...]]
contains <string> <substring>
file_getprop <file> <property>
set_perm <owner> <group> <mode> <file> [<file2> ...]
set_perm_recursive <owner> <group> <dir_mode> <file_mode> <dir> [<dir2> ...]
dump_boot
split_boot
unpack_ramdisk
backup_file <file>
restore_file <file>
replace_string <file> <if search string> <original string> <replacement string> <scope>
replace_section <file> <begin search string> <end search string> <replacement string>
remove_section <file> <begin search string> <end search string>
insert_line <file> <if search string> before|after <line match string> <inserted line>
replace_line <file> <line replace string> <replacement line> <scope>
remove_line <file> <line match string> <scope>
prepend_file <file> <if search string> <patch file>
insert_file <file> <if search string> before|after <line match string> <patch file>
append_file <file> <if search string> <patch file>
replace_file <file> <permissions> <patch file>
patch_fstab <fstab file> <mount match name> <fs match type> block|mount|fstype|options|flags <original string> <replacement string>
patch_cmdline <cmdline entry name> <replacement string>
patch_prop <prop file> <prop name> <new prop value>
patch_ueventd <ueventd file> <device node> <permissions> <chown> <chgrp>
repack_ramdisk
flash_boot
flash_generic <partition name>
write_boot
reset_ak [keep]
setup_ak
"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists. "cmdline entry name" behaves somewhat like this as a match check for the name of the cmdline entry to be changed/added by the patch_cmdline function, followed by the full entry to replace it. "prop name" also serves as a match check in patch_prop for a property in the given prop file, but is only the prop name as the prop value is specified separately.
Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
"scope" may be specified as "global" to force all instances of the string/line targeted by replace_string, replace_line or remove_line to be replaced/removed accordingly. Omitted or set to anything else and it will perform the default first-match action.
"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
dump_boot and write_boot are the default method of unpacking/repacking, but for more granular control, or omitting ramdisk changes entirely ("OG AK" mode), these can be separated into split_boot; unpack_ramdisk and repack_ramdisk; flash_boot respectively. flash_generic can be used to flash an image to the corresponding partition. It is automatically included for dtbo and vendor_dlkm in write_boot but can be called separately if using "OG AK" mode or creating a simple partition flashing only zip.
Multi-partition zips can be created by removing the ramdisk and patch folders from the zip and including instead "-files" folders named for the partition (without slot suffix), e.g. boot-files + recovery-files, or kernel-files + ramdisk-files (on some Treble devices). These then contain Image.gz, and ramdisk, patch, etc. subfolders for each partition. To setup for the next partition, simply set block= (without slot suffix) and ramdisk_compression= for the new target partition and use the reset_ak command.
Similarly, multi-slot zips can be created with the normal zip layout for the active (current) slot, then resetting for the inactive slot by setting block= to the partition (without slot suffix) again, slot_select=inactive and ramdisk_compression= to the desired options for the target slot and using the reset_ak keep command, which will retain the patch and any added ramdisk files for the next slot.
backup_file may be used for testing to ensure ramdisk changes are made correctly, transparency for the end-user, or in a ramdisk-only "mod" zip. In the latter case restore_file could also be used to create a "restore" zip to undo the changes, but should be used with caution since the underlying patched files could be changed with ROM/kernel updates.
You may also use ui_print "<text>" to write messages back to the recovery during the modification process, abort "<text>" to abort with optional message, and file_getprop "<file>" "<property>" and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.
Binary Inclusion
The AK3 repo includes current ARM builds of magiskboot, magiskpolicy, lptools_static and busybox by default to keep the basic package small. Builds for other architectures and optional binaries (see below) are available from the latest Magisk zip, or my latest AIK-mobile and Flashlt packages, respectively, here:
https://forum.xda-developers.com/t/...kernel-ramdisk-win-android-linux-mac.2073775/ (Android Image Kitchen thread)
https://forum.xda-developers.com/t/...-and-ends-multiple-devices-platforms.2239421/ (Odds and Ends thread)
Optional supported binaries which may be placed in /tools to enable built-in expanded functionality are as follows:
mkbootfs - for broken recoveries, or, booted flash support for a script/app via bind mount to /tmp (deprecated/use with caution)
flash_erase, nanddump, nandwrite - MTD block device support for devices where the dd command is not sufficient
dumpimage, mkimage - DENX U-Boot uImage format support
mboot - Intel OSIP Android image format support
unpackelf, mkbootimg - Sony ELF kernel.elf format support, repacking as AOSP standard boot.img for unlocked bootloaders
elftool (with unpackelf) - Sony ELF kernel.elf format support, repacking as ELF for older Sony devices
mkmtkhdr (with unpackelf) - MTK device boot image section headers support for Sony devices
futility + chromeos test keys directory - Google ChromeOS signature support
boot_signer-dexed.jar + avb keys directory - Google Android Verified Boot 1.0 (AVBv1) signature support
rkcrc - Rockchip KRNL ramdisk image support
Optionally moving ARM builds to tools/arm and putting x86 builds in tools/x86 will enable architecture detection for use with broad, device non-specific zips.
Boom . dibs on first :good:
You get 2 thank button presses fro me lol
Awesome work man as always
Good thing that this amazing work has it's own thread. Congrats buddy.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Thanks guys!
I figured it would be nice to get it out there and also have it as a "Help Desk" thread for kernel devs who have questions about implementation, etc. too. Some devices might require switching it from dd to MTD-Utils, so I can help with that. So on and so forth.
Once we get a few devs who know how to use it, it should be pretty easy to help others. I'm looking at you Smitty. No pressure.
I finished my thanks ... but as always a great job.
ak said:
I finished my thanks ... but as always a great job.
Click to expand...
Click to collapse
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
milojoseph said:
So wait im confused. ?.. so 1) those that mean I can flash ak kerenl 4.2 with ur any kernel to my 4.4 .
2) those it have to be same kerenl for same phone manufacturer. Meaning can I be stupid enought to flash a nexus 4 kernel in my gnexus?
I understand any kernel cause I have been using smitty so thanks
Click to expand...
Click to collapse
Haha I wrote "device-specific" in the OP to try and avoid this very confusion.
Since I answered this same question earlier tonight in my Odds and Ends thread I'll just paste it here:
caspboy said:
so now devs can use kernels from other devices with their roms?
Click to expand...
Click to collapse
osm0sis said:
No. That's crazy talk. :laugh:
The concept of AnyKernel has been around for awhile, (originally by Koushik Dutta/ClockworkMod,) which allows device-specific kernels to be flashed over device-specific ROMs and use the ramdisk that came with the ROM to reduce the chance of any issues arising from the custom kernel pairing.
The drawback to this is that some kernels require modifications to the ramdisk to enable/set up kernel features, but in the old AnyKernel format there was no way to do this. Until now.
AnyKernel 2.0 makes it easy for kernel devs to use a number of simple command methods to automate the process of adding tweaks into a ROM's underlying ramdisk during the flashing process. :good:
Click to expand...
Click to collapse
Hopefully that helps. Basically exactly what's in the OP since that's where I edited it in from.
The only way I can explain it any further is with the very basics: that kernel boot.img files contain a zImage and a ramdisk. "AnyKernel Classic" just slaps the custom kernel zImage on top of the ROM's untouched default kernel boot.img ramdisk. AnyKernel 2.0 allows kernel devs to also modify the ramdisk to add anything required for kernel features in addition to the usual repacking it with the custom zImage and flashing it.
Great thread!! Best of lucky bro!!!
Sent from my Galaxy Nexus using xda app-developers app
AnyKernel will work on my phone now ? Thanks for enhancing awesome @osm0sis but DrRamdisk to the rest of you guys ?
wow,thats very cool,great work.
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
osm0sis said:
Github updated with my own forked native compiles of mkbootimg+unpackbootimg.
This should expand AnyKernel 2.0 device support a lot by using all the available offsets in mkbootimg, as exported by my drastically updated unpackbootimg. :good:
Click to expand...
Click to collapse
Hi osm0sis,
Have You update anykernel 2.0 to work with cyanogen11 roms ? Thanks for Your hard work !
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
osm0sis said:
Should already?
It uses the ROM kernel ramdisk like AnyKernel always has. Your custom kernel dev just needs to use it. Spread the word. :good:
Click to expand...
Click to collapse
Recently I had used Your method on Cyano11 but boot stopped on "Google".. new Cyano11 (that required ramdisk changes) had just come out and maybe anykernel 2.0 was not ready yet (I had just discovered your brillant work on It ! : Dita incrociate.
I'll try again ... if I have trouble going to ask you for help ...
I am already spreading the word : Cool:
Thanks man : Good:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
osm0sis said:
What custom kernel were you trying to adapt to AnyKernel so you could flash it on CM?
Click to expand...
Click to collapse
Two kernels... My custom kernel (from cyanogenmod sources) and recently Fancy kernel (dirty-fancy)... now I want to try Fancy Kernel .. I need of a hibryd ramdisk for best final results and Your project is perfect for It !!! You're a genius !!!
Please, Can You link me Your dirty-V kernel re-pack by Anykernel 2.0 ? So I can follow It as an example. Thanks a lot...
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
osm0sis said:
So if I understand you, you're trying to make an AnyKernel 2.0 of Fancy Kernel so that you can flash it on any ROM for your device?
Should be doable. The DirtyV AnyKernel 2.0 is the example posted to the GitHub repo in the OP. Just follow the instructions to make your own anykernel script so that it will add the /sbin/ scripts and other ramdisk modifications (init.d, etc.) that @boype uses, instead of the DirtyV ones.
Good luck!
Click to expand...
Click to collapse
Yes !
osm0sis ? If I want include init.rc original file by "real" ramdisk can I copy It as is into patch folder ?
It would go against the idea of AnyKernel to include the file like that. Remember, everything automatically comes from the original ramdisk, I just give you the ability to alter those files to add tweaks. :good:
Hey,
i have a wileyfox storm smartphone with cyanogenmod firmware. i modified my kernel to allow loadable module support by creating a custom config which includes everything (like CONFIG_MODULES=y).
but after compiling and flashing boot.img to my device, "lsmod" command still returns: cat: /proc/modules: No such file or directory ... any ideas? :/
I did it similar to this tutorial: ytliu.info/blog/2015/12/14/enable-config-module-in-cyanogenmod-kernel/
I flashed the boot.img and the kernel is running on the phone, but there is still no /proc/modules...
Thank you very much for every help! :good:
// AVN
What's the tool for:
Almost all Qualcomm device is using linux device tree, and there're 2 ways to handle to kernel:
Use a "dt.img" to pack dtbs and attached it to boot.img. When booting, lk will unpack it and handle dtbs to kernel.(Most devices in this way)
Directly append dtbs on kernel image. When booting, lk will split them off and handle to kernel.(Nexus devices in this way since Nexus 5. Qualcomm switched to this way in every M branch, so generally you won't see a dt.img after unpacking a boot.img from official M release)
This tool is implemented to split a kernel image with appended dtbs into separated kernel and dtb files.
How it works:
Every dtb is started with 0xd00dfeed(defined in scripts/dtc/libfdt/fdt.h in kernel source), and a kernel image with appended dtbs is generated with command similar to the following one:
Code:
echo Image a.dtb b.dtb > Image-dtb
My program will search 0xd00dfeed in the provided kernel image, and dump "Image", "a.dtb", "b.dtb" in "Image-dtb" into sepreated files. After that, you're free to use dtc to decompile the .dtb into .dts
Download & Source:
https://github.com/dianlujitao/split-appended-dtb
XDA:DevDB Information
split-appended-dtb, Tool/Utility for all devices (see above for details)
Contributors
dianlujitao
Source Code: https://github.com/dianlujitao/split-appended-dtb
Version Information
Status: Stable
Created 2016-03-22
Last Updated 2016-03-22
@dianlujitao how to add dtb files back to zImage? Thank you
I have 13 dtb files.. converted them to dts, edited and converted back to dtb...
ingbrzy said:
@dianlujitao how to add dtb files back to zImage? Thank you
I have 13 dtb files.. converted them to dts, edited and converted back to dtb...
Click to expand...
Click to collapse
cat xxx.dtb >> zImage
dianlujitao said:
cat xxx.dtb >> zImage
Click to expand...
Click to collapse
Thanks it works!
dianlujitao said:
cat xxx.dtb >> zImage
Click to expand...
Click to collapse
By using this command, I added a new dtb to my zimage.
There is some way to replace it that already exists in the zimage and not to add a new dtb file inside the zimage.
Thank you very much
kenet said:
By using this command, I added a new dtb to my zimage.
There is some way to replace it that already exists in the zimage and not to add a new dtb file inside the zimage.
Thank you very much
Click to expand...
Click to collapse
this is the files' layout
| ++++++++++++ Image-dtb ++++++++++++++ |
| ______ zImage ______ | _ a.dtb _ | _ b.dtb _ |
Image-dtb contains zImage followed by dtbs
zImage itself doesn't contain device tree blobs, and that command will append the latter to it.
Hi everyone,
I'm currently having trouble finding the device tree blob (.dtb) file on my Motorola phone running Android 12. I've tried unpacking the boot image file using various tools, but I haven't been able to locate the .dtb file.
Here are the steps I've taken so far:
I've rooted my phone and have access to all system files.
I've unpacked the boot image using the Android Image Kitchen and other tools, but I can't seem to find the .dtb file.
I've checked the "firmware" and "by-name" folders, but I couldn't find the .dtb file there either.
I've even tried using the dtc (Device Tree Compiler) utility to convert the device tree blob to a human-readable text file, but the resulting file was empty.
I'm at a loss as to what to do next. I need the .dtb file to make some modifications to the device tree information, but I can't seem to find it anywhere.
Has anyone else experienced this issue with a Motorola phone running Android 12? Does anyone know where the .dtb file might be located, or have any suggestions for other tools or techniques I could try?
Thanks in advanced for any help or advice you can provide!
afaik separate dtbo partition
alecxs said:
afaik separate dtbo partition
Click to expand...
Click to collapse
Isn't dtbo just an overlay?
@FiniteCode post the boot image and I'll check it for DTB.
I'm really sorry but i don't get what you guys wanna say, Actually it's my first time developing rom so you see...
Renate said:
Isn't dtbo just an overlay?
@FiniteCode post the boot image and I'll check it for DTB.
Click to expand...
Click to collapse
Thank you a lot for your support!
Thank you everyone saw your answers put them to ChatGPT understood some New Concepts and Voila! Thank you a lot everyone.... Special Thanks to @alecxs.7285913 and @renate.4474482
FiniteCode said:
Thank you everyone saw your answers put them to ChatGPT understood some New Concepts and Voila! Thank you a lot everyone.... Special Thanks to @alecxs.7285913 and @renate.4474482
Click to expand...
Click to collapse
Hmmm...
That's an Android header version 4 which only has a kernel and a ramdisk.
See: https://source.android.com/docs/core/architecture/bootloader/boot-image-header#header-v4
There appears to be no DTB tacked onto the kernel.
Also weird, the ramdisk is CPIO, but they didn't even bother to gzip it.
That dtbo has three DTBs in it, preceeded by that new 128 byte header.
It appears to all be overlays. I don't know much about that.
Code:
000000 Android header
000080 Header
0000b8 / {
0000c0 [email protected] {
0000d8 target-path = "/";
0000e8 __overlay__ {
Edit: If you want the kallsysms (using my tools):
Code:
C:\>imgutil /x boot.img payload
C:\>kallsyms /b8 payload boot.sym
Renate said:
Hmmm...
That's an Android header version 4 which only has a kernel and a ramdisk.
See: https://source.android.com/docs/core/architecture/bootloader/boot-image-header#header-v4
There appears to be no DTB tacked onto the kernel.
Also weird, the ramdisk is CPIO, but they didn't even bother to gzip it.
That dtbo has three DTBs in it, preceeded by that new 128 byte header.
It appears to all be overlays. I don't know much about that.
Code:
000000 Android header
000080 Header
0000b8 / {
0000c0 [email protected] {
0000d8 target-path = "/";
0000e8 __overlay__ {
Edit: If you want the kallsysms (using my tools):
Code:
C:\>imgutil /x boot.img payload
C:\>kallsyms /b8 payload boot.sym
Click to expand...
Click to collapse
yup... i tried to open the dtbo.img i came up with one error on every software/method i tried (bad magic number)
FiniteCode said:
yup... i tried to open the dtbo.img i came up with one error on every software/method i tried (bad magic number)
Click to expand...
Click to collapse
Lop off the first 128 (0x80) bytes (of the Android non-standard header) and you'll see the signature, bigend 0xd00dfeed.
There are three concatenated DTB(O)s.
Renate said:
Lop off the first 128 (0x80) bytes (of the Android non-standard header) and you'll see the signature, bigend 0xd00dfeed.
There are three concatenated DTB(O)s.
Click to expand...
Click to collapse
Could you attach them If possible. I've been having a hard time with getting them
@FiniteCode Oh, alright.
Renate said:
@FiniteCode Oh, alright.
Click to expand...
Click to collapse
Thank you so much can't explain my happiness like seriously thank you a lot
FiniteCode said:
Thank you so much can't explain my happiness like seriously thank you a lot
Click to expand...
Click to collapse
Don't get too excited. Each of those dtbo's are only ~100k.
A real dtb is more like 300k and upwards.
Moreover, those three are all variants of each other, they are 75%+ the same.
And since they are all actually overlays we still don't know where the base dtb is.
Edit: Oh, I forgot that I had posted my dtbview.exe (in the sig).
If you do Windows it can dump dtb & dtbo (also wacky Android header).
Code:
C:\>dtbview dtbo.img > big.txt
Some new devices with header version 4 has more in the vendor_boot.img like kernel-dt so that not in the boot.img (only kernel).
But I made attempt to extract dtbo.img & dtb. Not know if help.
UPD
Okay. Again my friend @lopestom updated me on Header V4 information.
I used the correct tools on Linux and now it seems to be much better than before. Well it looks like you have a Mediatek phone.
Attached pictures "dddd".png and unziped_dtbo.zip
Thank you all for help I'll try if this works in my custom rom
FiniteCode said:
Thank you all for help I'll try if this works in my custom rom
Click to expand...
Click to collapse
Or else, the last resort might be contacting Motorola which I don't think should help out, I don't have any hopes from Motorola...
FiniteCode said:
Or else, the last resort might be contacting Motorola which I don't think should help out, I don't have any hopes from Motorola...
Click to expand...
Click to collapse
I not search in total but has very dts and dtc files.
GitHub - AbzRaider/kernel_moto_vicky: Kernel Tree for MediaTek MT6789 Based Motorola G72 ( Vicky )
Kernel Tree for MediaTek MT6789 Based Motorola G72 ( Vicky ) - GitHub - AbzRaider/kernel_moto_vicky: Kernel Tree for MediaTek MT6789 Based Motorola G72 ( Vicky )
github.com
GitHub - theh0riz0n/android_kernel_motorola_vicky: Kernel sources for Motorola G72 DS XT2255-1
Kernel sources for Motorola G72 DS XT2255-1. Contribute to theh0riz0n/android_kernel_motorola_vicky development by creating an account on GitHub.
github.com
Kernel sources for Motorola G72 DS XT2255-1
Using which tools were you guys able to extract the boot.img I'm unable to do that actually I need to extract the ramdisk and kernel please do attach if you can
AIK is the only tool I use. maybe you have separate vendor_boot partition