yashsingh1/xdaforums huggingface dataset:
[Desire Android Development] The Professor:
Psydox, were you ever bricked to the extent the rest of us were?
[Desire Android Development] shawe_ewahs:
If you can give me some information to try this method I can test id.
[Desire Android Development] sruon:
Actually, that's something I thought about yesterday...
[Desire Android Development] JDouce:
PsYDoX wasnt bricked i had the same issue as him its a software issue that causes the usb not to mount when u connect... using usb switcher and wired tether aps gives full usb functionality back its a problem with the htc sync.

and

how hard is it to boot recovery from the sd card? if its a possible fix ... lets do it ... its not gona do any harm so ... also if we had recover on the sd card could we also not have easy acess to the recovery. instead of pushiong them every time have them permenantly on the SD and just call them when needed ... may need usb connection to call them. but would remove another step from the recovery process...
[Desire Android Development] PsYDoX:
i have no permission to get dsemg | grep -i kernel (STOCK ROM, no root)

maybe flash original RUU from HTC and send the device to HTC... usb problemes xD
[Desire Android Development] shawe_ewahs:
dsemg | grep -i kernel

Can be probably because it isn't "dsemg" is "dmesg"?
[Desire Android Development] The Professor:
Unless I'm mistaken, booting recovery from SD card won't fix existing problems, it'll just prevent it in the future. Booting recovery from SD is impossible (unless it's freestanding on the SD card) without a USB connection to get into recovery and trigger the option to enter the menu. Since we don't have USB connections, well...

I do wonder if it's even possible to fix this given existing tools even if people find out what's wrong. If we've overwritten sections of the mtd or other memory areas, do we have any feasible way of correcting that? Could an HTC-signed update.zip even access those areas and fix them?

I'm in for adventure. :)
[Desire Android Development] JDouce:
if it Prevents the issue happening again....

its worth doing

and if it does prevent it

we know what we did and were half way to fixing it

if we had it on the sd cant we use terminal emulator to call it
[Desire Android Development] The Professor:
No doubt worth doing, didn't mean to imply otherwise. I definitely want this to not hit anybody else in the future. :) I just wanted to clarify that it didn't look like a fix - it looks like prevention, which is every bit as good beforehand. :D
[Desire Android Development] terminal 7:
more

you know i thought this was just desire that had this issue but it seems to have happened to other devices too... look....

http://xdaforums.com/showthread.php?t=629566

http://xdaforums.com/showthread.php?t=563298

i only mention it in case some info is in those posts that assist us with the desire
[Desire Android Development] The Professor:
All the more reason to hope and pray for an engineering SPL to become magically available... Looks like both of those were fixed with SPL tweaks that we can't do yet. :(
[Desire Android Development] PsYDoX:
android-sdk-linux_86/tools# ./adb shell
$ dmesg | grep -i kernel
grep: permission denied
write: Broken pipe
$
[Desire Android Development] JDouce:
legend too

any1 able to write the necessary code to put recovery on the SD and boot it?
[Desire Android Development] deovferreira:
I though of this already too and agree with your suggestions, booting the recovery from an ext partition in the card will prevent the mtd overlap to some extent.

However, if there is an overlap in an area it is also likely that some of the other mtd regions have wrong offsets too, meaning that devices could also get bricked when flashing the rom.

This theory fits perfectly because in flash memory blocks aren't allocated contiguously, the placement of data on flash can be expected to be semi-random, which could explain the randomness of USB bricks.
[Desire Android Development] JDouce:
wtf why don't manufacturers just ship with root access or purposley leak the tools .... then there would be fixes for every1 and they wouldn't have to do the repairs ....
[Desire Android Development] deovferreira:
Yeah, it also means generalized free software upgrades forever, the industry just doesn't work like that. But it should, it's your device after all.
[Desire Android Development] JDouce:
ppl that want stock desire get what they want

we get what we want

and devices dont get bricked so they dont have to do repairs that are completly unnecessary

tbh ... if a device runs android why dont they just all run stock then get updates from google ... then the manufacturers can add the crap to the market and let us get it ... or not ....
[Desire Android Development] lgrangeia:
Good point.

The purpose of this is to be able to safely boot recovery, but it does nothing to increase the security of flashing other partitions (boot, radio and system).

If we're able to safely boot recovery it might be easier to debug this problem, by dumping all partitions and looking at empty parts of the block device and see if there's anything there that we might be overlapping by writing to it.

I'm not going to be able to try this so soon, no time until the weekend and also not much experience (and not much willingness to boot into recovery :))
[Desire Android Development] shawe_ewahs:
I don't know if do you test this, but can somebody with a bricked device try something similar to this?

