Android on i900?

[Guest dego1988]

Can anybody upload the file's to run Android on i900 please? :)

thanks

[Guest adzrm]

hope u guys can do it.... great job!!!

[Guest aridoasis]

Can anybody upload the file's to run Android on i900 please? :)

thanks

it's still under way dude. read the entire thread.

anyway, nice job guys. very interesting developments.

[Guest Maxwell Newton]

The thread note has changed to "We have a running shell" can we see some screeshots? Sounds excitingly close!!

[Guest gianton]

Great project! Keep it going guys!!!

[Guest us1111]

I don't know if oxirot is active here... But he and tmzt from XDA made some great adjustments to the kernel to make it more Omnia compatible...

Hi all,

I've got some news for you. First off, let me thank tmzt, without his help I couln't have accomplished anything of this. So thank you tmzt, and you're most than welcome to post on this thread.

*New values for pxafb_mode_info structure. No pixclock confirmation for the moment.

*No more flashing nor vibration while booting. This should avoid some potential damage.

*We can now mount an ext2 partition on "my storage". Not in the external memory card yet.

New values for pxafb_mode_info structure.

Open arch/arm/mach-pxa/hpipaq214-lcd.c , and chage "struct pxafb_mode_info" to look like this:

static struct pxafb_mode_info hpipaq214_mode = {

		.pixclock			   = 96153,

		.xres				   = 240,

		.yres				   = 400,

		.bpp					= 16,

		.hsync_len			  = 8,

		.left_margin			= 8,

		.right_margin		   = 8,

		.vsync_len			  = 4,

		.upper_margin		   = 38,

		.lower_margin		   = 38,

		.sync				   = 0,

};

How did we get this?: tmzt asked me to paste this code on haretconsole:

pd 0x44000000 0x20

With the output:

44000000 | 03b008f9 07071cef 26260d8f 04700014 | ..........&&..p.

44000010 | 8400fe92 3f3f3f3f 00000000 00000000 | ....????........

...and a program (decoder?) I don't know about, he determined the correct margin values for pxafb_mode_info. I think it should have given some info about the pixclock, but unfortunately it didn't. tmzt suspects this info may be elsewhere in the memory. No more flashing nor vibration while booting. Open arch/arm/mach-pxa/hpipaq214.c , and change hpipaq214_init to look like this:

static void __init hpipaq214_init(void)

{

hpipaq214_init_lcd();

hpipaq214_init_mmc();

/*

		hpipaq214_init_mfp();

		hpipaq214_init_misc();

		hpipaq214_init_lcd();

		hpipaq214_init_mmc();

		hpipaq214_init_keypad();

		hpipaq214_init_nand();

		hpipaq214_init_usb();

		hpipaq214_init_audio();

		hpipaq214_init_power();


		//add the various platform devices

		platform_add_devices(hpipaq214_devices, ARRAY_SIZE(hpipaq214_devices));

*/

}

Open arch/arm/mach-pxa/hpipaq214-lcd.c , and change hpipaq214_init_lcd to look like this:

void __init hpipaq214_init_lcd(void)

{

/*	  int err;


		platform_device_register(&hpipaq214_backlight_device);


		err = gpio_request(gpio_lcd_setup, "LCD setup gpio");

		if(err){

				printk("Unable to register LCD setup gpio (%i)\n",gpio_lcd_setup);

				gpio_lcd_setup = -1;

		}else{

				gpio_direction_output(gpio_lcd_setup, 1); //keep it on for now!

		}

*/

		set_pxa_fb_info(&hpipaq214_lcd_info);

}

