[samcripp]

This thread is for the disscussion of the android for touchpad partition scheme, and disscussion and research over best dual booting method.

I first design this when i began working on #touchdroid channel in freenode, I'm a free agent i dont affiliate with any group in particular and anyone that have any questions is always welcome to ask. Currently my Scheme is use in touchdroid but im hoping it is used else where.

(please be aware im currently moving, and my internet is not yet running at my new place, so if i dont answer questions is not that im ignoring anyone, i simply dont have the internet)

Using LVM it is possible to partition the internal storage. Anything above the 14th partition is friendly to LVM and wont brick the device. The best way to utilize this is by partition the internal storage side of things to add android.

My main goal was to keep android 100% apart from webOS as to not limit either OS from modification, like custom kernels and roms.

scheme:
8mb /recovery
8mb /kernel
32mb /persist
320mb /system
320mb /cache
1.5gb /data

My perspective:
As I read about the device I came to the understanding, that you could chain boot. So by means of modifying bootie launch either OS. Thus keeping both system completely independent of each other allowing full Custom Roms and kernels. Even creating a third option to launch CWM.

Tho Ive been told you cant modify bootie config scripts as it causes a brick.

The touchdroid way:
As far as I understand, they use my scheme differently. They have frankenstein a kernel, to have both webos and android bits. During boot depending on a key selection the kernel will launch either android or webos.

Personally i think this could be a lot more elegant, and believe chain booting should be possible on the device.

If anyone wants to share ideas on the dual booting dilema, this is the place to do it. anyways with that said, like always.

Move forward at your own risk. PARTITIONING OR MODIFYING ANY FILES ON YOUR TOUCHPAD COULD LEAD TO A BRICK.

RULES:
#1 NO FLAMING ON THIS THREAD

#2 SHARE SHARE SHARE

 

[Athorax]

I had no idea virtual space was measured in milligrams

 

[calris]

As I read about the device I came to the understanding, that you could chain boot. So by means of modifying bootie launch either OS. Thus keeping both system completely independent of each other allowing full Custom Roms and kernels. Even creating a third option to launch CWM.

Tho Ive been told you cant modify bootie config scripts as it causes a brick

For dual boot, I am still thinking along the lines of getting Bootie to load and execute U-Boot instead of the WebOS kernel. I haven't looked too deeply yet, but I wonder if we could rename the WebOS kernel image and put a copy of U-Boot in with the same name as the old WebOS kernel image name (i.e. trick Bootie without changing any of it's scripts)

 

[LimitBreak]

For dual boot, I am still thinking along the lines of getting Bootie to load and execute U-Boot instead of the WebOS kernel. I haven't looked too deeply yet, but I wonder if we could rename the WebOS kernel image and put a copy of U-Boot in with the same name as the old WebOS kernel image name (i.e. trick Bootie without changing any of it's scripts)

That's what I did with my GPS that runs windows CE (swapped boatloader names of the original to another that opens a screen to choose which OS to boot from)

 

[calris]

I'll have a bit more of a dig around the boot process when I get a chance - looks promising

 

[AllThumb]

I like this open discussion idea!
I've been working on Android porting by myself and currently using uboot method through bootie and I couldn't come up with good idea bout dual booting other than similar to TouchDroid.
calris idea is certainly doable. Boot up with Android kernel using uImage with ramdisk and mount root device to a folder then we can modify webos's root directory.
Since we don't touch bootie, if something wrong we can always recover using WebOS doctor.

 

[calris]

I like this open discussion idea!

Ditto

I've been working on Android porting by myself and currently using uboot method through bootie

OK, I'm seeing 'uboot' cropping up again and again - Can you please clarify what you mean by 'uboot method'. Are you booting into bootie and then using novacom to launch custom built kernels or are you really and truly loading U-Boot (U-Boot git repository) onto the TouchPad somehow? If you are loading U-Boot, can you please provide some details (I know for a fact that mainline U-Boot has no support for the TouchPad or the Snapdragon SoC so if you are using U-Boot, you have patched it)

If you are not using U-Boot, can we all please stop refering to it

And bootie != U-Boot as per the following email conversation I had with the Palm Open Source Team:

Hello,

As you are probably well aware by now, there is a concerted effort to
port Android to the Touchpad. People involved in this effort have
suggested that the boot loader the Touchpad uses is a derivative of
U-Boot. Can you please advise if this is the case (or if the
bootloader is a derivative of any other Open Source boot loader).

If it is the case that the boot loader is an open source derivative -
Can you please provide a link to download the source code

