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