How To Compile Your Own Kernels, Modules, Tinboot (NAND boot), and More for Beginners

[natemcnutty]

Originally Posted by muziling

how to compile only one modules, example folder hardware/android-htc-ril

I have never done this, but you could try the guide here: http://www.pixelbeat.org/docs/rebuil...el_module.html

Originally Posted by siwsales

Im looking for a build for a Motorola Q and Q9 CDMA versions and a Palm Treo 700w can you help i have tried tons of defferent one and no luck if you can send me a private message on how to build on windows 7

You won't find one for any of those devices, and I would give up on that search right now.

First, none of them have a touch screen, so no developer is going to waste their time trying to backport Android to it. Even if they were bored, they would at least spend time on something that would be useful.

Second, those devices use an Intel XScale PXA272 312 MHz processor. That is not processor that is supported by this project (hence why the project is called Linux on Qualcomm). This specific forum is for discussion about Rhodium devices which use the Qualcomm MSM7600 processor.

In order to get Android on those devices, you would need to actually develop your own kernel and drivers from practically the ground up for everything on that device. Most of the devices here have drivers backported from real Android devices that use the same or similar hardware, but no true Android device uses the old hardware found in those devices from 2005-2006 or earlier.

[maurice.green]

I have been in the computer industry for 27 years and have been programming in just about every language except c and c branches for 23 years. I have taken a great interest in c, c branches, linux, and android in the last month. I want to be a contributor to this particular thread in this particular forum. First, I have been testing the Rhodium extensively by flashing several different kernels to the device. Some that I know will work and some that supposedly should brick the device. I have basically been trying to brick my device. I would like for a brave soul to verify my findings. If the device seems to bricked or stuck in a loop. Deplete the battery. Remove the battery and the usb power source. Put a RHODIMG.NBH image on the sdcard. Put the SD card in the card slot. Put the dead battery back into the phone. Plug the usb power cord back in to the phone. The charging led will come on. Let it sit for 10 mins the first time and it will try to load. Don't mess with the phone. It will recycle and try to boot again in about 5 min. When it try's to reboot hold down the volume down button, the power button and push the reset. This will bring you to the boot loader. Very quickly flash the NBH on the sdcard to the phone. The phone will cycle about 5 times before coming up completely. Let the battery fully charge and you are back in business. Second I have rewritten the init file from scratch for the initrd.img (I know most of the flashes use initrd.gz but sticking with best practices I am using Initrd.img - there really are no differences in the two files except for the file name). I have also successfully achieved the ability to mount the rootfs from the nand so that I am no longer running it off of the sd card. In about two weeks, if time permits in between my life and business I will be adding the external modules to the nand and hopefully the system.ext2. I will be posting a link in this thread with a RHODIMG.nbh for testing.

[Lmiller1708]

Originally Posted by maurice.green

I have been in the computer industry for 27 years and have been programming in just about every language except c and c branches for 23 years. I have taken a great interest in c, c branches, linux, and android in the last month. I want to be a contributor to this particular thread in this particular forum. First, I have been testing the Rhodium extensively by flashing several different kernels to the device. Some that I know will work and some that supposedly should brick the device. I have basically been trying to brick my device. I would like for a brave soul to verify my findings. If the device seems to bricked or stuck in a loop. Deplete the battery. Remove the battery and the usb power source. Put a RHODIMG.NBH image on the sdcard. Put the SD card in the card slot. Put the dead battery back into the phone. Plug the usb power cord back in to the phone. The charging led will come on. Let it sit for 10 mins the first time and it will try to load. Don't mess with the phone. It will recycle and try to boot again in about 5 min. When it try's to reboot hold down the volume down button, the power button and push the reset. This will bring you to the boot loader. Very quickly flash the NBH on the sdcard to the phone. The phone will cycle about 5 times before coming up completely. Let the battery fully charge and you are back in business. Second I have rewritten the init file from scratch for the initrd.img (I know most of the flashes use initrd.gz but sticking with best practices I am using Initrd.img - there really are no differences in the two files except for the file name). I have also successfully achieved the ability to mount the rootfs from the nand so that I am no longer running it off of the sd card. In about two weeks, if time permits in between my life and business I will be adding the external modules to the nand and hopefully the system.ext2. I will be posting a link in this thread with a RHODIMG.nbh for testing.

Thanks for the Tip, maybe some day I will have the need to use it...

