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

[[ACL]]

Originally Posted by steveholtam

First off, thanks to you guys who are way smarter then me. I've been following this thread since day one. Anyway, I have spent the last couple of hours running on NAND!!!

It took me a few tries to get up and running. The install-seq.sh file was not mentioned in the frst post. But once I moved that over, all was well. I'm using the files from the 23rd.

Most aspects are working just fine. I have a 400 model on Sprint, and data is not working over the Sprint network. I am getting texts and the phone works. Wifi works great though. A reboot worked fine.

I'm ready to continue testing as required. Booting off NAND was awesome! I can't wait till data is working and all current mods are incorporated into NAND.

Let me know if anyone needs testing done or a custom rom tested for them.

Steve

Yes, data is an issue right now. Bottom line is that xdandroid ril references /bin/pppd which we removed. So in the mean time we will have to create our own ril for nand until frx5 where we can correct the issue on xdandroid. I'm also interested in what cotulla will do for the ril since for the hd2 they made a wrapper for the real ril instead of creating their own. Either way we will pick one of those solutions soon enough.

Jonpry made a new ril but Lmiller reported issues with it. You are can try it if you want. I havent been able to get my env ready to compile the ril.

The other alternative is to either sym link /bin/pppd to /system/bin/pppd or include the file in your own initrd. Choice is yours.

[MassStash]

Originally Posted by vistazifta

and now for my stupid question being that im using a sprint branded rhod400 unlocked to gsm and i have to change cdma=1 to cdma=0 so gsm will work i probably have to compile a new tiboot right and if so can i just dump it into the nbh that has everything else already

it is all cdma based, so cdma is 1. If you know the Question is stupid, then please refrain from asking it. Come up with "not stupid questions", or chill like the rest of us bro...

Good that your attempting to think, no means to discourage. but try googleing "xdandroid/htc-linux irc logs" or something and read...

[vistazifta]

sorry again acl but when i used an sd only build i used to change it to zero and it worked like a charm but all im asking is if i compile a new tinboot will this work

[natemcnutty]

Originally Posted by [ACL]

Yes, data is an issue right now. Bottom line is that xdandroid ril references /bin/pppd which we removed. So in the mean time we will have to create our own ril for nand until frx5 where we can correct the issue on xdandroid. I'm also interested in what cotulla will do for the ril since for the hd2 they made a wrapper for the real ril instead of creating their own. Either way we will pick one of those solutions soon enough.

Jonpry made a new ril but Lmiller reported issues with it. You are can try it if you want. I havent been able to get my env ready to compile the ril.

The other alternative is to either sym link /bin/pppd to /system/bin/pppd or include the file in your own initrd. Choice is yours.

For now, I'm going to build mine as if we were using the rootfs files just because I want to try to keep all of stinebd's stuff together.

As for the /cache partition, we are creating a partition 1 that we are not using, right? Unless there is some other reason for having this mtdpart: 0x01000000@0x04000000(root)

I would really like to replicate the android environment as closely as possible, so if best practices or common practices have a specific layout, I'd like to go that route. Maybe some day we can get Clockwork Mod working on our stuff and be able to update using that. Maybe even a way to update the kernel without having to flash anything

[[ACL]]

Originally Posted by natemcnutty

For now, I'm going to build mine as if we were using the rootfs files just because I want to try to keep all of stinebd's stuff together.

As for the /cache partition, we are creating a partition 1 that we are not using, right? Unless there is some other reason for having this mtdpart: 0x01000000@0x04000000(root)

I would really like to replicate the android environment as closely as possible, so if best practices or common practices have a specific layout, I'd like to go that route. Maybe some day we can get Clockwork Mod working on our stuff and be able to update using that. Maybe even a way to update the kernel without having to flash anything

I agree 100 percent.. and this is why you cant use rootfs (since real androids dont)..lol .. Our new layout is welcomed by the team so far and they are exited that we are killing rootfs with a passion. So keep it to double check but lets keep our goal in mind to stick as closely to android.

With that said, the one we arent using is actually supposed to be used for boot. I want to shink this down to 5mb which will hold the new kernels and its backup initrd. I already use this so i know it works. This way you can update without flashing from inside android if you want. Its a developers dream actually. So even if the new kernel is bad, you simply erase the file and the old kernel will still take over without losing any data. This also allows us to use the reboot feature which isnt on xdandroid but is on cyanogen.

I don't see any harm in having a /cache as well, but since we cant use the native android tools to flash yet it will be useless. But in the future we might since Alex is working on his LK boot loader. This will eventually replace tinboot and get us closer to pureness .. So feel free to allocate a bit for that as well if you want. Not sure how big but if we find a good use for it might as well right?.

So cook up the final mtd parts so we can commit. I have some real work to do tonight so couldnt do anything here. damn job i tell you.. eating me up alive..

Also, haret guys reporting some pan display timeout during android use. Anyone experience that? i checked my logs and been running for 30 mins with nothing, so im hesitant to change our code with their fix. This error is in the frame buffer and it happens when you get the sleep of death.. I asked arrgg to check since he has a whacky rhod400 . I cant replicate the issue.

