Guest JobSup Posted March 30, 2011 Report Share Posted March 30, 2011 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 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted March 30, 2011 Report Share Posted March 30, 2011 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 Link to comment Share on other sites More sharing options...
Guest hecatae Posted April 18, 2011 Report Share Posted April 18, 2011 how do we alter this for gen2? Link to comment Share on other sites More sharing options...
Guest Len Ash Posted April 18, 2011 Report Share Posted April 18, 2011 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. Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted April 18, 2011 Report Share Posted April 18, 2011 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.... Link to comment Share on other sites More sharing options...
Guest hecatae Posted May 31, 2011 Report Share Posted May 31, 2011 I now use https://github.com/kalltkaffe/kernel_zte_blade as it allows you to choose gen1 or gen2 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted May 31, 2011 Report Share Posted May 31, 2011 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 Link to comment Share on other sites More sharing options...
Guest hecatae Posted May 31, 2011 Report Share Posted May 31, 2011 ok just built a kernel from that and it wont boot... blah Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted May 31, 2011 Report Share Posted May 31, 2011 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 Link to comment Share on other sites More sharing options...
Guest Grain Posted May 31, 2011 Report Share Posted May 31, 2011 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. Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted May 31, 2011 Report Share Posted May 31, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest sej7278 Posted July 22, 2011 Report Share Posted July 22, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted July 22, 2011 Report Share Posted July 22, 2011 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. Link to comment Share on other sites More sharing options...
Guest sej7278 Posted July 22, 2011 Report Share Posted July 22, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted July 22, 2011 Report Share Posted July 22, 2011 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 :) Link to comment Share on other sites More sharing options...
Guest sej7278 Posted July 22, 2011 Report Share Posted July 22, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest wbaw Posted July 23, 2011 Report Share Posted July 23, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest burstlam Posted July 23, 2011 Report Share Posted July 23, 2011 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% Link to comment Share on other sites More sharing options...
Guest sej7278 Posted July 23, 2011 Report Share Posted July 23, 2011 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. Link to comment Share on other sites More sharing options...
Guest wbaw Posted July 23, 2011 Report Share Posted July 23, 2011 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. Link to comment Share on other sites More sharing options...
Guest burstlam Posted July 23, 2011 Report Share Posted July 23, 2011 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 Link to comment Share on other sites More sharing options...
Guest kol0bok Posted July 24, 2011 Report Share Posted July 24, 2011 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. Link to comment Share on other sites More sharing options...
Guest wbaw Posted July 24, 2011 Report Share Posted July 24, 2011 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. Link to comment Share on other sites More sharing options...
Guest sej7278 Posted July 24, 2011 Report Share Posted July 24, 2011 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now