Maemo Summit 2009: Fremantle, Harmattan, and N900 [LWN.net]

Maemo Summit 2009: Fremantle, Harmattan, and N900

Posted Oct 14, 2009 20:16 UTC (Wed) by n8willis (subscriber, #43041)
In reply to: Maemo Summit 2009: Fremantle, Harmattan, and N900 by cry_regarder
Parent article: Maemo Summit 2009: Fremantle, Harmattan, and N900

Note: Jake didn't write that, I did.

I don't in any way discount your experience or rating of OpenMoko; I just base my assessment of the usability of the platform on the totality of the public reviews -- which, regrettably, are on the negative side. Like I said in the article, I have a ton of respect for what the project set out to do.

In my personal opinion, the real distinguishing characteristic of it was always the open specs for the components, it wasn't the shine of the software. But they did choose to pursue writing the OS and designing the hardware device from scratch, which might have been too much. Given the company's troubles, I don't think the future looks particularly bright for the project, but hey, maybe it will turn out okay after all. I follow it closely; we'll see where it heads. In the meantime, though, the evaluation of the masses is that it isn't ready for prime-time, non-hacker usage. Still, if you like it, that's great. It's good ot have options.

Nate

to post comments

OpenMoko

Posted Oct 15, 2009 5:08 UTC (Thu) by laf0rge (subscriber, #6469) [Link] (7 responses)

Just let me address that point that OpenMoko "chose" to develop the OS and the hadware from scratch:

The way the semiconductor and cellphone hardware industry works is so closed and proprietary that you are forced to develop your own hardware if you want to do anything that is even remotely open on the system level.
First of all, unless you put somewhere between USD5 to USD10 million as 'entry fee' on the table, the semiconductor vendors will not even start talking to you about their GSM/3G baseband chips.

There is no documentation on the majority of the components used in modern smartphones. If at all, it is under NDA's that don't permit you to write open source software such as drivers.

Based on this closed-ness in the hardware industry, you do not have much choice but to design your own hardware, based on a subset probably 1-5% of the components that the semiconductor makers offer :(

Regarding the software: When OpenMoko started out, there was no existing Linux based stack that fulfilled even only some of the requirements like "try to not deviate too much from the linux desktop world", "proprietary software is not acceptable" and "support for traditional phone applications like voice call, sms".

Sure, Openmoko made many mistakes... but developing the hardware was a burden and not a choice, as was development of a lot of the software.

Regards,

OpenMoko

Posted Oct 17, 2009 3:20 UTC (Sat) by daniels (subscriber, #16193) [Link] (6 responses)

Surely the OMAP having open specs has put a pretty big dent in the 'nothing that runs in any modern smartphone has open specs' argument? :)

OpenMoko

Posted Oct 17, 2009 6:06 UTC (Sat) by laf0rge (subscriber, #6469) [Link] (5 responses)

About the Omap:

While the application processor is an important component, it is only _one_ of many components in a smartphone. You have to think about the specification of things like the power management IC, the audio codec, the camera sensors and any other peripherals.

Oh, and talking about the OMAP: It is one of those parts that use an Imagination PowerVR GPU, which is the equivalent of nVidia in the embedded space: You cannot imagine any company that is more closed. Even as a device manufacturer, even under NDA, you will never get any bit of source code of the driver...

Most importantly, even though the 2G/2.5G/3G/3.5G baseband runs a proprietary firmware (like your wifi and bluetooth), the external interface/protocol needs to be documented.

If you look at people trying to get a truly open source software stack to work on any modern smartphone, the modem interface is where you waste months of reverse engineering, typically with very little success.

The Palm Pre is one example, where an undocumented binary protocol is used. There's a whole team looking at the binary stream going back and forth, without big success so far.

OpenMoko

Posted Oct 17, 2009 6:53 UTC (Sat) by daniels (subscriber, #16193) [Link] (4 responses)

The audio, camera, and power management parts shipped with most OMAP3xxx parts also have completely open specs. Combined with an open driver for the N900, basically all you're missing is the baseband code (which makes it no worse than the Moko in many respects), the SGX driver, the 'energy management' (read: battery charging logic) code, and the bootloader. While it's true that there is no open source SGX driver, there's no real alternative for mobile 3D, so slating device manufacturers for that seems a little unfair.

You'll note that CSD as shipped with the N900 is closed, but ofono is open, and Nokia are heavily involved with the project, aiming to replace CSD with an open alternative, so.

Assuming you don't want 3D, and are prepared to ignore the bootloader (given that it's really just a BIOS that can load a Linux kernel) as you would a BIOS on a PC, then all you're missing is the battery-charging stuff on the N900, at least when ofono arrives. That's not perfect, of course, but still seems pretty damn good to me.

OMAP, N900 and openness

Posted Oct 17, 2009 7:46 UTC (Sat) by laf0rge (subscriber, #6469) [Link] (3 responses)

1) audio, camera, pmic:

I cannot comment on this specifically for the N900, as I don't have a N900 and have not seen even something as simple as a block diagram of the hardware or a list of the major parts that are in it. As soon as somebody provides that or high-res PCB photographs, I'm happy to verify if that is the case. From my past experience with all the phones that I've spent time reverse engineering, it has not been true!

2) modem baseband firmware / interface

as stated, I can live with the proprietary baseband modem software (just like I have to live with proprietary GPS and bluetooth firmware), as long as the interface is documented.

Yes, with PhoNet in the kernel there is some code. What I've heard from a number of people who have worked with nokia firmware based modems, they tell me that PhoNet in the kernel is incomplete.

Also, I have never seen any documentation on that protocol, neither the lower layers (PhoNet), nor the higher layers that are being implemented in ophono now.

3) battery charging logic

that sounds like a really strange bit to keep proprietary. I doubt there can be many trade secrets in there that need to be hidden. So it is completely unacceptable to have something as simple as that proprietary. However, if the hardware is reasonably well documented (i.e. which gpio is attached to which external piece of hardware, how does the battery charger / coulomb counter work, ...) then somebody can write a replacement.

So far, I yet have to see any of that for the N900.

I think there is a common misunderstanding of people who mainly work in application space about how many hardware details you really need to be able to actually write your own free software drivers without reverse engineering. No offence, this is not about you personally but about many of the statements I see in the community.

4) Lack of open source SGX driver

Unless the various companies using SGX cores don't _demand_ a driver solution that is in line with the regular linux graphics architecture and that is at least open source 'friendly', Imgtec will certainly not change.

All I'm seing is that Intel has been hit hard by the Poulsboro debacle, as well as everyone who builds products on that chipset. I know of other semiconductor makers who are struggling very hard with their customers requests vs. what Imgtec can provide.

I also know that the TI OMAP contains the Imgtec SGX core based on customer request... I presume that customer was Nokia in the first place.

5) serial console / jtag