Thanks,

Graeme

Thank you for your interest in the Touchpad. The bootloader in webOS is proprietary, and as such is not released as source.

Regards,

Palm Open Source Team.

 

[scifan]

Was going to say... the palm opensource site for the touchpad includes uboot source + a uboot patch...

Look here: http://opensource.palm.com/3.0.2/index.html

 

[calris]

Was going to say... the palm opensource site for the touchpad includes uboot source + a uboot patch...

Look here: http://opensource.palm.com/3.0.2/index.html

Have a closer look, the patches are trivial and do not expand U-Boot to support the Snapdragon SoC. I think the U-Boot is only included in order to create the mkimage program needed to make image files for bootie to load

 

[scifan]

hmmm... that could be... Nuts

 

[calris]

P.S. I am currently investigating the validity of Palm/HP's claim that bootie is not open source - the similarities to U-Boot disturb me, although bootie seems to be too trivial to have used to U-Boot codebase. That being said, U-Boot 1.1.2 is very old and it has become far more sophisticated since then...

It would be very interesting indeed of a GPL violation cropped up.

 

[scifan]

It would appear that they've created 14 partitions (or is it 13... think it's 14) and they've made one bootable... (/dev/mmcblk0p13) and the rest are bound together in a LVM array... which is then configured however they want to do it... it seems somewhat convoluted... though I guess it could be a way to achieve faster access off of the flash media...

The question is why would messing with those other partitions cause the unit to be "bricked"... in theory, as long as p13 isn't impacted, everything should be ok...

(and no, I'm not about to putz with mine...)

 

[calris]

and no, I'm not about to putz with mine...

Chicken :tongue2:

I'm also trying to track down data sheets & manuals for the Snapdragon and iNAND flash - I _think_ it might be possible to access the iNAND directly via the solder pads next to it. I'd love to get my hands on a 1GHz, 16-channel logic analyzer to see what happens on those pins as the device boots up. If I could get that info, I think I could work out how to debrick a TouchPad

 

[scifan]

Chicken :tongue2:

Yeah, and...

 

[AllThumb]

If you are not using U-Boot, can we all please stop refering to it

And bootie != U-Boot as per the following email conversation I had with the Palm Open Source Team:

You're right and I'm sorry for using wrong term. I meant to use uImage and screwed up.

 

[Zaphod-Beeblebrox]

Some of you might find this interesting:

http://dl.dropbox.com/u/9669866/topaz.xml

It's a file inside the webosdr file that describes the partition structure.

 

[calris]

P.S. I am currently investigating the validity of Palm/HP's claim that bootie is not open source - the similarities to U-Boot disturb me, although bootie seems to be too trivial to have used to U-Boot codebase. That being said, U-Boot 1.1.2 is very old and it has become far more sophisticated since then...

It would be very interesting indeed of a GPL violation cropped up.

Wolfgang and I have had a look at bootie and agree that there is NO evidence that U-Boot code has been copied into bootie

 

[cursordroid]

Some of you might find this interesting:

http://dl.dropbox.com/u/9669866/topaz.xml

It's a file inside the webosdr file that describes the partition structure.

<Entry type="bootloader" partition="0x48" size="10240KB" reformat="false"/>

Interesting to see this 10MB partition for bootloader. I'm assuming this is where bootie sits right now. Very risky, but has anyone thought of replacing this with a U-Boot img or another similar bootloader?
Correct me if I'm way off base here...

 

[calris]

Interesting to see this 10MB partition for bootloader. I'm assuming this is where bootie sits right now. Very risky, but has anyone thought of replacing this with a U-Boot img or another similar bootloader?
Correct me if I'm way off base here...

Hmm, I don't know if this is where bootie lives, or if that is where the second stage boot loader lives. As far as I can tell, there are three boot stages - IPL (reset vector, first page of iNAND), SPL (???), TPL (bootie) - This 10MB partition might me the SPL

Either way, bootie lives in /boot (as boot.bin) as well as the boot splash images (hp, USB, charging logo's etc) and a kernel uImage (interestingly they simlink uImage to the actual kernel image which includes the version number in the file name). My suggestion would be to redirect the simlink. If this bricks the board, WebOS doctor _should_ be able to bring it back. It's a real pity bootie does not have any file system commands

I think I might start dd'ing the iNAND partitions and see what pops up

 

[tinnmann420]

I love boot.bin cause if your bored just changed out all the boot images for other stuff, like mine boots to my monogrammed initials (classy I know )