hey XDA here i'm again,
i need some help with extracting the kernel from boot.img
i already got system.img and boot.img, i also can covert more files, but i don't think thats a high priority rightnow.
check this mediafire map for the files(system.img and boot.img):
http://www.mediafire.com/?myyeyniydzh
Check the attachment for the "kernel-extract.pl"
this is the error i get when i try to extract the kernel from boot.img:
Code:
[[email protected] phone]# perl extract-kernel.pl boot.img
substr outside of string at extract-kernel.pl line 23.
Use of uninitialized value $kernel in print at extract-kernel.pl line 27.
the first line is the command i used to execute the perlscript on the boot.img
can someone help me with this little problem?
Odd. I assume the script is correct - I've not bothered to compare it to a verified one. So for you it slurps in the image, but two values in the header imply the kernel is in an illogical location within. Is the image file valid? I'd check it's md5sum. Also maybe get the script to dump the header values it reads in lines 20-21.
[Edit] Of course the other explanation is that the X10 boot.img doesn't have the standard format, but why Sony would do that I don't know.
[Edit2] A quick comparison of the headers to the img you uploaded against a recent back up of my Hero's current ROM's boot.img, cross-checked against the script to see if values seem plausible, suggests your image is faulty or the X10 uses a different data structure.
cauli said:
[Edit2] A quick comparison of the headers to the img you uploaded against a recent back up of my Hero's current ROM's boot.img, cross-checked against the script to see if values seem plausible, suggests your image is faulty or the X10 uses a different data structure.
Click to expand...
Click to collapse
hmm... well i think the data structure is different then, because i used an decrypted version from the X10 forums..
it was the only version that was there, so it was the only file i could even use..
Related
I have a working Kernel - http://forum.xda-developers.com/attachment.php?attachmentid=1743802&d=1361298599
but I need prepare a new one - compilation it is no problem, but how to prepare img file for taht?.
I heard that this is a Rockchip kernel image file - so I am a looking for information how to build this kind of kernel?
Procesor is RK3066.
mafamafa said:
I have a working Kernel - http://forum.xda-developers.com/attachment.php?attachmentid=1743802&d=1361298599
but I need prepare a new one - compilation it is no problem, but how to prepare img file for taht?.
I heard that this is a Rockchip kernel image file - so I am a looking for information how to build this kind of kernel?
Procesor is RK3066.
Click to expand...
Click to collapse
If that is a zImage, then you need to pack it into boot.img in order to flash.
There are many boot.img tools out there which can help you. But the thing is you will be needing your device's original boot.img (Which can be extracted from your device depending upon the partition) which contains the Ramdisk in order to be successful.
coolsandie said:
If that is a zImage, then you need to pack it into boot.img in order to flash.
There are many boot.img tools out there which can help you. But the thing is you will be needing your device's original boot.img (Which can be extracted from your device depending upon the partition) which contains the Ramdisk in order to be successful.
Click to expand...
Click to collapse
In fact it is a regular (no gziped) image not a zImage. The file after unpacking from RK3066 format starts with bytes d3 f0 21 (to unpack I'm using rkutils ).
But I don't understand why we need to make boot.img with this file and only after that, upload boot.img to the device. Normally it should be possible just to upload kernel.img to the partition where kernel is stored, no?
After kernel from the link above is uploaded to this partition, the device boots up without problem. But when we compile new kernel and upload it (after converting with rk-tools ) it is not even possible to boot the device.
Any idea what's going on? Is compiling a kernel, then converting to rk3066 format is enough ?
flowher said:
In fact it is a regular (no gziped) image not a zImage. The file after unpacking from RK3066 format starts with bytes d3 f0 21 (to unpack I'm using rkutils ).
But I don't understand why we need to make boot.img with this file and only after that, upload boot.img to the device. Normally it should be possible just to upload kernel.img to the partition where kernel is stored, no?
After kernel from the link above is uploaded to this partition, the device boots up without problem. But when we compile new kernel and upload it (after converting with rk-tools ) it is not even possible to boot the device.
Any idea what's going on? Is compiling a kernel, then converting to rk3066 format is enough ?
Click to expand...
Click to collapse
Ok, I just had a look at your link and yes, it contains the kernel.img file. So it should be the kernel image file which needs to be flashed. What you actually needed to do is, unpack that kernel image using the tools of your choice and you'll get the ramdisk, zImage etc when unpacking. If you have compiled kernel from Sources, then you need to replace the zImage with yours (Found in arch/arm/boot) if your compilation was successful without errors and repack it to form the kernel.img.
But that doesn't mean it should boot compulsorily, it may not boot depending upon various weird reasons. You may have to fix it by yourself. Nearest bet is using your device's config file (Found in /proc/config.gz) and use that to compile your kernel. You can find all infos regarding what I've mentioned in this thread:
http://forum.xda-developers.com/showthread.php?t=1748297
I have met some problem with boot.img and need some help if there's somebody know it.
I used unmkbootimg and mkbootimg, I unpacked a boot.img then got zimage and initramfs.cpio.gz, I repacked it without any edit but the new boot.img becames smaller, it changed from 13M to 7.9M, and the phone couldn't boot from new boot.img,
and there is no question if I use a boot.img extracted from an android3.x-version rom, but if the android version changes to 4.x, the unpack-repack process would lose much size...I tested on mi2s' rom......I don't know if there are some files that will be lost in unpack process, or say the process just ignore files other than zimage and initramfs...
does anybody knows why?
binghemoye said:
I have met some problem with boot.img and need some help if there's somebody know it.
I used unmkbootimg and mkbootimg, I unpacked a boot.img then got zimage and initramfs.cpio.gz, I repacked it without any edit but the new boot.img becames smaller, it changed from 13M to 7.9M, and the phone couldn't boot from new boot.img, does anybody knows why?
Click to expand...
Click to collapse
It could be because of incorrect settings for mkbootimg or there more files,than zImage and initramfs, needed for proper work. Hard to say without more information.
Sorry for my bad English.
B.B.N. said:
It could be because of incorrect settings for mkbootimg or there more files,than zImage and initramfs, needed for proper work. Hard to say without more information.
Sorry for my bad English.
Click to expand...
Click to collapse
There is no question if I use a boot.img extracted from an android3.x version rom, but if the android version changes to 4.x, the unpack-repack would lose much size...I tested on mi2s' rom......I don't know if there are some files that will be lost in unpack process, or say the process just ignore files other than zimage and initramfs...
I used Cm 13 sources to build a bootimage for my device and everything compiled without any serious error, but i got a very large boot image 8 megabytes. I tried flashing it via TWRP but it constantly gave me error saying bootimage too large for the device.
I also forced flash the bootimage that resulted into a bricked any help would be great
My device is Samsung vibrant
Now im currently compiling the entire rom
try
http://k.japko.eu/boot-img-manipulation.html
or
Okay, first off, let me tell you I'm not at all familiar with your device...so, instead of specifically answering your questions (which would be dangerous/irresponsible of me to have you do something for which I cannot be sure of or vouch since I don't have experience with your device), I'll try to give you some general information (it does seem like you have a good grasp of many of the concepts for getting where you want to go, so maybe I can just fill-in some gaps ).
1. Regarding renaming initlogo.rle to initlogo.rle.old: I'm not sure that doing that will change the splash screen or break something when it goes to look for the initlogo.rle file (a special image file). As you've probably researched, these files are a bit odd and are not just simple image files we're all used to dealing with. I've never successfully been able to create a new initlogo.rle file on my previous attempts a few years back.
2. When you re-pack a bootable image file (boot.img or recovery.img), you need:
- re-pack the updated ramdisk to a new ramdisk.gz file
- rebuild the .img file using mkbootimg utility, specifying the kernel file and the updated ramdisk.gz file
- it's might also be important / necessary to specify the base boot address using the --base <address> parameters when issuing the mkbootimg command where <address> is the base boot address of your device; your bootable image split/unpacking utility should tell you what it sees that the base address is; here is the information I saw when I unpacked the boot.img file that you supplied in your first post:
[email protected] ~/boot-img-split-tools/ameen
$ ../split_boot.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 9600396 (0x00927d8c)
Ramdisk size: 1313051 (0x0014091b)
Second size: 0 (0x00000000)
Board name:
Command line: 'console=ttyS0,115200 rw init=/init loglevel=5'
Base address: (0x40000000)
Writing boot/boot.img-kernel ... complete.
Writing boot/boot.img-ramdisk.cpio.gz ... complete.
Unpacking ramdisk... complete.
[email protected] ~/boot-img-split-tools/ameen
- not having properly set the base boot address might explain why your device didn't boot
- not properly re-packing the ramdisk might explain why your device didn't boot
- not properly rebuilding the bootable image (using the mkbootimg utility)
3. I kind of understand what you were trying to do by changing the the .md5 file...I'm guessing that you calculated a new MD5 sum of the new boot.img file thinking that would help CWM restore it; that probably doesn't matter unless you've got the MD5/checksum verification enabled; asking/using CWM to restore / install your boot.img is an interesting and non-traditional way of doing that
4. Is the CWM custom recovery specifically built for your device? I did a quick search for it and couldn't find anything. You do indeed need a custom recovery that is built specifically for your device and it's hardware & partition / filesystem layouts and sizes. Just want to make sure that you were aware of that...using the "wrong" custom recovery might be "problematic" (bad).
Edit: I think I might have found which one you used? http://forum.xda-developers.com/showthread.php?t=2189640
5. If you had previously booted into custom recovery on your "broken" device, you still should be able to re-flash or re-launch the custom recovery in the same way that you originally did, yes? The boot and recovery partitions should be separate--so, if you only messed with the boot partition, then you should be okay--unless you've got an incompatible custom recovery that overwrote important things (like your recovery partition...).
I hope that helps...I know I didn't touch on all of your questions...that's probably enough for this post and for what follow-up questions you might have .
Cheers!
source
http://androidforums.com/threads/help-with-boot-img.963358/
I dont have much knowledge about building bootimage but while i was compiling the bootimage i got an error saying no rule to make busybox flash image. So i just copied those file from kernel sources to the out directoru i dont know if that was the problem. Also i had tried using omni 6 sources a few days back i got the right bootimage size but none of my bootimages would bootup my device. Everytime id flash the omni bootimages i got a buggy twrp recovery(faded colors, unreadable text and bootloops. Also regarding the recovery you mentioned there were some dev that built omni lollipop for my device i used TWRP 2.8 to flash all the bootimages
While trying to create my first ever Android firmware I had solve several problems, especially if you consider that I prefer under Windows instead of Linux.
I won't go into too many details as I have to assume everyone attempting this did at least some reading on the general how to of firmware installations and modifications.
Things you need:
Original firmware for your device as a IMG file
Amlogic's Customisation tool
A Rom Kitchen of your choice (I use Carliv)
System_Extractor-WIN-master
Some time...
Step1: Load the firmware into the AML tool and tick all boxes except the last one.
In the tmp folder you will find the unpacked files.
Under Level one are the files we want.
You will see a bunch of "PARTITION" files, we copy the following ones into a seperate folder for further use to create the ZIP.
I suggest to name the folder "Install" so we are all on the same page here.
boot.partition
bootloader.partition
logo.partition
recovery.partition
If you checked a flashable ZIP update before you will notice some files are missing, let's try to fix that.
Rename all partition files you copied to img, so instead of boot.partition you get boot.img.
Unpack the boot.img with your kitchen.
You will find a file "boot.img-second" - copy that into your install folder and rename it to dtb.img.
Inside the unpacked ramdisk (In your kitchen) of the boot.img you will fing the "file_contexts" file - copy that into your install folder as well.
Most AML firmware I had so far used a system.new.dat and a system.transfer.list to create the system partition.
We can create them from the system.partition file after renaming to system.img in System_Extractor-WIN-master .
To do this the system.img needs to be unpacked and we need again a copy of the file_contexts.
After the image is unpacked we can pack it again as system.new.dat and system.transfer.list.
The last missing bits can be tricky though as now we need a META-INF folder that works for our device in question.
There are two way to fix that.
Method one:
Search the usually chinese websites using Google to find original firmware for your device.
Chance are that you will find something like an OTA update - in there you will find what you need.
Method two (I never tested that):
Take the META-INF folder from an OTA update of a box with identical hardware specs.
Most important part here is the memory configuration so for a 2/16GB box you need a 2/16GB OTA update.
Next of same importance is the WiFi/Bluetooth config.
If you only have Wifi than an update for a box With daul wifi and BT4.0 won't help you.
If the actual Wifi chip is a different one but CPU, GPU, Memory and connections are the same it should still work.
Once you have the META-INF folder included into your Install folder the firmware is ready to be zipped - in theory!
The X96 for example uses a hash check for the update and created system partition.
To be able to flash your image you need to know what the original recovery would expect - has check or not.
The updater script within the META-INF folder needs to be updated to match your build.prop details as well hash check/no hash check.
Again, with an original OTA update you will find these infos.
Only if you don't have the OTA and no clue what your updater script and recovery needs you are a bit lost.
I know I has not all the steps in detail and if you are without and OTA update you need to search but otherwise feel free to ask and I will try to assist to make it complete if I can.
Downunder35m said:
While trying to create my first ever Android firmware I had solve several problems, especially if you consider that I prefer under Windows instead of Linux.
I won't go into too many details as I have to assume everyone attempting this did at least some reading on the general how to of firmware installations and modifications.
Things you need:
Original firmware for your device as a IMG file
Amlogic's Customisation tool
A Rom Kitchen of your choice (I use Carliv)
System_Extractor-WIN-master
Some time...
Step1: Load the firmware into the AML tool and tick all boxes except the last one.
In the tmp folder you will find the unpacked files.
Under Level one are the files we want.
You will see a bunch of "PARTITION" files, we copy the following ones into a seperate folder for further use to create the ZIP.
I suggest to name the folder "Install" so we are all on the same page here.
boot.partition
bootloader.partition
logo.partition
recovery.partition
If you checked a flashable ZIP update before you will notice some files are missing, let's try to fix that.
Rename all partition files you copied to img, so instead of boot.partition you get boot.img.
Unpack the boot.img with your kitchen.
You will find a file "boot.img-second" - copy that into your install folder and rename it to dtb.img.
Inside the unpacked ramdisk (In your kitchen) of the boot.img you will fing the "file_contexts" file - copy that into your install folder as well.
Most AML firmware I had so far used a system.new.dat and a system.transfer.list to create the system partition.
We can create them from the system.partition file after renaming to system.img in System_Extractor-WIN-master .
To do this the system.img needs to be unpacked and we need again a copy of the file_contexts.
After the image is unpacked we can pack it again as system.new.dat and system.transfer.list.
The last missing bits can be tricky though as now we need a META-INF folder that works for our device in question.
There are two way to fix that.
Method one:
Search the usually chinese websites using Google to find original firmware for your device.
Chance are that you will find something like an OTA update - in there you will find what you need.
Method two (I never tested that):
Take the META-INF folder from an OTA update of a box with identical hardware specs.
Most important part here is the memory configuration so for a 2/16GB box you need a 2/16GB OTA update.
Next of same importance is the WiFi/Bluetooth config.
If you only have Wifi than an update for a box With daul wifi and BT4.0 won't help you.
If the actual Wifi chip is a different one but CPU, GPU, Memory and connections are the same it should still work.
Once you have the META-INF folder included into your Install folder the firmware is ready to be zipped - in theory!
The X96 for example uses a hash check for the update and created system partition.
To be able to flash your image you need to know what the original recovery would expect - has check or not.
The updater script within the META-INF folder needs to be updated to match your build.prop details as well hash check/no hash check.
Again, with an original OTA update you will find these infos.
Only if you don't have the OTA and no clue what your updater script and recovery needs you are a bit lost.
I know I has not all the steps in detail and if you are without and OTA update you need to search but otherwise feel free to ask and I will try to assist to make it complete if I can.
Click to expand...
Click to collapse
Thank you for this explanation, but the explanation of the video to better understand everyone
Will see if I can at least add some pics while working on Nougat.
Hello,
Thanks for you tutorial.
I have a h96 Pro+ and the last firmware was a .img file... (Link of the firmware : https://mega.nz/#F!d1tHVZgA!Qc0mAom7FBHT9HDv3rGtGQ )
Is there a good guy who can convert this .img to a .zip file please ?
A lot of users are asking for this, me too and if you can help me to do this it will be really cool and appreciate
Thank you,
Carmin.
Thanks for your explanation im trting to port 7.1.1 to my tv box and i have found one funcional the only troble is the wi fi drivers not working ill give it a try latter today
Sent from my SM-N9300 using Tapatalk
I've spent last day automating the guide at https://forum.xda-developers.com/t/guide-t220-t225-flash-a-gsi-on-the-a7-lite-without-twrp.4456821/ into a bash script (linux only)!
Here it is releasing it for anyone that needs it
Code:
I am not responsible whatever happens to your device
by using this script, i have tested it on my own device
and it worked but it may or may not work for you.
I will do my best to help you but that may be limited
as i have other responsibilities in life
Before starting read the third post
UsageDownload the your desired firmware from somewhere like samfw.com and extract it
Download your desired GSI image and extract it
Download otatools-mini, gsi-build script and vbmeta image, place them all together inside one directory (extract the otatools-mini next to the script)
Download patched odin
Run this in Linux or WSL!
Code:
$ ./build-gsi.sh <PATH TO YOUR AP FILE .tar.md5> <PATH TO GSI .img>
And let it do the work, may take a while depending on your PC
You may get something like this in the process, ignore it
Code:
Invalid sparse file format at header magic
Then go into download mode (VOLUME UP and DOWN when plugging in USB) and flash the CUSTOM_AP file you got from the script and BL, CSC from the firmware you used, DO NOT USE HOME_CSC
Reboot into recovery and factory reset (VOLUME UP while booting)!
If you are getting dm-verify error then flash the vbmeta_disabled_R (it needs to be .tar, extract it) in odin as AP and try rebooting again into recovery
DownloadsI used to provide one archive but it was large and i couldnt change the script without reuploading it so i am going to use gist for the script and provide other files separately
ota-tools-mini
build-gsi.sh
Getting HelpIf you want me to help you ALWAYS post full output from the script, and make sure to use the latest script from the gist
I've spent a lot of time trying to make it work with all GSIs but i could not get it to work consistently
By default it works for all smaller GSIs, if you get the following error
Code:
ERROR: Output image is bigger than original super image, rerun the script with correct super image size
Then you will have to manually provide the new super size which i cannot help you with try to guess but it has to be divisible by 512
Not enough free space to expand partition: vendor
error while repacking
i have a lot of space . but it shows me like that
lpmake E 01-15 23:22:16 100 100 builder.cpp:698] [liblp]Not enough free space to expand partition: vendor
i am using debian wsl
Please post full script log in a spoiler or pastebin
sandorex said:
Please post full script log in a spoiler or pastebin
Click to expand...
Click to collapse
Could you try normal AP file not the magisk patched, i do not know how it modifies it
Also from my experience you do not need to patch whole AP file for magisk, you just need to patch the boot.img, zip it then flash it
OK . i will try
i tried with original ap file but same error
dxsyrz said:
i tried with original ap file but same error
Click to expand...
Click to collapse
It seems for some reason your gsi is too big, i managed to reproduce it, ill see if i can fix it
@dxsyrz can you test this one, it should work now
EDIT: i've updated the gist so you can just use that instead
good util but test more.
tom.android said:
good util but test more.
Click to expand...
Click to collapse
It worked for me, i would not release it if it did not work
sandorex said:
It worked for me, i would not release it if it did not work
Click to expand...
Click to collapse
OK sorry to write that message.
sandorex said:
It worked for me, i would not release it if it did not work
Click to expand...
Click to collapse
Well, something did not work in my case:
:: Uncompressing super image
super.img.lz4 : decoded 5637366988 bytes
:: Running simg2img
./build-gsi.sh: line 79: /mnt/c/Users/Zero/Desktop/otatools-mini/otatools-mini/simg2img: No such file or directory
^ Despite the files actually existing. You tell me cuz I've no idea (do note I do know how to do this manually, was just trying your script to simplify everything).
nirogu325 said:
Well, something did not work in my case:
:: Uncompressing super image
super.img.lz4 : decoded 5637366988 bytes
:: Running simg2img
./build-gsi.sh: line 79: /mnt/c/Users/Zero/Desktop/otatools-mini/otatools-mini/simg2img: No such file or directory
^ Despite the files actually existing. You tell me cuz I've no idea (do note I do know how to do this manually, was just trying your script to simplify everything).
Click to expand...
Click to collapse
You need to place otatools-mini in folder next to the script not together with the script
hi i have this problem
izimen said:
hi i have this problem
View attachment 5814501
Click to expand...
Click to collapse
You havs a space in your path, its actually a bug but you can jist move the files to somewhere without spaces
EDIT: Fixed it on gist
sandorex said:
You havs a space in your path, its actually a bug but you can jist move the files to somewhere without spaces
EDIT: Fixed it on gist
Click to expand...
Click to collapse
ok i try
bro it worked thank you I managed to make it work with a GSI and when I try with another I have this error