OpenMoko [LWN.net]

OpenMoko

Posted Oct 17, 2009 6:06 UTC (Sat) by laf0rge (subscriber, #6469)
In reply to: OpenMoko by daniels
Parent article: Maemo Summit 2009: Fremantle, Harmattan, and N900

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.

to post comments

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.