What's this for?: As you can see, we're commenting out a lot of hardware initialization. This will prevent potentially damaging the omnia and let us focus on what we need for the moment. The mmc initialization is needed for the next step, so it's left uncommented. With the above changes I'm finally able to boot from the "my storage" device, and I don't quite recall whether I'm able to boot from the card as well... We can now mount an ext2 partition on "my storage". Connect your omnia to the computer using the usb cord, and in winmo select "my storage" as usb connection, instead of activesync or the external card. Make a backup of the complete "my storage" device on your computer. In my computer this was detected as /dev/sde, with /dev/sde1 being an extended partition, and /dev/sde5 being a logical vfat partition. I made the backup using dd, like this: "dd if=/dev/sde of=/home/oxi/mybackup.bin". This kind of backup (a whole device) will ensure you're keeping not only the partitions content, but the partition table as well, so you should be ok if you ever want to restore. This took around an hour to complete for my 16gb mem. Maybe you can speed up the process by using high blocksize value in dd. Make the new partition/s on the "my storage" device. You may want to use fdisk or cfdisk for this. Since the default vfat partition is logical, I kept the extended partition, created a new logical 2gb ext2 partition at the end and then created a new logical vfat partition at the beginning. I did this so to prevent possible problems if the omnia/winmo couldn't rightly handle primary partitions on this memory. Now I must say I'm not that sure I did the right thing. Now winmo is able to see the ext2 partition and depicts it as "my storage2"; also, my computer will mount it as an vfat if no type is specified. So I wouldn't recommend this partition schema. I will be repartitioning the "my storage" device to have just two primary partitions, the first one being vfat, and the other one ext2, ASAP, because I don't really like all this behaviour. But I can't recommend this second schema as I have not tried it yet. Note that the default vfat partition is of type: 0b, not the usual 06. Edit: Of course, create the new filesystems on the partitions.

mkfs.vfat /dev/sdXY

mkfs.ext2 /dev/sdXZ

I have now tried the second schema, that is, creating two primary partitions. Results are exactly the same. For some strange reason, when you disconnect the usb cord, winmo has the bad habbit of writing two files in each partition, no matter if it's an ext2 partition, winmo will write them to it in FAT format. This apparently doesn't pose any problems, but just to be on the safe side I run a fsck.ext2 on the partition everytime before I mount it on my computer. You can now deploy a busybox(or whatever) on the ext2 partition. Just set the cmdline of default.txt accordingly, by setting the proper init parameter, and setting the root to your ext2 partition. If you're using an extended, and logical partitions:

root=mmcblk0p6	1 is the extended partition, 5 is the first logical partition (vfat in my case), 6 is the second logical partition (ext2 in my case)

If you're using primary partitions:

root=mmcblk0p2	1 is the first primary partition (the vfat partition, maybe), 2 is the second primary partition (the ext2 partition, maybe)

Note that if you have an external memory card inserted, you will need to use mmcblk1 to access the "my storage" device, because even if we can't use yet the external card, it is detected and named as mmcblk0. If no card is inserted then the "my storage" device will be named mmcblk0, and the examples above should work for you.

Edit: Set rootdelay parameter on cmdline to an appropriate value, so to give time for the memories to be detected. A value of 10 is more than enough.

Now I feel we should be directing our efforts on trying to establish a connection with the computer, as a means of communicating with the device without having to constantly reboot, etc. Maybe start by uncommenting the usb initialization related stuff and set up a telnetd or ssh in a busybox.

I hope I'm not leaving anything behind...

Once again, thanks go to tmzt

Needless to say, I don't take any responsibility for any damage, data loss, etc. you may get by using this info.

Cheers,

oxi

[Guest Mertoglu]

hmm.. any updates? i want androird so badly :$

[Guest sid0101]

is thread dead....?

yes, I rhymed.

Just saw this awesome app on the android and made me very jealous:

[Guest justpratik]

It's not that perfect.

One very big problem is current Android does assume that it will run on device with hardware keyboard.

That it does not have any support for software input/virtual keyboards.

That you will not only have to program the software input from scratch, but to modify all input-related things in OS to make all applications to actually work with software input. I think there are some projects to do that out there, but they are not that usable right now.

htc dream won't have physical keyboard.

can we take the chance

[Guest nate.mcbride]

Is cupcake out yet (new android version)? I know i read about cupcake having software input but i forget if/when it will be released

[Guest ricflairandy]

wow, is anyone still working on this?

[Guest kramer65]

I am visiting this threat almost daily because I've got an Omnia and I just hate Windows Mobile. I would really really like android on the Omnia. Can't we put some money together for the people who manage to put android on the Omnia within half a year from now.

I'll chip in €100 (about US$135 at the moment). Does anybody want to join me? (doesn't need to be €100. Can also be $5 or so.. Anything is appreciated I guess.)