fastboot -c "board_bravo.disable_uart3=0 board_bravo.usb_h2w_sw=0 board_bravo.disable_sdcard=0 diag.enabled=0 board_bravo.debug_uart=0 smisize=0 userdata_sel=0 androidboot.emmc=false androidboot.keycaps=qwerty androidboot.mode=normal no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5" boot NAMEOFYOURRECOVERYIMAGE.img

I know that we don't have a recovery image, but probably nexus-image can work in this case.
[Desire Android Development] adi90:
booting... FAILED (remote: not allowed)
[Desire Android Development] shawe_ewahs:
And this?

fastboot -c "board_bravo.disable_uart3=0 board_bravo.usb_h2w_sw=0 board_bravo.disable_sdcard=0 diag.enabled=0 board_bravo.debug_uart=0 smisize=0 userdata_sel=0 androidboot.emmc=false androidboot.keycaps=qwerty androidboot.mode=normal no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5"
[Desire Android Development] JDouce:
did i mention i hate htc for being arkward :D
[Desire Android Development] shawe_ewahs:
what is the meaning of arkward?
[Desire Android Development] pina_:
awkward :p
[Desire Android Development] adi90:
the command work but no change when you reboot !
[Desire Android Development] shawe_ewahs:
Ok, if command work can be a little step more. I read a similar to this for Hero. I go to read more for try to do something more useful.

I read the command from here: http://xdaforums.com/showthread.php?t=556335
[Desire Android Development] terminal 7:
good effort

good effort guys

this is what makes xda-devs so good

problem solving with as many minds and scenarios as possible..

(and no immature flaming)

