I'm new to the iconia and tegra based devices. I'm used to the qualcomm msm based devices. When trying to unpack the boot.img and repack it now of the tools I normally use can detect the kernel command line. Does this device require a modified mkbootimg/unpackbootimg and what is the correct kernel command line and args to use?
drellisdee said:
I'm new to the iconia and tegra based devices. I'm used to the qualcomm msm based devices. When trying to unpack the boot.img and repack it now of the tools I normally use can detect the kernel command line. Does this device require a modified mkbootimg/unpackbootimg and what is the correct kernel command line and args to use?
Click to expand...
Click to collapse
It gets the command line from bootloader via atags, so no need to add it to the boot.img. Actually to force custom cmdline, you'll have to hardcode it in kernel config and rebuild kernel.
sp3dev said:
It gets the command line from bootloader via atags, so no need to add it to the boot.img. Actually to force custom cmdline, you'll have to hardcode it in kernel config and rebuild kernel.
Click to expand...
Click to collapse
Thanks for the info and prompt reply.
Related
This tool i came across when i was working on the Ubuntu for Eris.
Code:
It copies your bootimage to a temp file so it has a space to work in
It then unpack the boot.img
Replaces the zImage you included ith the original one
Repacks the boot.img
Flashes the new boot.img with your kernel in it.
All you need to do is rename your kernel zimage, and place it in the kernel folder and re-sign it. MUCH easier than fastboot or baking up a custom boot.img each time you have to swap the kernel.
All thanks to Koush, i just found the thing
Hi,
I've compiled a modified version of the 2.6.36.3 kernel (downloaded from the git repository) to include a USB Network Adapter driver (AX88772A) into a zImage. But I don't know how to flash the zImage onto my A500. When I run "fastboot flash zimage zImage" it always returns < waiting for device >. But I am able to run adb to pull and push files to the tablet.
How can I update the kernel so that it can detect my USB -> Ethernet adapter (chipset AX88772A)? Any ideas? Thanks!
You have to put it in the boot.img, then you can dd it or create a zip update, like custom roms!
You can ask for more info to a kernel guy like richardtrip or thor202ro!
Try to open one of their zip update to see how it works!
you should use android's mkbootimg
like
mkbootimg --ramdisk initrd.gz --kernel zImage -o boot.img
then you can dd it to boot partition (/dev/mmcblk0p2) and run itsmagic. And do not flash both p1 and p2 at the same time - if you flash two unbootable images or forget to update the checksum, you'll have to pm sc2k to recover the device via nvflash.
Moving to General.
PS: Every Q? thread should be posted in General.
This script is built from the knowledge gathered from:
http://forum.xda-developers.com/showthread.php?t=1332629
http://nookdevs.com/NookColor:_Build_the_Original_Kernel
http://nookdevs.com/User_talk:Warewolf
This script will let you extract the ramdisk off of the working kernel and will create a directory with the ramdisk for you to edit to your heart's content. The script will then download dalingrin's kernel source and move back to a known working commit (if it hasn't done this already.) The script will then compile said kernel and merge the new ramdisk to the kernel. The script will give you the option of backing up your current kernel and then pushing the new kernel into your touchpad.
Warning: I am not responsible for any damage that come to your touchpad.
Requirements:
It assumes you have all the required programs to compile the kernel. Maybe v2 will check for this and install the required items.
You must have adb somewhere in your user's PATH.
You must have mkimage in your path. Later versions may do thi for you.
How to use:
Place the script in a folder with a known working boot.img from the Touchpad's CM7.
Open a terminal window and browse to that folder.
Give the script execute permissions:
Code:
$ chmod +x KernelModCorner
Run the script:
Code:
$ ./KernelModCorner
This command bring up the following menu:
Code:
What do you want to do?
1: Extract from boot.img (Warning: This will delete any previously extracted ramdisk.)
2: Recompile kernel and merge with new ramdisk
3: Backup current uImage and transfer new one.
4: Clean up all temporary files and ramdisk (Note: This does not include the kernel sources.)
5: Restore backup.
6: Exit
You can probably figure out which options do what...
I just used it successfully to compile the following kernel (which I also started trying to overclock the GPU in... not sure if it is overclocked at the moment as most adreno's in the past have had their GPU clock locked... test it if you'd like and let me know.)
Great job on this invaluable tool
Thanks
I would suggest posting which kernel/CM release this script is intended to work with
since it is highly version specific.
The ramdisk offset being used will only work with one version. Also, there could be a mismatch between the git commit being used and any newer ramdisk/system.
To make the script less version specific, you could use uimage-extract available in the tools dir of the moboot source (see http://code.google.com/p/moboot/source/browse/#git%2Ftools). To compile, add "-lz".
I've put together a tool undoing what mkbootimg does. There are other tools splitting a boot image into the
kernel and root file system, but I didn't find any extracting the command line and base addresses, so I wrote this one.
It handles plain boot images as well as boot images embedded in larger filer, e.g. update-images.
Code:
$ unmkbootimg boot.img
Kernel size 2419636
Kernel address 0x20008000
Ramdisk size 152656
Ramdisk address 0x21000000
Secondary size 0
Secondary address 0x20f00000
Kernel tags address 0x20000100
Flash page size 2048
Board name is ""
Command line "no_console_suspend=1"
This image is built using standard mkbootimg
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x20000000 --cmdline 'no_console_suspend=1' -o new_boot.img
---------------
$ ls -l
totalt 5044
-rw-r--r-- 1 kuisma kuisma 2576384 9 sep 09.44 boot.img
-rw-r--r-- 1 kuisma kuisma 152656 9 sep 09.44 initramfs.cpio.gz
-rw-r--r-- 1 kuisma kuisma 2419636 9 sep 09.44 zImage
Version 1.2 - Support for embedded boot images
Version 1.1 - Support for non-standard mkbootimg images.
Version 1.0 - Initial release.
Including a gziped binary for GNU/Linux in this post (32 bit, linked static). Download, unzip, make sure it is executable.
If running on a 64bit machine, make sure you've got the ia32-libs installed to be able to run 32bit binaries.
Great Tool........ i Always use it..........Thanks For Share
I've updated unmkbootimg. Now it detects and warns if the boot.img is built using a non-standard mkbootimg, and tells you how to patch it.
$ unmkbootimg samsung-boot.img
Kernel size 4905092
Kernel address 0x40408000
Ramdisk size 893395
Ramdisk address 0x41800000
Secondary size 0
Secondary address 0x41300000
Kernel tags address 0x40400100
Flash page size 2048
Board name is ""
Command line "androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4"
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_RAMDISK_ADDR is 0x01400000
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x40400000 --cmdline 'androidboot.hardware=qcom msm_watchdog.appsbark=0 msm_watchdog.enable=1 loglevel=4' -o new_boot.img
---------------
Click to expand...
Click to collapse
Thank you for your tool my friend
Though I have one question regarding this:
--cmdline 'no_console_suspend=1'
Click to expand...
Click to collapse
When I attempt to compile kernel from source, Sony said in the read me file that memory layout and other stuff are passed to kernel via cmdline. I do that just like it's written in the cmdline I quoted?! because I want to use the latest kernel source with an existing zRam but i'm unable to make the newly compiled kernel to boot because I am unable to pass arguments via cmdline on boot :crying:
DeepUnknown said:
Thank you for your tool my friend
Though I have one question regarding this:
When I attempt to compile kernel from source, Sony said in the read me file that memory layout and other stuff are passed to kernel via cmdline. I do that just like it's written in the cmdline I quoted?! because I want to use the latest kernel source with an existing zRam but i'm unable to make the newly compiled kernel to boot because I am unable to pass arguments via cmdline on boot :crying:
Click to expand...
Click to collapse
As far as I know, Sony passes all important parameters via kernel ATAGs, not command line.
kuisma said:
As far as I know, Sony passes all important parameters via kernel ATAGs, not command line.
Click to expand...
Click to collapse
I'm sorry I wasn't clear in the previous comment, here is what Sony mentioned:
In the official SW the following command line arguments are given
to the kernel:
cachepolicy=writealloc
noinitrd
init=init
board_id=1
logo.nologo
root=/dev/ram0
rw
rootwait
console=ttyAMA2,115200n8
androidboot.console=ttyAMA2
androidboot.hardware=st-ericsson
<memory layout>
mpcore_wdt.mpcore_margin=359
Click to expand...
Click to collapse
I'm sorry I went out of subject but I was using tools like yours to get zRam from other boot.img file.
Very nice tool, thanks for sharing.
unmkbootimg as of version 1.2 now supports embedded boot images, e.g. a boot image embedded deep in an update.img file.
$ unmkbootimg update.img
unmkbootimg version 1.2 - Mikael Q Kuisma <[email protected]>
File update.img not a plain boot image, seeking for embedded image ... found!
Kernel size 8073252
Kernel address 0x60408000
Ramdisk size 6380372
Ramdisk address 0x62000000
Secondary size 0
Secondary address 0x60f00000
Kernel tags address 0x60088000
Flash page size 16384
Board name is ""
Command line ""
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0x00380100
OFF_RAMDISK_ADDR is 0x01F78100
OFF_SECOND_ADDR is 0x00E78100
Please modify mkbootimg.c using the above values to build your image.
****************
Extracting kernel to file zImage ...
Extracting root filesystem to file initramfs.cpio.gz ...
All done.
---------------
To recompile this image, use:
mkbootimg --kernel zImage --ramdisk initramfs.cpio.gz --base 0x60087f00 --pagesize 16384 -o new_boot.img
---------------
$ ls
initramfs.cpio.gz update.img zImage
$
Click to expand...
Click to collapse
kuisma said:
unmkbootimg as of version 1.2 now supports embedded boot images, e.g. a boot image embedded deep in an update.img file.
Click to expand...
Click to collapse
Thanks for the update, very cool feature.
Can not extract zImage?
Could you check why I Can not extract zImage from this Kernel:
http://forum.xda-developers.com/showpost.php?p=37909023&postcount=56
mafamafa said:
Could you check why I Can not extract zImage from this Kernel:
http://forum.xda-developers.com/showpost.php?p=37909023&postcount=56
Click to expand...
Click to collapse
It's because it's not an Android boot image, but a Rockchip specific kernel image file.
Hi, could you please post the source here or upload in github or similar and provide the link. That will be much better.
Sent from my Amazon Kindle Fire HD using xda app-developers app
jeevas.v said:
Hi, could you please post the source here or upload in github or similar and provide the link. That will be much better.
Click to expand...
Click to collapse
Why? It's a trivial hack, and if you're a programmer, you'll put one together in minutes anyway.
So, no.
That is very bad and unethical. It is not a question of I or somebody can do it. Even it violates many things by saying no. What a pathetic situation.
Sent from my Amazon Kindle Fire HD using xda app-developers app
jeevas.v said:
That is very bad and unethical. It is not a question of I or somebody can do it. Even it violates many things by saying no. What a pathetic situation.
Click to expand...
Click to collapse
Say what? I'm providing the community a useful software for free - and you blame me for being unethical? :laugh:
I'm saying that you are using Foss as you like and hesitating to publish even a trivial change that you made. How can the community trust your binaries unless they don't have the source. What kind of mindset is that? Have you ever read GPL?
What do you think you are doing? Social service the Microsoft way? What a joke!
Sent from my Amazon Kindle Fire HD using xda app-developers app
jeevas.v said:
I'm saying that you are using Foss as you like and hesitating to publish even a trivial change that you made. How can the community trust your binaries unless they don't have the source. What kind of mindset is that? Have you ever read GPL?
What do you think you are doing? Social service the Microsoft way? What a joke!
Click to expand...
Click to collapse
GPL? My code is written from scratch, and is not a subject of GPL whatsoever.
You, my friend, are making a fool of your self. Please, don't let me hinder you.
I am trying to spread the awareness against the closed source behaviour and I hope I achieved that in whatever miniscule way.
I don't care about your binary or code but thought of asking you to know if you are intentionally not giving the source by giving just the 32bit binaries. Anyway so now everyone knows...
Sent from my Amazon Kindle Fire HD using xda app-developers app
how to build Rockchip specific kernel image file?
kuisma said:
It's because it's not an Android boot image, but a Rockchip specific kernel image file.
Click to expand...
Click to collapse
Can you tell how to build Rockchip specific kernel image file - or where to loog for that information?
mafamafa said:
Can you tell how to build Rockchip specific kernel image file - or where to look for that information?
Click to expand...
Click to collapse
I have no idea whatsoever how Rocketchip manages its boot images.
THIS IS NOT A "HOW TO BUILD A KERNEL" POST
The Pixel 2, unlike other phones I've worked with, requires two extra tools: dtc (Device Tree Compiler) and mkdtimg.
Yes, dtc is available in the main repos for most linux distros, but the Pixel 2 kernel requires the AOSP modified version of dtc.
First, grab the Pixel 2 + XL Unified kernel source (wahoo) from https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1
Then download wahoo-kernel-tools.zip file attatched to this post and unzip it. Make sure that the 2 files in the bin folder are available in your path (possibly by moving them to ~/bin) and symlink or move the libc++.so into an included library directory, such as /lib, /usr/lib, or /usr/local/lib.
These specific binaries were compiled on Arch Linux by me, so they may not work on every system. To build binaries compatible with your system, sync any android oreo source (AOSP, Lineage, Carbon, etc.) and run "make dtc mkdtimage -jX" instead of "make bacon" or your normal command. The binaries will be located in out/host/linux-x86/.
This is tested and working with the stock google 4.9 toolchain and the initial source as of Oct 23rd, 2017.
frap129 said:
THIS IS NOT A "HOW TO BUILD A KERNEL" POST
The Pixel 2, unlike other phones I've worked with, requires two extra tools: dtc (Device Tree Compiler) and mkdtimg.
Yes, dtc is available in the main repos for most linux distros, but the Pixel 2 kernel requires the AOSP modified version of dtc.
First, grab the Pixel 2 + XL Unified kernel source (wahoo) from https://android.googlesource.com/kernel/msm/+/android-msm-wahoo-4.4-oreo-dr1
Then download wahoo-kernel-tools.zip file attatched to this post and unzip it. Make sure that the 2 files in the bin folder are available in your path (possibly by moving them to ~/bin) and symlink or move the libc++.so into an included library directory, such as /lib, /usr/lib, or /usr/local/lib.
These specific binaries were compiled on Arch Linux by me, so they may not work on every system. To build binaries compatible with your system, sync any android oreo source (AOSP, Lineage, Carbon, etc.) and run "make dtc mkdtimage -jX" instead of "make bacon" or your normal command. The binaries will be located in out/host/linux-x86/.
This is tested and working with the stock google 4.9 toolchain and the initial source as of Oct 23rd, 2017.
Click to expand...
Click to collapse
Thanks for the files dude, you saved me some serious time since I don't need to sync AOSP
DespairFactor said:
Thanks for the files dude, you saved me some serious time since I don't need to sync AOSP
Click to expand...
Click to collapse
No problemo, I figured I'd post this since my fastboot is being retarded and I can't do much else
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
skaforey said:
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
Click to expand...
Click to collapse
Maybe? It doesn't seem like how the boot image is packed has been changed, just how the actual kernel image is put together.
nathanchance said:
Maybe? It doesn't seem like how the boot image is packed has been changed, just how the actual kernel image is put together.
Click to expand...
Click to collapse
Strange. Thanks for the response though. In the Magisk thread here, someone has posted a boot image that was simply unpacked/repacked (no changes) and we can't get it to boot. I don't want to derail this thread any further though.
skaforey said:
Forgive me for being a noob, but would these new requirements for the Pixel 2 cause existing tools used to pack/unpack the boot image fail or at least partially fail? I'm wondering if this is why we can't get Magisk to work
edit: to be clear, when I unpack the boot.img file all I see are kernel and ramdisk. When I unpack the boot.img from the Pixel 1 XL, I see those same 2 files along with devicetree.dtb and kernelimage
Click to expand...
Click to collapse
skaforey said:
Strange. Thanks for the response though. In the Magisk thread here, someone has posted a boot image that was simply unpacked/repacked (no changes) and we can't get it to boot. I don't want to derail this thread any further though.
Click to expand...
Click to collapse
No they don't, these just build the dtb/dtbo. The magisk issue is with patching sepolicy likely.
frap129 said:
No problemo, I figured I'd post this since my fastboot is being retarded and I can't do much else
Click to expand...
Click to collapse
Did you try to flash a factory image and get stuck in the bootloader? If so, extract 'image-walleye-[build number].zip' and flash each image manually. fastboot -w update doesn't work for some reason. After you flash all the images, do fastboot format userdata, and you should be back to normal. Took me a couple hours to figure this out.
ryanbg said:
Did you try to flash a factory image and get stuck in the bootloader? If so, extract 'image-walleye-[build number].zip' and flash each image manually. fastboot -w update doesn't work for some reason. After you flash each image, do fastboot format userdata, and you should be back to normal. Took me a couple hours to figure this out.
Click to expand...
Click to collapse
Thanks! I don't get stuck in the bootloader, but it won't let me flash boot images. Fastboot either hangs or spits out "remote: error: max size not reported"