Hidden power management, binary blobs? [LWN.net]

Hidden power management, binary blobs?

Posted Dec 31, 2008 2:23 UTC (Wed) by ajross (subscriber, #4563)
In reply to: Hidden power management, binary blobs? by tajyrink
Parent article: The Android Dev Phone 1

The wifi driver is free, although not in the kernel tree. Source
is available at:

http://android.git.kernel.org/?p=platform/system/wlan/ti.git;...

Non-free parts of the system that I can remember off-hand are:

+ Everything running on the ARM9 "baseband" CPU (i.e. the radio
side of the world) is a black box. Only the ARM11 core is
exposed.

+ The ATI Imageon OpenGL-ES implementation is proprietary.

+ Access to the DSP cores on the MSM7k chipset is undocumented.
The kernel drivers are free but do nothing but validate command
streams generated by closed userspace libraries (e.g. video
codecs).

+ Many of the Google applications (the ones not distributed with
the SDK) are closed, including the market and maps clients.

(Log in to post comments)

Hidden power management, binary blobs?

Posted Dec 31, 2008 8:44 UTC (Wed) by tajyrink (subscriber, #2750) [Link]

Ok interesting, they have a separate ARM CPU for GSM etc. purposes. I wonder if it functions as an external device transparently or if it requires something on the ARM11 side.

Regarding power management, I referred to this Matthew Garrett's quote of the week about Android's power management being done using tokenized dead mice passed through a wormhole, which sounds a bit non-optimal: http://lwn.net/Articles/306531/

Hidden power management, binary blobs?

Posted Dec 31, 2008 14:05 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

Having the gsm hardware running on an entirely separate core is pretty standard - it avoids the need to have a realtime OS on the application side. Normally it ends up being presented as some sort of serial UART that's then controlled using extended AT commands, so there's no real magic needed on the host.

From the power management point of view, the drivers are open, the power management core is open and the application layer that interacts with their power management interface is open. I think it's a pretty dreadful and unscalable solution (suspend sequencing is implemented by devices registering callbacks with priorities, so dependencies need to be explicitly stated rather than being implied by the device tree) and I still don't have any idea what problem it's trying to solve, but they're certainly not hiding anything secret there.