Database Develop

building an NBH

I was wondering how I would go about building an NBH file. I do dev for and use OpenAFS, and I would like to be able to install an OpenAFS client on my vogue. As I understand it, the NBH contains the kernel, and OpenAFS requires a kernel module.
If I'm barking up the wrong tree, and it's possible to insert a kernel module without needing an entire NBH file, I'd be interested to know if there's anything special that needs to be done for that, or if the standard linux 'insmod' method would work.
I'm also open to any thoughts or feedback on this idea/concept.

summatusmentis said:
I was wondering how I would go about building an NBH file. I do dev for and use OpenAFS, and I would like to be able to install an OpenAFS client on my vogue. As I understand it, the NBH contains the kernel, and OpenAFS requires a kernel module.
If I'm barking up the wrong tree, and it's possible to insert a kernel module without needing an entire NBH file, I'd be interested to know if there's anything special that needs to be done for that, or if the standard linux 'insmod' method would work.
I'm also open to any thoughts or feedback on this idea/concept.
Click to expand...
Click to collapse
insmod will work, just build your module against this kernel:
http://git.linuxtogo.org/?p=groups/mobile-linux/kernel.git;a=shortlog;h=refs/heads/htc-vogue
If your module needs something enabled in the kernel you may need to build a new nbh, in that case use this:
http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/tinboot.git;a=summary

[Q] Rebuilding zImage

After successfully extracting the ramdisk for zImage, I would like to edit init.rc and repack my chnages back to zImage.
I have searched throughout the forums but didn't find it, only guys like me who were able to extract the ramdisk...
Can anyone help here?
Thanks,
Johny

To the best of my knowledge, you cannot to it.
The ramdisk is compiled into the kernel object with some symbols/labels that point to the start and the end (subsequently giving the kernel a way to access the image).
It is more than just repacking that is required - you would also need to update the symbol tables/data where it points to the ramdisk - basically redo what linker / compiler have done.

I'm inclined to do so. How can I find the info required to do this?

Look at ./arch/arm/kernel/vmlinux.lds.S and ./init/initramfs.c in kernel sources.
There are two labels defined in the first and used in the second. The lds is a script that directs the linker when creating the vmlinux kernel.

will look into it, thanks.

There's a neat trick: make sure the initramfs archive is the exact same size as the original before you gzip and cat all the kernel pieces together again.

miki4242 said:
There's a neat trick: make sure the initramfs archive is the exact same size as the original before you gzip and cat all the kernel pieces together again.
Click to expand...
Click to collapse
Did that actually work for you?
I tried it. the only thing I changed in the kernel file was changing a single bit, ro.secure=1 to 0, and gzipped/catted it all back together again - and my phone wouldn't boot.
Looks like these guy have a way...
http://forum.xda-developers.com/showthread.php?t=891333

[Guide]How to Port roms to your mobile

