Okay, after looking around for a bit it looks like some really incompetent "devs" have completely screwed people over on the TouchPad and like to act like little girls, so I'm here to try to organize information that I have and try the best method I think we have available to get Android on the TouchPad, which is by doing a byte-by-byte copy of the TouchPads that have Android on them, maybe manipulating WebOS doctor to flash what we need (since we have the source), and then going from there. It will be super simple to do all kinds of Android Development when this is done.
We already have a dump of Android that was shipped on very few TouchPads as test devices for Qualcomm (or at least that's the rumor). This dump has each partition listed as a number, although I'm not sure that they are in order and I don't know very much about them, but they are available here:
The problem with this mainly is that I'm not sure that things are in order. You can see that WebOS has 14 partitions if you check in /dev. These devices are listed as /dev/mmcblk0p? (with ? going up to 14). In the android build, things are partitions differently and it goes up to 17.
We'll come back to this later.
You need to be able to get into recovery so that stuff isn't mounted that shouldn't be. To get into recovery, power down and then press power and volume up while you are plugged into your computer. You will then get a USB symbol.
Download WebOS Doctor
Make sure you download WebOS doctor and install the PDK tools. This is available at:
If you start the doctor, it will connect to your device and start flashing it. Around 12% you should be able to run:
novacom open tty:// = novaterm
in a terminal. From here we can do whatever we want because things aren't mounted and the things that are we can umount. When you get to this point, if you unplug your device and plug it back in then you will cancel the update process but still be able to run commands (after re-running the novacom open command again). You will need to reboot by pressing the center key (first) and power button, then holding down the volume up and power to boot back into recovery and start WebOS doctor and let it finish to use your device again.
From here we should be able to dd those partitions, but because the schemas are likely different, I think the best chance we have of doing this and keeping the MBR is getting a dump of /dev/mmcblk0 (this will include the ENTIRE disk), the only question is where internal storage is at. If the device that the dump is from is a 16gb device and you try to flash to a 32 gig, you won't fill up your disk which probably isn't a big deal. We can grow the partition later. If it was a 32 gig and you try to dd it to a 16 gig, then you will run out of disk space, but you should still be able to recover using doctor.
A good thread with some information:
WebOS Doctor, and why we need it
It looks like WebOS doctor flashes the images by just using an InputStream. I didn't look into it much at all, but I think the best way to get the partition(s) or whatever you're going to dd is by booting into WebOS, copying the files over through USB, then mounting it in recovery. I haven't tested this yet because somehow I managed to kill my touchscreen last night and haven't had time to fix it so I can enable Developer Mode back on my tab.
That is pretty much where we're at. I'm trying to get ahold of the guy that has the Android TouchPad, so far only through Twitter. If somebody has connections, please hook me up. If nothing else, I would like him to get a dump of the entire disk.
Source to WebOS Doctor is here:
Next Steps and how you can help:
We need to contact the guy who has the TouchPad with Android on it and get him to run
dd if=/dev/mmcblk0 of=/tmp/mmcblk0 or something similar. Somehow we need to get this if we want this to be a simple process! Otherwise we are looking at trying to recreate MBR records and such...
If you are good at looking around in Linux, post any information you can find about flashing or how WebOS works.
If you want to test stuff, READ through what I have posted, try a few things, post back!
Also would be helpful if we could get the owner of the Android TouchPad to run printenv in the shell. Thanks rainlake for the input.
We should be able to get this running TODAY if people help out like they should. Let's do this as a community, not as some lame "team" with exclusive members/information asking/not asking for donations and acting like little girls. This thread should basically be a wiki. Post any information here, read through what people have posted, help out.
This thread will be updated as I find more things out and get more information. PLEASE post if you have any useful information. Thanks.
Update 1 - 2:28 PM: After doing a little socializing on IRC, it sounds like they were unable to read the partition table by doing a cat /proc/partitions - no such file or directory. They were also unable to copy /dev/mmcblk0, however it was pointed out that they should try in recovery. Here is what the output of df -h (from TouchPad with Android)
df /dev: 410928K total, 0K used, 410928K available (block size 4096)
/system: 153376K total, 110392K used, 42984K available (block size 4096)
/data: 151136K total, 86356K used, 64780K available (block size 4096)
/system/etc/firmware/misc: 204580K total, 4964K used, 199616K available (block size 4096)
/mnt/asec: 410928K total, 0K used, 410928K available (block size 4096)
/mnt/sdcard: 14301760K total, 24800K used, 14276960K available
A developer (Craptain) has gotten the images to boot. As per samcripp:
Craptain and eval- are to thank for the info.
Once you set bootie to android bootloader mode.
You can fastboot image 12 (system) to block 14.
Edit ramdisk to use 14 to boot from
You can then add data to the inside of internal storage and the persist img there as well and loop mount then.
The technicalities like setting bootie the right way you will have to discuss with Craptain. But that's the crash course of booting the dumps.
I haven't tried this yet, but apparently somebody did it and touchscreen wasn't working. They believe this is due to the fact that /persist isn't mounted (from what I was told).
With novacom, it's pretty easy to send files across and boot kernels and such. Boot into recovery and then run the following in terminal to get devices that are connected:
The most important part of the output is the long string you can use later to connect to the device through novacom.
First it's probably a good idea to boot into a kernel that's compatible with novacom. You can send kernels across extremely easy from your computer, using the following command:
novacom -d <device string you got above> boot mem:// < /path/to/kernel
That will boot the kernel. Right now I think it would be worth trying to compile Little Kernel from here:
Which would give us fastboot.
I haven't been able to compile it yet, getting errors while trying to use the toolchain from CodeSourcery.
You can send files through novacom after the kernel boots using the following command:
sudo novacom put file:///path/on/tab < /path/to/file/on/local/computer
We need to get an android kernel, change the ramdisk to make sure we're booting from a partition with android and then we should be good. I believe there is a kernel somewhere, I just need to find it
Edited by damageless, 27 August 2011 - 04:55 PM.