Building a kernel?

[Guest JobSup]

Have a look here which I blogged about compiling your own kernel....hope this helps :D

Great reference, thank you! I also tried to build but have a question to step 7:

7. Navigate back to the $HOME/myrom, and go into the system/lib/modules directory:

cat $HOME/repository/ZTE-BLADE-2.6.32/modules.order | sed s/^kernel\//g | awk ‘{ system(sprintf(“cp $HOME/repository/ZTE-BLADE-2.6.32%s .\n”, $0)); }’

What we have done here, is copied the freshly built optional kernel modules here.

In my extracted rom, system/lib/modules doesn't contain the modules directly. They are in a sub folder 2.6.32.9-perf (only two modules, cifs.ko and zram.ko). Do I have to copy the freshly compiled modules to this sub folder to replace the old modules?

Also, the compile created many more modules, some of them seem to be for testing. Can I safely delete these (i.e. dma_test.ko or all mtd_*test.ko)

Thanks

[Guest t0mm13b]

Great reference, thank you! I also tried to build but have a question to step 7:

In my extracted rom, system/lib/modules doesn't contain the modules directly. They are in a sub folder 2.6.32.9-perf (only two modules, cifs.ko and zram.ko). Do I have to copy the freshly compiled modules to this sub folder to replace the old modules?

Also, the compile created many more modules, some of them seem to be for testing. Can I safely delete these (i.e. dma_test.ko or all mtd_*test.ko)

Thanks

Well, I have added an additional posting on my blog in which I created two scripts which simplifies the steps of creating the boot.img and copying over the kernel modules... also, you can safely overwrite the modules by invoking the second script. You can most certainly remove the testing modules as they just suck up space... :D

[Guest hecatae]

how do we alter this for gen2?

[Guest Len Ash]

how do we alter this for gen2?

Is it not just this?

Gen1 phones load it's kernel to 0x02a00000 while phones sold with Android 2.2, from now on called Gen2 phones loads it to 0x02600000.

[Guest t0mm13b]

Is it not just this?

Gen1 phones load it's kernel to 0x02a00000 while phones sold with Android 2.2, from now on called Gen2 phones loads it to 0x02600000.

Have a look at the default configuration for the kernel gen2 here

Line 224 is the key and also for the mkbootimg as well, where the base offset needs to be adjusted...

If my memory serves me correct, there's another spot for loading the video memory into a particular offset somewhere....

[Guest hecatae]

I now use https://github.com/kalltkaffe/kernel_zte_blade as it allows you to choose gen1 or gen2

[Guest t0mm13b]

I now use https://github.com/kalltkaffe/kernel_zte_blade as it allows you to choose gen1 or gen2

Its on TomG's kernel also as well :D

[Guest hecatae]

ok just built a kernel from that and it wont boot...

blah

[Guest t0mm13b]

ok just built a kernel from that and it wont boot...

blah

Oh! okay... here's the attached file that helps simplify the building of a rom image, copy both into your $HOME/bin directory and make sure that $HOME/bin is in your $PATH.

ak_stg1 copies the zImage from arch/arm/boot and combines with the original rom's boot-img.ramdisk.gz to make a boot.img

ak_stg2 copies the kernel modules into a pre-determined directory

The way I do it is this, assume the kernel is already built in $HOME/kernel, and original ROM's files are in $HOME/origrom. Assume $HOME/myrom is the working directory for generating a clockwork flashable script, invocation would be like this

ak_stg1 -g2 -k $HOME/kernel/arch/arm/boot/zImage -r $HOME/origrom/boot.img-ramdisk.gz

boot.img is now in place in $HOME/myrom.

Then,

ak_stg2 -k $HOME/kernel -m system/lib/modules/2.6.xx.x-perf

This copies the kernel modules into that directory.

Having a clockwork flashable script in place, requires a META-INF directory structure in $HOME/myrom

Now, its a matter of zipping up META-INF directory, boot.img, and system directory into one file ready for clockwork flashing

IF the kernel b0rks, look in /proc/last_kmsg for the log of the previous boot (it may be there, may not be there).

ak_stg_scripts.zip

[Guest Grain]

Having a clockwork flashable script in place, requires a META-INF directory structure in $HOME/myrom

A side note, if you only want to replace boot.img, flashing that using fastboot is probably quicker than flashing it via CWM.

[Guest t0mm13b]

A side note, if you only want to replace boot.img, flashing that using fastboot is probably quicker than flashing it via CWM.

Dang! Good point Grain - completely forgot about the fastboot.... meh

Old habits die hard I guess :D

lol

Edited May 31, 2011 by t0mm13b

[Guest sej7278]

Is it not just this?

Gen1 phones load it's kernel to 0x02a00000 while phones sold with Android 2.2, from now on called Gen2 phones loads it to 0x02600000.