For your second part would you care to share what you have so far? I have been trying to get the Nand working off and on for some time now (But I'm Still Learning ). I trying to replicate what was done on the Vogue... Maybe it is the wrong direction.

IMO, I like the idea of having just the initrd and the Zimage on the NBH file. This way the user does not have to reflash when the system.ext2 is updated or any other important file. Also maybe we could look at the benefits of combining the Rootfs and initrd into one (like they did with the vogue) I am however not too sure about this and why they even did it... To save space maybe?

And lastly were you able to get access to the MTD by modifying the drivers? If you do have access to them then you should be able to mount the System.ext2 and Data.img to MTD2 and MTD3 respectively.

Thanks again!=D>

[maurice.green]

Sorry that it has taken me a while to respond. I was trying to incorporate the back light work done by acl into the work that I was doing. Yes I have resolved the MTD issue but I was going further keeping the initrd separate from the rootfs unlike the vogue and loading it in to a separate partition in the nand but merging the rootfs with the system.ext2 and maybe the modules. I haven't decided yet if the modules will run best that way or actually integrated into the kernel. I am testing this for speed. I have found that booting is faster with the rootfs separate from th initrd. Though, yes you could combine them it makes the booting time slower. I have gotten the initrd init down to about ten lines of code, if that. As far as flashing goes - you wouldn't need to unless there was a new kernel. The initrd should not ever need to be modified. I have everything else with rw access so that updates can be done live. As soon as I can get with ACL to resolve the back light issue I should be ready to post. The current nbh size that I am dealing with, between the different builds that I am testing is less that 100 mg which leaves a lot of space for user data. I have gone away from actually mounting the system.ext2 and the data image as the device runs much faster when these files are pre decompressed and integrated into the rootfs which is where they are being mounted anyway.

[natemcnutty]

Originally Posted by maurice.green

Sorry that it has taken me a while to respond. I was trying to incorporate the back light work done by acl into the work that I was doing. Yes I have resolved the MTD issue but I was going further keeping the initrd separate from the rootfs unlike the vogue and loading it in to a separate partition in the nand but merging the rootfs with the system.ext2 and maybe the modules. I haven't decided yet if the modules will run best that way or actually integrated into the kernel. I am testing this for speed. I have found that booting is faster with the rootfs separate from th initrd. Though, yes you could combine them it makes the booting time slower. I have gotten the initrd init down to about ten lines of code, if that. As far as flashing goes - you wouldn't need to unless there was a new kernel. The initrd should not ever need to be modified. I have everything else with rw access so that updates can be done live. As soon as I can get with ACL to resolve the back light issue I should be ready to post. The current nbh size that I am dealing with, between the different builds that I am testing is less that 100 mg which leaves a lot of space for user data. I have gone away from actually mounting the system.ext2 and the data image as the device runs much faster when these files are pre decompressed and integrated into the rootfs which is where they are being mounted anyway.

That sounds absolutely awesome! So if you have rw access, we should be able to do OTA updates where we basically run an update app that downloads the latest update.zip, then restart the phone into recovery mode and apply the update?

[Lmiller1708]

Originally Posted by maurice.green

Sorry that it has taken me a while to respond. I was trying to incorporate the back light work done by acl into the work that I was doing. Yes I have resolved the MTD issue but I was going further keeping the initrd separate from the rootfs unlike the vogue and loading it in to a separate partition in the nand but merging the rootfs with the system.ext2 and maybe the modules. I haven't decided yet if the modules will run best that way or actually integrated into the kernel. I am testing this for speed. I have found that booting is faster with the rootfs separate from th initrd. Though, yes you could combine them it makes the booting time slower. I have gotten the initrd init down to about ten lines of code, if that. As far as flashing goes - you wouldn't need to unless there was a new kernel. The initrd should not ever need to be modified. I have everything else with rw access so that updates can be done live. As soon as I can get with ACL to resolve the back light issue I should be ready to post. The current nbh size that I am dealing with, between the different builds that I am testing is less that 100 mg which leaves a lot of space for user data. I have gone away from actually mounting the system.ext2 and the data image as the device runs much faster when these files are pre decompressed and integrated into the rootfs which is where they are being mounted anyway.

I agree with Nate! That sounds great! Easy updates are the way to go!
Can't wait to try it out!!!
So you are just going to leave the System and data on the mtd0 partition or are you going to separate them out?

[natemcnutty]

Maurice, whenever you get a chance, would you mind a quick explanation of what changes you've made in regards to tinboot and how you've combined ext2 and data.img into the rootfs? Is it just copying all of the files from kernel, ext2 into rootfs, then genext2?

I also think that combining modules with kernel would be best since they need to be replaced at the same time anyway. So we would have initrd.gz, rootfs, and the kernel/modules basically doing away with system.ext2 and data.img. This would make it so we can do update.zip to update just the kernel/modules

Also, I updated the first post on making the rootfs and modifying tinboot2.S for everyone else. If you have any suggestions or improvements, please let me know. This stuff is a hobby for me, and I know I'm not an expert in this area. I am always open to being schooled

[arrrghhh]

Heh, guess I should check this thread more frequently. Glad to hear we've got yet another dev hopping on NAND development... sounds like we're actually close to full NAND, lets beat those HD2 guys to the punch!

maurice.green, welcome aboard. Always nice to get more devs that can contribute Too many schmos like me that have little to no programming knowledge!

[maurice.green]

Tinboot modified to allow the modules to be combined with the kernel. Its not completed as of yet as I have only been working on the rhod400. I will modify in the next day to support other keyboards. If you would like to try send me a message and I will send you the zImage and the modified tinboot. Also I have been able to create mtd 0 - 4 on the nand so we are just about there.

Combining the ext2 was just a process of merging it into the rootfs system folder since thats where its mounted to anyway, although I am now thinking of moving it to its own partition. The idea is that you would be able to update any component with a rom flash with out touching the other components. The data file I have not been to worried about as it will be empty on first load anyway. I will bind it to mtd4. I went with 4 partitions because I wanted to have a recovery partition available. Merry Christmas!

[arrrghhh]

Awesome maurice.green. Merry Christmas to you, pieces of this project are really falling together quite quickly!