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

[[ACL]]

Originally Posted by natemcnutty

Also thought I'd post this here. I have been thinking about a way to get the SIM card working on CDMA phones, and I might have a great idea for someone like ACL to check out.

While in Android, plug in the USB. As long as USB is plugged in, your phone is receiving enough power to continue running without a battery. Yup, you guessed it. Yank that battery, and Android will still run so you can mess around with the SIM card slot.

Unfortunately, Android doesn't recognize the slot or when you slide things in our out, but the phone certainly reboots when looking for the sdcard on boot if you have a SIM card in the slot. This is happening during initrd phase, so we have something in there that references the SIM card slot properly but must be trying to access it in an improper way.

One of my goals is to force the correct location for our SD card in bootenv. Without having the logic that looks for the location of the sd card slot, I think we might be able to dumb luck our way into finding the SIM card slot

interesting. Well i have no service anymore and god knows where my sim card is. But i have asked Jonpry for help on this.

I think and there may be a conflict in what gsm and cdma use in the smd channels. We are dealing with this now actually on .35 but havent really planned how to switch back and froth. I'll see if i can find my sim card to see what logs i can pull up before the crash.

[natemcnutty]

Wirelessly posted (Opera/9.80 (Windows Mobile; Opera Mini/5.1.21594/23.333; U; en) Presto/2.5.25 Version/10.54)

Originally Posted by [ACL

]

interesting. Well i have no service anymore and god knows where my sim card is. But i have asked Jonpry for help on this.

I think and there may be a conflict in what gsm and cdma use in the smd channels. We are dealing with this now actually on .35 but havent really planned how to switch back and froth. I'll see if i can find my sim card to see what logs i can pull up before the crash.

I wish I knew more about the SMD channels. That is the reason NAND is not working on GSM devices from what I can tell. I wonder if the vogue bootenv might support it better. Going to play some more with their installer and our FRX04 tonight.

[Lmiller1708]

Wirelessly posted (Vogue: Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; MSM Build/FRX03) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1)

Originally Posted by [ACL

]

if android is saying that then the issue is on the /data portion not the system. I will upload my frx4 tarball.

When you mount data, there is a number of directories that must exist since our scripts dont make it for us. Just make sure they are already created before android begins.

Thanks for all the testing by the way.. glad i can count on you guys to hone this project to perfection.

After a bit more playing around with the androidinstall.tgz I have a feeling that I'm not packing it correctly. When I extract the vogue one and repack it I can't get that to boot anymore either.
it should be just a simple tar command... I will post what I'm using later tonight. Just thought I would see if you guys know what's going on.

[[ACL]]

Sorry vfellas .. at a rooftop ripped drunk... I won't be able to look into anything till tomottow.

[natemcnutty]

Originally Posted by [ACL]

Sorry vfellas .. at a rooftop ripped drunk... I won't be able to look into anything till tomottow.

Haha, have fun

[natemcnutty]

Well, this is going better than I expected. Unless someone tells me otherwise, I'm modifying the new bootenv/tinboot for the following:

1) Full NAND only (at least initially until it is stable)
2) Rhodium support only (taking out detection of other phones)
3) build.prop is now responsible for setting lcd density (currently 240 in FRX04 and makes our cmdline is redundant...)
4) Incorporating stinebd's OTA update.zip method
5) Froyo libs moved into system (see note below)

I've learned that you can't bind mount onto an initrd, so you have to use links and copy the data that way. Unfortunately, this poses a problem for our method of copying hw lib files based on the build type. For now, I am going to cook the libs into the system. This means we need to cook the libs and stuff into system for each build type (i.e. froyo, gingerbread, cynogen, etc.) that you want to try.

Here's the code I'm talking about:

RCSCRIPT=""
RCCONFIG=""

echo "Checking for build type..."
if [ -f /system/hero.build ] ; then
    echo "Hero build detected"
    RCSCRIPT="hero"
    RCCONFIG="hero"
    ln /data/app_s /system/app

elif [ -f /system/eclairhero.build ] ; then
    echo "HERO 2.1 BUILD DETECTED -- ECLAIR"
    RCSCRIPT="eclairhero"
    RCCONFIG="eclairhero"
    mount --bind /lib/eclair/hw /system/lib/hw

elif [ -f /system/eclair.build ] ; then
    echo "Eclair build detected"
    RCSCRIPT="eclair"
    RCCONFIG="eclair"
    mount --bind /lib/eclair/hw /system/lib/hw

elif [ -f /system/froyo.build ] ; then
    echo "Froyo build detected"
    RCSCRIPT="froyo"
    RCCONFIG="froyo"
    ln -s /lib/froyo/hw /system/lib/hw

    # vold: Fix sdcard device location for CDMA boards (thanks paalsteek)
    if [ -d /sys/devices/platform/msm_sdcc.3 ]; then
        /bin/sed -i -e 's:/devices/platform/msm_sdcc\.2:/devices/platform/msm_sdcc.3:g' /etc/vold.fstab
    fi

