Issues with USB connectivity etc. and root / A2SD

[Guest dimor]

This would be useful from anyone with a non-working phone. You can get the device id in windows like this.

couldn't find "Device Instance Id", "Device Instance Path" was the closest i could find.

i hope vid is the vendor id:

"USB\VID_05C6&PID_9002&MI_02\6&22B0018&0&0002"

the same in "charge only"... for me at least...

Edited May 26, 2010 by dimor

[Guest ciairo]

Could you give my newer version a shot?

I quickly tried it before going to work. It didn't work for me (should I add some parameter?)

lsusb reports no devices (but the phone is charging). I will dig into dmesg and device and vendor id when I'm back home. It might be worth checking the difference between the fastboot mode and the kernel mode too.

Mate, thanks anyway for what you've done and for sharing with the community!

[Guest l1nuxfre4k]

I'v tried fastboot oem ereaseconf

oem boot

boot

update

none is working good enough to fix it.

[Guest atconc]

Could it be a usb cable issue? My desire is sometimes flaky in ADB with the cheap ebay cables I bought but is fine with the original one

[Guest Snarkasm]

No, it's not a USB cable issue.

When plugging in on a bricked phone on disk mode, I get the following out of dmesg:

batt: M2A_RPT: cable_update: USB at 1705658388002 09:49:43.901000986 UTC

batt: htc_cable_status_update: 0 -> 1

[HTC_BATT] cable change to 1

batt: charger ON (SLOW)

More references to charger ON (SLOW)

lsusb returns /sys/bus/usb/devices: No such file or directory.

When plugging in on HTC Sync mode, I get one difference - it adds a notification msm_hsusb_set_vbus_state: 1

Otherwise, no differences I can see. I'm also not sure how to find the vendor ID, but as mentioned, the device works fine in fastboot anyway; it's everything else that's borked.

[Guest pina]

since everyone can perform step1, but most people have problems performing step2, there must be something wrong in the files that are being pushed from step1. Maybe buggy files or an interrupted connection so the pushed file are being corrupted?

[Guest Snarkasm]

Or, as is being postulated over on XDA, a buggy recovery kernel on the Desire leading to pushed files accidentally overwriting some memory it's not supposed to, or a bad call in the recovery script that does the same.

It's less likely that it's a connection issue, imho.

[Guest Normola]

It's more of an internal issue to do with the USB chipset inside the phone switching to an unsupported mode with no currently known way of switching it back.

[Guest SonicArt77]

Since a complete ROM reflash does not help, nandroid restore can't as well.

Thing is, we can still get into recovery (2e, not the custom one), and we can still flash a file named update.zip. Problem is, the file must be signed by HTC.

[Guest afiorillo]

Thing is, we can still get into recovery (2e, not the custom one), and we can still flash a file named update.zip. Problem is, the file must be signed by HTC.

That won't solve the issue, the corrupted data area isn't accessible by the flash procedure.

@Snarkasm: I totally agree with the XDA folks on a recovery console bug that causes it to crash and to corrupt the otherwise unreachable data area responsible for the Qualcomm test mode. Moreover, I think that this is likely to happen on selected devices, probably due to a slightly different hardware revision.

[Guest Snarkasm]

Not sure where a hardware revision may be affecting it; it's not like a certain class of users bricked on the first root and nobody else has. Everybody who's bricked has ended up in a different place, different number of flashes.

Who knows. I'm just wondering if we've done irreparable damage to any of those sectors.

[Guest Normola]

A previous post mentioned usb_modeswitch at http://www.draisberghof.de/usb_modeswitch/#download.

I've got it compiled and working.

 * usb-modeswitch: handle USB devices with multiple modes

 * Version 1.1.2alpha (C) Josua Dietze 2010

 * Based on libusb0 (0.1.12 and above)


 ! PLEASE REPORT NEW CONFIGURATIONS !


Usage: usb-modeswitch [-hvpVPmMrdHn] [-c filename]


 -h, --help					this help

 -e, --version				 print version number and exit

 -v, --default-vendor NUM	  vendor ID to look for (mandatory)

 -p, --default-product NUM	 product ID to look for (mandatory)

 -V, --target-vendor NUM	   target vendor (optional, for success check)

 -P, --target-product NUM	  target model (optional, for success check)

 -C, --target-class NUM		target device class

 -m, --message-endpoint NUM	where to direct the message (optional)

 -M, --message-content <msg>   command to send (hex number as string)

 -2 <msg>, -3 <msg>			additional commands to send

 -n, --need-response		   read a response to the message transfer

 -r, --response-endpoint NUM   where from read the response (optional)

 -d, --detach-only			 just detach the storage driver

 -H, --huawei-mode			 apply a special procedure

 -S, --sierra-mode			 apply a special procedure

 -O, --sony-mode			   apply a special procedure

 -G, --gct-mode				apply a special procedure

 -R, --reset-usb			   reset the device in the end

 -c, --config <filename>	   load different config file

 -Q, --quiet				   don't show progress or error messages

 -W, --verbose				 print all settings before running

 -D, --sysmode				 specific result and syslog message

 -s, --success NUM			 check switching result after NUM secs

 -I, --no-inquire			  do not get device details (default on)


 -i, --interface NUM		   select initial USB interface (default 0)

 -u, --configuration NUM	   select USB configuration

 -a, --altsetting NUM		  select alternative USB interface setting

