NAND Testing - 05-25 Update: New LK, Recovery.img, Kernel Updates through Recovery

[[ACL]]

Originally Posted by Lmiller1708

Yup! Sad part about being a developer... You are never done flashing!

I do like android a lot better then windows... Every time you flashed a ROM it took forever to get it back how you wanted it, that is why I started to cook my own ROM's. Now with android all you have to do is back up your data.img and wallah you are back to where you started! So that might be a option too via the replimenu.

Never heard of kexec before but it might work... Until a reboot then it will get overwritten by the original kernal.

Edit: Are you running Full NAND currently and do you have data working?

Finally stabilised this bad boy. No more reboots, all done via sysinit.rc and its the sexiest thing to be able to mount the sdcard as mass storage.

I'll talk to jonpry about this whole kernel portion poop. When wozzer bricked himself i know he was talking about possibly writing to nand from within android. If this is possible, then all kernel updates can be done from inside without bothering the damn bootloader.

In anycase i'll repost my stuff up tonight and continue working on this. Wifi is still broken for me but i know why. Eventually i think our build will have a set of custom scripts that android will execute on boot. 2 i can think of is setting up the wifi nvram part and the other applying the calib points to the input. This way our initrd remains small since the kernel will only get bigger.

I think we have done a great deal of streamlining and i'll discuss with stinedb about possibly using our sysinit.rc for frx05. This way we will only have to worry about updates and not the build itself.

I'll commit the mtd parts tonight..

[natemcnutty]

Originally Posted by [ACL]

Finally stabilised this bad boy. No more reboots, all done via sysinit.rc and its the sexiest thing to be able to mount the sdcard as mass storage.

I'll talk to jonpry about this whole kernel portion poop. When wozzer bricked himself i know he was talking about possibly writing to nand from within android. If this is possible, then all kernel updates can be done from inside without bothering the damn bootloader.

In anycase i'll repost my stuff up tonight and continue working on this. Wifi is still broken for me but i know why. Eventually i think our build will have a set of custom scripts that android will execute on boot. 2 i can think of is setting up the wifi nvram part and the other applying the calib points to the input. This way our initrd remains small since the kernel will only get bigger.

I think we have done a great deal of streamlining and i'll discuss with stinedb about possibly using our sysinit.rc for frx05. This way we will only have to worry about updates and not the build itself.

I'll commit the mtd parts tonight..

You're awesome

Also, for calibration, the program we invoke to do the calibration is pretty small and wouldn't really cause problems with initrd or adding it to system. The problem is that I always end up with random text cluttering up the touch points. I'd much rather see an app in Android for calibration so lcd density doesn't mess up calibration. I really agree that the closer we can mimic true android devices, the better experience we are going to get.

On the kernel side of things, I was looking at the work of cedesmith on a bootloader that builds on top of tinboot. He's done some interesting things including the ability to load a kernel from the computer which would absolutely rock. He's designing it for the HD2 crowd, but I think I'm going to play around with it and see what I can learn about it. Might be something useful there

http://forum.xda-developers.com/showthread.php?t=901305

[Lmiller1708]

Originally Posted by natemcnutty

Wonder if that's why magldr just uses the zImage and initrd.gz from the first partition. Then you could use the update utility to update them without having to ever flash again.

On a side note, I would double check with the Vogue guys to make sure everything does get wiped when they update their kernel. I'm still wondering if partition tables may have something to do with this. Hopefully I can finally get a break from work and home to actually do some serious testing. I find it really odd that the partition table has two partitions that start at the same location rather than simply erasing the second partition and moving the locations of everything.

Magldr is a custom bootloader... It can do about anything.

We are in the same as the Vogue (since we copied it). They need to reflash to upgrade there kernal too. No way around it with out a custom bootloader...

Originally Posted by [ACL]

Finally stabilised this bad boy. No more reboots, all done via sysinit.rc and its the sexiest thing to be able to mount the sdcard as mass storage.

I'll talk to jonpry about this whole kernel portion poop. When wozzer bricked himself i know he was talking about possibly writing to nand from within android. If this is possible, then all kernel updates can be done from inside without bothering the damn bootloader.

In anycase i'll repost my stuff up tonight and continue working on this. Wifi is still broken for me but i know why. Eventually i think our build will have a set of custom scripts that android will execute on boot. 2 i can think of is setting up the wifi nvram part and the other applying the calib points to the input. This way our initrd remains small since the kernel will only get bigger.

I think we have done a great deal of streamlining and i'll discuss with stinedb about possibly using our sysinit.rc for frx05. This way we will only have to worry about updates and not the build itself.

I'll commit the mtd parts tonight..

GREAT!

If it is possible to write to nand from within that would probably solve our problem. (Maybe)


I will wait for your System.tgz. Did you get data working on it?
That was my problem.. It was stable but with no data.

[[ACL]]

Originally Posted by Lmiller1708