elif [ -f /system/gingerbread.build ] ; then
    echo "Gingerbread build detected"
    RCSCRIPT="gingerbread"
    RCCONFIG="gingerbread"
    ln -s /lib/froyo/hw /system/lib/hw

    # vold: Fix sdcard device location for CDMA boards (thanks paalsteek)
    if [ -d /sys/devices/platform/msm_sdcc.3 ]; then
        /bin/sed -i -e 's:/devices/platform/msm_sdcc\.2:/devices/platform/msm_sdcc.3:g' /etc/vold.fstab
    fi

elif [ -f /system/tattoo.build ] ; then
    echo "Tattoo build detected"
    RCSCRIPT="tattoo"
    RCCONFIG="tattoo"

elif [ -f /system/donut.build ] ; then
    echo "Donut build detected"
    RCSCRIPT="donut"
    RCCONFIG="donut"
    mount --bind /lib/donut/hw /system/lib/hw

elif [ -d /system/lib/donut ] ; then
    echo "Donut build detected"
    RCSCRIPT="donut"
    RCCONFIG="donut"

elif [ -f /system/xrom.build ] ; then
    echo "xROM build detected"
    RCSCRIPT="xrom"
    RCCONFIG="xrom"

elif [ -f /system/rogers.build ] ; then
    echo "Rogers build detected"
    RCSCRIPT="rogers"
    RCCONFIG="rogers"

elif [ -f /system/cyanogen.build ] ; then
    echo "cyanogen experimental detected.....eating donuts"
    RCSCRIPT="cyanogen"
    RCCONFIG="cyanogen"

elif [ -f /system/custom.build ] ; then
    echo "Custom init.rc detected"
    cp /system/sysinit.rc /build.cfg/init.sysinit.rc
    RCCONFIG="hero"
    RCSCRIPT="sysinit"
    
else
    echo "Unknown Android build. Assuming Ion variant"
    RCSCRIPT="ion"
    RCCONFIG="ion"

    # for the fake sensors library
    mount /lib/hw /system/lib/hw -o loop
    chmod 666 /dev/input/event0
fi

echo "using /init.$RCSCRIPT.rc as init.rc"
echo "using $card/conf/$RCCONFIG.user.conf"
cp "/init.cfg/init.$RCSCRIPT.rc" /etc/init.rc

Edit: We also need to cook the rootfs file /lib/froyo/libhardware_legacy.so into system.

[Lmiller1708]

Great work Nate.

For the LCDDENSITY this line of code won't work anymore?

LCDDENSITY=`/bin/grep -o "lcd.density=.*" /proc/cmdline | /bin/sed -e "s/.*lcd.density=//g" -e "s/ .*//g"`

if [ "$LCDDENSITY" != "" ] ; then
    echo "ro.sf.lcd_density=$LCDDENSITY" >> /etc/default.prop
    echo Setting ro.sf.lcd_density=$LCDDENSITY
fi

Also were you able to get Android booted?
And how did you make your initramfs?

[bheremans]

Originally Posted by Lmiller1708

Nope no modification was necessary. To get to the replimenu hold the Vol Up key. Then the screen can be used instead of the keys... Not perfect but it works. Touch the lower left to go down and lower right to go up, then touch the center for OK.

I just installed the most recent Vogue from the link you gave me above.

How are you guys making your initramfs, I think this is where I'm going wrong? Here is the script that I made...

cd initramfs
find . | cpio -o -H newc | gzip > ../initrd.gz
cd ../
mv initrd.gz tinboot-linux-msm/kernel/initrd.gz
echo rm initrd.gz

I think it is a problem with the files in git. Most files should be links to the busybox executable. If you clone kaisers git, the files are links :