This guide will help you in porting ROM's to different devices. Although it my not work 100% of the time, it should you show the steps involved in porting a ROM but also which files are important to a device's functionality.
Some handy tools to have before starting:
- The Android SDK, this contains ADB logcat which is a hugely important tool in ROM development. It lets us know what is perhaps causing an app to F/C or a ROM to bootloop. See our guide on how to set this up HERE
- Notepad++ , very useful for altering scripts.
- Patience, getting ports to boot can sometimes take a lot of effort and time but hopefully this guide will show you the quickest and easiest way to get your ported ROM booting.
Okay first decide which ROM you would like to port, don't port HDPI ROM's to MDPI devices or vice versa it just won't work.And it's best to start with the easy and simple ports to get some experience behind you before you go off porting Sense 3.0 to your X10.
Let's get started...
Porting is fairly easy and requires only some folders, files and a boot.img to be replaced.
Now because this is a universal guide I can only tell you how to get the basic hardware working on your port. AOSP ROMs are fairly easy to figure out so you won't have much trouble figuring out what needs replacing. Manufacturer specific ROMs such as Sense 3.0 ROMs are bit more difficult to figure out but the basic skills you will be taught here can be applied in principle to those ROMs.
1. First off lets start with the biggie, the kernel. Those of you familiar with linux will know how important the kernel is a to system, I won't go into detail here but if your kernel isn't specific to your device then your ROM won't boot. The kernel is contained within the boot.img of your ROM's zip (or zImage if it's a Samsung). During flashing it is unpacked and wrote to the system.
To replace the kernel we need to decompile it and no this isn't as easy as opening it winzip. The best way to do this is using Linux; we can use a combination of both perl scripts and terminal commands.
In order for us too see the kernel files contained within the boot.img, we need to first unpack it and this will extract the kernel binary and the ramdisk. What you need at this point is the split_bootimg.zip. This contains a perl script which will extract both files and display the boot.img header, the kernel command line and the board name (if specified).
An example of the output would be:
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
So how to use this perl script you ask? Well...
First open a terminal and cd to the directory which contains the perl scripts you just downloaded. Next, type this command: "perl split_bootimg.pl boot.img" and that will extract the kernel to your current directory.
Now, we need to extract the ramdisk, the ramdisk has been unpacked from the boot.img and is sitting your current directory with the file name "boot.img-ramdisk.gz", at the moment this still isn't useful to us so we need to un-gzip and then un-cpio it.
So for that we need the Linux terminal. So again from the terminal or using the same terminal enter these commands:
mkdir ramdisk < Creates a directory where we can store the ramdisk
cd ramdisk < Changes our current directory to that of the ramdisk
gzip -dc ../boot.img-ramdisk.gz | cpio -i < Will un-gzip and un-cpio ramdisk
Okay so now we can see all the ramdisk files:
./init.devicename.rc
./default.prop
./proc
./dev
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data
So what's important here is the "init.devicename.rc" and "unvented.device.rc". This is the target devices .rc files contained within the ramdisk, now all we have to do here is rename this .rc file to that of the device you are porting to, e.g: "init.trout.rc" > "init.hero.rc"
Some devices ramdisk differ and may not contain "unvented.device.rc" so if this is case for you,then begin by renaming the init.device.rc to your model id and leave it at that. If you get problems well.. that's what the live support is for.
The other file which may be of use to us here is "init.rc", this contains all the system wide kernel properties which we can change to our liking but we'll leave as it is for now.
So now we've edited the ramdisk, we need to change the kernel so that the one the ROM uses is actually specific to our device, when we used the split_bootimg perl script it also unpacked the kernel and that is also in our current directory with the filename "boot.img-kernel".
Easiest way to replace the kernel is to take a kernel update zip for your device, un-zip it and rename the zImage file to "boot.img-kernel" and copy and replace the file of the same name in your directory.
Okay, now that's all done, we need to pack this back up into something that android can understand when it's being flashed. So we need to make a new boot.img from the files we have in our current directory.
First, we need to pack the ramdisk back up into it's original state, so again we need to use the Linux terminal. The command that will do this is this:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Remember the ../ is the path to the directory of your ramdisk, remember to remove anything that won't be used by the kernel as cpio will include EVERYTHING in the working directory.
Okay now that the ramdisk is back in it's original format we need to repack the kernel and ramdisk into the boot.img.
So back into the terminal we go and this time we're going to use the "repack-bootimg" perl script (as if that wasn't obvious enough). The command you will ise here is esentially the same to the one we used to split it, so:
"perl repack-bootimg.pl ../path to kernel ../path to ramdisk directory ../path to outfile"
And the boot.img is complete!
So if we look back to the ROM we are porting we can see that we need to put the boot.img into the root of the zip, this will hold true for almost every Android ROM. Next we need to replace some of the files which allow the hardware and keys to work. This is the easy part.
Go into the root of the zip and follow this path to the kernel modules; "/system/lib/modules" Delete all the files you find here.
Now take the kernel modules which came along with the kernel you added to the boot.img and copy them there. Next follow this path to the propietary hardware files;
"/system/lib/hw" Delete all the files you find here.
Again this as simple as taking the files from a ROM meant for your device and copying them into this directory. So what we've done there is added the kernel modules that we can set symlinks to in the updater-script and contain the modules needed for things like WiFi, bluetooth etc. The "/hw" directory as you can see contains the files which control the sensors and lights such as GPS and the accelerometer.
Next, we can look at making sure the hard and soft keys work, the files which contain the layout of your device keys can be found in;
"/system/usr/keylayout" and "/system/usr/keychars"
Touch only those 2 directories.
Delete all the files in here and copy the ones from your device (following the same directory) here.
Okay now to finish off we need to copy over the mount point information for your device and the WiFi drivers.
Follow this path; "/system/etc" and delete only these files and directories.
- vold.fstab
- /wifi
- /ppp
Now follow the same path in a ROM for your device and copy over these files.
Okay we're done!
Before flashing take a look and some guides which show you how to write updater-scripts, incase you need to create important symbolic links.
Happy Porting!
**mod edit** credits to JieeHD from the VillainROM team for this guide! original thread here: http://www.freeyourandroid.com/guide/porting-android

