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

[[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/

[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

[[ACL]]

Originally Posted by natemcnutty

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

I'm confused about the navipad stuff you mentioned. I'm a few commits behind but you are saying i should not commit anything navipad ?

I dont think i have any mountbinds. If i do, let me know. I should not since they cant be used. This was a complete hack we implemented back in the day which people got too comfy with.

Yes, uevend i saw while booting. I dont have it so it just errors out and skips it. what is it and what does it do ? I was actually going to remove it since i though it was more for gingerbread. Need more info on this service i suppose.

If i cant get a new ril today then simlink from /bin/pppd to /system/bin/pppd will be our solution.. falling behind on the next build.. I dont see any other reason now to fully release this to more people.

also fellas.. mtdparts.. someone do the math today we can agree on..

[Lmiller1708]

Originally Posted by [ACL]

I'm confused about the navipad stuff you mentioned. I'm a few commits behind but you are saying i should not commit anything navipad ?

I dont think i have any mountbinds. If i do, let me know. I should not since they cant be used. This was a complete hack we implemented back in the day which people got too comfy with.

Yes, uevend i saw while booting. I dont have it so it just errors out and skips it. what is it and what does it do ? I was actually going to remove it since i though it was more for gingerbread. Need more info on this service i suppose.

If i cant get a new ril today then simlink from /bin/pppd to /system/bin/pppd will be our solution.. falling behind on the next build.. I dont see any other reason now to fully release this to more people.

also fellas.. mtdparts.. someone do the math today we can agree on..

I put together a Spreadsheet for figuring out NAND, only change the values in RED. See Attached

So here is what we currently have:

mtdparts=msm_nand:0x20000000@0x0(nand),0x01000000@0x04000000(root),0x08000000@0x05000000(system),0x13000000@0x0D000000(userdata)

This is with root set to 5MB, This would give the system 143 MB and Data 300MB:

mtdparts=msm_nand:0x20000000@0x0(nand),0x500000@0x04000000(root),0x8F00000@0x4500000(system),0x12c00000@0xD400000(userdata)

Again maybe we can change the starting point to a smaller value other then 4000000... But it's only 3.8MB of space... Maybe this is where the Kernal is kept which it 3.6MB currently...

[natemcnutty]

Originally Posted by Lmiller1708

I put together a Spreadsheet for figuring out NAND, only change the values in RED. See Attached

So here is what we currently have:

mtdparts=msm_nand:0x20000000@0x0(nand),0x01000000@0x04000000(root),0x08000000@0x05000000(system),0x13000000@0x0D000000(userdata)

This is with root set to 5MB, This would give the system 143 MB and Data 300MB:

mtdparts=msm_nand:0x20000000@0x0(nand),0x500000@0x04000000(root),0x8F00000@0x4500000(system),0x12c00000@0xD400000(userdata)

Again maybe we can change the starting point to a smaller value other then 4000000... But it's only 3.8MB of space... Maybe this is where the Kernal is kept which it 3.6MB currently...

I'll look at this in a bit when I get in, but quick comment on it starting at 0x4000000. That is actually 64 MB into the NAND, and we certainly don't need that much space. Also, what exactly is the point of the root partition since I don't think we are using it? I'm really curious what its purpose is supposed to be

[Lmiller1708]

Originally Posted by natemcnutty

I'll look at this in a bit when I get in, but quick comment on it starting at 0x4000000. That is actually 64 MB into the NAND, and we certainly don't need that much space. Also, what exactly is the point of the root partition since I don't think we are using it? I'm really curious what its purpose is supposed to be

Where do you get 64MB?

Also we can change and remove these MTDParts as need be... Maybe just leave it up to the cooks.
If we want to add the cache we can with no problem.

Edit: I think ACL has plans for the Root...

[natemcnutty]

Originally Posted by Lmiller1708

Where do you get 64MB?

Also we can change and remove these MTDParts as need be... Maybe just leave it up to the cooks.
If we want to add the cache we can with no problem.

Edit: I think ACL has plans for the Root...

I get 64 MB by this:

0x04000000 (base 16) = 67,108,864 (base 10)
67,108,864 (bytes) / 1024 = 65,536 (kb) / 1024 = 64 (MB)

The kernel and tinboot code only occupy the first 6 MB or so of NAND. I think we could safely shrink the starting point to 16 MB without any fear of overwriting stuff. How does this look:

mtdparts=msm_nand:
0x20000000@0x0(nand) - 512 MB total
0x00800000@0x01000000(root) - 8 MB of space
0x0A000000@0x01800000(system) - 160 MB of space
0x14800000@0x0B800000(userdata) - 328 MB of space

I think 160 MB might be a bit much for system, but that does give the chefs a lot of space to work with. 328 MB for user data will really be 310 MB of usable space since we are eating up 18 MB with modules.