bhe@HP-dv3500-bhe:/tmp/test/initrd-kaiser/initrd/bin$ ls -ali
total 2544
549794 drwxr-xr-x 2 bhe bhe   12288 2011-02-04 15:40 .
549793 drwxr-xr-x 4 bhe bhe    4096 2011-02-04 15:40 ..
549796 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 [ -> busybox
549797 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 [[ -> busybox
549798 -rwxr-xr-x 1 bhe bhe  117460 2011-02-04 15:40 adbd
549799 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 addgroup -> busybox
549800 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 adduser -> busybox
549801 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 adjtimex -> busybox
549802 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 ar -> busybox
549803 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 arp -> busybox
549804 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 arping -> busybox
549805 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 ash -> busybox
549806 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 awk -> busybox
549807 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 basename -> busybox
549808 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 bbconfig -> busybox
549809 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 bunzip2 -> busybox
549810 -rwxr-xr-x 1 bhe bhe 1530860 2011-02-04 15:40 busybox
549811 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 bzcat -> busybox

initrd-kaiser in android-initrd-kaiser - Gitorious

You could download it here as tar.gz to start test building : Tree for initrd-kaiser in android-initrd-kaiser - Gitorious

[natemcnutty]

Originally Posted by Lmiller1708

Great work Nate.

For the LCDDENSITY this line of code won't work anymore?

LCDDENSITY=`/bin/grep -o "lcd.density=.*" /proc/cmdline | /bin/sed -e "s/.*lcd.density=//g" -e "s/ .*//g"`

if [ "$LCDDENSITY" != "" ] ; then
    echo "ro.sf.lcd_density=$LCDDENSITY" >> /etc/default.prop
    echo Setting ro.sf.lcd_density=$LCDDENSITY
fi

Also were you able to get Android booted?
And how did you make your initramfs?

I'm trying to cut down on boot time since we added a lot of stuff to initrd. The whole checking cmdline is redundant because we can already set it in build.prop (and it is already set to 240 in FRX04).

Originally Posted by bheremans

I think it is a problem with the files in git. Most files should be links to the busybox executable. If you clone kaisers git, the files are links :

bhe@HP-dv3500-bhe:/tmp/test/initrd-kaiser/initrd/bin$ ls -ali
total 2544
549794 drwxr-xr-x 2 bhe bhe   12288 2011-02-04 15:40 .
549793 drwxr-xr-x 4 bhe bhe    4096 2011-02-04 15:40 ..
549796 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 [ -> busybox
549797 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 [[ -> busybox
549798 -rwxr-xr-x 1 bhe bhe  117460 2011-02-04 15:40 adbd
549799 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 addgroup -> busybox
549800 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 adduser -> busybox
549801 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 adjtimex -> busybox
549802 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 ar -> busybox
549803 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 arp -> busybox
549804 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 arping -> busybox
549805 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 ash -> busybox
549806 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 awk -> busybox
549807 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 basename -> busybox
549808 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 bbconfig -> busybox
549809 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 bunzip2 -> busybox
549810 -rwxr-xr-x 1 bhe bhe 1530860 2011-02-04 15:40 busybox
549811 lrwxrwxrwx 1 bhe bhe       7 2011-02-04 15:40 bzcat -> busybox

initrd-kaiser in android-initrd-kaiser - Gitorious

You could download it here as tar.gz to start test building : Tree for initrd-kaiser in android-initrd-kaiser - Gitorious

Excellent. Thanks for the heads up. What I was doing was opening the Vogue's initrd and replacing files with the ones I modified. I'll look at this later today. Once I get to work, I'll be testing the new initrd.lzma and initrd.gz I pumped out last night

[[ACL]]

Originally Posted by natemcnutty

Well, this is going better than I expected. Unless someone tells me otherwise, I'm modifying the new bootenv/tinboot for the following:

1) Full NAND only (at least initially until it is stable)
2) Rhodium support only (taking out detection of other phones)
3) build.prop is now responsible for setting lcd density (currently 240 in FRX04 and makes our cmdline is redundant...)
4) Incorporating stinebd's OTA update.zip method
5) Froyo libs moved into system (see note below)

I've learned that you can't bind mount onto an initrd, so you have to use links and copy the data that way. Unfortunately, this poses a problem for our method of copying hw lib files based on the build type. For now, I am going to cook the libs into the system. This means we need to cook the libs and stuff into system for each build type (i.e. froyo, gingerbread, cynogen, etc.) that you want to try.

Here's the code I'm talking about:

Full nand is the only way to go.. you know my old saying ? "give me nand or give me death".. :-p

The other phones are so far behind nand its good if we wipe em out ..

Lets face it. Each build from now on will most likely need tweaking so moving the libs so we dont need to mount bind isnt a bad idea. Plus once the cookers get their hands on our precious code, bam they will release builds like wild fire. It will be up to them to move the modules to the right place. An alternative is to create a thin slice to hold the modules so we can mount bind them that way. But a new partition just for modules? i dunno if thats a good idea.

What about the rc files ? having a directory dedicated to just rc files like the haret rootfs limits us to builds. So we should just do the same as vogue (and every other build) and have the rc in the build itself.

i got so drunk last night and i had to call in sick. So im doing some small changes here and there to help out, but it sounds like you got it all under control. I'll have to commit the links for bin directly instead of the binaries and any patches you want to tinboot itself, let me know.

Also i'm uploading the frx04 now.. i'll post a link later.

Edit: Forgot about the screen calibration. ideas ?.