You’ll have to pardon me while I go on a bit of rant here. Hopefully you’ll hang in there and at the end of this have a better understanding of “why” the Droid 3 is in the state it’s in and where it may be going next.
As most of Droid 3 owners are well aware by now, Motorola has officially crushed our hopes and dreams by saying “NO.” to any ICS upgrade.
Shocking? For many I would imagine, yes. The device is a spry 10 months old. But, over the last few months, I tried to warn people that I couldn’t see Motorola putting in the time to make ICS run correctly on the Droid 3. What exactly did I mean by that? Or perhaps I should just say “Why won’t Motorola be upgrading the Droid 3 to ICS”?
The answer is astonishingly simple: RAM.
Add to that, how the OMAP4 design has changed from Gingerbread to Ice Cream Sandiwch and it can provide a rather bleak picture of how difficult it has been to bring functions like HD codecs and full camera support to the device.
I know you’re seeing OMAP3 phones with something like hardware acceleration and usable codecs for viewing video and possibly a video camera running at 10fps. And you’re saying: Why not us? What have you been doing with the Droid 3? And why would having 1GB of RAM be so important anyway? Isn’t most of it wasted?
–
Let’s start with the RAM issue. Yes, most of it is waste… in Gingerbread. However, the way ICS is supposed to run on the device there is over 320MB of memory which is allocated by the OS for use by HD codecs, and graphic texture memory. Some quick napkin math = not enough left for the OS (would need about 250MB+ for a bare bootup in most cases).
What the hell happened to the RAM in ICS? Why so much? It all comes down to the initial source code provided by Texas Instruments. If you’re a company like Motorola, you take a look at what TI has done setting up OMAP4 devices for a specific version of Android. From there you pickout a nice starting point in their code (we’ll call this starting point: 4AI.5 which equates to ICS 4.0.4)
To use the 4AI.5 kernel source as it comes from TI, you need a device with 1GB of RAM. There are more than 3-4 places in the source which have hard-coded memory maps which make the assumption of 1GB of usable RAM. And it get’s worse. Not just the kernel is mapped for 1GB of RAM. There is a second set of source that is also provided by TI for compiling the binary which runs on the HD codec processor (called Ducati in our device). That source is ALSO mapped for 1GB of RAM.
Let me ask you a question? Have you seen *ANY* OMAP4 phones w/ 512MB running ICS yet? No. As a matter of fact, there is only 1 device in existence running an official version of ICS, and thats the Archos Gen9 80 tablet. And it’s unique in that Archos took the time to develop a completely custom way of running memory management in ICS to support 512MB of RAM. (I’ll bring this device up later).
With the current onslaught of phones and technology progression, MOST companies like Motorola just don’t have the time to redesign the 4AI.5 kernel to make it work with 512MB RAM. They have bigger fish to fry, and more devices to sell.
Q: So, we’ve established why in theory having 1GB RAM makes it easier for a company like Motorola to bring an ICS update to the device, but… that doesn’t really explain the lack of HD codecs and full camera support for the current ICS ports for Droid 3, Bionic, RAZR and Droid 4 that I’ve been working on. After all, we’re not using a true ICS kernel. We’re using the original Gingerbread kernel! Aha! We don’t *need* 1GB RAM for that!
A: Quite right. And the current Gingerbread HD codec binaries which get loaded onto the Ducati processor also don’t work with the ICS operating system .. at all. In general, the Gingerbread binaries work in Gingerbread structures called “overlays”. In Ice Cream Sandwich, the entire graphical sub system works on “native Window” structures instead. — Uh.. what?
This means you can’t use Gingerbread ducati binaries in ICS. They don’t talk the same language.
So how does the current camera hack work? It’s exactly just that. A hack. It uses a pre-compiled Gingerbread camera library to read from the Gingerbread ducati binary what the camera is viewing at that particular moment. And then it shoves it right on to the frame buffer, bypassing the entire OS. This also means stuff that uses the camera like bar code scanners, Google Goggles, etc. All will not work.
Q: So why does it seem like nothing has been happening over the last few months?
A: Simple. There really hasn’t been much happening.
That’s not to say I haven’t been looking at options or running tests on viable paths to take to get those features worked out. They just haven’t been working and/or end up being too much work for 1 guy like me to do.
Case in point: We’ve established that KEXEC can work on the Droid 3. That means we can load a new kernel. What would it take to get a kernel loaded that has support for all the “stuff” we’re missing from ICS? Answer: “A lot of work”. It took me 4 months of work to get a usable kernel (as it stands today) for the Kindle Fire. And it’s not even done. Imagine adding to that: a camera, a 3G modem, bluetooth, and other devices that the Kindle Fire doesn’t even have. It might take me 6-7 months to bring a full fledged ICS kernel to the Droid 3.
Q: But, perhaps, I don’t have to do a FULL ICS kernel. What about “back porting” just enough of the kernel to get Syslink 6.0 running so that we can load the necessary binaries to run HD codecs and camera?
A: Great idea! However, remember that whole 1GB RAM issue? There is only 1 ducati binary in existence (that I know of) that runs on 512MB and that’s from the Archos Tablet I mentioned before .. and it only has a 720p front-facing camera. So there’s a very good chance you can’t use it for full camera support and isn’t that 1/2 the reason for re-writing the kernel?!
The last option would be to hack in some kernel “modules” which are much smaller than a full kernel and somewhat easier to manage. And some of you may have seen me working from time to time on different versions of these.
To date: I’ve never been able to load any ducati binary on the Droid 3 using kernel modules. It’s a brutal process of ripping out routines and replacing them w/ Gingerbread counter parts and in the end, I don’t know if it will ever work.
But, since I’m just 1 guy and not a whole army of coders who work full-time on it, this last option is still probably the only viable option at the moment. And even then, I still *need* Texas Instruments to probably step up their support for 512MB devices and create a new ducati binary which we can run which has full camera support, etc.
Q: What *IS* the future of development for the Droid 3?
A: While I will continue to tinker with backporting enough function from the ICS kernel to make a usable ICS build … the truth is, we’re probably looking at CM 7.2 as a decent alternative where you can actually use the majority of the device’s functions.
Q: When will I start work on CM 7.2?
A: Probably as soon as things settle down w/ the RAZR and Droid 4 MotoICS leaks (few weeks).
And that’s it. /rant-off. I hope you can all keep in mind that I do this at night, on weekends, during holiday breaks and while I sleep sometimes.
I’ll try and do a better job of keeping everyone in the loop. :)
