[calris]

When I finally get to open my new Touchpad (my better half has quarantined it :sad I'm looking to do some really low level hacking (bootloader level) but before I do, I need to know if there is any way to 'de-brick' it if it gets 'perma-bricked'

Most bricking does not impact the bootloader so there will still be a recovery mode in the bootloader which is accessed by holding various button combinations. But if I trash the bootloader then it's pretty much game over unless I can get in at a hardware level (i.e. craking open the case) and restoring the bootloader.

So does anyone know if anyone has found a way to program the onboard bootrom which contains the bootloader? I have heard something about an onboard SD Card device - This might hold the bootloader but I would really like to know what I am up against before I turn by Touchpad into a paperweight :androidwink:

 

[Byakushiki]

Real good question...I highly doubt it's possible at this point. If it's bricked, it's bricked. Shame they're not like Motorola devices for that, where you can just fire up RSD lite and just sbf it to restore everything to an out-of-box state. Unless you can get into the system, code in a backup bootloader/boot menu of sorts, akin to HBoot (I suppose it's possible with some knowledge of gnome terminal and/or xterm, after getting into the touchpad as superuser via command prompt or gnome terminal) that only boots when you hold a specific button combination. In theory, this is all possible.

 

[jstafford1]

There is something. Its called a doctor, or meta doctor. I'm still learning the ins and outs of this thing as well. But it does seem pretty hard to brick this thing.

Been digging in my free time but that's been limited this week.

end of line...

 

[Rakeesh]

I'm trying to find info on the same subject before I get down and dirty. There's the webOS doctor, but I want to know what limits I can hit before not even that can de-brick the touchpad.

 

[Pulser]

Yeah, I have not established as of yet what the Doctor is capable of... Perhaps it uses a hardware mode of the CPU to enter recovery... Or perhaps this relies on the bootloader...

 

[calris]

Yeah, I have not established as of yet what the Doctor is capable of... Perhaps it uses a hardware mode of the CPU to enter recovery... Or perhaps this relies on the bootloader...

If it uses USB to communicate with any kind of 'doctor' app running on a host PC then that would be done by a bootloader. There may be an IPL (initial program loader) which allows a raw restore image to be streamed via USB.

Looking forward to getting access to the raw memory image (not just a file system dump)

 

[Pulser]

Yeah, just spoke to someone who bricked his messing with partition tables. Recovery mode is not infallible.

 

[yarly]

The best place to ask this question is on precentral, where people have been using webos devices for years.

 

[hk135]

The Bootie bootloader, which is where the recovery mode lives is on the same disk device as the main data partitions, if you wipe it then its bricked.

 

[Rakeesh]

Ouch. Would there be any known hardware methods of debricking in that case? Something as simple as a jtag port perhaps?

 

[yarly]

If you are super paranoid, I would attempt to do something like this and avoid modifying the device at all. http://code.google.com/p/android-on-pre/

 

[Rakeesh]

Well I'm not afraid of tinkering, but I won't trust myself to do any low level stuff, especially if it involves low level access to the nand flash (or whatever kind of memory it uses for nonvolatile storage.) I'll leave that up to those who are more familiar with that sort of thing.

 

[calris]

Well I'm not afraid of tinkering, but I won't trust myself to do any low level stuff, especially if it involves low level access to the nand flash (or whatever kind of memory it uses for nonvolatile storage.) I'll leave that up to those who are more familiar with that sort of thing.

According to TechRepublic the non-volatile memory (in the 32GB version) is a SandDisk SDIN4E2-32G. I've had a quick look for a datasheet but no luck. From the photo, it looks pretty hard to get to

 

[Nth]

Well I doubt they preprogram the flash chip before they solder it to the system board so there has to be some magic bits that can be send over the USB link or maybe test points on the system board to directly program the flash. If you look at this image (http://www.techrepublic.com/photos/cracking-open-the-hp-touchpad/6253940?seq=59&tag=thumbnail-view-selector;get-photo-roto) there is an area of 8 points in a green box towards the bottom that could be it. I'm not about to tear apart my TP to find out but maybe someone who has bricked theirs will.

 

[calris]

Well I doubt they preprogram the flash chip before they solder it to the system board

Actually, this is not as uncommon as you may think - A long time ago, in the dark ages, the only way to get firmware on a device was to pre-program a write-once ROM. Then came UV erasable chips (which you still had to physically remove to reprogram) then EEPROM (Electronically Erasable ROM) but these needed a high erase voltage so had to be removed before erasing to prevent damage to the rest of the device. Then came Flash which allowed the chip to be programmed in-circuit. But to save on time (and therefore cost) the assembler will be given hundreds (or thousands) of chips which have been pre-programmed (or given an image to program themselves) before putting the chips in the feed of the 'pick-and-place' machine. To keep up with demand, there are usually a number of device assemblers.

It is quite possible that some incorrectly programmed chips (maybe some spares lying around the R&D department) got put in the a batch that was sent to an assembler, or even the wrong image file got sent, and that's how there came to be a number of Touchpads with Android installed in the wild - I doubt that they were 'developer' devices that then get packed and sold

 

[Rakeesh]

According to TechRepublic the non-volatile memory (in the 32GB version) is a SandDisk SDIN4E2-32G. I've had a quick look for a datasheet but no luck. From the photo, it looks pretty hard to get to

ouch that thing is a ball grid array. Yeah if you brick it via that, you're pretty well screwed.

 

[calris]

ouch that thing is a ball grid array. Yeah if you brick it via that, you're pretty well screwed.

I found a datasheet for the SanDisk SDIN2C2 series of iNAND - SDIN4E2 looks like an similar, more recent, set of parts with higher capacity. The SDIN2C2 parts have an SD interface (and, therefore, an SPI interface as well). So looking at those images, there is a set of pads (8) to the left of the flash chip - maybe they expose the SD interface of the chip

 

[c0ns0le]

I found a datasheet for the SanDisk SDIN2C2 series of iNAND - SDIN4E2 looks like an similar, more recent, set of parts with higher capacity. The SDIN2C2 parts have an SD interface (and, therefore, an SPI interface as well). So looking at those images, there is a set of pads (8) to the left of the flash chip - maybe they expose the SD interface of the chip

Check out webinternals there is a way to flash a boot.bin via usb, lool for last resort recovery

 

[calris]

Check out webinternals there is a way to flash a boot.bin via usb, lool for last resort recovery

Yes, I saw that but I think that is Palm Pre specific (specifically the OMAP3430 Soc) - The TouchPad uses a Snapdragon SoC so there is no guarantee that the same recovery process will apply (unless Snapdragon == OMAP3430 of course)

Edit: OMAP and Snapdragon are not related - The former is Texas Instruments, the later is Qualcomm

 

[Rakeesh]

I don't know much in the way of hardware hacking, I don't suppose it is possible to find out if the snapdragon SoC has such a mechanism available?

It would be nice knowing there's a universal fix all before I get my hands dirty. Likewise, I believe the touchdroid team would benefit as well seeing that we have only so many touchpads, and they are the most likely to brick them in this manner.