Also did you check to see if the ril i posted worked for you? if not then we need to build our ril until i can get stine to do it.

Edit: Bro actually i need your help since your scripting is top notch. I never got around to finish the other variants for the kb auto install. This is how i detect it on the install script. I need to fill in the rest of the parts but i think you already have that done. We need the 500 in there and i guess might as well throw in those poor gsm bastards for the future.

if [ "`cat /sys/class/htc_hw/machine_variant`" == "RHOD40000" ];then
    echo "USING EXPERIMENTAL RHOD400 LAYOUT"
    cp -f /system/etc/keymaps/rhod400_microp-keypad.kl /system/etc/keymaps/microp-keypad.kl
    cp -f /system/etc/keymaps/rhod400_microp-keypad.kcm.bin /system/etc/keymaps/microp-keypad.kcm.bin
    cp -f /system/etc/keymaps/rhod400_navi_pad.kl /system/etc/keymaps/raph_navi_pad.kl 
else
    echo "Add other variants here."
fi
    cp -af /system/etc/keymaps/qwerty.kcm.bin /init.etc/keymaps/qwerty.kl /etc/keymaps/

[[ACL]]

Originally Posted by vistazifta

sorry again acl but when i used an sd only build i used to change it to zero and it worked like a charm but all im asking is if i compile a new tinboot will this work

To be honest i never actually used that or even know how to fix it. You will need to build your own kernel and tinboot for that so you can set the cmdline line. But my next patch will prob wipe that out which i guess is bad since there are people who use gsm on their rhod 400s? i need to rethink this

[natemcnutty]

Originally Posted by [ACL]

I agree 100 percent.. and this is why you cant use rootfs (since real androids dont)..lol .. Our new layout is welcomed by the team so far and they are exited that we are killing rootfs with a passion. So keep it to double check but lets keep our goal in mind to stick as closely to android.

With that said, the one we arent using is actually supposed to be used for boot. I want to shink this down to 5mb which will hold the new kernels and its backup initrd. I already use this so i know it works. This way you can update without flashing from inside android if you want. Its a developers dream actually. So even if the new kernel is bad, you simply erase the file and the old kernel will still take over without losing any data. This also allows us to use the reboot feature which isnt on xdandroid but is on cyanogen.

I don't see any harm in having a /cache as well, but since we cant use the native android tools to flash yet it will be useless. But in the future we might since Alex is working on his LK boot loader. This will eventually replace tinboot and get us closer to pureness .. So feel free to allocate a bit for that as well if you want. Not sure how big but if we find a good use for it might as well right?.

So cook up the final mtd parts so we can commit. I have some real work to do tonight so couldnt do anything here. damn job i tell you.. eating me up alive..

Also, haret guys reporting some pan display timeout during android use. Anyone experience that? i checked my logs and been running for 30 mins with nothing, so im hesitant to change our code with their fix. This error is in the frame buffer and it happens when you get the sleep of death.. I asked arrgg to check since he has a whacky rhod400 . I cant replicate the issue.

Also did you check to see if the ril i posted worked for you? if not then we need to build our ril until i can get stine to do it.

Edit: Bro actually i need your help since your scripting is top notch. I never got around to finish the other variants for the kb auto install. This is how i detect it on the install script. I need to fill in the rest of the parts but i think you already have that done. We need the 500 in there and i guess might as well throw in those poor gsm bastards for the future.

if [ "`cat /sys/class/htc_hw/machine_variant`" == "RHOD40000" ];then
    echo "USING EXPERIMENTAL RHOD400 LAYOUT"
    cp -f /system/etc/keymaps/rhod400_microp-keypad.kl /system/etc/keymaps/microp-keypad.kl
    cp -f /system/etc/keymaps/rhod400_microp-keypad.kcm.bin /system/etc/keymaps/microp-keypad.kcm.bin
    cp -f /system/etc/keymaps/rhod400_navi_pad.kl /system/etc/keymaps/raph_navi_pad.kl 
else
    echo "Add other variants here."
fi
    cp -af /system/etc/keymaps/qwerty.kcm.bin /init.etc/keymaps/qwerty.kl /etc/keymaps/

That is great news. I cloned cLK on git to play with a bit, but haven't had a chance to get back to it. Hopefully Alex has seen that over in the HD2 area of XDA.

For the code, this is what you want:

LAYOUT=`/bin/grep ".*0*" /sys/class/htc_hw/machine_variant`
if [ $LAYOUT = "RHOD30000" ] ; then
    echo "USING EXPERIMENTAL TILT2 LAYOUT"
        cp -f /init.etc/keymaps/tilt2_microp-keypad.kl /etc/keymaps/microp-keypad.kl
    cp -f /init.etc/keymaps/tilt2_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
    cp -f /init.etc/keymaps/tilt2_navi_pad.kl /etc/keymaps/raph_navi_pad.kl