If needed we can make it official by setting up a paypal account or something..

Edited March 22, 2009 by kramer65

[Guest ricflairandy]

id chip in whats in my paypal account, (i think its around $20)

[Guest Maxwell Newton]

If it was easy to set up and worked well then id chip in for sure. However at the moment i am using M2D with the touchflo home screen, it means i hardly every use the windows interface which is nice. My point is im finally happy with my phone and would only upgrade if it meant i didnt have to go back to flashing it and resetting it everyday because somethings gone wrong!

I would definately like Android though B)

[Guest Gibeon]

Count me in for 25 euros

[Guest thierryyy]

Please work on this, If the Omnia had Android it maybe is the best phone ever.

Thanks guys!

[Guest Akshay_LP]

I'm in for any support you guys need! Lets get this going people!

[Guest JASTECH]

We are talking about getting it done on our forum.

http://www.samsung-omnia.org/samsung-omnia-hd-discussions/

Thanks, JASTECH

[Guest flibio]

Hi everybody!

I'm anxious to buy an omnia i900. Maybe that will happen next week.

It's great news your all working on running the android on it. That will be awesome!

Any news? Plz, keep us updated about your progress!

Best Regards. B)

Edited March 31, 2009 by flibio

[Guest Mertoglu]

When will Android work? Count me in for 20 dollars...

[Guest Zeski]

I'm a bit of a rookie on linux.... and programming in general...

But from the look of things you guys are able to get the kernel up... I didn't follow the thread too closely but does that mean you guys can get to "bash" and run commands already?

Just to get my head around the porting process -

The first stage is to create an image of the kernel as per http://www.kandroid.org/android_pdk/bring_up.html and then run that on HaRET

The second stage is to then implement display, audio and input drivers (which seems to have been done to the extent that the display res is correct but because this is a touchscreen phone the key inputs can't really be configured yet)

The third stage is to configure telephony and then I guess X and all the good stuff

From what I understand of what I've read and the OP's last edit... he now wants to telnet into the kernel running on HaRET? Is this to facilitate easier entry of commands? If you guys are at a bash prompt... how is anyone typing commands into it? Are you guys preparing scripts on your PC's and then running them?

Sorry for the barrage of questions but I'm very curious about the status and very keen to do what I can to help this off the ground. I feel like the Omnia has the body of a shark but the mind of a brain damaged jellyfish.

P.S. On the note of keyboards - would it maybe be possible to install a keyboard via Bluetooth?

[Guest bpivk]

P.S. On the note of keyboards - would it maybe be possible to install a keyboard via Bluetooth?

That's just the problem.... The shell is runing but they are not able to issue commands to it because the don't have a working driver for keyboard so they can't program anything. It would be hard to program the keyboard to work trough bt if you can't actually program it.

[Guest mynullvoid]

LiMo is out, perhaps omnia driver used there could be ported for android

[Guest eugopnosaj]

That's just the problem.... The shell is runing but they are not able to issue commands to it because the don't have a working driver for keyboard so they can't program anything. It would be hard to program the keyboard to work trough bt if you can't actually program it.

Cupcake should be released soon which contains an on screen keyboard for Android on the G1, perhaps there is a way to use the softare written for this

Android G1 Onscreen Keyboard

[Guest Zeski]

bpivk

Ahh crap. I'm going to get a Ubuntu sesh sorted soon and see how far I can get before I encounter a serious error... but any idea on what the issue with the keyboard drivers is? I think the thread on XDA seemed to indicate that they couldn't map GPIO's to inputs on the phone... but I figured that that was because of the complexities of mapping touchscreen inputs without a visual keyboard on the screen? Or am I totally offtrack...

mynullvoid

I think the guys over at XDA are trying to get in touch with the LiMo team. From the sound of the issues everyone's having with the porting, it seems that we just need to get the kernel off the ground... so a pre-compiled rom from LiMo would be the Hail Mary of this porting process.

shows that not only was LiMO able to get a UI working, they have touchscreen and all the bells and whistles working with a Samsung-ized Android. In fact, I would go so far as to say that whatever they're running seems mature enough to offer us Omnia a true WinMO alternative... but we'll see what happens ey