Dead Pre 3 (QHUSB-DLOAD mode)

[GMMan]

Actually, I just looked at the files in Trenchcoat again, and they contain references to sbl1, sbl2, etc. etc. There were two XML files, and they don't match, but with a dump of the memory regions indicated there's a chance the base bootloaders can be recovered. I remember seeing Trenchcoat saving tokens, formatting blocks, and then restoring tokens. Anyone want to reverse engineer Trenchcoat?

[GMMan]

I see what the trenchcoat config does now. It only flashes images to the flash memory, but does not do any partitioning. That is probably done in the factory with a separate tool. Check out the image on this thread.

A listing of devices:
mmcblk0: internal flash (512 bytes MBR accessible here)
mmcblk0p1: fat.bin FAT partition (modem/other bootloaders?) (Size varies; Mine is 100MB, webOS Doctor says 1024KB, picture says 1.1GB)
mmcblk0p2: rpmsbl.mbn/sbl1.mbn CFG_DATA (sbl1)
mmcblk0p3: spbl.mbn/sbl2.mbn SPBL (sbl2)
mmcblk0p4: Extended Partition MBR
mmcblk0p5: rpm.mbn APPSSBL (Resource Power Management)
mmcblk0p6: ssbl.mbn/sbl3.mbn QCSBL (sbl3)
mmcblk0p7: emmc_appsboot.mbn FOTA (chainbootie)
mmcblk0p8: boot.img/boot.min APPS (bootie)
mmcblk0p9: tz.mbn OEMSBL (TrustZone)
mmcblk0p10: MODEM_ST1 (blank on regular TP)
mmcblk0p11: MODEM_ST2 (also blank)
mmcblk0p12: NVRAM (contains tokens and bootloader graphics)
mmcblk0p13: Boot Partition (/boot)
mmcblk0p14: Main storage LVM

Note sizes of partitions are not always the same as in trenchcoat config files. The sizes specified seems like minimum sizes.

chainbootie is quite notable: it seems to be the code that initializes hardware and also handle tellbootie commands.

I feel that using partition IDs are a blatant abuse. Of course, this allows the flexibility for config files to not state all and exact positions of partitions.

I found an empty space of around 400MB at the start of the extended partition. Don't know why. Might try to dump it if my TP would stop randomly completely dying.

FYI: parted seems broken, won't list partitions.

Resources:
Android/HTC/Vision/BootProcess
[REF][R&D] MSM8960 Info, Architecture and Bootloader(s) - xda-developers
xda-developers - View Single Post - [R&D] Unlock Bootloaders
http://ibot.rikers.org/%23webos-inte...111016.html.gz
Some more info (from Sept. 19-25): http://irclog.netripper.com/msm-bootloader/2011/9/19/

[GMMan]

Just noticed all the bootloader files mentioned above are available in webOS Doctor. Bootie is in webOS.tar, and on device /boot contains boot-genesis.tar.gz. The only things that are not in webOS Doctor are the NVRAM and the FAT partition. Actual file system layout isn't included either.

[GMMan]

The FAT partition seems to contain firmware for various components. Supposedly those are loaded during one of the SBL stages. Some of the files can be found in /lib/firmware (e.g. q6.bxx).

[TopTongueBarry]

How I killed one of my TP GO's was by trying to use trenchcoat to correct the device tokens which had been modified to make the device look like a different device by its prior owner. He left out the carrier token. The device wouldn't doctor or meta-doctor because the token needs to be there even if its null. Couldn't get the device doctored using any of the usual methods and I remembered that trenchcoat sets the tokens in some form or fashon so I began experimenting with it to add the carrier token. One of the stupidest things I have ever done. This thread is hopefully my savior.

BTW:
/boot/boot-genesis.tar.gz should have the mbn files including partition.mbn

[TopTongueBarry]

This thread on XDA may prove useful. There are more and more developers working on getting into bricked Qualcomm MSMXXXX devices. Some have had a little success.

[DEV][REF] El Grande Partition Table Reference - xda-developers

and here's a link I shared previously. If you go to the last two pages of the thread, you'll find recent updates and some success stories.

http://forum.xda-developers.com/show...0#post33017800

[GMMan]

Just a note that parted didn't work for me. One of the other utilities may have to be compiled.

[TopTongueBarry]

Some good news, sort of ......

I've now successfully broken through the QHUSB-DLOAD mode barrier on a Touchpad GO using QPST's emmcswdownload, with the brixfix scripts, 8660_msimage.mbn and EMMCBLD.HEX as detailed in this xda post by darkspr1te:

xda-developers - View Single Post - [JTAG,BRICK]SHV-E160L Korean model

That left me with one drive letter in Windows representing the entire 64GB sdcard for the device. The instructions warned not to format that drive in windows,

I've powered off the device and removed its battery while I use another TP GO that's got a bad Touchscreen connector on the main board with WOSQI, novaterm, fdisk, opal.xml, and recovery mode commands to gather patrtition information so a partition.mbn or partition.bin can be created. .

