btw my download of android eclair failed so.. idk
I did the following and it looks like I got all the code, haven't tried compiling yet:
mkdir eclair-source && cd eclair-source
repo init -u git://android.git.kernel.org/platform/manifest.git -b eclair
Is that what you tried?
someone more proficient than I figure out how to decompress and re compress the zImage without destroying the decompression stub (aka still boot-able when repacked) so that we can hex edit the init.rc
I was looking into this last night. I found out there is a script in the linux kernel source tree /scripts/extract-ikconfig which is supposed to be able to extract some config info from a zImage. It doesn't really work for finding that config on our zImage, but I was able to look at the script source to see how it decompresses the data from zImage. Basically it searches for the offset of the first occurence of hex values "1f 8b 08 00" which is the magic number used to identify .gz files. In our stock zImage, this occurs at 0x33F0 (13296 in decimal).
If you take the file from that offset forward, then you can decompress it with standard tools.
dd bs=1 skip=13296 if=zImage of=Image.gz
zcat Image.gz > Image
As for putting it back into a zImage, I'm assuming that everything before the gz chunk is part of the decompression stub, and should not ever require modification. So hopefully prepending that to a re-archived image would work.
However there is one other snag that I haven't quite figured. If you notice when you zcat the .gz, it displays a message about "ignoring trailing garbage". So there is apparently some data at the end of this zImage file, which is not part of the gz archive, and I'm still not sure what that represents. When I tried re-compressing the unmodified image on my ubuntu box...
gzip -cn --best Image > Image2.gz
I got a nearly identical file, except for bytes 5 through 8 (representing modified time), and of course the missing trailing garbage that was ignored during extracting the archive.
I don't know if we can just append that trailing data onto the end of our re-compressed file, or if maybe it's some super secret checksum data or something like that which depends on the contents of the rest of the image.
I spoke with someone smarter than me on irc, regarding the trailing data (name removed for privacy):
<xxxxxxxx> peeps: look at arch/arm/boot/compressed/vmlinux.lds.in. The compressed image is in .text.piggydata, so following are alignment, *(.got), *(.got.plt) and *(.data)
<peepsalot> thank you xxxxxxxx i will check that out
<xxxxxxxx> peeps: you can just ignore it (as gzip does for you)
<peepsalot> ok, i still don't completely understand though. what are piggydata, got, plt, etc.
<peepsalot> if I modify the uncompressed image and try to piece the zImage back together, how do I know what to put at the end
<xxxxxxxx> peeps: probably you cannot as the offsets are hardcoded in the binary after linking
<xxxxxxxx> you can directly boot the Image
<peepsalot> the problem is i want to flash a modified kernel, and the only tool I have for reflashing at the moment requires that zImage afaik.
<xxxxxxxx> then you need to hack the Makefile not to rebuild Image and recreate a zImage
<xxxxxxxx> probably you need to modify arch/arm/boot/compressed/Makefile
Has anyone successfully compiled the Samsung kernel source? As I understand it doesn't include the needed filesystem drivers, but is it possible to compile at all? I'd be interested to see what the output image looks like. I will probably give it a try later. Maybe we can find a way to build from the source we have, and then patch in that binary driver from the recovery image kernel somehow.