Generating boot.img for dell streak

[Guest uev85]

Hi, I am using on the Dell Streak the rooted ROM with 3883 build, and I am trying to load my own kernel on the Dell Streak. But when I try to load the zImage with fastboot -i 0x413c boot the HBOOT doesn't allow to do this, so I generated a boot.img and load it with fastboot -i 0x413c flash boot. This last command writes the boot image but the Streak doesn't run, it shows all the time the Dell logo but doesn't show the O2 screen or the home screen and I have turn off it taking out the battery.

I generate the boot.img opening Modaco's boot.img, adding the kernel and creating a new boot.img with

mkbootimg --base 0x20000000 --cmdline 'console=ttyMSM2,115200n8 androidboot.hardware=qcom' --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot-new-streak_base0x2.img

I don't know if the base address is correct (I know that this one is used for the nexus one).

I have read that in the Acer Liquid after generating the boot.img it has to be opened with a hex editor and add a header, any news about that?

Thank you

Edited August 4, 2010 by uev85

[Guest maxrfon]

Hi, I am using on the Dell Streak the rooted ROM with 3883 build, and I am trying to load my own kernel on the Dell Streak. But when I try to load the zImage with fastboot -i 0x413c boot the HBOOT doesn't allow to do this, so I generated a boot.img and load it with fastboot -i 0x413c flash boot. This last command writes the boot image but the Streak doesn't run, it shows all the time the Dell logo but doesn't show the O2 screen or the home screen and I have turn off it taking out the battery.

I generate the boot.img opening Modaco's boot.img, adding the kernel and creating a new boot.img with

mkbootimg --base 0x20000000 --cmdline 'console=ttyMSM2,115200n8 androidboot.hardware=qcom' --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot-new-streak_base0x2.img

I don't know if the base address is correct (I know that this one is used for the nexus one).

I have read that in the Acer Liquid after generating the boot.img it has to be opened with a hex editor and add a header, any news about that?

Thank you

Did you compile your kernel yourself?

[Guest uev85]

Did you compile your kernel yourself?

Yes, the first time I tried with my kernel. But now I tried to open the boot.img with split_bootimage.pl and generating again without changing anything using mkbootimg but happens the same thing. I have seen that the boot.img's size is 5mb, but when I open it and generate it again without changing anything its size is the half (aprox. 2,5mb).

[Guest fards]

i usually do

fastboot flash:raw

boot zImage ramdisk.img

it's a pity there's no boot option in the Dell fastboot

[Guest fards]

what toolchain are you using guys?

I've tried 4.4.0 that's included with the codearoura and it's not working..

[Guest uev85]

I am using 4.4.0 too

[Guest kwaaq]

Same issues, results, findings as above really..

Working boot images all seem to have a significantly bigger header size than what is considered standard. I'm also intrigued by the ramdisks that boot, they are in a '.' directory.

I've also tried throwing an eclair system on top of the 1.6 kernel. That can't boot 4-5 base services hence unusable without some major fiddling that I really don't have the time or patience for.

My straight compile is recognised over USB as a device, something most my hex-edits are not. But it ain't really good when your greatest success so far is a device that constantly resets instead of just locking up.

Hex edits did reveal something of interest though. Scripts in the 4399-superboot's ramdisk do contain Code Aurora headers. Dell may very well be building right from that q8250_surf branch.

[Guest fards]

I think what we need is a decent way of reverse engineering boot.img so we can see what they've done properly.

I've not found one yet,

Dell complying with the gpl would help, or even a friendly dev from the streak team who came on here incognito and gave us some inside knowledge occasionally :)

I've just realised Paul must know how to rebuild this particular boot.img and get it booting as he's added some extra bits to it in his kitchen...

So Paul, are you going to stop playing with the samsung s for long enough to throw us a bone?

Edited August 7, 2010 by fards

[Guest fards]

going back to this I'm curious why are you using --base 0x20000000 ?