The temporary bootloader I wrote to the sdcard is on p1. however p2 and p3 may also need to be restored from either a dd backup or webosdoctoring. IF I can successfully get the partitions set back up, There's a good chance of bringing the device back to its original webOS life! There'salso the possibility I could load up a native version of CM 9/10 at this juncture, but I'd rather not go that route , considering its an Opal, I'd like to return it to factory condition, then add CM 9/10 dual boot.

Since I do have a 32 GB device carrying the same model type as the one I've just brought back from near death, I know there are a few different paths forward I can take to get the bootloader back onto the 64GB device, I'm planning on using a virtual box instance of Ubuntu from this point forward to work on it, but not sure on which path would be best.

I could shell out the bucks for revskills pro, but am hoping someone can help me from this point to get the 64GB opal's partiton table restored and maybe only just the bootie loaded so I could doctor it with a meta doctor I've made just for the purpose.

Attached is opal.xml in case someone can assist me by creating a partition.mbn or partition.bin file based on its contents.

I hope to get a few suggestions and mavbe even a tried and true method or process used previously on older devices. One project that comes to mind is the 2.2.3 and 2.2.4 Veer efforts. I'm hoping that something gleaned in those efforts can now help with this effort.
Thanks,
TTB

[GMMan]

The partition table looks like a regular MBR partition table with a whole bunch of extended partitions (couldn't tell if they were chained, since they weren't really standard). Each partition is recognized by partition ID (e.g. FAT, NTFS, Ext3, etc., except those ID's don't necessarily represent the data format in that partition). When flashing the partition ID is checked to determine the destination to flash.

[TopTongueBarry]

Originally Posted by GMMan

Just a note that parted didn't work for me. One of the other utilities may have to be compiled.

parted may need to be run from novaterm while the device is in recovery mode in order to get the information we need.


Here's some more data I've collected off of the spare device in case we need to build partition.bin from scratch.

cat /proc/partitions
major minor #blocks name

179 0 31160320 mmcblk0
179 1 102400 mmcblk0p1
179 2 500 mmcblk0p2
179 3 1500 mmcblk0p3
179 4 1 mmcblk0p4
179 5 500 mmcblk0p5
179 6 750 mmcblk0p6
179 7 2500 mmcblk0p7
179 8 10240 mmcblk0p8
179 9 1500 mmcblk0p9
179 10 3072 mmcblk0p10
179 11 3072 mmcblk0p11
179 12 4096 mmcblk0p12
179 13 32768 mmcblk0p13
179 14 30504960 mmcblk0p14
254 0 581632 dm-0
254 1 65536 dm-1
254 2 16384 dm-2
254 3 24576 dm-3
254 4 262144 dm-4
254 5 139264 dm-5
254 6 28860416 dm-6
254 7 524288 dm-7
254 8 262144 dm-8
254 9 139264 dm-9
root@BarrysATTTouchpad4G:/#
root@BarrysATTTouchpad4G:/#
cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root /boot ext3 rw,relatime,errors=continue,barrier=0,data=writeback 0 0
/dev/mapper/store-root / ext3 rw,relatime,errors=continue,barrier=0,data=writeback 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
/dev/mapper/store-root /dev/.static/dev ext3 ro,relatime,errors=continue,barrier=0,data=writeback 0 0
tmpfs /dev tmpfs rw,relatime,size=2048k,mode=755 0 0
none /dev/cpuacct cgroup rw,relatime,cpuacct,cpu 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
/dev/mapper/store-var /var ext3 rw,noatime,errors=continue,barrier=0,data=writeback 0 0
tmpfs /tmp tmpfs rw,relatime,size=40960k 0 0
tmpfs /var/run tmpfs rw,relatime,size=16384k 0 0
tmpfs /var/tmp tmpfs rw,relatime,size=32768k 0 0
tmpfs /media/ram tmpfs rw,relatime 0 0
/dev/mapper/store-log /var/log ext3 rw,noatime,errors=continue,barrier=0,data=writeback 0 0
/dev/mapper/store-media /media/internal vfat rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
cryptofs /media/cryptofs fuse.cryptofs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other 0 0
none /dev/cpuset cgroup rw,relatime,cpuset 0 0
/dev/mapper/store-cryptodb /var/db ext3 rw,noatime,errors=continue,barrier=0,data=ordered 0 0
/dev/mapper/store-cryptofilecache /var/file-cache ext3 rw,noatime,errors=continue,user_xattr,barrier=0,data=writeback 0 0
extractfs /var/luna/data/extractfs fuse.extractfs rw,nosuid,nodev,relatime,user_id=0,group_id=0 0 0
root@BarrysATTTouchpad4G:/#
root@BarrysATTTouchpad4G:/#