There are some interesting options in there.

[Guest afiorillo]

Not sure where a hardware revision may be affecting it; it's not like a certain class of users bricked on the first root and nobody else has. Everybody who's bricked has ended up in a different place, different number of flashes.

Who knows. I'm just wondering if we've done irreparable damage to any of those sectors.

You should see what C pointers are able to do when out of control... :rolleyes:

[Guest afiorillo]

[...]

There are some interesting options in there.

Indeed. If only my Desire was "bricked"... :rolleyes:

[Guest Normola]

Indeed. If only my Desire was "bricked"... :D

Part of me really wants to flash my phone 50 times in a row to try to force it to happen :rolleyes:

usb-modeswith is actually included in the Ubuntu repos, so Ubuntu users should be able to run ' sudo aptitude install usb-modeswitch usb-modeswitch-data' to install it without resorting to compiling source.

I still have no idea how to use it though, or if it would even help.

*edit*

Browsing the USB_Mode forums I found this:

lsusb


 - Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 - Bus 002 Device 004: ID 1e0e:cefe

 - Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


sudo usb_modeswitch -v 1e0e -p cefe

Could someone try this replacing the vendor and subclass with the ones for the bricked phone?

Edited May 26, 2010 by Normola

[Guest pina]

I could help with my bricked phone, but I don't understand what you're asking here :rolleyes:

[Guest maja]

maybe, but I'm not 100% sure I found the problem that cause the USB brick.

I have my Desire flashed with my personal custom ROM with APP2SD on board; I removed

the MicroSD and turned on the Desire and surprise! Was not recognized via USB!

got back the MicroSD on the slot, turned on and the USB was fine again.

Now the million dollar question, could be the USB brick related with APP2SD?

[Guest geek78]

maybe, but I'm not 100% sure I found the problem that cause the USB brick.

I have my Desire flashed with my personal custom ROM with APP2SD on board; I removed

the MicroSD and turned on the Desire and surprise! Was not recognized via USB!

got back the MicroSD on the slot, turned on and the USB was fine again.

Now the million dollar question, could be the USB brick related with APP2SD?

I have never used APP2SD and I have bricked my 1st Desire ...

[Guest Normola]

maybe, but I'm not 100% sure I found the problem that cause the USB brick.

I have my Desire flashed with my personal custom ROM with APP2SD on board; I removed

the MicroSD and turned on the Desire and surprise! Was not recognized via USB!

got back the MicroSD on the slot, turned on and the USB was fine again.

Now the million dollar question, could be the USB brick related with APP2SD?

Don't think so. People have completely wiped or replaced the SD card with a full reflash of the rom (to stock) with no recovery. Others have bricked the phone without installing app2sd.

[Guest MarvinFS]

What about Paul's discussion of this issue with HTC guys? No news\updates for a while...

[Guest Paul]

It's still ongoing, together with other efforts!

P

[Guest xTc is loVe]

It's still ongoing, together with other efforts!

P

Can we have a little update? Was has done/tryed yet or so...?

[Guest MarvinFS]

my 2cents for the issue:

Here in Russia we have unbranded generic Desires certified by Russian authorities, so called white shipment - it has special labels ans stamps in Russian language behind the battery. So far no bricks as for our main russian android forum... Only one guy had bricked the phone but he bought it in Clove so it's grey shipment and is not serviced in Russia.... Could it be interesting? As for my self i have russian one too, and i flash it very intensively.

The only thing - after pushing recovery if i notice screen flashing or recovery closes by itself before flashing i turn off the phone and put out the battery before trying once more.

---

CU round,

MarvinFS

HTC Desire

MCRr2 with APP2SD+

uvoc_v12 kernel with audio patch

Edited May 26, 2010 by MarvinFS

[Guest jdouce]

it'll happen ... but its a matter of time

[Guest afiorillo]

[...]

The only thing - after pushing recovery if i notice screen flashing or recovery closes by itself before flashing i turn off the phone and put out the battery before trying once more.

[...]

Have you experienced this? How many times? What exactly did you noticed?