PPCGeeks

PPCGeeks (http://forum.ppcgeeks.com/index.php)
-   Android On TP2 Development (http://forum.ppcgeeks.com/forumdisplay.php?f=319)
-   -   NAND Testing - 05-25 Update: New LK, Recovery.img, Kernel Updates through Recovery (http://forum.ppcgeeks.com/showthread.php?t=134598)

[ACL] 02-03-2011 02:56 PM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Quote:

Originally Posted by natemcnutty (Post 2050284)
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 02-03-2011 06:06 PM

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

Quote:

Originally Posted by [ACL
]
Quote:

Originally Posted by natemcnutty (Post 2050284)
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.

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 02-03-2011 06:38 PM

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)

Quote:

Originally Posted by [ACL
]
Quote:

Originally Posted by Lmiller1708 (Post 2050258)
Not a problem. Vogue is the same way as yours though...
I think its in the build script, but not sure...

Also do you have a TAR of the FRX04?
I made one but I can't get it to boot, I also included the files from the Rootfs.
Thanks!

Error I get with my tar:
A N D R O I D [xxx] init:Unable to open persistent property directory /data/property error:2

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] 02-03-2011 10:40 PM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Sorry vfellas .. at a rooftop ripped drunk... I won't be able to look into anything till tomottow.

natemcnutty 02-03-2011 11:06 PM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Quote:

Originally Posted by [ACL] (Post 2050609)
Sorry vfellas .. at a rooftop ripped drunk... I won't be able to look into anything till tomottow.

Haha, have fun ;)

natemcnutty 02-04-2011 03:49 AM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
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:
Code:

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 02-04-2011 08:19 AM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Great work Nate.

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

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 02-04-2011 10:44 AM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Quote:

Originally Posted by Lmiller1708 (Post 2050168)
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...
Code:

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 :

Code:

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 02-04-2011 12:38 PM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Quote:

Originally Posted by Lmiller1708 (Post 2050765)
Great work Nate.

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

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).

Quote:

Originally Posted by bheremans (Post 2050802)
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 :

Code:

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] 02-04-2011 01:45 PM

Re: NAND Boot Testing - 01-07: Panel power on/off fixes
 
Quote:

Originally Posted by natemcnutty (Post 2050738)
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 ?.


All times are GMT -4. The time now is 06:38 PM.

Powered by vBulletin® ©2000 - 2025, Jelsoft Enterprises Ltd.
©2012 - PPCGeeks.com


Content Relevant URLs by vBSEO 3.6.0