Related
1) download source code from https://opensource.samsung.com/index.jsp. You are looking for source code for SGH-T839.
2) Get initramfs (Need to make a kernel package)
Extract it using extract boot http://www.mediafire.com/?lc12eceeh617b97.
This is why I am looking for a boot.img
extract it
Code:
tar -xvf extractboot.tar.gz
now move into directory with extract boot and copy your boot.img into here and do
Code:
./extractboot boot.img
3) Get mkboot tools
http://www.mediafire.com/?w06d1m6n1dgo4op
untar it by doing
Code:
tar -xvf $FILENAMEHERE
Add the bin directory to your path by moving to the bin directory and copying down the path then
Now you will add this to your path by editing your .bashrc file.
Go to your bashrc file
Code:
gedit ~/.bashrc
and adding this
Code:
PATH=$PATH:/FULLDIRECTORYYOUWROTEDOWN/
export PATH
4) Download the ARM toolchain
https://sourcery.mentor.com/sgpp/lite/arm/portal/package5385/public/arm-none-linux-gnueabi/arm-2009q3-67-arm-none-linux-gnueabi.bin
and
https://sourcery.mentor.com/sgpp/lite/arm/portal/package5355/public/arm-none-eabi/arm-2009q3-68-arm-none-eabi.bin
5) Install the ARM Toolchain
create the directory /opt/toolchains/arm-2009q3/
Code:
sudo mkdir /opt/toolchains/arm-2009q3/
then install the toolchain using /opt/toolchains/arm-2009q3/
as the install directory
Code:
sudo chmod +x arm-2009q3-68-arm-none-eabi.bin
sudo chmod +x arm-2009q3-67-arm-none-linux-gnueabi.bin
sudo ./arm-2009q3-67-arm-none-linux-gnueabi.bin -i console
sudo ./arm-2009q3-68-arm-none-eabi.bin -i console
6) Compile
Extract your source code and go to the directory Kernel and do the following
WARNING: MAKE SURE THERE ARE NO SPACES IN YOUR FILEPATH BECAUSE THE MAKEFILE DOESNT LIKE THEM.
Code:
make clean
make arch=arm sidekick_rev02_defconfig
make ARCH=arm HOSTCFLAGS="-g -O3" -j8 CROSS_COMPILE=/opt/toolchain/bin/arm-none-eabi-
Now copy any of the resulting compiled ko files into the initramfs file you have extracted and you should have what you need to package a kernel.
you forget initramfs
windxixi said:
you forget initramfs
Click to expand...
Click to collapse
yeah I kept it out so that somebody would post a boot.img then could do steps related to that. I am looking for a boot.img to get initramfs from
unpack zImage
Sent from my SGH-T839 using XDA
---------- Post added at 08:46 AM ---------- Previous post was at 07:49 AM ----------
and how to pack a boot.img?
A request to anyone building SK4G kernels.
Please disable the keystroke logging printk statements in the file:
Code:
drivers/input/keyboard/s3c-keypad.c
The lines look like this:
Code:
//printk("\nkey Pressed : key %d map %d\n",i, pdata->keycodes[i]);
and
Code:
//printk("\nkey Released : %d map %d\n",i,pdata->keycodes[i]);
It is possible to recover the actual keystrokes from the numerical codes those statements log, and the messages go into the dmesg buffer. So it's pretty easy to extract them and determine exactly what the user typed.
In the latest Samsung sources I've seen, those lines were already commented out. It makes sense to enable them while debugging a new ROM build, but please do disable them prior to building a kernel intended for general consumption.
Do you guys know if the available source code will produce a kernel that will work with kj2? the kernel version in SGH-T839_Opensource_Update1 looks to match up, but I compilied a zImage and it didn't boot on stock kj2. but I could very well be missing something.
I have done a small amount of kernel work on an HTC device, but I basically just used the Rom Kitchen to pack up my zImages with a boot.img-ramdisk to create a boot.img. I guess I might need a little more instruction for packing up a Samsung kernel. Is it also an option to just tar up the zImage and flash it with Odin/Heindall?
Thanks for this thread, and for any other advice!
Sent from my SGH-T839 using Tapatalk 2
In case it might be useful to someone else working on building a kernel.
The official and Bali_SK4G sources both seem to insist on building with debug symbols enabled for some of the modules. In particular, i was ending up with dhd.ko being 2.4 MB in size, where it should have been less than 400 KB.
The ideal case would be to determine why the debug symbols are being included -- commenting out the labelled debug options in the bcm4329 Makefile didn't accomplish this.
But a workaround is to strip the modules after the build is finished, before assembling the initramfs.
Has anyone been able to build a working zImage for KJ2 using Dr. Honk's Bali sources [1] and sduvick's KJ2 ramdisk files [2]?
I have been able to build a zImage of a reasonable size (6520 KB). But when I flash this to the KERNEL partition using heimdall, the device boot loops to the B&W Sidekick logo. It doesn't get far enough to show any adb log output.
I can then use the same heimdall flashing procedure to flash the Platypus Egg v1 zImage, or other KJ2-compatible zImage files, and the device boots and works properly.
So I'm trying to figure out what I'm doing wrong in building my zImage. If anyone has any advice I would be appreciative.
[1] https://github.com/drhonk/Bali_SK4G
[2] https://github.com/sduvick/SK4g_KJ2_Ramdisk
I got an updated Bali_SK4G kernel booting using the ramdisk from GenericGinger 2.0.
I have worked up some patches to disable the logging of keystrokes and other more trivial debug spew in dmesg. Also included is a Makefile patch that was required for the compile to complete with my toolchain.
https://carbon.flatlan.net/nxd/patches_Bali_SK4G_nxd.tar.bz2
md5sum: 5d14ac32de155cdca0fd82f14bc4ceca
These patches are GPL licensed, in compliance with the license for the Linux kernel itself. I make no guarantees about their suitability for any purpose. I grant permission to use them to anyone who would like to do so, so long as they comply with the GPL.
I'd like to make a compiled kernel available with these changes, but XDA's rules can be interpreted to mean that I must obtain permission from a series of upstream contributors, some of whom may not be reachable. Perhaps a moderator will clarify the parameters of the permission rule.
Dear All,
I have been building some custom Android ROMS for the past few years, and my latest toy is a Flytouch 3 I wanted to share some of my findings and methods here, perhaps other newbies like me will find it useful.
1. FT3 ROM contents:
FT3 ROMs will be in RAR or ZIP format and have 2 or 3 files in them as explained below. Just unzip or unrar the package to use them:
firmware2 - flash tool which burns the firmware ( I guess...lol)
bootloader-discovery - 7zip file which contains the bootloader
IMPORTANT! Do not flash a wrong bootloader to your device or it will be bricked! Actually this is the only way you can brick the thing, it's pretty sturdy in that sense. If you are not sure, do not copy bootloader-recovery to your sdcard when flashing, it will boot with your existing bootloader anyway.
firmware-discovery - 7zip file which contains the firmware and it's the main file you want to edit.
2. firmware-discovery contents:
This is the easy part! Modifying this file will let you modify system and data partitions. You can also use different ramdisks and kernels compatible with your device. It's a 7zip file and you can unpack and repack easily with the 7-zip file manager (http://www.7-zip.org/).
I use 7-zip on Windows although I use Ubuntu Linux as my main OS. There is something wrong with my 7-zip installation most probably, but I was too lazy to check it If you are on Windows anyway, you are good, just download and use 7-zip from the URL above. I advise that you do all your firmware-discovery editing within 7-zip file manager. That way, you won't have to worry about re-packing with the correct 7-zip settings. At least, that's how I do it and had no problems.
firmware-discovery will have these files in the 7zip package:
uImage - kernel
Very important Your kernel will make the difference between having and not having certain functionality, even if your hardware supports it.
uImage_recovery - recovery file - I beleive this is what runs when you push menu+power.
ramdisk.img - ramdisk
This is one of the interesting files you might want to play with. Ramdisk is a simple file system with some crucial files, mainly init.rc that lets you control the boot process. You can also stick a initlogo.rle image here to display a splash image in initial boot. More details below at title 4.
data.tar - /data partition - tar archive
All user data is stored here, including apps and user definable settings. This is what gets wiped when you do a recovery by pushing menu+power.
system.tar - /system partition - tar archive
System data, drivers and apps, including Android OS itself (except kernel). Certainly the most interesting part for the average modder
3. Editing system.tar and data.tar:
This might be the bulk of your modding, and most probably what will be most visible to the end user.
I very strongly suggest that you use a Linux system to edit these files. If you use Windows, file permissions will not be saved! If Windows is your main OS, simply install a VM host such as VirtualBox and install your fav Linux distro inside it. Most of them will have an Archive Manager with a GUI and will certainly support TAR. Even without a GUI, you can use "tar" and "untar" commands from a terminal to unpack and repack these files. When you are on Linux, TAR files will preserve file ownership and file permissions. This can be very crucial in your modding.
For modders who are new to Linux, I can recommend Ubuntu. It's very user friendly and easy to use in my opinion.
When you are done editing system.tar and data.tar copy them to your Windows box and drop and them to firmware-recovery file within 7-zip file manager.
4. Unpack, Edit and Repack ramdisk.img:
Now we are on to more serious stuff ramdisk.img consists of a 64 byte U-Boot header, followed by a gzip compressed ramdisk cpio image. So we need to strip the first 64 bytes, and use gunzip to extract it to a folder. After making the changes in the folder, we need apply cpio+gzip compression to the folder and add the 64 byte u-boot header again. You will need to use Linux and install the mkimage tool for these operations.
Here's the command to install mkimage tool in Ubuntu:
Code:
sudo apt-get install uboot-mkimage
It sounds complicated, but no worries, I have some shell scripts that can do all that for you! Thanks to leeh33 from Techknow for the scripts below:
unpack_ramdisk.sh
Code:
mkdir ramdisk
cd ramdisk
dd if=../ramdisk.img bs=64 skip=1 of=ramdisk.gz
gzip -dc ramdisk.gz | cpio -idmv
rm ramdisk.gz
repack_ramdisk.sh
Code:
cd ramdisk
find . | cpio -o -H newc -C 512 | gzip -n > ../ramdisk.cpio.gz
cd ..
mkimage -A ARM -O Linux -T ramdisk -C none -a 0x41000000 -e 0x41000000 -n hRamdisk -d ramdisk.cpio.gz ramdisk.img
rm ramdisk.cpio.gz
Create the scripts above using a text editor or download the attachment to this post and put the scripts together with your ramdisk.img file in a new folder. Executing unpack_ramdisk.sh will create a folder named ramdisk and extract the ramdisk contents here. You can edit e.g. init.rc in this folder, or add a static bootlogo. To add a custom bootlogo create a initlogo.rle image file by following this guide: http://www.androidtablets.net/forum/android-tablet-hacking/438-how-setup-static-bootlogo-before-animated-boot-animation.html Then place the resulting initlogo.rle file directly in the ramdisk directory.
After you are done editing the ramdisk folder, simply run repack_ramdisk.sh and your new ramdisk.img will be created, replacing the old one. Copy the ramdisk.img file to your Windows box again and drop it to firmware-recovery file within 7-zip file manager.
That's it, you have a custom ROM now! Please feel free to ask questions or correct me if you think I have any errors in the info above.
Happy Modding!!!
Tolga
Big problem about my device...
Thank you for this useful post!
I have seen a good knowledge about these devices(flytouch 3) and decided to post my question here:
I have a big problem! I used IUW Burning tool to flash my device. my device is:
SuperPad III (As box says)
Model: ANDR P1001
I decided to try tim's custom rom. It doesn't work. After restarting the device, screen become black (There was no connection
with screen, it was not turned on). The device had vibration when I pressed power button. It continued vibrating periodically(like it was restarting).
After that I flashed my device using IUW with most likely firmware, but during the process I FORGOT TO CHOOSE userdata.img FILE!
Now the device can't even communicate with pc.
OTG method is not working. The device no more vibrates at start up! At motherboard led is lighting when pressing power button.So IS MY DEVICE DEAD? Or is there any solution in this situation(Alternative communication, or whatever...)
I following the instructions found from here:
Building Kernels
and download the kernel from here:
INDEX of ROMS/RECOVERY/ROOT/GUIDES/FIRMWARE/KERNEL/VIDEOS/etc..
I am using TF300TG, so I just followed the link to my tablet kernel source from the thread. I have successfully built the kernel by using the config.gz found in the tablet /proc/config.gz (is great that Asus is providing such info). I also enable a kernel module for my old USB ethernet dongle and able to use it to get online. :victory:
After poking around the kernel configuration, and reading the thread TF300T kernel source repository, I am curious about enabling OC and possible other features. I had downloaded the update.zip from the thread, and trying to understand the whole process of how to flash kernel to the tablet. My idea is to modify the update.zip to make use of it to update my tablet. But before I start doing something serious, I have questions...
I found the following kernel file: kernel.blob in update.zip. Is this the same file as 'zImage' in arch/arm/boot/ after built successful?
The next question is on how to backup my existing kernel? I notice from the update-script, the kernel is flash using the following command:
run_program("/sbin/busybox", "dd", "if=/tmp/kernel.blob", "of=/dev/block/mmcblk0p4");
Click to expand...
Click to collapse
Does this mean, I can run the same command in reverse to keep a copy of my current kernel?
I had done kernel compiling before, but those were in PC/x86 platform. ARM platform seems to be different from what I used to.
I found the following kernel file: kernel.blob in update.zip. Is this the same file as 'zImage' in arch/arm/boot/ after built successful?
Click to expand...
Click to collapse
Not exactly...
A blob file is a sort of archive that can contain several files.
For example, the kernel.blob you mention above contains the actual kernel (zImage) but also a ram disk.
As far as I understand a blob file is the only type of file that can be flashed to different partitions of your TF300T(G) using fastboot method.
To flash using CWM or TWRP you will need to pack blob file(s) into a special kind of zip package.
Below I have shared my script that I use to create a TWRP flashable zip package including a custom built kernel.
Hopefully it may shed some light in the steps required to go from zImage to blob file and TWRP flashable zip package.
The script takes the root path to your kernel source directory as first (and only) argument.
In same directory as script I have unpacked update.zip (from untermensch's kernel repository thread) as parts of this zip file are re-used.
---
#!/bin/sh
KERNEL_HOME=$1
KERNEL_NAME=my_kernel_$$
# Repack new kernel and old ram disk into blob file
cp ${KERNEL_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# Prepend magic header
cat signblob_magic out.blob > kernel.blob
# Add kernel modules to ensure kernel and modules always match.
# If mismatch e.g WiFi might not work.
find ${KERNEL_HOME} -name "*.ko" -exec cp {} system/lib/modules \;
# Save kernel config in case it needs to be rebuilt some day.
cp ${KERNEL_HOME}/.config kernel_config
# Zip everything
zip -9 -r ${KERNEL_NAME}.zip kernel_config kernel.blob system/ META-INF/
# Sign zip using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
---
The next question is on how to backup my existing kernel? I notice from the update-script, the kernel is flash using the following command:
Does this mean, I can run the same command in reverse to keep a copy of my current kernel?
Click to expand...
Click to collapse
In theory this should work but if not mistaken mmcblk0p4 is just a sort of staging partition.
During bootup whatever is in mmcblk0p4 is copied to another partition (mmcblk0p0?).
(I guess this is the blue bar you can observe when flashing custom roms/kernels)
Someone more familiar with the details please correct me.
Instead of trying to backup your current kernel I would suggest to try to get the original
kernel by unpacking the official update packages from ASUS support web page.
I had done kernel compiling before, but those were in PC/x86 platform. ARM platform seems to be different from what I used to.
Click to expand...
Click to collapse
Not that much different really, just need to search the google.com and XDA forums and you shall find answers...
gaze57 said:
Not exactly...
A blob file is a sort of archive that can contain several files.
For example, the kernel.blob you mention above contains the actual kernel (zImage) but also a ram disk.
As far as I understand a blob file is the only type of file that can be flashed to different partitions of your TF300T(G) using fastboot method.
To flash using CWM or TWRP you will need to pack blob file(s) into a special kind of zip package.
Below I have shared my script that I use to create a TWRP flashable zip package including a custom built kernel.
Hopefully it may shed some light in the steps required to go from zImage to blob file and TWRP flashable zip package.
The script takes the root path to your kernel source directory as first (and only) argument.
In same directory as script I have unpacked update.zip (from untermensch's kernel repository thread) as parts of this zip file are re-used.
---
#!/bin/sh
KERNEL_HOME=$1
KERNEL_NAME=my_kernel_$$
# Repack new kernel and old ram disk into blob file
cp ${KERNEL_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# Prepend magic header
cat signblob_magic out.blob > kernel.blob
# Add kernel modules to ensure kernel and modules always match.
# If mismatch e.g WiFi might not work.
find ${KERNEL_HOME} -name "*.ko" -exec cp {} system/lib/modules \;
# Save kernel config in case it needs to be rebuilt some day.
cp ${KERNEL_HOME}/.config kernel_config
# Zip everything
zip -9 -r ${KERNEL_NAME}.zip kernel_config kernel.blob system/ META-INF/
# Sign zip using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
---
In theory this should work but if not mistaken mmcblk0p4 is just a sort of staging partition.
During bootup whatever is in mmcblk0p4 is copied to another partition (mmcblk0p0?).
(I guess this is the blue bar you can observe when flashing custom roms/kernels)
Someone more familiar with the details please correct me.
Instead of trying to backup your current kernel I would suggest to try to get the original
kernel by unpacking the official update packages from ASUS support web page.
Not that much different really, just need to search the google.com and XDA forums and you shall find answers...
Click to expand...
Click to collapse
Whoa... Thanks for the info. I go read up more on this.
This is the stock kernel without system write protection. Completely stock configuration, completely stock ramdisk. The only difference is it allows write to system
Uses Telstra 3.17.841.2 source from htcdev.com:
http://dl4.htc.com/RomCode/Source_and_Binaries/evitaul-jb-crc-3.4.10-240d4d5.zip
Devs who need a vanilla kernel are free to modify or include with ROMs
installer: http://goo.gl/64HJc
boot.img: http://goo.gl/IRZ9m
Does this also uninstall any old modules?
Sent from my VENOMized HoxL
area51avenger said:
Does this also uninstall any old modules?
Sent from my VENOMized HoxL
Click to expand...
Click to collapse
The installer deletes /system/lib/modules/wp_mod.ko and /system/lib/wp_mod.ko
There is no init.d support either, so it won't load any init scripts.
Nice job, this should be useful! :good:
On my side, I had some problems. I have tried to compile the kernel, but I went a little bit further with the modifications:
disabled the /system write protection.
integrated the prima_wlan source tree in drivers/staging. The sources were downloaded from the codeaurora.org site and the driver version was 3.1.7.16 (I have specifically chosen this version because it was the closest to the 3.1.7.0 version that exists in the stock ROM).
compressed the vmlinux image with LZMA instead of gzip (this is an option in the configuration) to obtain the zImage file.
compressed the ramdisk image with LZMA instead of gzip (in the configuration file, I have seen 3 enabled options: gzip, LZMA and XZ and I thought recompressing the ramdisk might not hurt).
The toolchain I have used was downloaded from android.googlesource.com. Then I have unpacked the original boot.img like this: trimmed the first 128 bytes from the file (up to the ANDROID magic label), then used the unpackbootimg tool (this was a tool I have found in a Gingerbread source tree). Then, I have used the new zImg, the LZMA compressed ramdisk and mkbootimg (this was also picked from the same Gingebread source tree) to build a new boot.img. I have booted in the recovery, flashed the new modules, then booted in fastboot mode and flashed the boot.img. The result was an annoying boot loop and it wasn't very easy to put the phone in fastboot mode again.
I have some questions about what I have done so far. Could you, please, tell me if there was a wrong manoeuvre/setting/thingie? I suspect the unpacking process has not produced the proper data (command line, base address ...). What tool have you used to unpack the original boot.img file? I also suspect the packing process. Is a new mkbootimg required?
And some questions about your work. What prima_wlan driver have you used in your boot.img? Have you modified the suffix added to the 3.4.10 version when you have configured the kernel in order to make it work?
AlxMAX said:
On my side, I had some problems. I have tried to compile the kernel, but I went a little bit further with the modifications:
disabled the /system write protection.
integrated the prima_wlan source tree in drivers/staging. The sources were downloaded from the codeaurora.org site and the driver version was 3.1.7.16 (I have specifically chosen this version because it was the closest to the 3.1.7.0 version that exists in the stock ROM).
compressed the vmlinux image with LZMA instead of gzip (this is an option in the configuration) to obtain the zImage file.
compressed the ramdisk image with LZMA instead of gzip (in the configuration file, I have seen 3 enabled options: gzip, LZMA and XZ and I thought recompressing the ramdisk might not hurt).
The toolchain I have used was downloaded from android.googlesource.com. Then I have unpacked the original boot.img like this: trimmed the first 128 bytes from the file (up to the ANDROID magic label), then used the unpackbootimg tool (this was a tool I have found in a Gingerbread source tree). Then, I have used the new zImg, the LZMA compressed ramdisk and mkbootimg (this was also picked from the same Gingebread source tree) to build a new boot.img. I have booted in the recovery, flashed the new modules, then booted in fastboot mode and flashed the boot.img. The result was an annoying boot loop and it wasn't very easy to put the phone in fastboot mode again.
I have some questions about what I have done so far. Could you, please, tell me if there was a wrong manoeuvre/setting/thingie? I suspect the unpacking process has not produced the proper data (command line, base address ...). What tool have you used to unpack the original boot.img file? I also suspect the packing process. Is a new mkbootimg required?
And some questions about your work. What prima_wlan driver have you used in your boot.img? Have you modified the suffix added to the 3.4.10 version when you have configured the kernel in order to make it work?
Click to expand...
Click to collapse
use dsi xda kitchen to pack the boot.img for easy use
or
use this
unpackbootimg -i boot.img -o /directoryfordump
mkbootimg --cmdline 'console=ttyHSL0,115200,n8' --kernel zImage --ramdisk ramdisknew.gz --base 80400000 --ramdiskaddr 81900000 -o newboot.img
Where have you got that ramdisk address from? unpackbootimg doesn't report it.
Zarboz said:
mkbootimg --cmdline 'console=ttyHSL0,115200,n8' --kernel zImage --ramdisk ramdisknew.gz --base 80400000 --ramdiskaddr 81900000 -o newboot.img
Click to expand...
Click to collapse
Edit: I have done some research on mkbootimg and unpackbootimg and their usage is a little bit confusing. The boot image header contains a kernel address, a ramdisk address and some other data (including the command line provided to the kernel by the bootloader). The mkbootimg tool like it is in the Android repository uses more measures: a base address, a kernel offset, a ramdisk offset etc. The kernel address is base + kernel offset and so on. When unpacking the boot image with unpackbootimg, one must suppose one of the parameters fixed, usually the kernel offset (0x00008000). Consequently, the base address is computed as the kernel address - the kernel offset. To conclude, the command line to use should be:
Code:
mkbootimg --cmdline 'console=ttyHSL0,115200,n8' --base 80400000 --ramdisk_offset 1408000 --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz -o boot-2.img
This produces the same boot.img as the one posted by flar2, except for the command line.
Edit 2: I have recompiled the kernel, disabled the /system protection, used the mkbootimg command line right above and now my phone boots and runs well. The prima_wlan.ko that I have compiled together with the kernel (3.1.7.16 from codeaurora source repository) doesn't work. It might be a matter of wi-fi firmware. Fortunately, the stock prima_wlan.ko (proprietary 3.1.7.0) module works well.
AlxMAX said:
Where have you got that ramdisk address from? unpackbootimg doesn't report it.
Edit: I have done some research on mkbootimg and unpackbootimg and their usage is a little bit confusing. The boot image header contains a kernel address, a ramdisk address and some other data (including the command line provided to the kernel by the bootloader). The mkbootimg tool like it is in the Android repository uses more measures: a base address, a kernel offset, a ramdisk offset etc. The kernel address is base + kernel offset and so on. When unpacking the boot image with unpackbootimg, one must suppose one of the parameters fixed, usually the kernel offset (0x00008000). Consequently, the base address is computed as the kernel address - the kernel offset. To conclude, the command line to use should be:
Code:
mkbootimg --cmdline 'console=ttyHSL0,115200,n8' --base 80400000 --ramdisk_offset 1408000 --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz -o boot-2.img
This produces the same boot.img as the one posted by flar2, except for the command line.
Edit 2: I have recompiled the kernel, disabled the /system protection, used the mkbootimg command line right above and now my phone boots and runs well. The prima_wlan.ko that I have compiled together with the kernel (3.1.7.16 from codeaurora source repository) doesn't work. It might be a matter of wi-fi firmware. Fortunately, the stock prima_wlan.ko (proprietary 3.1.7.0) module works well.
Click to expand...
Click to collapse
you have to do some haxxing to get the CAF prima to load up
Zarboz said:
you have to do some haxxing to get the CAF prima to load up
Click to expand...
Click to collapse
I am interested of that hack. Could you, please, send me a link to some documentation about it?
AlxMAX said:
I am interested of that hack. Could you, please, send me a link to some documentation about it?
Click to expand...
Click to collapse
There isn't any I have found just trial and error
Sent from my HTC One X using xda app-developers app
Zarboz said:
There isn't any I have found just trial and error
Click to expand...
Click to collapse
If you are referring to the code enclosed by #ifdef CONFIG_HTC_WIFI_NVS ... #endif in wlan_hdd_main.c, then it is not simple trial and error. Have you picked the code from somewhere else and integrated into the prima sources or have you found the prima sources containing already that piece of code?
About
These two applets ( mkbootimg + unpackbootimg ) are used to pack and unpack any standard android kernel with 4096 / 2048 page size . Most of tools that pack and unpack boot.img files such as Dsixda kitchen , Kernel kitchen or. ... use these applets .
These applets were compiled only for X86 so we could only (un)pack boot.img in Windows or Ubuntu but I compiled and fixed these applets for Arm7 platform on android devices from Android sources. So you may pack and unpack boot.img on any android device !!
Sources are here ( Lisenced under GPL 2.0 lisence ) : My github
How to use
1- First download applets package
2- Unzip it and push two files in it to /system/bin or /system/xbin
3- Set their pemissions to 777 ( rwxrwxrwx )
For unpacking a kernel
* Assuming that you have boot.img in /sdcard
* Open terminal and type : [ this is just an example , you can change it ]
Code:
su
unpackbootimg -i /sdcard/boot.img -o /sdcard/ -p 4096
*You will have extracted boot.img at /sdcard
* Save ouput information that applets gives you at the end . you need them in future
For packing a kernel
* Copy ramdisk.gz , zimage , cmdline , pagesize , base you got from unpacking boot.img into /sdcard
* Open terminal and type :
Code:
su
mkbootimg --cmdline cmdline --kernel zimage --ramdisk ramdisk.gz --base base --pagesize pagesize -o boot.img
* You will have output ( boot.img ) at /sdcard/boot.img
Download
Download build 1 @ Dev-Host
* Initial build
Credits
* Alireza7991 - for fixing , improving and cross-compiling for arm^7
* Andrew Huang ( [email protected]) - for sources
* Android Open Source Project - for sources
This applet is under GPL 2.0
Using this is free but you have to ask me if you want to use this in your tools or ...
Reserved for OP
very cool, :good::good::good:
Awesome thanks for sharing your work !
I'll be back in a flash
A better link would be really cool can't DL it to my nexus for the life of me :banghead:
Rushing said:
Awesome thanks for sharing your work !
I'll be back in a flash
A better link would be really cool can't DL it to my nexus for the life of me :banghead:
Click to expand...
Click to collapse
What problem do you have with download link ?
segmentation fault
Hey
Trying to unpack a samsung kernel, but I get this error
BUILDER: Alireza7991
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE e19f8000
BOARD_PAGE_SIZE 24061976
Segmentation fault
I guess my boot.img is not supported?
biopsin said:
Hey
Trying to unpack a samsung kernel, but I get this error
BUILDER: Alireza7991
BOARD_KERNEL_CMDLINE
BOARD_KERNEL_BASE e19f8000
BOARD_PAGE_SIZE 24061976
Segmentation fault
I guess my boot.img is not supported?
Click to expand...
Click to collapse
I have unpacked Samsung Galaxy S plus kernel successfuly
Only 2048 & 4096 page sizes are supported !
Edit : I have forgot to say Samsung exynose kernel which uses zImage as in SGS 1/2/3 are not supported
alireza7991 said:
For unpacking a kernel
Click to expand...
Click to collapse
For a good understanding of the structure of boot and recovery images can read such here.
So, now that I unpacked my boot.img, next question is:
How can I modify them through the phone also? Does an application that modifies ramdisk.gz / zImage exist?
I can modify my APKs' xmls and smali files and recompile then on my phone, so I'm wondering if I can modify this also on my phone.... Can it be?
Edit: I tried unpacking boot.img-ramdisk.gz via TermEmu:
Code:
lzma -dc ../boot.img-ramdisk.gz | cpio -i
But, as I expected, it failed and says:
Code:
lzma: out of memory
(Yes I'm new at this thing. Still worth trying )
So, any other workarounds to unpack and modify these babies via our phones?
souler456 said:
So, now that I unpacked my boot.img, next question is:
How can I modify them through the phone also? Does an application that modifies ramdisk.gz / zImage exist?
I can modify my APKs' xmls and smali files and recompile then on my phone, so I'm wondering if I can modify this also on my phone.... Can it be?
Edit: I tried unpacking boot.img-ramdisk.gz via TermEmu:
Code:
lzma -dc ../boot.img-ramdisk.gz | cpio -i
But, as I expected, it failed and says:
Code:
lzma: out of memory
(Yes I'm new at this thing. Still worth trying )
So, any other workarounds to unpack and modify these babies via our phones?
Click to expand...
Click to collapse
I'm amazed , how do you unpack APKs on your phone ? I saw sth for packing APKs but I do'nt know how to decompile APKs
ZImage is a static executable of compiled kernel . but ramdisk is an small file system which includes some essential files for booting your phone such as init.rc , and ... . ramdisk has two compressions , cpio and gz . first you have to gunzip it and then uncpio .
I'm working on a ramdisk unpack tool too .
alireza7991 said:
I'm amazed , how do you unpack APKs on your phone ? I saw sth for packing APKs but I do'nt know how to decompile APKs
ZImage is a static executable of compiled kernel . but ramdisk is an small file system which includes some essential files for booting your phone such as init.rc , and ... . ramdisk has two compressions , cpio and gz . first you have to gunzip it and then uncpio .
I'm working on a ramdisk unpack tool too .
Click to expand...
Click to collapse
I use Apktool, but ported to my phone (yes, an Apktool which is an APK) to get my APKs down and dirty. I'm sure it's on XDA, but I forgot where I did get it though...
For the ramdisk to be unpacked, can I use those commands (gunzip) and execute them via TermEmu? Did you tried it yet?
Also, I don't have a single idea of what a zImage is (except the one you just said, which is also kinda noob-shot my head), what's contained about it, and how to modify it for my tastes... Any tutorials you may shed some?
Will wait patiently for the development of your works related with this. It's really great man
souler456 said:
I use Apktool, but ported to my phone (yes, an Apktool which is an APK) to get my APKs down and dirty. I'm sure it's on XDA, but I forgot where I did get it though...
For the ramdisk to be unpacked, can I use those commands (gunzip) and execute them via TermEmu? Did you tried it yet?
Also, I don't have a single idea of what a zImage is (except the one you just said, which is also kinda noob-shot my head), what's contained about it, and how to modify it for my tastes... Any tutorials you may shed some?
Will wait patiently for the development of your works related with this. It's really great man
Click to expand...
Click to collapse
Since some people here don't know there was an apktool for android then I'll just create a thread for it with instructions for noobs
souler456 said:
I use Apktool, but ported to my phone (yes, an Apktool which is an APK) to get my APKs down and dirty. I'm sure it's on XDA, but I forgot where I did get it though...
For the ramdisk to be unpacked, can I use those commands (gunzip) and execute them via TermEmu? Did you tried it yet?
Also, I don't have a single idea of what a zImage is (except the one you just said, which is also kinda noob-shot my head), what's contained about it, and how to modify it for my tastes... Any tutorials you may shed some?
Will wait patiently for the development of your works related with this. It's really great man
Click to expand...
Click to collapse
I found apk tool on android not on xda , on google code .
Zimage can not be modified because it is compiled , also can not be decompiled . so you can not modify it .
when boot process starts , bootloader reads zimage from pre-defined partition and loads it in ram . then it calls cpu to execute zimage . when zimages executes it sets up initial board configurations ( such as regulators , GPIOs and ... ) , drivers and ... . then it opens ramdisk and unpacks ramdisk . when ramdisk opens , init process starts by kernel . it executes init.rc , init.<target>.rc . init.rc sets up initial kernel configurations and any other thing related to android . init.rc executes some initial android binarys such as bootanimation , surface flinger , adb and finally app process . app process turns on java and dalvik enviroments . finally framework and other java classes runs and android appears
Did you understand what is zimage and ramdisk ??
Juhan Jufri said:
Since some people here don't know there was an apktool for android then I'll just create a thread for it with instructions for noobs
Click to expand...
Click to collapse
You don't have to. There's already a thread for it (found it 35mins after I started the topic ) : http://forum.xda-developers.com/showthread.php?t=2388135
It will only be deleted by Mods, so, yeah...
alireza7991 said:
I found apk tool on android not on xda , on google code .
Zimage can not be modified because it is compiled , also can not be decompiled . so you can not modify it .
when boot process starts , bootloader reads zimage from pre-defined partition and loads it in ram . then it calls cpu to execute zimage . when zimages executes it sets up initial board configurations ( such as regulators , GPIOs and ... ) , drivers and ... . then it opens ramdisk and unpacks ramdisk . when ramdisk opens , init process starts by kernel . it executes init.rc , init.<target>.rc . init.rc sets up initial kernel configurations and any other thing related to android . init.rc executes some initial android binarys such as bootanimation , surface flinger , adb and finally app process . app process turns on java and dalvik enviroments . finally framework and other java classes runs and android appears
Did you understand what is zimage and ramdisk ??
Click to expand...
Click to collapse
Yes. Thanks so much!
So the probability of a modifying process can only be done by the ramdisk only? Well...
souler456 said:
You don't have to. There's already a thread for it (found it 35mins after I started the topic ) : http://forum.xda-developers.com/showthread.php?t=2388135
It will only be deleted by Mods, so, yeah...
Yes. Thanks so much!
So the probability of a modifying process can only be done by the ramdisk only? Well...
Click to expand...
Click to collapse
Oh ****, just created it. But with somewhat better instructions for newbies.
alireza7991 said:
I'm amazed , how do you unpack APKs on your phone ? I saw sth for packing APKs but I do'nt know how to decompile APKs
ZImage is a static executable of compiled kernel . but ramdisk is an small file system which includes some essential files for booting your phone such as init.rc , and ... . ramdisk has two compressions , cpio and gz . first you have to gunzip it and then uncpio .
I'm working on a ramdisk unpack tool too .
Click to expand...
Click to collapse
waiting for this unpack tool...
I only make,decompile,theme and mod apks via my phone...
so slicing up the boot.img via phone is a good additiob too.... XD
great work for this...haven't tried it yet...
but will do whenever the unpack tool is also ready... XD
alireza7991 said:
I'm working on a ramdisk unpack tool too .
Click to expand...
Click to collapse
I'm waiting for this .
Captain_Throwback said:
I'm waiting for this .
Click to expand...
Click to collapse
done
Code:
cpio -i < ramdisk.gz
alireza7991 said:
About
These two applets ( mkbootimg + unpackbootimg ) are used to pack and unpack any standard android kernel with 4096 / 2048 page size . Most of tools that pack and unpack boot.img files such as Dsixda kitchen , Kernel kitchen or. ... use these applets .
These applets were compiled only for X86 so we could only (un)pack boot.img in Windows or Ubuntu but I compiled and fixed these applets for Arm7 platform on android devices from Android sources. So you may pack and unpack boot.img on any android device !!
Sources are here ( Lisenced under GPL 2.0 lisence ) : My github
How to use
1- First download applets package
2- Unzip it and push two files in it to /system/bin or /system/xbin
3- Set their pemissions to 777 ( rwxrwxrwx )
For unpacking a kernel
* Assuming that you have boot.img in /sdcard
* Open terminal and type : [ this is just an example , you can change it ]
Code:
su
unpackbootimg -i /sdcard/boot.img -o /sdcard/ -p 4096
*You will have extracted boot.img at /sdcard
* Save ouput information that applets gives you at the end . you need them in future
For packing a kernel
* Copy ramdisk.gz , zimage , cmdline , pagesize , base you got from unpacking boot.img into /sdcard
* Open terminal and type :
Code:
su
mkbootimg --cmdline cmdline --kernel zimage --ramdisk ramdisk.gz --base base --pagesize pagesize -o boot.img
* You will have output ( boot.img ) at /sdcard/boot.img
Download
Download build 1 @ Uploadboy
* Initial build
Credits
* Alireza7991 - for fixing , improving and cross-compiling for arm^7
* Andrew Huang ( [email protected]) - for sources
* Android Open Source Project - for sources
This applet is under GPL 2.0
Using this is free but you have to ask me if you want to use this in your tools or ...
Click to expand...
Click to collapse
Gonna try this soon
Sent from my H100 using xda app-developers app
alireza7991 said:
done
Code:
cpio -i < ramdisk.gz
Click to expand...
Click to collapse
Hmmm. Was this a recent update? I downloaded the tools this morning. I'm getting the below error:
Code:
cpio: unsupported cpio format, use newc or crc