ls -al | grep mmc
brw-r----- 1 root disk 179, 0 Mar 31 08:43 mmcblk0
brw-r----- 1 root disk 179, 1 Mar 31 08:43 mmcblk0p1
brw-r----- 1 root disk 179, 10 Mar 31 08:43 mmcblk0p10
brw-r----- 1 root disk 179, 11 Mar 31 08:43 mmcblk0p11
brw-r----- 1 root disk 179, 12 Mar 31 08:43 mmcblk0p12
brw-r----- 1 root disk 179, 13 Mar 31 08:43 mmcblk0p13
brw-r----- 1 root disk 179, 14 Mar 31 08:43 mmcblk0p14
brw-r----- 1 root disk 179, 2 Mar 31 08:43 mmcblk0p2
brw-r----- 1 root disk 179, 3 Mar 31 08:43 mmcblk0p3
brw-r----- 1 root disk 179, 4 Mar 31 08:43 mmcblk0p4
brw-r----- 1 root disk 179, 5 Mar 31 08:43 mmcblk0p5
brw-r----- 1 root disk 179, 6 Mar 31 08:43 mmcblk0p6
brw-r----- 1 root disk 179, 7 Mar 31 08:43 mmcblk0p7
brw-r----- 1 root disk 179, 8 Mar 31 08:43 mmcblk0p8
brw-r----- 1 root disk 179, 9 Mar 31 08:43 mmcblk0p9

TTB

[cyberprashant]

very interesting thread here - jscullins has managed to debrick a touchpad. Unfortunately his procedure didn't help mine but awesome progress:

TPDebrick v0.1 - HP Touchpad - RootzWiki

[a1145987]

Would anyone here be kind enough to dump their mmcblk0p12? (Hopefully I'll be able to replace any serial numbers with a hex editor.)

I've b0rked my TouchPad in an attempt to thoroughly erase everything and reinstall right back from QPST. Now, I've done the QPST and TPDebrick steps, got bootie access (although the screen is showing a moire pattern rather than a USB symbol), novacom boot mem:// < nova-installer-image-topaz.uImage works, but doctor fails because of the missing tokens, which are not found in the doctor itself.

[Herrie]

Originally Posted by a1145987

Would anyone here be kind enough to dump their mmcblk0p12? (Hopefully I'll be able to replace any serial numbers with a hex editor.)

I've b0rked my TouchPad in an attempt to thoroughly erase everything and reinstall right back from QPST. Now, I've done the QPST and TPDebrick steps, got bootie access (although the screen is showing a moire pattern rather than a USB symbol), novacom boot mem:// < nova-installer-image-topaz.uImage works, but doctor fails because of the missing tokens, which are not found in the doctor itself.

So you want Touchpad or Pre3? I can probably pull this from my devices when you can point me to the instructions

[a1145987]

Originally Posted by Herrie

So you want Touchpad or Pre3? I can probably pull this from my devices when you can point me to the instructions

TouchPad. I see we're in the Pre 3 forum but I came across this thread because a few people are talking about the TouchPad. Mine is the normal 32GB black wifi-only model.

As for instructions,

dd if=/dev/mmcblk0p12 of=/media/internal/mmcblk0p12.img

as root should do the trick, leaving the copy in your media partition.

[Herrie]

Originally Posted by a1145987

TouchPad. I see we're in the Pre 3 forum but I came across this thread because a few people are talking about the TouchPad. Mine is the normal 32GB black wifi-only model.

As for instructions,

dd if=/dev/mmcblk0p12 of=/media/internal/mmcblk0p12.img

as root should do the trick, leaving the copy in your media partition.

There you go, this is for TP 4G and WiFi.

I replaced my serial# with XXXXXXXXXX

It was at 4 locations:

For TP4G:
0x5180
0x5EF4
0x3FF180
0x3FFEF4

For WiFi:
0x50F0
0x5E10
0x3FF0F0
0x3FFE10

[a1145987]

Thanks, it seems to be working now. I had to try a few times to find out my edits weren't working, until that is I found this page on WebOS Internals. Now it has its own serial number, SKU and MAC addresses back.

[jmdesai]

Originally Posted by a1145987

Thanks, it seems to be working now. I had to try a few times to find out my edits weren't working, until that is I found this page on WebOS Internals. Now it has its own serial number, SKU and MAC addresses back.

Bravo. I love you guys who just won't give up. I don't need this thread at present fortunately, but would love to struggle like this when my time comes. Wishing you guys all the best.

[cyberprashant]

Please see this thread TPDebrick v0.1 - HP Touchpad - RootzWiki - Page 35. @jcsullins is a genius!!!!!!
http://rootzwiki.com/topic/36658-tpd.../page__st__350
After 4 months my TP is working!

[ajguns]

Hello,
@cyberproshant: Does this work on a Pre3? Is just that solutions in here seem to be directed to TP when the thread refers to Pre3.
Regards,

[cyberprashant]

Originally Posted by ajguns

Hello,
@cyberproshant: Does this work on a Pre3? Is just that solutions in here seem to be directed to TP when the thread refers to Pre3.
Regards,

might want to hit up the developer in that thread. @jcsullins Suspect it's probably a similar underlying issue. The guy's a genius/android pro and expert on hardware booting up software etc. Maybe he can rig something up similar for @pre3.