Another thing that is key for actually doing efficient/reasonable system-level development on any hardware: serial console and jtag pinout. This information has never been officially released by Nokia,
not even for the previous n770/n800/n810. I know somee people have discovered the serial port, but where is JTAG? Doing kernel-level or bootloader work without JTAG is an order of magnitude harder. If Nokia cared about enabling a community to work on that level of their product, they should disclose that information.

On the general openness of the N900:

_If_ it is really true what you are writing, i.e. the documentation is all there and there are no other closed bits apart from bootloader, battery charging, SGX driver and baseband firmware: Yes, it is more open than most what we've seen before in that market. But given the hype that existed about every new device, including the previous Nokia nXXX products, I am extremely careful with my enthusiasm. So far, all of them have not really been very exciting from an openness point of view.

Battery charging "logic"

Posted Oct 22, 2009 14:28 UTC (Thu) by forthy (guest, #1525) [Link] (2 responses)

Having seen the data sheets of several battery charger chips for mobile phones, I can't see what's that fuzz about (the data sheets are available). These chips have an extremely simple interface: three logic pins, all open drain logic: enable, power present, charging. There's little possible magic behind driving these three pins.

What's more interesting is a charge tracking circuit - and the code behind that. That code might have patented algorithms inside, so it's probably not easy to release it.

Battery charging "logic"

Posted Oct 24, 2009 10:14 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

The people who sell those circuits also claim that they are protected for
health and safety reasons: if they released the code and someone changed
it and a battery exploded...

... and that's why nobody ever uses Linux or free software in
life-or-death situations. They rely on reliable code from vendors who can
be sued for endangering life and limb, like Microsoft.

(But perhaps that's not entirely 100% accurate.)

Battery charging "logic"

Posted Oct 24, 2009 21:11 UTC (Sat) by anselm (subscriber, #2796) [Link]

It turns out that the Microsoft EULA doesn't allow you to use Windows in life-or-death situations, such as nuclear plant or air traffic control. This tells us that Microsoft doesn't think their own code is good enough for these applications -- at least not to the point of putting their money on it.

On the other hand, nobody ever successfully sued Microsoft over a bug in their software.

Openmoko inc. != Openmoko project

Posted Oct 15, 2009 6:27 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

I have to note even with the off-topicness of it that the project is not dependent on the company. With gta02-core we are seeing a completely new area being pursued, and in that sense the open hw was really the number one thing Openmoko Inc. managed to create. New companies can arrive to support gta02-core, but also the community itself is able to do further development of new, open phones, created with fully free software tools - which I think is pretty radical in the longer term perspective.