but which one do we choose for gen1 phones TPT'd to gen2 - as on my phone 0x02A works just fine, i've also seen this on Tom_G's github:

https://github.com/T...b0ec743a5bf9975

also looking at the output of split_bootimg.pl, it looks like we should add the serial number and serial console support, so the mkbootimg command becomes:

mkbootimg --cmdline 'androidboot.hardware=blade console=ttyMSM2,115200 g_android.product_id=0x1354 g_android.serial_number=Blade-CM7' --base 0x2A00000 --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot.img 

also, in my modules.order i get this lot (removed the mtd-test ones)

kernel/arch/arm/mach-msm/reset_modem.ko

kernel/arch/arm/mach-msm/dma_test.ko

kernel/crypto/ansi_cprng.ko

kernel/drivers/misc/pmem_kernel_test.ko

kernel/drivers/scsi/scsi_wait_scan.ko

kernel/drivers/net/wireless/libra/librasdioif.ko

kernel/drivers/input/evbug.ko

kernel/arch/arm/oprofile/oprofile.ko

so how come we only get cifs.ko and zram.ko in a regular cm7 nightly build - especially when cifs is built-in and not a module anyway in defconfig! is it safe to not bother with these modules?

Edited July 22, 2011 by sej7278

[Guest t0mm13b]

but which one do we choose for gen1 phones TPT'd to gen2 - as on my phone 0x02A works just fine, i've also seen this on Tom_G's github:

https://github.com/T...b0ec743a5bf9975

also looking at the output of split_bootimg.pl, it looks like we should add the serial number and serial console support, so the mkbootimg command becomes:

mkbootimg --cmdline 'androidboot.hardware=blade console=ttyMSM2,115200 g_android.product_id=0x1354 g_android.serial_number=Blade-CM7' --base 0x2A00000 --kernel zImage --ramdisk boot.img-ramdisk.gz -o boot.img 

also, in my modules.order i get this lot (removed the mtd-test ones)

kernel/arch/arm/mach-msm/reset_modem.ko

kernel/arch/arm/mach-msm/dma_test.ko

kernel/crypto/ansi_cprng.ko

kernel/drivers/misc/pmem_kernel_test.ko

kernel/drivers/scsi/scsi_wait_scan.ko

kernel/drivers/net/wireless/libra/librasdioif.ko

kernel/drivers/input/evbug.ko

kernel/arch/arm/oprofile/oprofile.ko

so how come we only get cifs.ko and zram.ko in a regular cm7 nightly build - especially when cifs is built-in and not a module anyway in defconfig! is it safe to not bother with these modules?

The reason is based on the discretion of the kernel maintainers in the CM7 team.

Be aware though, there's a limited size on the boot.img that can be flashed.... hovers around the 4Mb mark or thereabouts, make the kernel too big, by stuffing every possible option into it will prevent the handset to boot.

Hence the reason why some are modules which is the whole point of reducing size of kernel.

You compile your own kernel - fine, just be selective and remember the above point, the testing stuff can be safe to remove as they are never used at all. Its something of a legacy from the old kernel config when .32.9 first came on the blade scene.

[Guest sej7278]

The reason is based on the discretion of the kernel maintainers in the CM7 team.

Be aware though, there's a limited size on the boot.img that can be flashed.... hovers around the 4Mb mark or thereabouts, make the kernel too big, by stuffing every possible option into it will prevent the handset to boot.

Hence the reason why some are modules which is the whole point of reducing size of kernel.

You compile your own kernel - fine, just be selective and remember the above point, the testing stuff can be safe to remove as they are never used at all. Its something of a legacy from the old kernel config when .32.9 first came on the blade scene.

after a bit of googling:

evbug.ko - probably don't want that on anything with limited disk space

oprofile.ko - isn't used as there's no /dev/oprofile on a running blade

not sure what the rest do, so i guess i'd better copy them across i guess, it just annoys me that its not documented anywhere.

edit: well my rom/kernel works fine, none of those modules are loaded it seems (no output from lsmod at all actually!) so i'd say its probably safe not to copy them across.

Edited July 22, 2011 by sej7278

[Guest t0mm13b]

after a bit of googling:

evbug.ko - probably don't want that on anything with limited disk space

oprofile.ko - isn't used as there's no /dev/oprofile on a running blade

not sure what the rest do, so i guess i'd better copy them across i guess, it just annoys me that its not documented anywhere.

edit: well my rom/kernel works fine, none of those modules are loaded it seems (no output from lsmod at all actually!) so i'd say its probably safe not to copy them across.

scsi_wait_scan.ko is important to hold - that is used by the sdcard handling mechanism of the kernel and treats it as a scsi device as such.

