Last Resort Emergency BootLoader Recovery
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
GSM Pre Plus SFR: DMCARRIER=ROW, DMMODEL=P101UEU, HWoRev=A, KEYoBRD=w1 (AZERTY), PN=180-10773-01, PRODoID=P101UEU
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 BATToCH DMCARRIER DMCLoNONCE DMSVRoAUTHPW KEYoBRD PRODoID WIFIoADDR 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
Anyone is willing to provide a MD5 hash of these tokens on his device, to see if they're device unique or not?
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 Options: --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)
novaterm
You should get a shell prompt
root@palm-webos-device:/#
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.
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.)