where have you got that figure from? is it something qualcomm specific ? where is the boot located on the nexus? mtd0 1 or 2?

what about

# mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-boot --cmdline "no_console_suspend=1 console=null" -o newBoot.img --base 0x19200000

doing more reading, is the reason for the larger size than usual in boot.img a second stage loader as referenced here http://android-dls.com/wiki/index.php?titl...ack_Boot_Images

I just looked with a hexeditor at the boot.img I can't see where the kernel starts..

Edited August 7, 2010 by fards

[Guest kwaaq]

There is no second stage in the images just additional padding at the start. 0x8002 vs 0x10002 is where the 0's stop. Even catting the block straight off the drive I'm pretty sure that extra 2.5 meg was just garbage data.

1F 8B 08 00 is the hex to search for for start-end of ramdisk/kernel. (the perl scripts on that page above won't do the job properly.)

First occurrence through to the byte before the second occurrence = the gzipped->cpioed ramdisk (trailling zeros are fine to include in the cut/paste into new file.

Second occurrence to the end is the kernel.

If anyone knows if there is any relevance to the 20 bytes at 0x2400 as well I'd be interested to know.

Edited August 8, 2010 by kwaaq

[Guest fards]

ok cool, thanks for the info, I did say I'm learning as I'm going :)

I'll play some more with it,

[Guest kwaaq]

mkbootimg --kernel zImage --ramdisk ramdisk.cpio.gz --cmdline "console=ttyMSM2,115200n8 androidboot.hardware=qcom" --base 0x2000000 --pagesize 4196 --output boot.img

Should in theory make the boot image, but the ramdisk still appears to be place wrongly compared to the working images.

Also as an aside for anyone else working on this. Make update.zips -> factory reset and apply zip in ClockworkMod. I'm iffy on whether fastboot is actually flashing the boot images properly.

Edited August 9, 2010 by kwaaq

[Guest uev85]

I'm iffy on whether fastboot is actually flashing the boot images properly.

Yes, it does, everytime I load my own boot.img and fails I made a fastboot with Paul's boot.img and after that it works ok.

[Guest kwaaq]

Yes, it does, everytime I load my own boot.img and fails I made a fastboot with Paul's boot.img and after that it works ok.

Let me expand on my comment. I'm working with 4 different boot.imgs that work. Paul's, a catted one of Pauls (5meg). A 'modified' one of mine from Paul's, and a catted one of that (5meg).

The modified ones just contain a few simple hex edits in an attempt to closer match what my froyo header + positioning in the file look like.

All will work when placed in update.zips. Only the first two will work in fastboot (version supplied in sticky at top of page or the latest sdk fastboot).

The catted one of mine really has to be a legit img after all it's a direct rip from a booting file system. Yet try and apply it with fastboot and it will constantly reboot.

[Guest uev85]

Let me expand on my comment. I'm working with 4 different boot.imgs that work. Paul's, a catted one of Pauls (5meg). A 'modified' one of mine from Paul's, and a catted one of that (5meg).

The modified ones just contain a few simple hex edits in an attempt to closer match what my froyo header + positioning in the file look like.

I'll try as you say. How do you create the update.zip? Uncompressing Modaco's zip, adding your boot.img and compressing it again?

[Guest kwaaq]

Correct. Needs the meta-inf folder and system folder as well to actually install. Simply replace the boot.img with yours.

[Guest uev85]

Correct. Needs the meta-inf folder and system folder as well to actually install. Simply replace the boot.img with yours.

I have made some proofs with no success. I have try opening Paul's boot.img and generating diferent boot.imgs:

- Adding my kernel and generating the boot.img with --base 0x20000000

- Adding my kernel and generating the boot.img without the base

- Repacking that img without changing anything with --base 0x20000000

- Repacking that img without changing anything without base

- Repacking that img without changing anything with --base 0x20000000 and adding at the end of the boot.img with a hex editor FF until it has the same size as the original one

What kind of modifications and how did you did them on the boot.img?

[Guest kwaaq]

What kind of modifications and how did you did them on the boot.img?

No success doing anything like that. Just hex edits directly to the boot.img. The ramdisk in particular.

I still believe pagesize should be 4192 when making images, but this lack of success is starting to get to me.

Edited August 9, 2010 by kwaaq

[Guest uev85]

No success doing anything like that. Just hex edits directly to the boot.img. The ramdisk in particular.

I still believe pagesize should be 4192 when making images, but this lack of success is starting to get to me.

A workmate has told me that most phones have a 2k pagesize, but the dell streak has 4k. We will try that.

[Guest kwaaq]

Kernel starts at 0x1000 in the working images. So all of that above should be the header = 4k = page size. Other peculiarity is that in working images the ramdisk load location is at 0x24000000 while makebootimg defaults this to 0x01000000 above the kernel address (a.k.a 0x21000000) so i've been hexing in 00 00 00 24 at locations 0x14 through to 0x17 in my many failed attempts.

Anyone had any luck with fastboot flash:raw? Even with ripped working kernel/ramdisk and setting the -n and -b parameters I fail miserably.

Also I believe if you are trying to cut and paste in a different kernel you will not only have to update the sizes in the header, but recalculate the SHA at 0x2400.

[Guest carlosloz]

Kernel starts at 0x1000 in the working images. So all of that above should be the header = 4k = page size. Other peculiarity is that in working images the ramdisk load location is at 0x24000000 while makebootimg defaults this to 0x01000000 above the kernel address (a.k.a 0x21000000) so i've been hexing in 00 00 00 24 at locations 0x14 through to 0x17 in my many failed attempts.

Anyone had any luck with fastboot flash:raw? Even with ripped working kernel/ramdisk and setting the -n and -b parameters I fail miserably.

Also I believe if you are trying to cut and paste in a different kernel you will not only have to update the sizes in the header, but recalculate the SHA at 0x2400.

Reading the header of the working "boot.img", pagesize is 0x800, then it is 2k pagesize, but every block must be align to 4k (zero padding). Changes to "makebootimg.c" are:

//static unsigned char padding[2048] = { 0, };

static unsigned char padding[4096] = { 0, };

...


	if(write(fd, &hdr, sizeof(hdr)) != sizeof(hdr)) goto fail;

	//if(write_padding(fd, pagesize, sizeof(hdr))) goto fail;

	if(write_padding(fd, 4096, sizeof(hdr))) goto fail;


	if(write(fd, kernel_data, hdr.kernel_size) != hdr.kernel_size) goto fail;

	//if(write_padding(fd, pagesize, hdr.kernel_size)) goto fail;

	if(write_padding(fd, 4096, hdr.kernel_size)) goto fail;


	if(write(fd, ramdisk_data, hdr.ramdisk_size) != hdr.ramdisk_size) goto fail;

	//if(write_padding(fd, pagesize, hdr.ramdisk_size)) goto fail;

	if(write_padding(fd, 4096, hdr.ramdisk_size)) goto fail;

Besides "makebootimg.c" must be modified because "-base" argument is not working in Dell Streak:

		/* default load addresses */

	//hdr.kernel_addr =  0x10008000;

	//hdr.ramdisk_addr = 0x11000000;

	//hdr.second_addr =  0x10F00000;

	//hdr.tags_addr =	0x10000100;


	hdr.kernel_addr =  0x20008000;

	hdr.ramdisk_addr = 0x24000000;

	hdr.second_addr =  0x20F00000;

	hdr.tags_addr =	0x20000100;

Anyway, we have been able to boot with kernel 2.6.29-perf, but we have failed to update the kernel (yet).

About SHA values, it is ignored, boot.img worked with SHA values to 0.

[Guest kwaaq]

Reading the header of the working "boot.img", pagesize is 0x800, then it is 2k pagesize, but every block must be align to 4k (zero padding). Changes to "makebootimg.c" are:

...

Anyway, we have been able to boot with kernel 2.6.29-perf, but we have failed to update the kernel (yet).

About SHA values, it is ignored, boot.img worked with SHA values to 0.

Good to see I wasn't the only one making changes to mkbootimg.c yesterday!

Even better, to see someone who seems to actually know about this properly (unlike me)on the case!

Not good, it's a Public holiday and you've given me another avenue to go down.

Edited August 10, 2010 by kwaaq

[Guest carlosloz]

Anyway, we have been able to boot with kernel 2.6.29-perf, but we have failed to update the kernel (yet).

About SHA values, it is ignored, boot.img worked with SHA values to 0.

The kernel 2.6.29-perl included on Dell Streak is a mix of 2.6.29 & 2.6.35, and probably more experimental modules... it can't be updated easily.

For example:

2.6.35: http://cateee.net/lkddb/web-lkddb/MACH_QSD8X50_SURF.html

2.6.35: http://cateee.net/lkddb/web-lkddb/ARCH_MSM_SCORPION.html

Regards,

Carlos.

[Guest kwaaq]

The kernel 2.6.29-perl included on Dell Streak is a mix of 2.6.29 & 2.6.35, and probably more experimental modules... it can't be updated easily.

For example:

2.6.35: http://cateee.net/lkddb/web-lkddb/MACH_QSD8X50_SURF.html

2.6.35: http://cateee.net/lkddb/web-lkddb/ARCH_MSM_SCORPION.html

Regards,

Carlos.

Actually I was under the impression that the entire dell 1.6 implementation was a mish-mash since there is a jni library floating around (again, not an expert but I don't believe that should be there in a vanilla 1.6).

I believe I've got a kernel loading. At least since I'm pretty certain it's hitting the ramdisk. Can't get any usb debugging working on it though to look further. Pulled the .config for the kernel from the device and used defaults for everything not supplied. I've been using a current branch, so usb mass storage hosting and q6audio were foobared in the tree so chopped them out with an axe.

Misc stuff:

*Paul's boot image has an incorrect kernel size in the header (from memory) 240218. Should be 240228. Changing this size still allows it to boot (so it's not like the acer liquid). Stripping the kernel to this size will still boot, but give battery monitoring issues.

*Noticed the ramdisk has goldfish stuff floating around in it. Thats messy :D

*Yup SHA is ignored.

Damn, I hate writing replies. Always get ideas on new approaches to explore. And I really don't have the time to work on it :D

[Guest smokku]

Kernel starts at 0x1000 in the working images. So all of that above should be the header = 4k = page size. Other peculiarity is that in working images the ramdisk load location is at 0x24000000 while makebootimg defaults this to 0x01000000 above the kernel address (a.k.a 0x21000000) so i've been hexing in 00 00 00 24 at locations 0x14 through to 0x17 in my many failed attempts.

Anyone had any luck with fastboot flash:raw? Even with ripped working kernel/ramdisk and setting the -n and -b parameters I fail miserably.

I am analyzing boot.img from r2-4399-streak-superboot.zip and r2-4399-streak-superboot.zip

Both have 1F 8B 08 00 gzip signatures at offsets:

0x49E0 - kernel

0x242000 - initrd

I extracted them manually using:

dd if=boot.img of=kernel.gz ibs=1 skip=18912 count=2348576

dd if=boot.img of=initrd.gz ibs=1 skip=2367488

and they look fine. 'zcat kernel.gz | strings | less' gives a lot of interesting strings and gzip does not complain during decompression. Same for initrd.gz - it's extractable.

But I cannot successfully reassemble them to working boot.img.

Aces Liquid guys needed to modify mkbootimg because Liquid bootloader expects non standard images.

This is probably a case for Streak too.