Last Resort Emergency BootLoader Recovery

From WebOS Internals
Jump to navigation Jump to search

Recovery Mode

Typically, any damage to the operating system on the Palm Pre/Pre Plus can be recovered by booting into recovery mode. (How_To_Recover)

One situation which cannot be recovered so easily is the extremely unlikely event of corruption of the installed bootloader (bootie) stored on the Pre's flash disk.

If bootie on the flash disk has been damaged or corrupted in such a way that booting into recovery mode is not possible, the Pre is still not "bricked" as the OMAP3430 processor in the Pre provides for a mechanism to boot code from its USB interface. At this time this operation has not been performed on a Pixi, and will not be the same as it has a different core.

The OMAP method listed below worked successfully to reset the phone when the phone lock password was forgotten to rebuild the phone without losing the photos on the Palm Pre phone.

NVRAM Tokens

If the NVRAM partition gets trashed too, the token area will be empty and the doctor will refuse to install. If you're in this situation you need to rebuild it. Here are a few of the minimal token sets to allow the doctor to start:

Note : you cant get all minimal token sets below with the showprops (Show Properties Application) app that is available HERE.

GSM Pre for O2 and Movistar: DMCARRIER=ROW, DMMODEL=castle, HWoRev=A, PN=180-10722-03, PRODoID=P100UEU


Sprint Pixi: DMCARRIER=Sprint, DMMODEL=P200EWW, HWoRev=A, KEYoBRD=z, PN=180-10714-03, PRODoID=P200EWW

Sprint Pre: DMCARRIER=Sprint, DMMODEL=P100EWW, HWoRev=A, KEYoBRD=z, PN=180-10642-05, PRODoID=P100EWW

Verizon Pixi Plus: DMCARRIER=Verizon, DMMODEL=P121EWW, HWoRev=A, KEYoBRD=z, PN=180-10714-01, PRODoID=P121EWW

Verizon Pre Plus: DMCARRIER=Verizon, DMMODEL=P101EWW, HWoRev=A, KEYoBRD=z, PN=180-10724-01, PRODoID=P101EWW

AT&T Pre Plus: DMCARRIER=ATT, DMMODEL=P101UNA, HWoRev=A, KEYoBRD=z, PN=180-10725-03, PRODoID=P101UNA

Pre 2 (US): DMCARRIER=ROW, DMMODEL=P102UNA, HWoRev=A, KEYoBRD=z, PN=180-10827-00, PRODoID=P102UNA

Pre 2 (EU): DMCARRIER=ROW, DMMODEL=P102UEU, HWoRev=A, KEYoBRD=z, PN=180-10808-00, PRODoID=P102UEU

If you want BlueTooth and Wifi to work, You may also want to set BToADDR=00:1D:FE:xx:yy:zz, WIFIoADDR=00:1D:FE:uu:vv:ww and PalmSN=serial. If you are unsure of your original MAC addresses, They can safely be any random number, the serial number is on the box and on a sticker inside the battery compartment.

Token Backup

If you are a heavy experimenter, you should probably backup your tokens before you start experimenting, this way you can easily recover a future problem without as much hassle. Also, there are tokens that control things like touchscreen calibration, so these cannot be easily obtained if they are lost! Once booted, you can backup all your tokens by copying everything in /tmp/tokens. Here are a list of the Tokens on an Average Pre:

ACCELCAL       BToADDR        DMCLoAUTHPW    DMSETS         HWoRev         PN             ProdSN
BATToRSP       DMCLoAUTHNAME  DMMODEL        DMSVRoNONCE    ModemSN        PalmSN         installer
MfgCode        SimLockDef

The purpose of the "BATToCH", "BATToRSP", "DMCLoAUTHPW", "DMCLoNONCE", "DMSVRoAUTHPW", "DMSVRoNONCE" tokens are as yet not fully understood. They appear to be unused, as they're never visible inside any part of the code as strings, and completely removing them does not seem to change anything in the device behavior. However, on webOS 2.0 and later, it seems that they need to exist for a successful login to your Palm Profile.

The BATToCH/BATToRSP is likely a challenge/response crypto system used to authenticate the battery pack. This means that Palm could use the capability to lock out "fake" batteries should they ever want to. So far they haven't implemented any of this, as it would probably affect the Seidio aftermarket packs. If Palm ever has a problem with fake Chinese packs finding their way into the market, they could implement the security to protect their customers. Historically, There has been a problem with inferior separator materials used in fake batteries causing fires, which is a good reason to have a way secure it. These fraudulent packs have been known to appear to be identical on the outside complete with OEM markings, so a fire caused one of these could really damage Palm's reputation should it occur.

A best guess is that the "DM" stuff is used (or could be used) in OTA activation/provisioning. Keep in mind, It's possible that you may not see these referenced in any code visible on the device, as they could be used by the AMSS (radio) firmware which has it's own ARM core and software. The interface between the systems is the TelephonyInterfaceLayer, but AMSS could request the Tokens from it's (large) codebase and therefore you won't see it anywhere in the visible filesystem. The AMSS handles battery charging and (obviously) a lot of what takes place during provisioning and activation. If your AMSS is already activated, it may no longer need these, so that may explain why they can be omitted and not affect operation.

