See, NOW it makes sense...

Posted Feb 3, 2010 21:55 UTC (Wed) by dlang (guest, #313)
In reply to: See, NOW it makes sense... by dcbw
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

I wasn't aware that android was supposed to be tied to a specific chipset. I was under the impression that it was intended to be used on a wide variety of devices.

is there anything that would prevent android from being run on the nokia phones, or the nokia software from running on android phones (other than the fact that some drivers are only in the android fork and the android fork does not include all the drivers in the main kernel)?

See, NOW it makes sense...

Posted Feb 3, 2010 22:04 UTC (Wed) by dcbw (guest, #50562) [Link] (11 responses)

Android *isn't* tied to a specific chipset. But when Google was creating Android they built it for the reference design (HTC Dream which used a Qualcomm MSM7201A SoC). And Google doesn't appear to be interested in porting Android to other SoCs like TI's OMAP; they appear to be entirely focused on Qualcomm chipsets where they can leverage their existing investment.

As a company building phones, would you rather just use the same hardware Google build Android for, or would you rather invest a ton of time into porting Android to another SoC and write completely new SDIO, radio, power-management, etc drivers while your competitors come out with 3 new phones?

It makes a ton of sense that (AFAIK) nobody has come out with a non-Qualcomm Android phone, since to do so would require a significant investment. If you use Qualcomm MSM7K or MSM8K (snapdragon) platforms, then Google has already made that investment for you, for the most part.

See, NOW it makes sense...

Posted Feb 3, 2010 22:10 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (3 responses)

Not phones, but the Nook is android on a Samsung platform.

See, NOW it makes sense...

Posted Feb 3, 2010 22:38 UTC (Wed) by dcbw (guest, #50562) [Link] (1 responses)

Interesting; though the scope there is quite a bit smaller; no real radio management, low-latency audio paths, fast 3D graphics, are required which makes the driver bring-up less intensive. Also the hardware refresh cycle for these is probably a lot slower than a phone, so you can recoup a lot more of your investment.

See, NOW it makes sense...

Posted Feb 4, 2010 11:24 UTC (Thu) by broonie (subscriber, #7078) [Link]

Thing is, Linux has a pretty good mainline stack for all of these things (possibly excepting 3D) - to the extent that people play with mainline a lot of this stuff is available off the shelf.

See, NOW it makes sense...

Posted Feb 4, 2010 11:35 UTC (Thu) by SimonKagstrom (guest, #49801) [Link]

The Samsung Spica Android phone is also built on their own platform (6410 I
believe).

See, NOW it makes sense...

Posted Feb 3, 2010 22:13 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

so all the vendors working on android based e-readers, netbooks, etc should not be doing so, they should be using some other linux variant ans android only cares about phones with the current generation of qualcomm chipsets.

this also says that the next generation of qualcom chipsets may need a different OS as android is not working to be multi-platform.

See, NOW it makes sense...

Posted Feb 3, 2010 22:49 UTC (Wed) by dcbw (guest, #50562) [Link]

I never said anything of the sort. Netbook and ebook reader makers can certainly use Android.

What I *did* say was that if you move away from the Qualcomm-based platform, you are going to be investing a *lot* more into the driver and architecture bring-up. But that could very well be a way of differentiating yourself in the market. It's a cost/benefit analysis and it appears that ebook reader makers have decided that over the long run they will make more money than it cost to port Android to a new architecture.

But the fact that almost all the phones running Android are doing so on Qualcomm 7k or 8k chipsets shows that most *phone* companies appear to be maximizing their investment by leveraging the work that Google has already done. Phone product cycles are also a lot faster than ebook reader product cycles, and phones have a lot more hardware in them (which requires more/different drivers) than ebook readers.

And just because Qualcomm comes out with a new platform doesn't mean your investment is worthless. Often new iterations of a chipset will contain only tweaks of the older hardware; they rarely rearchitect the entire system because that simply trashes all the money you've invested in the software so far. Which isn't smart.

For example, Android on the MSM8k can use mostly the same radio drivers (qmi), shared memory drivers (smd), network device (rmnet), etc that the MSM7k used. The GPU probably required a significantly modified driver, but at least you didn't have to rewrite *all* the drivers just to move from MSM7K -> MSM8K.

See, NOW it makes sense...

Posted Feb 3, 2010 23:08 UTC (Wed) by cdibona (guest, #13739) [Link] (3 responses)

As an aside, the Verizon/Moto Driod runs on a TI OMAP. So...

See, NOW it makes sense...

Posted Feb 3, 2010 23:59 UTC (Wed) by dcbw (guest, #50562) [Link] (1 responses)

Right you are. Quick question, I see a lot of @android.com on the OMAP patches. Who spearheaded the Android OMAP efforts here? Google, TI, Motorola, combination of all?

See, NOW it makes sense...

Posted Feb 4, 2010 7:33 UTC (Thu) by cdibona (guest, #13739) [Link]

A combination. It's always a mix, from what I understand.

See, NOW it makes sense...

Posted Feb 4, 2010 0:32 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

OMAP, of course, being a platform that achieves good battery life without wakelocks.

See, NOW it makes sense...

Posted Feb 4, 2010 19:51 UTC (Thu) by rahvin (guest, #16953) [Link]

As a company building phones, would you rather just use the same hardware Google build Android for, or would you rather invest a ton of time into porting Android to another SoC and write completely new SDIO, radio, power-management, etc drivers while your competitors come out with 3 new phones?

I would rather see you upstream all your changes (including userspace), then TI or other phone makers can upstream and GPL all their changes (including userspace tools) and in the long run Android runs on anything that the Kernel runs on. There is a reason it's called a community. Rather that build everything yourself why not get upstream so that all the work others are doing can be used. That way if some new SOC maker comes to Google and says "we want you to use our chip" you simply tell them to get "X" into the Kernel and then you aren't dependent on one supplier/IP platform. I think you guys have fully missed the point of FOSS.