Time for some Motorola merging!

So I've been AFK for awhile again… What can I say? Work has been hectic, so sue me. Actually, on second thought, I shouldn't make that suggestion, since it seems I can't go a day without reading some news about someone suing someone else over some ridiculous trademark or patent claim. Alright everyone, all together!

SSSSSSSSSSIIIIIIIIIIIIIGGGGGGGGGGHHHHHHHHH

It's important to point out that I haven't been gone from android entirely, just quiet lately as I've been busy with other things as well, and the fact of the matter is, when testing doesn't go well, you simply won't hear about it!

So what HAVE I been working on? Well let's get right to it.

Oh fragmentation... how I loathe you >.>

So there's been a problem with the DX, D2, etc builds, and that's fragmentation. They both use nearly identical code bases to implement hijacking and 2nd-init, with the only difference being how they “brand” the packages. This is just stupid and that was brought to my attention when I noticed that the droid2 repos had fixed some typos and a calling error in my hijack code.

The present solution was to simply cherry-pick their commit over into the shadow repo, but when I was thinking about doing that it dawned on me how ridiculously inefficient that is (I for one hate duplicated code).

The solution? It was time for a device/motorola/common repository. This is a common repo from which all Motorola devices can inherit. This repo implements all of the hijackery and 2nd-init magick required to boot on devices like shadow and droid2, and simplifies their implementation to simply having their product makefiles inherit from device/motorola/common/common_hijack.mk! Much better if you ask me!

2nd-init with a GB kernel?

So while doing this merging stuff, I decided to take a look at 2nd-init and why it wasn't working with the GB kernels. I remembered the problem being that GB kernels removed the ability to execute code on the heap (which is where 2nd-init was injecting its code), so the solution was to just inject the code somewhere near the end of the code space (which is of course executable).

So anyway, I was working on some compile-time settings that make 2nd-init either work on a froyo kernel (w/ exec heap) or a gb kernel (w/o exec heap), when it dawned on me, why choose between the two?

After a few minutes of coding and testing some theories, I now have a wonderful reincarnation of 2nd-init that will work on kernels regardless of whether or not the heap is executable. Essentially it does an autodetection on whether or not heap space is executable, if it is it uses it (because that's the smart thing to do), and if not it attempts to use the code stack.

What does this mean? It means that we now have a smarter 2nd-init that isn't as tied down to what kernel it's being put on. The new 2nd-init was tested using both a froyo and gb kernel, and both systems booted, though the gb kernel system boot-looped (which was expected, as the system libraries were still based on the froyo kernel, and thus interfaces were all screwed up). The point is, that 2nd-init functioned on both systems regardless of the kernel version, which is a plus!

I also modified some other aspects of 2nd-init to just generally clean things up and make it throw less compiler warnings and whatnot. I continue to dig through this wonderful piece of magick on a regular basis and enjoy seeing what else there is to be done with it.

Droid 2 Global merging

I've been working with RevNumbers and x13thangelx to get the droid2we vendor merged into CM since it's basically in the same state as the shadow and droid2. They will be maintaining it once it is merged and it will also utilize the new motorola common repo! This is good news for all you D2G users out there!

This is yet another thing we're waiting on merging to take place in order to move forward (it's ugly to apply patches and whatnot while waiting on merges to occur ><).

Thunderbolt and the horrors of LTE

So I've been neglecting to do the task I was charged with a few months ago, namely coming up with a proper merge path of LTE into the core of CM's framework. Part of me was hoping Motorola would do it and save me the trouble, but it's been put off long enough.

Starting next week I'll be taking on the endeavor the straightforward way. I'm talking a giant multi-thousand line diff of the entire damn repo with CM's and a manual line-by-line merge. It may take some time but it will ultimately do the trick and I can't think of a better way to do it that doesn't involve a bunch of guesswork.

Either way, don't expect results immediately, but there will be work done on it!

Droid X CM7 GB kernel release?

Soon young grasshopper! Soon! The whole point of the 2nd-init GB support and kernel merging nonsense you read about earlier (you did read all of this, didn't you?) was to work towards getting the CM4DX kernel updated so people don't have to flash back to the old froyo SBFs to get things functioning.

Now that we have a proper 2nd-init that doesn't give a crap what kernel it's running on, the next step is to determine a good upgrade path from the existing CM4DX to the new variant with an updated kernel. This will involve LOTs of testing, and updating libraries and files, which could take a bit to determine, but should be on the horizon.

Who knows, maybe we'll get lucky and updating the libs will fix some of the existing camera problems? (maybe? please?)

Droid X All-In-One fixer merging

Yep, still more merging! I've decided it's about time to merge in some of these fixes that razorloves has been so nice as to keep going!

First will be the torch fix, as that one really should have been merged ages ago. Problem with that was the ownership of the sys files torch uses were assigned to the “system” group instead of the “camera” group (DOH!).

Next will likely be the camera stuff, but I need to look at it a bit more. The only thing holding back the camera fix from merge all this time is the requirement of a prebuilt libstagefright, which is an ugly hack that is bound to break things somewhere. The idea is to try to fix it so that at least libstagefright can function from source with moto's libs.

Before all of this though I want to get CM4DX upto GB kernel status, because who knows what weird things will result from using the updated libraries! (oh goody)

Congratulations to Cyanogen

I hadn't said it publicly so I just wanted to give a quick shout-out to congratulate Cyanogen on his recent hire at Samsung! It's always nice to see a fellow developer in communities such as these make good on all of the hard work they've been doing, especially when that means getting a job continuing to do the work they love!

Kudos!

Um... conclusion

Yeah I didn't really know what to call this section and after about 26 seconds decided that it didn't matter anyway.

That is pretty much all I have for right now. Once again I put off blogging forever and now have written the equivalent of a short story. (must remember to post more frequently to avoid this…)

Thanks for all the support and it's about time to get some serious business done again!

tl;dr

Please don't sue me! (it seems to be the “thing to do” these days >.>)

Created a device/motorola/common repo for consolidation of Motorola stuffs.

2nd-init is now kernel-neutral. Down with segregation!

Droid 2 Global will hopefully be merged shortly.

I will be re-starting my LTE merging efforts next week.

Droid X will get a GB kernel-based release soon, needs moar testing.

Droid X will get some more fixes merged soon (torch, camera, etc).

Grats on da job, Cyanogen!

Android = Serious Business O.O

Comments

 
blog/2011-08-18/time_for_some_motorola_merging.txt · Last modified: 2014/05/13 12:36 (external edit)
 

Hosted on Microsoft Azure Powered by PHP Driven by DokuWiki RSS Feed

© 2011 Austen Dicken | cvpcs.org