In my case, the phone is an unlocked GSM device. There's no such thing as a device "activation". This may explain why they're unused.

The structure of these "mystery" tokens are as follows:

BATToCH       16 digits hex number
BATToRSP      40 digits hex number
DMSVRoNONCE   16 bytes in base64
DMSVRoAUTHPW  a floating point number in ASCII format
DMCLoNONCE    16 bytes in base64
DMCLoAUTHPW   a floating point number in ASCII format
DMCLoAUTHNAME an integer number (probably 32 bits) in ASCII format

The tokens are unique to each device.

Token Editing

Palm has provided a utility in WebOS for manipulation of tokens located at /sbin/tokens.

Here is a Summary:

root@palm-webos-device:/var/home/root# tokens -h

tokens - used for listing and editing tokens

  --help                 Print this help output
  --list                 List all tokens in the system
  --remove <token>       Remove the given token from the system
  --mount                Mount the tokens into the filesystem
  --device <dev>         Use the specified device path

OMAP boot Procedure

First, ensure that the Linux SDK and novacom packages are installed, as you will need to run webOS Doctor as the final step in this process. Second, ensure that you have a copy of the webOS doctor jar ready for your phone.

Download: omap3_usb.tar.bz2. If you have not libusb 0.1.3 installed on your computer, install it. It is needed for the header file /usr/include/usb.h On Ubuntu, make sure you have the libusb-dev package installed.

If you have a Pre 2, you need to change the ProductID in the code to 0xd00e

Compile on Linux system with "make". Optionally install with "sudo cp omap3_usbload /usr/local/bin"

Now extract the bootie binary from a WebOS Doctor image: (note: webosdoctor file name will vary)

mkdir doctor; cd doctor; unzip ../webosdoctor.jar; cd resources
mkdir webOS; cd webOS; tar xvf ../webOS.tar; mkdir nova-cust-image-castle.rootfs; cd nova-cust-image-castle.rootfs
tar xvzf ../nova-cust-image-castle.rootfs.tar.gz ./boot/boot.bin; cd boot

Booting bootie over USB:

Ensure USB is unplugged from the Pre, and remove the Pre's battery.

On your Linux system, run:

sudo omap3_usbload boot.bin

This should return:

TI OMAP3 USB boot ROM tool, version 0.1

and a series of dots while it looks for an OMAP3 to send boot code to.

Now, plug the pre into USB.

If all works as it should, the usbload program should return:

found device!
download ok

And your Pre will now show a USB logo. (this is bootie's "Recovery mode")

Put the battery back in without unplugging the USB.

Since you are now in USB recovery mode, you should be able to run the webOS doctor on the host Linux box. Remember that the SDK novacom package must be installed for the webOS Doctor to work in Linux.

One way to do this is to launch the doctor from the command line like:

sudo java -jar webosdoctor.jar

And follow the usual steps to recover your pre's operating system from here.

Alternative Recovery

Another available option now that bootie is running is to send bootie a Linux image over USB and perform some kind of recovery work directly on the pre itself. This is not recommended unless you are very familiar with linux systems administration.

First you send bootie the boot image of the doctor's installer. This can be extracted from the WebOS Doctor jar.

novacom boot mem:// < nova-installer-image-castle.uImage

Wait 15 seconds for the system to boot then connect in to a shell on the running linux system with novaterm. (you will see no on-screen indication that the device is booting linux, only a solid Palm logo)


You should get a shell prompt


Now find and activate the LVM disk voumes with the following two commands:

lvm.static vgscan --ignorelockingfailure
lvm.static vgchange -ay --ignorelockingfailure

Next, mount all disks

for N in root var media log update; do mkdir /mnt/$N; mount /dev/mapper/store-$N /mnt/$N; done

When done with whatever you need to do on the system, shutting it down safely is a good idea

umount -a; tellbootie reboot

Corrupted LVM

If your LVM disk volumes are completely corrupted, and the webOS Doctor will not run as a result, then use the Alternate Recovery technique above to enter a recovery shell, and run the following command to completely wipe the LVM disk labels and metadata:

lvm.static pvremove -ff /dev/mmcblk0p3

Then run the webOS Doctor again. (WARNING!! the 2.1 doctor does not like this at all! DataPreCheckStage: mount: mounting /dev/mapper/store-media on /tmp_media failed: No such file or directory )

Recovery using OS/X

For a Mac, the process of running USB booting the OMAP may be much simpler.

The MacOS X version of the SDK provides a pre-built executable /opt/nova/bin/cpuboot and a recovery image. You can simply run

/opt/nova/bin/cpuboot  -o -v -d usb -f /opt/nova/bin/recovery-castle.bin

(Note that the SDK no longer provides these tools. Palm removed them for some reason.)