Issues with USB connectivity etc. and root / A2SD

[Guest Specialist79]

Not necessarily. Timing will be subtly different between different recovery sessions, which might be sufficient to explain the weird bricking pattern.

Coming back to the timing topic:

step1-linux.sh issues the erase cache and rebootRUU commands without any delay inbetween. Not sure whether erase cache runs asynchronously, but what if oem rebootRUU gets invoked before before erase cache has finished?

sudo ./fastboot-linux erase cache

sudo ./fastboot-linux oem rebootRUU

[Guest xhemp]

Coming back to the timing topic:

step1-linux.sh issues the erase cache and rebootRUU commands without any delay inbetween. Not sure whether erase cache runs asynchronously, but what if oem rebootRUU gets invoked before before erase cache has finished?

sudo ./fastboot-linux erase cache

sudo ./fastboot-linux oem rebootRUU

It's a good guess :)

What if we use: sudo ./fastboot-linux erase cache; sleep 5; sudo ./fastboot-linux oem rebootRUU for now?

It won't do any harm and maybe we can avoid more people having problems.

Valid, no? ;)

[Guest Specialist79]

It's a good guess :)

What if we use: sudo ./fastboot-linux erase cache; sleep 5; sudo ./fastboot-linux oem rebootRUU for now?

It won't do any harm and maybe we can avoid more people having problems.

Valid, no? ;)

Looks sensible...

[Guest jdouce]

its not step 1.... since this happens post initial root ... so ppl shouldnt be re-running step1.sh

or step2.sh for that matter

its got to be a problem with the recovery

something is messing up between

./recovery-xxxx.sh being run

and the phone rebooting after a flash

Edited May 17, 2010 by jdouce

[Guest xhemp]

its not step 1.... since this happens post initial root ... so ppl shouldnt be re-running step1.sh

or step2.sh for that matter

its got to be a problem with the recovery

something is messing up between

./recovery-xxxx.sh being run

and the phone rebooting after a flash

Well, you can still do step1 because you have usb on fastboot but no more step2 (no recovery).

Who guarantee that the problem is indeed with recovery and not with with step1 leading to the recovery problem?

Again, we have no idea what's happening, all we have are guesses. I believe the more we can do here to avoid more people having problems will be valid.

[Guest adi90]

Anyone test what xTc is loVe said ?

[Guest deovferreira]

I found this while trying to port the kernel to a more forward version:

#define ULPI_VERIFY_MAX_LOOP_COUNT  3

static int msm_hsusb_phy_verify_access(void __iomem *usb_base)

{

        int temp;


        for (temp = 0; temp < ULPI_VERIFY_MAX_LOOP_COUNT; temp++) {

                if (ulpi_read(usb_base, ULPI_DEBUG) != (unsigned)-1)

                        break;

                msm_hsusb_apps_reset_phy();

        }

        if (temp == ULPI_VERIFY_MAX_LOOP_COUNT) {

                pr_err("%s: ulpi read failed for %d times\n",

                                __func__, ULPI_VERIFY_MAX_LOOP_COUNT);

                return -1;

        }

}


[/codebox]


Can someone with a usb-bricked device thoroughly check the kernel log for  messages containing [b]ulpi read failed[/b] or similar?


If I am right the only thing one needs to do to revert this is call one of this functions from kernel space.

[codebox]

        if (reset)

                ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_ASSERT,

                                &usb_id, NULL);

        else

                ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_DEASSERT,

                                &usb_id, NULL);

This would need to be done in a module, I am not sure if we can easily insert modules now. I am not able to test this because my device is working correctly but I thought it might be useful for some.

[Guest stevebrush]

...Can someone with a usb-bricked device thoroughly check the kernel log for messages containing ulpi read failed or similar?

...

I post my usb-bricked dmesg a few days ago :

http://android.modaco.com/content-page/307...t-a2sd/page/40/

post 50.

no reference to ulpi... but some interresting things like :

usb serial or :

init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'...

[Guest Carnage21]