elif [ $LAYOUT = "RHOD21000" ] ; then
    echo "USING EXPERIMENTAL RHOD210 LAYOUT"
        cp -f /init.etc/keymaps/rhod210_microp-keypad.kl /etc/keymaps/microp-keypad.kl
    cp -f /init.etc/keymaps/rhod210_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
    cp -f /init.etc/keymaps/rhod210_navi_pad.kl /etc/keymaps/raph_navi_pad.kl
elif [ $LAYOUT = "RHOD40000" ] ; then
        echo "USING EXPERIMENTAL RHOD400 LAYOUT"
        cp -f /init.etc/keymaps/rhod400_microp-keypad.kl /etc/keymaps/microp-keypad.kl
        cp -f /init.etc/keymaps/rhod400_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
        #cp -f /init.etc/keymaps/rhod400_navi_pad.kl /etc/keymaps/raph_navi_pad.kl #does not exist, just following example
elif [ $LAYOUT = "RHOD50000" ] ; then
        echo "USING EXPERIMENTAL RHOD500 LAYOUT"
        cp -f /init.etc/keymaps/rhod500_microp-keypad.kl /etc/keymaps/microp-keypad.kl
        cp -f /init.etc/keymaps/rhod500_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
        #cp -f /init.etc/keymaps/rhod500_navi_pad.kl /etc/keymaps/raph_navi_pad.kl #does not exist, just following example
else
        echo "DEFAULTING TO RHOD500 LAYOUT BECAUSE WE CAN'T DETERMINE YOUR MODEL TYPE AND NO .KB FILE EXISTS IN ANDBOOT FOLDER ON THE SD CARD!"
        cp -f /init.etc/keymaps/rhod500_microp-keypad.kl /etc/keymaps/microp-keypad.kl
        cp -f /init.etc/keymaps/rhod500_microp-keypad.kcm.bin /etc/keymaps/microp-keypad.kcm.bin
        #cp -f /init.etc/keymaps/rhod500_navi_pad.kl /etc/keymaps/raph_navi_pad.kl #does not exist, just following example
fi

Note: We never made some of the commits from Haret, so we don't want the navi_pad stuff or it messes up our buttons.

Also, no need for the following stuff since we moved these files into system:

cp -af /init.etc/keymaps/qwerty.kcm.bin /init.etc/keymaps/qwerty.kl /etc/keymaps/
mount --bind /etc/keymaps /system/usr/keychars
mount --bind /etc/keymaps /system/usr/keylayout

It seems that the init.android from our rootfs requires ueventd and ueventd.rc to be included. I have it to the point where the boot animation starts, but it just goes on forever and never finishes loading. Not really sure how to diagnose that without having ADB. I guess I could upload the files for someone else to take a look at it, but that seems like a lot of effort :P

[vistazifta]

thanks i appreciate all ur help. so if u guys do leave in all the gsm stuff for the poor ppl like me on at&t is there a way to force cdma=0 on its own if it detects a sim card as most sprint and verizon users dumped their sim cards ages ago anyhow and being that its a second line im not afraid to eff it up so im playing with the build on page one and im getting weird reboots and it usually loops a couple times on boot but im gonna format my sd card and and put in a fresh copy of sys.ext2 and build a new data.img ill c if it help and will get back to u guys

[vistazifta]

more feedback for u guys i did a fresh format and install heres what i got while simcard was inserted it would have a boot-loop 5-6 times then it would crash in the console. finally i said ok lets c what happens if i take out the sim and it only looped once and built a data.img nicely after that didnt try rebooting it yet but so far 30 minutes no crashes problem is that when trying to connect to wifi (i am using connectify as i forgot the password to my router and im to lazy to reset it and ad hoc doesnt work automatically on android maybe u can play with it if u guys r bored ever) it keeps saying authenticating and the disconnecting kind of in a "loop" lol. android itself otherwise is relatively slow. u guys are all running newer builds that r only distributed via pm though and i was told to wait for latest build so i dont really know whats working and whats not. ill continue playing with it so just ask if u want me to give more feedback if thats what u want but ill assume that some stuff r working better on latest build forget about gsm for now once the hard work is done u can always do a small gsm-only rom ill have to give it up use another fone will keep this for testing only if thats what u guys want and i call it giving it up for a few so thr bulk can get their goodies

[Lmiller1708]

Originally Posted by vistazifta

hey steve i know im going to sound stupid and all but did u set up an apn that says sprint and #777 cuz without it aint no sprint user gettin data almost everyone knows it if they used tiad8's roms or anything that boots thru haret console basically

No. Data will not work by doing that. It's the RIL that is not working, it's supposed to be in the bin folder but we have it in the /system/bin. (So it can be upgraded with out re flashing.
Jonpry and ACL are working on a fix.

Originally Posted by vistazifta

and now for my stupid question being that im using a sprint branded rhod400 unlocked to gsm and i have to change cdma=1 to cdma=0 so gsm will work i probably have to compile a new tiboot right and if so can i just dump it into the nbh that has everything else already

You will not boot with your SIM card... Period.
You will not need to change anything in Tinboot either.

Edit: Well I don't know what happened there but... I guess these were already on the other page... Darn refresh!