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

[[ACL]]

Ok so this is the order or execution in the ril.

1) talk to modem and make sure you are ok
2) check pap and chap files make sure you can open them
3) attempt to fire up pppd

Now you notice pppd is the last step. Funny thing is we arent even getting there, we are failing at least once on 1 and then we keep failing on 2. Only reason i know this is because of the rils i made. They are very verbose so we get to see everything

Unfotunately we cant copy because android is natively setup this way. /etc will always be a link for /system/etc. But thats where it ends. We decide about the internals. So we can move ppp to data if we want to and link it back to /etc

The other method is to recompile pppd and have it look somewhere else. Now arrg was able to bring up data once after much hacking which was manual. But it was also short lived.

At this stage i say we try anything.. i finally got a boost mobile account and will try to activate today. So we will continue this through the weekend.

[natemcnutty]

Originally Posted by [ACL]

Ok so this is the order or execution in the ril.

1) talk to modem and make sure you are ok
2) check pap and chap files make sure you can open them
3) attempt to fire up pppd

Now you notice pppd is the last step. Funny thing is we arent even getting there, we are failing at least once on 1 and then we keep failing on 2. Only reason i know this is because of the rils i made. They are very verbose so we get to see everything

Unfotunately we cant copy because android is natively setup this way. /etc will always be a link for /system/etc. But thats where it ends. We decide about the internals. So we can move ppp to data if we want to and link it back to /etc

The other method is to recompile pppd and have it look somewhere else. Now arrg was able to bring up data once after much hacking which was manual. But it was also short lived.

At this stage i say we try anything.. i finally got a boost mobile account and will try to activate today. So we will continue this through the weekend.

Great information. I think that if we have it working with rootfs, we should have no issue porting that over to initrd or elsewhere and using symlinks or whatever we need to do. I'm slowly testing out changes at the moment to see what breaks what. Next on my list is to try swapping out android.init and see what changes I need to make to get that one working.

[[ACL]]

Originally Posted by natemcnutty

Great information. I think that if we have it working with rootfs, we should have no issue porting that over to initrd or elsewhere and using symlinks or whatever we need to do. I'm slowly testing out changes at the moment to see what breaks what. Next on my list is to try swapping out android.init and see what changes I need to make to get that one working.

Our initrd automatically checks for this already. It looks for a file called "init" on the system. If not found, then it executes its own android.init. Good for cookers who want to deploy a custom init if needed. So we should include the android.init inside /system but rename it as init

BoominSVX got me a boost account so ill be active tonight to continue the good fight.. also the recovery is coming along fine. Not sure if im going to git it or not.

[natemcnutty]

Just as an update, I swapped init.android out for the one from our rootfs and added ueventd.rc and the symlink of /sbin/ueventd (pointing to ../init.android) to my initrd and it boots into Android beautifully.

Next, I added in pppd, netd, su, and sqlite3 to see how it functions with those. Everything seems to be up and running smoothly for initrd.

Now I'm working on moving some of this into /system instead of initrd. Will post back when I have a little more done

[[ACL]]

Originally Posted by natemcnutty

Just as an update, I swapped init.android out for the one from our rootfs and added ueventd.rc and the symlink of /sbin/ueventd (pointing to ../init.android) to my initrd and it boots into Android beautifully.

Next, I added in pppd, netd, su, and sqlite3 to see how it functions with those. Everything seems to be up and running smoothly for initrd.

Now I'm working on moving some of this into /system instead of initrd. Will post back when I have a little more done

awesome..

i talked to sine about ueventd.rc and it looks like its for gingerbread only. That part of the rc doesnt belong in this base and should be removed. On the gigerbread build we can put it back.

Which leads me to my next question. We doing gingerbread cyanogen or wha? this thing is turning into a masterpiece ..

[natemcnutty]

Originally Posted by [ACL]

awesome..

i talked to sine about ueventd.rc and it looks like its for gingerbread only. That part of the rc doesnt belong in this base and should be removed. On the gigerbread build we can put it back.

Which leads me to my next question. We doing gingerbread cyanogen or wha? this thing is turning into a masterpiece ..

OK, I removed those two files then. I still don't get why data isn't working, but that is what I'm looking into right now.

Also, for some reason, when booting we only see 3 of the mtdparts. I did an ls of /dev/block and /dev/mtd/ during the install script to find that the mtd4 was not being created until we get into Android. That means I can't format or reference our cache partition, and when I do it, Android will not boot since there is no /cache mount point. Any idea why this might be?

As for cyanogen, I don't know what all would be needed to get it running, but I'd be willing to look into it

Edit: You sure we don't need/want ueventd? I was just looking at our sysinit.rc and has this:

service ueventd /sbin/ueventd
    critical

Without it, it throws an error that it couldn't find it and is disabling the daemon. I think it is required by our init.android but not the other one that the vogue used originally. I'm leaving it in since we are only going up to gingerbread from here, and it appears Froyo is happy with it being there.

[[ACL]]

Originally Posted by natemcnutty

OK, I removed those two files then. I still don't get why data isn't working, but that is what I'm looking into right now.

Also, for some reason, when booting we only see 3 of the mtdparts. I did an ls of /dev/block and /dev/mtd/ during the install script to find that the mtd4 was not being created until we get into Android. That means I can't format or reference our cache partition, and when I do it, Android will not boot since there is no /cache mount point. Any idea why this might be?

As for cyanogen, I don't know what all would be needed to get it running, but I'd be willing to look into it

Edit: You sure we don't need/want ueventd? I was just looking at our sysinit.rc and has this:

service ueventd /sbin/ueventd
    critical

Without it, it throws an error that it couldn't find it and is disabling the daemon. I think it is required by our init.android but not the other one that the vogue used originally. I'm leaving it in since we are only going up to gingerbread from here, and it appears Froyo is happy with it being there.

another thing stine said make sure we grab the correct init.android. They arent the same from froyo and gingerbread so we need to make sure we get them from the correct git.

cyanogen is easy .. had 5.0 running before but im interested in the later one. So in time i will upload those tars as well.

anyways i wont be back till later tonight so keep attacking it

Edit: i saw you issue. I'm fixing it in my commit tonight. Our initrd wasnt creating the directories for all the new nandparts thats all. We are all set now.