Here is my dmesg

http://insurrectiondath.com/Carn/dmesg.txt

init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'...

same line

Edited May 18, 2010 by Carnage21

[Guest dimor]

Anyone test what xTc is loVe said ?

it's for droid, not desire

[Guest Specialist79]

init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'...

Also shows up on my Desire, which has not even been rooted.

[Guest Biliskner]

it's for droid, not desire

yeh don't try what xTc is loVe posted, you'll definitely brick your Desire (or any other android phone that's not the Droid)

[Guest xTc is loVe]

yeh don't try what xTc is loVe posted, you'll definitely brick your Desire (or any other android phone that's not the Droid)

Holy s*** sry. I liked t say if there is a similar method fpr our Desire? An if somene test it or someone write a one for us!

Greetz

[Guest Specialist79]

Holy s*** sry. I liked t say if there is a similar method fpr our Desire? An if somene test it or someone write a one for us!

Greetz

It most likely won't help anyway. IMHO there are some strong indicators that the config area is messed up, which is different from the flash overwritten by a firmware update.

[Guest r&a]

browsing through i noticed that i havn't made nandroid backup b4 flashing

could it be that flash needed that system backup saved to sd card

and not finding fails the creation of those mising directories ?

[Guest zanshin]

browsing through i noticed that i havn't made nandroid backup b4 flashing

could it be that flash needed that system backup saved to sd card

and not finding fails the creation of those mising directories ?

Hmmm I didn't do that either. I thought it just backed up user stuff, so I skiped that.

Edited May 18, 2010 by zanshin

[Guest NOFX]

Hmmm I didn't do that either. I thought it just backed up user stuff, so I skiped that.

Same here - didn't back up!

[Guest Paul]

I found this while trying to port the kernel to a more forward version:

#define ULPI_VERIFY_MAX_LOOP_COUNT  3

static int msm_hsusb_phy_verify_access(void __iomem *usb_base)

{

        int temp;


        for (temp = 0; temp < ULPI_VERIFY_MAX_LOOP_COUNT; temp++) {

                if (ulpi_read(usb_base, ULPI_DEBUG) != (unsigned)-1)

                        break;

                msm_hsusb_apps_reset_phy();

        }

        if (temp == ULPI_VERIFY_MAX_LOOP_COUNT) {

                pr_err("%s: ulpi read failed for %d times\n",

                                __func__, ULPI_VERIFY_MAX_LOOP_COUNT);

                return -1;

        }

}


[/codebox]


Can someone with a usb-bricked device thoroughly check the kernel log for  messages containing [b]ulpi read failed[/b] or similar?


If I am right the only thing one needs to do to revert this is call one of this functions from kernel space.

[codebox]

        if (reset)

                ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_ASSERT,

                                &usb_id, NULL);

        else

                ret = msm_proc_comm(PCOM_CLK_REGIME_SEC_RESET_DEASSERT,

                                &usb_id, NULL);

This would need to be done in a module, I am not sure if we can easily insert modules now. I am not able to test this because my device is working correctly but I thought it might be useful for some.

Very interesting... we are able to insert modules, so this could be worth a try?

P

[Guest jeckyllhavok]

Very interesting... we are able to insert modules, so this could be worth a try?

P

count on me as tester

[Guest Carnage21]

Very interesting... we are able to insert modules, so this could be worth a try?

P

Dont mind sticking my hand up to test either

[Guest stuliv12]

Dont mind sticking my hand up to test either

me either, ill test.

[Guest ZiCoN]

Very interesting... we are able to insert modules, so this could be worth a try?

P

Count me in also

[Guest zanshin]

me either, ill test.

Since you guys test I don't have to :)

[Guest NOFX]

Since you guys test I don't have to :)

Just managed to un-root my device. So now I'm sending it in for repairs. Hope you guys will solve this - so either way I'll have a functional phone when I get it back. Whether it is returned (still bricked) or replaced...

[Guest dimor]

Count me in also

me too! :)