Magldr is a custom bootloader... It can do about anything.

We are in the same as the Vogue (since we copied it). They need to reflash to upgrade there kernal too. No way around it with out a custom bootloader...




GREAT!

If it is possible to write to nand from within that would probably solve our problem. (Maybe)


I will wait for your System.tgz. Did you get data working on it?
That was my problem.. It was stable but with no data.

i cant test cdma data since i have no service but wifi is coming up.. so i'll post my stuff tonight. last night i passed out and forgot to upload.

i guess its time to unleash this info to the cookers soon.. see what nand abominations they come up with.

[tiad8]

@ THE A TEAM

I been following you guys for a long time. I have so much respect for this team. You guys are true hereos in my book.

I have never seen a team of people like you guys. It's just simply amazing works. The XDA, PPC. WE ARE REALLY PROUD TO HAVE A TEAM LIKE YOU GUYS.

THANK YOU GUYS FOR YOUR AMAZING WORK

FROYO X/SPRINT TOUCH PRO 2/RHOD

[[ACL]]

Originally Posted by tiad8

@ THE A TEAM

I been following you guys for a long time. I have so much respect for this team. You guys are true hereos in my book.

I have never seen a team of people like you guys. It's just simply amazing works. The XDA, PPC. WE ARE REALLY PROUD TO HAVE A TEAM LIKE YOU GUYS.

THANK YOU GUYS FOR YOUR AMAZING WORK

FROYO X/SPRINT TOUCH PRO 2/RHOD

thanks dood. You are my first target. I'm cooking up a large post bout the rom process. I've yet to commit the camera portion to the kernel but once thats done you can go to town.

[tiad8]

Originally Posted by [ACL]

thanks dood. You are my first target. I'm cooking up a large post bout the rom process. I've yet to commit the camera portion to the kernel but once thats done you can go to town.

Your the man buddy plus the A TEAM

thanks

FROYO X/SPRINT TOUCH PRO 2/RHOD

[natemcnutty]

ACL, I'm custom building a busybox for us, and I've already compiled a flash_erase from the latest mtd utils. I currently have the initrd.gz at 1.1 MB, but I think I can shave quite a bit off if I remove some of the unnecessary stuff from busybox.

Here's what I need to know. Do we only need the commands that are used in initrd.gz and init.rc to be referenced to busybox, or do we need all of the commands that are in the /bin folder for initrd? There are quite a few commands in there that we do not use, and I'm wondering if I need to keep them, or if I can just add them in the future if we need them.

Once finished cleaning that up, I think we can get initrd.gz under 1 MB. I also think we can clear up another 3 MB of space by shifting the partition table, but I'll play with that later. Also, I'm still not sure why we are starting at an offset of 64MB for our partitions, and we can reclaim some of that space if we can find where it is safe to move it to. I'm trying to get us enough space in the system partition that we can accommodate the chefs while still having plenty of room for user date

[m4f1050]

I sold my Touch Pro2 but maybe for calibration you can check in:

HKEY_LOCAL_MACHINE\Hardware\Devicemap\Touch\Calibr ationData

[[ACL]]

Originally Posted by natemcnutty

ACL, I'm custom building a busybox for us, and I've already compiled a flash_erase from the latest mtd utils. I currently have the initrd.gz at 1.1 MB, but I think I can shave quite a bit off if I remove some of the unnecessary stuff from busybox.

Here's what I need to know. Do we only need the commands that are used in initrd.gz and init.rc to be referenced to busybox, or do we need all of the commands that are in the /bin folder for initrd? There are quite a few commands in there that we do not use, and I'm wondering if I need to keep them, or if I can just add them in the future if we need them.

Once finished cleaning that up, I think we can get initrd.gz under 1 MB. I also think we can clear up another 3 MB of space by shifting the partition table, but I'll play with that later. Also, I'm still not sure why we are starting at an offset of 64MB for our partitions, and we can reclaim some of that space if we can find where it is safe to move it to. I'm trying to get us enough space in the system partition that we can accommodate the chefs while still having plenty of room for user date

Right now to get it to be small i removed e2fsck from the bin folder. This is because we dont check on ext2 partitions anymore so no need to have it there. That file alone is pretty big so im going to commit my change. This isnt part of busybox, but the vogue script supported ext2 img files which we dont, so it can be removed.

Well the system partition already has its own bin directory with all the goodies possible so the busybox for initrd should be the bare essentials to boot and run the install script. So i think we will be safe with a small busybox.. I think we should be good to test your busybox.

edit: oops.. not a bin directory but xbin is on system. Not sure if it has a full busy box in there..

Edit2: Also here is the latest install, update and install-seq

You are big boys so you can make your own NHB and harvest your own modules and apply it to the android update. Wifi is working for me but i cant test cdma data. I'll leave that up to you fellas.

http://htcdevs.wirelesstcp.net/files/xdandroid/