it will come good in time im certain :)
[Desire Android Development] potter1984:
Here, here, well said. :)
[Desire Android Development] The Professor:
I'm repurposing my laptop to a Linux machine tonight to try and help a little more. I'll try as many non-destructive solutions as I can. :) (I'm happy with the ROM I bricked on - I'd be a sad panda if I tried a fix that didn't work and broke it.)
[Desire Android Development] shawe_ewahs:
Use this form for MoDaCo info, it can be more easy for collect information for all people bricked:

http://spreadsheets.google.com/viewform?formkey=dHl2Y0kzeUx1U290MjI4a0J0QVdJRHc6MQ
[Desire Android Development] TheAshMan:
It's the direction all the animals were facing before they got on Noah's boat!

With regards to this issue, I'm subscribed to see how it turns out. My Desire wasn't bricked (using Mac) but once rooting is stable I'm hoping to start doing some development.
[Desire Android Development] richardtrip:
I can disable the check for usb_h2w_sw=1 completely but that will only help people who are not already bricked now an flash this kernel before they brick (and only in normal boot = not in recovery) :

This is wat it looks now:

if (!opt_usb_h2w_sw) {

msm_register_usb_phy_init_seq(bravo_phy_init_seq);

msm_add_usb_id_pin_gpio(BRAVO_GPIO_USB_ID_PIN);

msm_add_usb_id_pin_function(config_bravo_usb_id_gpios);

config_bravo_usb_id_gpios(0);

msm_enable_car_kit_detect(1);

msm_hsusb_set_product(bravo_usb_products,

ARRAY_SIZE(bravo_usb_products));

msm_add_usb_devices(bravo_usb_phy_reset, NULL);

}
[Desire Android Development] The Professor:
Richard, what about a test kernel where you NOT the opt_usb_h2w_sw value before that check? Might it restore function, or does it need to be corrected somewhere earlier up the line?
[Desire Android Development] richardtrip:
I think that could work, but it wil only work in normal boot (not in recovery because that uses its own kernel we cannot change a.t.m.).

Can't check to make sure (no usb-brick here).
[Desire Android Development] eViL D::
Just so you guys know, there is a thread at Modaco, a poll actually, that is keeping count of how many usb bricks there are so far. Please go there and submit if you are bricked.

http://android.modaco.com/content/h...-or-legends-lets-get-a-count-50-and-counting/
[Desire Android Development] The Professor:
Running with the "overwriting things we shouldn't" path, any chance this is related to how much available space you have on the phone at the time of pushing recovery? Maybe the Desire's recovery doesn't protect itself if you try to write more to the NAND than you're allowed...? How big are the recovery files we're pushing? If that seems plausible, for reference, I have 31mb available right now; that should be roughly the same as when I bricked, I think.
[Desire Android Development] jamlam22:
I posted this over at Modaco a while ago, but I'll mention it again here seeing as this has come up again.

On the flash that bricked my phone at one point a message saying something like "no space left on device" (I can't remember the exact wording) flashed up at the bottom left of the phone screen. It was only there briefly, and would be pretty easy to miss.

It sounds pretty plausible to me that this is what's causing the issues.
[Desire Android Development] viper_campbell:
Might be worth doing a factory reset before flashing a new ROM... In order to free up as much space as possible... Not sure if it would really help though...

Hope this all gets sorted for the people that are currently bricked, and found out so that there won't be more to add to to the list!!

-------------------------------------

Sent via the XDA Tapatalk App
[Desire Android Development] xtcislove:
I think the push files "overwrite" others. So they dont affect the space. The new Method where the recovery will stay until u loose USB Connection needs more space i think. And paul say its safer!

Any brickes out there with the r5 Rooting Method?
[Desire Android Development] jamlam22:
The push files are certainly meant to overwrite others, but it's possible that the rooting method means this doesn't happen, at least for the people who brick. There's a lot of protection for the system areas on the Desire so it's possible that this is what's happening.

I'd love to try this out, but I've bricked one already so the replacement is staying as stock until we find out what's going on!
[Desire Android Development] terminal 7:
opinions

hi

you know what seems odd.. differing opinions !

obviously there is a problem - people have usb-brick desires ...

but when you take a look at some of the rom makers posts they seem to never give this a fleeting thought !!

im not saying their wrong , but is it that most people just have the idea it wont happen to them, or do they think some people here have done something wrong to make this happen to their phone.

i wish we had a better idea of the percentage of failed devices,
[Desire Android Development] rolfd:
I think that devs are just really lucky! Apart from Evil, he was making roms for the desire and his phone bricked.
[Desire Android Development] terminal 7:
spl

from what i read about other devices having similar issues it may need a HSPL ( hard SPL ) to be constructed before a fix is made.

just search google with this line here and you find some similar problems...

.usb_h2w_sw=1

one that gives example of a fix by flashing the SPL is here

http://xdaforums.com/archive/index.php/t-629566.html

No easy task !!
[Desire Android Development] scotch whisky:
I see that a new version of "recovery" has been posted.

http://xdaforums.com/showthread.php?t=689778

It is reported to correctly wipe the "ext" partition. As this is probably one of the major causes of bootloops maybe it will prevent "USB bricking".

Only time will tell.
[Desire Android Development] terminal 7:
Yeah i asked AHMGSK if he had any worries about bricking using the mass storage switch in his new recovery, he didnt seem to have a worry at all, he replies that he was flashing 30 times a day !!
[Desire Android Development] stingerpl:
USB-MS switch has nothing to do with the brick
[Desire Android Development] terminal 7:
so why does modaco paul say " avoid using ms-toggle untill usb brick problem fixed "

.

.
[Desire Android Development] jamlam:
I think thats just old info, originally it was thought that the USB-MS was causing the brick but I think that's been disproved now.
[Desire Android Development] StuMcBill:
It appears that this version of the recovery doesn't include the "nohup" command that Paul @ MoDaCo has added to his recovery batch file.
[Desire Android Development] shawe_ewahs:
I added and it don't work for me, parameter don't recognized.
[Desire Android Development] nespresso33:
And some people used "nohup" and got a bricked device
[Desire Android Development] kurt666:
Maybe you should look into the similarity of the bricked Phones.

Could it be that it's from the same phone company. Or the same firmware ?

Which OS was used when the phone accidently bricked. ?

I think if we record theese informations we are one step closer to finding the root cause.
[Desire Android Development] shawe_ewahs:
kurt666 do this form and you can see the others answers http://spreadsheets.google.com/gform?key=tyvcI3yLuSot228kBtAWIDw&hl=es#
[Desire Android Development] lgrangeia:
Hi again!

I managed to grow some balls and for the sake of science booted into recovery (still in it), and just pushed the files and ran a shell to investigate.

Turns out my theory (of the files push overwritting some critical memory positions that contain bootloader configuration) is starting to make more sense!

The files are being pushed into / which is a "rootfs" device, meaning its essentially RAM memory we are writing into:

[B]rootfs on / type rootfs (rw)[/B]
tmpfs on /dev type tmpfs (rw,mode=755)
devpts on /dev/pts type devpts (rw,mode=600)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
/dev/block/mtdblock4 on /cache type yaffs2 (rw,nodev,noatime,nodiratime)
/dev/block/mtdblock5 on /data type yaffs2 (rw,nodev,noatime,nodiratime)

My suggestion to devs is stop writing to / and push files into a data subdir and change the scripts and code to point to /data instead. Leave rootfs, alone and bricks should disappear.

I don't know if its possible to entirely run off /data without a single symlink (shared libraries come to mind), but I believe with some changes to scripts and source, it should be possible.

Plus, you only needed to push files once, then you could just run the recovery script anytime.
[Desire Android Development] StuMcBill:
You should maybe try and get in touch with Paul at MoDaCo and see what he thinks?
[Desire Android Development] paulobrien:
I'm working on a root method (the 'new' method) that removes this, but if this was the cause, I would expect the USBricks to be 'all or none'.

This could sort work by pushing the files to data or cache then symlinking the files into /sbin, although very bad things would happen if you then proceeded to wipe data or cache as appropriate.

I am working on a better way...

P
[Desire Android Development] ephumuris:
Ok so no cause has been determined but you think it is the root method/recovery to blame. How can you be sure your new method will not still happen to have bricks.

All i can say is you're a brave guy doing all this for us too thick to learn these things lol.
[Desire Android Development] JDouce:
this pretty much confirms its where the recovery is being written to. completely rules out anything else.
[Desire Android Development] Specialist79:
I tend to disagree. Linux is using address space randomization to make some exploits more difficult. So, the memory layout differs from session to session.
[Desire Android Development] ninuuz:
I agree

AFAIK this seems to be same knowledge that I posses of Linux.
[Desire Android Development] paulobrien:
Hmm, bit of a design flaw if it lets you do this!

Will get my alternative solution out asap.

P
[Desire Android Development] paulobrien:
I'm assuming symlinking to the files on /cache will be safer as a temporary solution... Oh, wait, we can't symlink until we've pushed the files, at least on the initial root. Hmmm...

P
[Desire Android Development] eViL D::
I don't think it would be all or nothing, I think it would imply like exactly where it's being written to, random.
[Desire Android Development] Specialist79:
Well, it's just a theory, but if it's true HTC seem to have omitted excluding the NVRAM memory page from the address range available for mem allocations. At least for the recovery...

Regarding symlinking: Wouldn't it be possible to push the files directly to the cache/data partition and symlink them later (if at all)?
[Desire Android Development] lgrangeia:
Also, its more interesting that most of the people that get bricked seem to run the recovery script more than one time per session. Since files are being written do the filesystem again, its internal logic is overwritting is probably writing to a different physical address, increasing likelihood of writing to bad addresses.
[Desire Android Development] adam235:
For me it looks like some flags will be reseted. Like the .usb_h2w_sw flag which will get resetet to 1 if something goes wrong.

my question is if its possible to write into the rom at this location:

ROM:8E006554 GetFlagDWORD ; CODE XREF: sub_8E041754+4p
ROM:8E006554 ; sub_8E041764+4p ...
ROM:8E006554
ROM:8E006554 var_4 = -4
ROM:8E006554
ROM:8E006554 STR R4, [SP,#var_4]!
ROM:8E006558 MOV R3, DATAPtr ; 8E07D5B0
ROM:8E006560 LDR R4, [R3]
ROM:8E006564 MOV R3, #0x1020
ROM:8E006568 LDR R0, [R4,R3] ; (DWORD *) 8E07E5D0
ROM:8E00656C LDMFD SP!, {R4}
ROM:8E006570 BX LR
ROM:8E006570 ; End of function GetFlagDWORD

at first i would like to read/read from 0x8E07E5D0 to reset the flag and hopefully get the usb device back. any idea how to do that ?
[Desire Android Development] shawe_ewahs:
lgrangeia, this are only the different or also there are more parameters?

active commandline:

board_bravo.disable_uart3=0

board_bravo.usb_h2w_sw=0

board_bravo.disable_sdcard=0

diag.enabled=0

This can be changed, but people say that isn't applied on reboot, what do you do to get this information?

I recommend this on another post:

fastboot -c "board_bravo.disable_uart3=0 board_bravo.usb_h2w_sw=0 board_bravo.disable_sdcard=0 diag.enabled=0 board_bravo.debug_uart=0 smisize=0 userdata_sel=0 androidboot.emmc=false androidboot.keycaps=qwerty androidboot.mode=normal no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5"

Doing something like this:

fastboot -c "board_bravo.disable_uart3=0 board_bravo.usb_h2w_sw=0 board_bravo.disable_sdcard=0 diag.enabled=0"

An adding other parameters that you see diferent than yours. Can be possible try to "combine" with your for debug for try if you can get this values changed?
[Desire Android Development] lgrangeia:
I'm not changing a lot on my device, because it is working!

adam's device is not.

yeah, it really seems that getting that command line OK again will fix this, and the answer lies in fastboot and the bootloader.

here are some interesting bits of info on the bootloader:

Complete list of hero fastboot commands:

http://xdaforums.com/showthread.php?t=544409

Hermes Boot Loader:

http://wiki.xda-developers.com/index.php?pagename=Hermes_BootLoader
[Desire Android Development] lgrangeia:
This is all, I just added newlines so that its easier to compare both outputs.

boot into fastboot mode, then via USB type in "fastboot oem boot", check the output.
[Desire Android Development] kubino99:
Hi All

it looks like the bricked devices have overwrited NAND part wich contathis kernel boot cmdline. Most interesting part :

output from "fastboot-linux oem boot" on usb bricked desire (reformated):

... setup_tag addr=0xA0000100 [COLOR="Red"][B]cmdline add=0x8E07D98C[/B][/COLOR]
commandline from head:
no_console_suspend=1

command line length =[COLOR="Red"][B]419[/B][/COLOR]

output from "fastboot-linux oem boot" on non-bricked desire:

... setup_tag addr=0xA0000100 [COLOR="Red"][B]cmdline add=0x8E07D98C[/B][/COLOR]
commandline from head:
no_console_suspend=1
msmsdcc_sdioirq=1
wire.search_count=5
command line length =[B][COLOR="Red"]461[/COLOR][/B]

is it possible to dump 0x8E07D98C addr on bricked and non-bricked devs ?
[Desire Android Development] adam235:
if im flashing a new image in RUU mode does it also flash a new bootloader and if yes does the new bootloader need to be signed ?
[Desire Android Development] The Professor:
Tell me how and I'll get you a bricked version. I'll be around all day.
[Desire Android Development] kubino99:
unfortunately I don't know how to do that yet. I was thinking about dumping mtd6 partition and see if there are any usefull informations. But this need a patched kernel and not sure if the bricked users can flash boot partition.
[Desire Android Development] Aphax:
Here's another from a non-usb-bricked desire (rooted though, with modaco R4 guide):

$ fastboot oem boot
... INFOsetup_tag addr=0xA0000100 cmdline add=0x8E07D98C
INFOTAG:Ramdisk OK
INFOTAG:smi ok, size = 0
INFOTAG:hwid 0x0
INFOTAG:skuid 0x21F04
INFOTAG:hero panel = 0x0
INFOTAG:engineerid = 0x0
INFOMCP dual-die
INFOMCP dual-die
INFOTAG:mono-die = 0x0
INFODevice CID is not super CID
INFOCID is VODAPE17
INFOsetting->cid::VODAPE17
INFOserial number: HT03xxxxxxxx
INFOcommandline from head: no_console_suspend=1 msmsdcc_sdioirq=
INFO1 wire.search_count=5
INFOcommand line length =467
INFOactive commandline: board_bravo.disable_uart3=0 board_bravo.
INFOusb_h2w_sw=0 board_bravo.disable_sdcard=0 diag.enabled=0 boa
INFOrd_bravo.debug_uart=0 smisize=0 userdata_sel=0 androidboot.e
INFOmmc=false androidboot.baseband=4.05.00.11 androidboot.cid=V
INFOODAPE17 androidboot.carrier=VODA-Netherland androidboot.mid=
INFOPB9920000 androidboot.keycaps=qwerty androidboot.mode=normal
INFO androidboot.serialno=HT03ZPL03544 androidboot.bootloader=0.
INFO75.0000 no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_c
INFOount=5
INFOaARM_Partion[0].name=misc
INFOaARM_Partion[1].name=recovery
INFOaARM_Partion[2].name=boot
INFOaARM_Partion[3].name=system
INFOaARM_Partion[4].name=cache
INFOaARM_Partion[5].name=userdata
INFOpartition number=6
INFOValid partition num=6
INFOmpu_nand_acpu_rw A1E 1000
INFOjump_to_kernel: machine_id(2457), tags_addr(0x20000100), ker
INFOnel_addr(0x20008000)
INFO-------------------hboot boot time:44503 msec
FAILED (status read failed (Protocol error))

Seems like at least mpu_nand_acpu_rw value is the same for both non-usb-bricked devices.

BTW I also wanted to point out that this mpu_nand_acpu_rw symbol I have also seen in a bit of code that unprotected the nand flash for some other HTC device, but it was defined to be a different value. The code was essentially a little kernel module that would just iomap a bunch of different sizes starting at mpu_nand_acpu_rw and then set it to 0. I guess this would normally disable write protection, but I havent been able to get it to work on my Desire.

I lost the pastebin link for the code but I'll see if I can dig it up..