librasdioif.ko is a bit of an elusive mystery as to why that's there but is part of networking mechanism, I suspect either wifi or bluetooth - not 100% sure, the keyword in the filename sdio (relating to sd cards), if as in unix/linux parlance, interface... so keep that there (to be on the safe side)

reset_modem.ko - think that's part of when the handset powers down and goes to sleep and handles the mechanism of waking up the cellular 2/3g mechanism when awoken from sleep...

ansi_cprng.ko is to do with encryption random number generator (rng) do not know where is it used exactly.

As for the rest of them - they can be safely dismissed/ignored/omitted as that would be for say, debugging the kernel at the low-level and profiling the kernel to see how the function calls internally, are made...

Congrats on your kernel build :)

[Guest sej7278]

Congrats on your kernel build :)

cheers, i'm dead chuffed really, not that i have a major use for my own kernel - my programming skills don't really reach to device drivers - but the control freak in me likes to be able to do these things :D

i still don't really understand how the regular build can do without those modules though (and is over 1mb lighter) or why cifs.ko is there when its built-in.

maybe the .config is different on the nightlies to what's in github, which might change when its pushed out to gerrit.....

i seem to recall tom_g or someone was proposing a --kernel flag to the brunch system, so you could specify your own kernel (and modules?) rather than unzipping and repackaging a cm7 build, that would be much easier than all this mkbootimg/split_bootimage/signapk stuff.

the compulsory tutorial is here

Edited July 22, 2011 by sej7278

[Guest wbaw]

sdio is this: http://en.wikipedia.org/wiki/Secure_Digital#SDIO It's so that IO (input/output) devices, like Bluetooth, IrDA, GPS & wifi adaptors can connect using the sd card interface. Most people aren't going to need it, might be useful for one or two people, but I can't see most people wanting to swap their microsd memory for an extra gps receiver. Unless the phone is using that type of interface internally for some hardware, then it'd be vital. Disable it & see what happens, that's the easy way to find out.

Edited July 23, 2011 by wbaw

[Guest burstlam]

The reason is based on the discretion of the kernel maintainers in the CM7 team.

Be aware though, there's a limited size on the boot.img that can be flashed.... hovers around the 4Mb mark or thereabouts, make the kernel too big, by stuffing every possible option into it will prevent the handset to boot.

Hence the reason why some are modules which is the whole point of reducing size of kernel.

You compile your own kernel - fine, just be selective and remember the above point, the testing stuff can be safe to remove as they are never used at all. Its something of a legacy from the old kernel config when .32.9 first came on the blade scene.

In current source only have gzip method or the kernel compression

port in the lzma compression could download size around 30%

[Guest sej7278]

In current source only have gzip method or the kernel compression

port in the lzma compression could download size around 30%

yes i thought it odd it was a zImage and not a bzImage (bzip2) that regular linux uses.

[Guest wbaw]

libra.ko is a proprietary module included in the zte gingerbread leak, it looks like a wifi driver, possibly the thing that keeps wifi alive in sleep mode? It also looks like it'd work on .32.9 kernels.

[Guest burstlam]

libra.ko is a proprietary module included in the zte gingerbread leak, it looks like a wifi driver, possibly the thing that keeps wifi alive in sleep mode? It also looks like it'd work on .32.9 kernels.

I remember that libra,ko is the module for Qualcomm wcn1312 chipset (support 802.11n).

I think blades are using ar6002 instead

[Guest kol0bok]

yes i thought it odd it was a zImage and not a bzImage (bzip2) that regular linux uses.

First, file names do not tell anything about the packaging format. Second, bzImage (packaging format) can be anything (gzip, bzip2, lzma, ...). b mean BIG and not bzip2 (to distinguish from the ancient zImage format which had a size limit around 900kb, IIRC.

And replacing gzip with is lzma is generally a good idea. On x86, the decompression code of lzma is only few kib big and works almost as fast as gunzip.

[Guest wbaw]

I remember that libra,ko is the module for Qualcomm wcn1312 chipset (support 802.11n).

I think blades are using ar6002 instead

Yeah, Tom G told me. No idea why it's in all ZTE's roms, wifi driver for a chipset they don't use, just wasting 1.8mb - it can be safely removed.

librsdioif.ko seems to be as pointless as I thought too, that can be safely removed as long as you don't want to use sdio cards with the blade & I can't see why anybody would want to do that.

[Guest sej7278]

so taking out the test modules, we're left with:

kernel/arch/arm/mach-msm/reset_modem.ko (maybe needed for 3g)

kernel/crypto/ansi_cprng.ko (maybe needed for encryption)

kernel/drivers/scsi/scsi_wait_scan.ko (maybe needed for sd card, probably deprecated)

kernel/drivers/net/wireless/libra/librasdioif.ko

kernel/drivers/input/evbug.ko

kernel/arch/arm/oprofile/oprofile.ko