reserved for future......

Hey,how did i help in this?
PS:i m thinking of buying this phone.....is it any good?

i have both the galaxy sl and spice mi 410 i copied from your thread so had to give you credit even though you are not the original poster
spice mi 410 competely outshines galaxy sl so much so that i hardly use sl hooked to this at i.6ghz its lightning fast great plays any game hardly random reboots though average camera galaxy sl better
side note :if you could build succh a nice rom with sl god knows what good you can do with mi 410 please buy it haha
cranium rocks

oh cool............i had forgotten about that thread
2nd hand for 9999 only.................

Hey that's my tutorial... Hope it helps someone....
Sent from my SAMSUNG-SGH-I777 using xda premium

rdannar said:
Hey that's my tutorial... Hope it helps someone....
Sent from my SAMSUNG-SGH-I777 using xda premium
Click to expand...
Click to collapse
than credit to you i am just sharing with everyone "hope it helps someone"

Thank you!!! Will try too port a gt-I9100 rom to a gt-I9100G.
Hope it will be easy with this guide.

Dear Preyesh1.... Could you add the credit to the creator of this guide or at least you mention the url source because I've seen this guide just exactly as in this thread somewhere in the internet.
Except if this guide is pure of yours.
Just to remind...
Edited: Never mind... The creator has been here after all...

I have some questions:
so this means you can take the U9000 android 2.2.2 kernel and merge with ICS?
or does this only works with kernel coming from a GB build to another GB build?

It will help me cause I'm gonna use it soon
Sent from my Triumph using XDA

ziggy46 said:
It will help me cause I'm gonna use it soon
Sent from my Triumph using XDA
Click to expand...
Click to collapse
Hey are you going to port your rom to your device this will be great...!!

I wanna try this great tutorial
Sent from my Droid using Tapatalk

Nice plagiarism.
I mean look at that OP. You've selected the entire article, hit copy, hit new post here, hit paste then hit submit. That's plagiarism of the laziest kind you could have at the very least put some effort in, formatted the text, used code blocks etc.
My word.
edit:
preyesh1 said:
See our guide on how to set this up HERE
Click to expand...
Click to collapse
Hahahahaha.

[Q] Unpacking CM boot image

Hello guys, I've been struggling since two and a half hours now to unpack boot.img taken from cm10.1 zip (get.cm). I have an error about the magic header, here it is.
Code:
Android Magic not found in boot.img. Giving up.
Fyi, I need to unpack/repack the boot image to change the bootlogo and kernel.
I've tried with any tool available (dsixda kitchen, championswimmer kernel kitchen, simple mkbootimg or unmkbootimg, xperia boot tools and more), no results. Anyone please?

Try asking in the question and answer section, that may help
Sent from the luxury of my tent

That's actually a kernel.elf, not boot.img Rename it to kernel.elf, and use the kernel kitchen to extract it's contents.
..

NuriJ said:
That's actually a kernel.elf, not boot.img Rename it to kernel.elf, and use the kernel kitchen to extract it's contents.
..
Click to expand...
Click to collapse
Thank you man, you're a lifesaver. It works.

NuriJ said:
That's actually a kernel.elf, not boot.img Rename it to kernel.elf, and use the kernel kitchen to extract it's contents.
..
Click to expand...
Click to collapse
Hi.. I found this dead thread when i googled for the same thing that OP also had,, I managed to unpack the kernel's boot.img by renaming it to kernel.elf.. I have to edit init,rc file in order to get bootclasspath lines from a cm10 fxp kernel and put it in my port ROM's init.rc and replace the bootclasspath.. But i never found init.rc file anywhere, there is an init file which doesn't have a bootclasspath but only PATH.. Can u help me with this?

tOrNadO_007™ said:
Hi.. I found this dead thread when i googled for the same thing that OP also had,, I managed to unpack the kernel's boot.img by renaming it to kernel.elf.. I have to edit init,rc file in order to get bootclasspath lines from a cm10 fxp kernel and put it in my port ROM's init.rc and replace the bootclasspath.. But i never found init.rc file anywhere, there is an init file which doesn't have a bootclasspath but only PATH.. Can u help me with this?
Click to expand...
Click to collapse
Are you looking in ramdisk?

