OMAP is a brand of system-on-chips inside several recent Android phones.
At the lowest layer, it's pretty much just like any other embedded device, and in particular it needs to be bootstrapped at the factory. This program implements the lowest level protocol that starts the bootstrap process in these chips:
- omap4430
- omap????
- ????????
In theory, this lets you completely sidestep the system sitting on the NAND, making physical access == root access like it should be.
I love getting comments and knowing I'm helping people, and also feedback on what's broken if I'm not. So please, don't be shy! Leave me an email or post in the issue tracker here, especially if you discover a different chip model that this works for.
- python3
- either pyusb>=1.0.0 or {Open,Net,Free}BSD
- a smartphone with the chip (or possibly a pandaboard)
This is not published yet, but for now you can install it with setuptools:
$ git clone https://github.com/kousu/omapboot
$ cd omapboot
$ python setup.py develop --user
$ omapboot
usage: usbboot [-a] 2ndstage.bin 3rdstage.bin
By using 'develop', the script installed to your $PATH gets pointed at cloned folder, so you can tweak it directly (which you might need to do). By using "--user" you don't need to worry about stomping on the rest of your system by accident, though you'll need to edit your $PATH:
$ cat ~/.profile
[...]
export PATH=~/.local/bin:$PATH
[...]
(I don't know the equivalents on Windows. Sorry. I plan to make a Windows prepackaged .exe sometime)
Before anything, MAKE BACKUPS. I took backups of all my NAND partitions like so:
$ adb shell
$ su
# for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14; do dd if=/dev/block/mmcblk0p$i of=/sdcard/mmcblk0p$i.img; done
and then copied the images off the SD card. This will probably take at least an hour to get everything.
This requires a rooted Android, of course. In theory having control of the bootloader should allow you to boot an image which just takes backups automagically, but I don't have that built yet
Depending on the size of your partitions, you may need to do this in multiple steps.
The extension of kousu omapboot make you able to boot from different interface then hardwire boot option. This is primary done for Samsung Galaxy Tab 2 P5100 to be able boot from SD Card, but may work with other devices. I think the device have to have hardwire boot options to boot from USB that is probably case of Samsung Galaxy Tab 2 P5100.
You can boot your device from MMC1 interface (Samsung Galaxy Tab 2 P5100 SD Card) by doing the following:
- Plug in the usb cable with the battery still out. You should see a device attaching and detaching in dmesg(8) or in the Windows Device Manager, it's ther only for 1sec or less.
- If you want load original u-boot from SD Card you have to have battery in. Press power button for 10sec, after run the program.
- run the program:
[kousu@birdlikeplant omapboot]$ omapboot -b
Boot from MMC1 interface selected.
Waiting for omap44 device.
Model: 4430
ROM revision: 0x04
CH: enabled
Underdocumented ASIC subblock #18: 00
IDEN: 0xE5FD23CE0F5FDF902D7EDA9B4D848D687F62372A
MPKH: 0xB585ACF1DD15B06A74813BFDDD6ECD64227CE4C90658C65B4C53AC229B4C6DC0
CRC0: 0x9C669AD9
CRC0: 0x682ADCCF
recevied ASIC ID banner:
Model: 4430
ROM revision: 0x04
CH: enabled
Underdocumented ASIC subblock #18: 00
IDEN: 0xE5FD23CE0F5FDF902D7EDA9B4D848D687F62372A
MPKH: 0xB585ACF1DD15B06A74813BFDDD6ECD64227CE4C90658C65B4C53AC229B4C6DC0
CRC0: 0x9C669AD9
CRC0: 0x682ADCCF
Giving x-loader a chance to come up...Probably loaded!
Contiunue of original README.
Then, you need to find or make some boot images. In general, this is the most frustrating and difficult part, and I cannot help you with it because every phone is slightly different. You also need to ensure that the images are signed for your device. Here are some possible sources:
- If you have taken backups, then two of the images should be the two bootloaders. Fun fun fun!
- xda: "l9 p760 p765 p768 p769"
- xda: "u-boot / omap4boot for P920/P720/P940 and its variant"
- @swetland's omap4boot will build generic images, but you need to get the u-boot it builds signed.
- And here's ssome possibly bad information on rolling your own from xda-university.
The 2nd stage images are all pretty much identical, and can't do much anyway, so once you find one that works for you you can just stick with it. It's the U-Boot images that are more interesting; some U-Boots have fastboot; some have S/W update mode; some cryptographically enforce content, some let you read the contents of NAND without booting Linux and all let you write NAND without booting Linux.
With images in hand, you can boot your device on them by doing the following:
- Pull all power from your device (i.e. take out the battery and unplug the USB cable)
- Plug in the usb cable with the battery still out. You should see a device attaching and detaching in dmesg(8) or in the Windows Device Manager.
- run the program:
[kousu@birdlikeplant omapboot]$ omapboot images/lelus/p940-aboot.2nd images/lelus/p940-u-boot_fastboot.bin
Waiting for omap44 device. Make sure you start with the battery out.
Uploading x-loader...done.
Giving x-loader a chance to come up...
Received boot banner ("0xAABBCCDD") from x-loader.
Insert battery and press enter to upload u-boot > [ENTER]
Uploading u-boot... done.
- Then you should be able to poke at your device with the fastboot protocol
[kousu@birdlikeplant omapboot]$ fastboot getvar version
version: 0.5
finished. total time: 0.000s
You could also roll your own u-boot images to do whatever you need.
There's a -a command line option which will skip the "Insert battery" line if you think you can be fast enough with your hands. (TODO: document this better).
- Check your cables and try again. This is hardware we're dealing with, afterall.
- If you're on OpenBSD, make sure you have no other ugen(4) devices active (I'll fix this, but right now I just have to say sorry)
- If the device is not responding at all, try uncommenting the ASIC ID lines to ensure you're talking to the right thing
- If the device is dropping you after x-loader uploads, try tweaking
sleep(1)inOMAP.boot()and file a bug report, please.
- NAND: a type of solid state storage; all omap devices on the market come with a NAND chip where all data beyond the 1st stage is kept.
- 1st stage: the very lowest level bootloader, at the same level as the BIOS in a PC, which implements the protocol that this script speaks to. This is burned-in to the ROM; it does not sit on a NAND partition.
- 2nd stage: the small bootstrap bootloader whose job is to load the 3rd stage. Also called "aboot" and "x-loader", for some reason. This intermediate loader is a quirk of the OMAP system; most computers have a ROM bootloader, a disk bootloader, and a kernel--though actually, this three stage system should be familiar to BSD users. Only on the systems that I've seen, the NAND partition for this is named "x-loader" (and so that's the name you'd use if you want to flash it). In principle, you could subvert this to do something besides loading the 3rd stage.
- 3rd stage: the larger bootloader, always always some version of U-Boot, which knows how to boot Linux and/or NetBSD and/or etc. The NAND partition is named "u-boot".
- boot: in the context of Android, a simply packed kernel+ramdisk created by mkbootimg. ping.se's unmkbootimg can tear it apart.
- recovery.img: an alternate boot.img which is meant to be like Windows Startup Repair; a lot of rooting guides methods have as their goal the installation of a "recovery", like ClockworkMod
- system.img: where the Android system lives. If you know unix, think of boot as /boot, and system as /usr ((XXX is this accurate?))
- vendor.img: this is meant to be where all the bloatware that a cellphone carrier stuffs onto your phone goes. whether it actually gets used for that is up to the vendor. Sort of like /opt
- cache.img: Android is written in java, and java takes a long time to compile. Compiled files get put here. Clearing the cache (XXX is this accurate?)
- userdata.img: like /home. But unlike /home, at the Android layer, apps get separate folders and cannot see each other's area (TODO: link a good explanation of how android jailing works). Some devices set aside a subfolder here for an "internal SD card", which apps can share.
- TI's flash.exe and poorly named wiki page, particularly the file pheriphalboot.c
- TI's OMAP repo, with code for all the chips(!)
- @swetland's omap4boot, helped out by @wkpark and @dimitry
- Kuisma's every-root guide (this is really just "how to install your own OS on an ARM system", with rooting an Android as an immediate corrollary).
- Android's code -- did you know you can download snippets of Android's code? The entire project is huuuuge, but this site will package any subfolder for you at a click, and with a bit of ingenuity you can get most tools built.
- I would link XDA, but there's nothing decent there that isn't wkpark's stuff.