NuriJ said:
Are you looking in ramdisk?
Click to expand...
Click to collapse
Yes.. I did that too.. Unfortunately all the methods didn't work.. One simple method worked though.. Change the permissions of all the unpacked files and mount the ramdisk.img and then extract it and change contents of any file of your choice and then repack it.. It works like a charm..

[Q] Chromecast command line primer

Apologies if this has already been covered but a quick search turned up nothing. I recently rooted and was wondering if there was any resource to describe the ins and outs of the chromecast shell. Specifically I wanted to know if there is a way to define a custom start up script. For the moment I would just like to auto update the PATH env variable to include my own bin directory on /data with some of the more useful busybox commands symlinked and maybe add some cooler stuff later. I've done something similar in dd-wrt with a special nvram variable to point to a script, but I don't know if there is an equivalent here. Thanks.

bobcat987 said:
Apologies if this has already been covered but a quick search turned up nothing. I recently rooted and was wondering if there was any resource to describe the ins and outs of the chromecast shell. Specifically I wanted to know if there is a way to define a custom start up script. For the moment I would just like to auto update the PATH env variable to include my own bin directory on /data with some of the more useful busybox commands symlinked and maybe add some cooler stuff later. I've done something similar in dd-wrt with a special nvram variable to point to a script, but I don't know if there is an equivalent here. Thanks.
Click to expand...
Click to collapse
I think we need to edit /init.rc
but it's write protected =/

bobcat987 said:
Apologies if this has already been covered but a quick search turned up nothing. I recently rooted and was wondering if there was any resource to describe the ins and outs of the chromecast shell. Specifically I wanted to know if there is a way to define a custom start up script. For the moment I would just like to auto update the PATH env variable to include my own bin directory on /data with some of the more useful busybox commands symlinked and maybe add some cooler stuff later. I've done something similar in dd-wrt with a special nvram variable to point to a script, but I don't know if there is an equivalent here. Thanks.
Click to expand...
Click to collapse
Mape0661 said:
I think we need to edit /init.rc
but it's write protected =/
Click to expand...
Click to collapse
You can, but you would have to do the modifications with an extracted system image, re-squashfs it back up, and then flash it back to the device.

Thanks for the replies. If I'm feeling bold this weekend I'll take a look at creating a one-off /system for this.

bobcat987 said:
Thanks for the replies. If I'm feeling bold this weekend I'll take a look at creating a one-off /system for this.
Click to expand...
Click to collapse
I've been writing some, gonna post it later on git if you want to see it.
mostly stuff to make it easy to start ftp, samba etc.
/mape

ddggttff3 said:
You can, but you would have to do the modifications with an extracted system image, re-squashfs it back up, and then flash it back to the device.
Click to expand...
Click to collapse
Seeing this you guys are making me think (always dangerous!)
Is it possible to code and inject an on device player app that could be inserted into the system (similar to Netflix) that could be triggered by another app for local playback without the need for an Internet connection?
Something like that would really increase the streaming capability for areas where Internet connection is not available.
And if the right code is found could even give local streams DHT capability if we had the ability to add those codecs to the player system.

ddggttff3 said:
You can, but you would have to do the modifications with an extracted system image, re-squashfs it back up, and then flash it back to the device.
Click to expand...
Click to collapse
I've been looking at system.img from 19084.001.zip
it seems it only got this then I unsquashfs it
[email protected]:~/squashfs-root# ls
bin boot chrome etc lib netflix res usr
I'm I looking in the wrong file?

Mape0661 said:
I've been looking at system.img from 19084.001.zip
it seems it only got this then I unsquashfs it
[email protected]:~/squashfs-root# ls
bin boot chrome etc lib netflix res usr
I'm I looking in the wrong file?
Click to expand...
Click to collapse
if you want to modify init.rc, then you need to extract the initramfs from the kernel, modify it, repackage the initramfs, compile the kernel from src (as the default one is signed, and can't be merged with a modified initramfs), and then merge the compiled kernel with the initramfs you modified.

ddggttff3 said:
if you want to modify init.rc, then you need to extract the initramfs from the kernel, modify it, repackage the initramfs, compile the kernel from src (as the default one is signed, and can't be merged with a modified initramfs), and then merge the compiled kernel with the initramfs you modified.
Click to expand...
Click to collapse
Looks like this gonna be my "children are sleeping" project for some time .-)
Well I extracted initramfs from boot.img and mounted it with cpio. At least I'm looking at the right files. I have never compiled a kernel for this kind of devices before (only for my computer) and I having trubble to cross compile, my arm compiled programs wont run on CC.
Do you got some good pages I can read and learn this stuff from?