Closed Bug 1080483 Opened 8 years ago Closed 6 years ago

[META] Allow B2G to build using device repos designed for CyanogenMod


(Firefox OS Graveyard :: GonkIntegration, defect)

Not set


(Not tracked)



(Reporter: afarden, Unassigned)




(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:

During a conversation at xda:devcon, Asa Dotzler expressed his desire to provide builds of FxOS for abandoned Android devices with known security issues.

The biggest hurdle to this is the lack of available device repos that work with the B2G build process.

Probably the easiest way to overcome this will be to make B2G compatible with existing device repos that are designed for CyanogenMod.

There are currently 13.5 million active CM users, literally hundreds of devices that are compatible with it, and an army of developers at XDA that would be much more interested in B2G if it were compatible with their existing projects.

around 10 commits were taken from CyanogenMod and applied to the B2G /build repo to work with a CM device repo. The major differences are how the kernel is built and how the boot.img is created.

Besides some device specific patches elsewhere, this is the bare minimum to successfully build with a repo designed for CM. 

If there is interest and willingness to accept patches that allow building with CM repos I can investigate this further.
Flags: needinfo?(mwu)
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(fabrice)
Flags: needinfo?(asa)
Flags: needinfo?(lissyx+mozillians)
Confirming, this would be very welcome. I'm just not sure in which component it would be better to file it, maybe "GonkIntegration"? The "General" component is very generic and bugs that stay there for too long tend to fall through the cracks.
Ever confirmed: true
I support the idea, but I defer to mwu on the implementation details.
Flags: needinfo?(fabrice)
Component: General → GonkIntegration
Flags: needinfo?(mwu)
To handle a CM device repo we need to account for the lack of scripts normally found in device/qcom/common.

The first four patches from the branch above:

1) "QCOM helper macros" - CM devices do not use QCOM's device/qcom/common repo, so we include these definitions here.

2) "Generically define own headers" - CM devices often include device specific header files, such as a lights header file in a device specific repo that is used by a liblights included in a common device repo.

3) "Inline kernel building" - CM devices do not reference like qcom/common does, but each device simply defines a defconfig and the location of the kernel sources. This script takes care of building and installing the kernel and all modules.

4) A small fix to ensure the correct OUT_DIR for building the kernel.

How these interfere with a 'regular' QCOM build I do not know, but I can make and depend on "BUILD_B2G_WITH_CM_REPO := true" or something similar.
Adam, do you mind givng the steps I should follow to make sure your changes are okay with CAF repos?
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(adam)
Essentially just run the normal build (lunch/make) with these five commits included:

It's mostly about making sure the kernel is build correctly, and that the included definitions don't interfere with the same definitions found in device/qcom/common.
Flags: needinfo?(adam)
(In reply to Adam Farden from comment #5)
> Essentially just run the normal build (lunch/make) with these five commits
> included:
> It's mostly about making sure the kernel is build correctly, and that the
> included definitions don't interfere with the same definitions found in
> device/qcom/common.

Testing on my Flame KK tree:
> cd build/
> git remote add recaf
> git fetch recaf 
> git checkout recaf/B2G-4.4-CM 
> cd ../
> ./
Flags: needinfo?(lissyx+mozillians)
So it early fails because of some bad path:
> /bin/sh: 1: cd: can't cd to ..//home/alex/codaz/Mozilla/b2g/devices/Flame/B2G.KK/out/target/product/flame/obj/KERNEL_OBJ
Flags: needinfo?(adam)
Removed |core/tasks/| as suggested, everything has been built and B2G boots.
Hey Adam, I have a Samsung wave, that has been ported to CM. I'm available to test things if you want. 

Right now, I'm stuck in the build process with this error:

> build/tools/fs_config/fs_config.c:29:47: fatal error: private/android_filesystem_config.h: No such file or directory
> compilation terminated.
>build/core/ recipe for target '/home/augustin/workspace/mozilla/b2g/src/out/host/linux-x86/obj/EXECUTABLES /fs_config_intermediates/fs_config.o' failed
> make: *** [/home/augustin/workspace/mozilla/b2g/src/out/host/linux-x86/obj/EXECUTABLES/fs_config_intermediates/fs_config.o] Error 1
Cool, I was able to compile FlatFish using your b2g-4.2.2_r1 branch.
Love this initiative, I'll help with it :)
Ok, this branch was the very same we use in our repos, no patches for CM compatibility (... thanks Alex for warn me)
Bump to Adam for input on comment #7 and #9.
This sounds awesome, how can I help?
The repos linked above got deleted. Sorry about that.

Most of what I had to port was CM build system for kernel, QCOM flags etc.

CM's Lollipop build repo is now very different compared to when I was working on KK. However we have a working L build system so I cherry-picked the b2g-5.1 branches on top of CM's 12.1 branches (specifically the stable/cm-12.1-YOG4P branch).

You can find the repos at including manifest.

Build of B2G is working fine with CM build scripts, except I was trying to build a 64bit device (CM's tomato) which is not yet supported (see bug 1187826).

I'll be on holiday until mid August so I won't have any time to look at this further until then, at the earliest.
Flags: needinfo?(adam)
I finally got a chance to test the repos with a known good 32bit device from CM.

To put it mildly, it was a disaster. Gecko is in no way compatible with CM 12.1, a massive amount of work needs to be done to if you want to go that way.
Can you elaborate a bit on the gecko issues? I would rather expect gonk level changes.
Actually after trying to solve the issues in Gecko there were only two. They just happened at the beginning of Gecko build, it was late and I simply feared it would cascade into many.

Anyway it's caused by these two commits in CM repos:

The first is a forward-port of old Android functionality. Quick hack:

Add the extra "bool isCpuConsumer" here:
Remove "#elif ANDROID_VERSION < 19" here:

The second was also an easy hack fix:
Add: "sp<MetaData> vMeta = new MetaData;" #L52
Change: "canOffloadStream(meta, false, false, AUDIO_STREAM_MUSIC))"
To: "canOffloadStream(meta, false, vMeta, false, AUDIO_STREAM_MUSIC))"

Mozilla's bluetoothd and nfcd also don't compile, I simply removed them for now to get something to flash.

After that, B2G builds! However after flashing the images there is no display...

02-19 15:30:01.369: I/Gecko(1583): [Child 1583] WARNING: pipe error (10): Connection reset by peer: file /home/adfa666/B2G/gecko/ipc/chromium/src/chrome/common/, line 459
02-19 15:30:01.369: I/ServiceManager(296): service 'media.audio_flinger' died
02-19 15:30:02.840: E/sdcard(340): missing packages.list; retrying
02-19 15:30:05.839: E/sdcard(340): missing packages.list; retrying
02-19 15:30:06.520: I/mediaserver(1595): ServiceManager: 0xb58700c0
02-19 15:30:06.520: I/AudioFlinger(1595): Using default 3000 mSec as standby time.
02-19 15:30:06.520: I/ServiceManager(1595): Waiting for service batterystats...
02-19 15:30:06.639: I/Gecko(1602): [1602] WARNING: Tried to RegisterCallback without an AtExitManager: file /home/adfa666/B2G/gecko/ipc/chromium/src/base/, line 40
02-19 15:30:06.639: W/(1596): could not open framebuffer
02-19 15:30:06.649: I/qdutils(1596): PartialUpdate status: Disabled
02-19 15:30:06.649: I/qdutils(1596): Left Align: 0
02-19 15:30:06.649: I/qdutils(1596): Width Align: 0
02-19 15:30:06.649: I/qdutils(1596): Top Align: 0
02-19 15:30:06.649: I/qdutils(1596): Height Align: 0
02-19 15:30:06.649: I/qdutils(1596): Min ROI Width: 0
02-19 15:30:06.649: I/qdutils(1596): Min ROI Height: 0
02-19 15:30:06.659: D/qdutils(1596): int qdutils::getHDMINode(): HDMI is at fb1
02-19 15:30:06.659: I/qdhwcomposer(1596): Initializing Qualcomm Hardware Composer
02-19 15:30:06.659: I/qdhwcomposer(1596): MDP version: 500
02-19 15:30:06.659: D/qdutils(1596): int qdutils::getHDMINode(): HDMI is at fb1
02-19 15:30:06.659: D/qdhwcomposer(1596): hwc_getDisplayAttributes disp = 0, width = 1080
02-19 15:30:06.659: D/qdhwcomposer(1596): hwc_getDisplayAttributes disp = 0, height = 1920
02-19 15:30:06.659: E/qdhwcomposer(1596): Unknown display attribute 0
02-19 15:30:06.659: I/QCOM PowerHAL(1596): QCOM power HAL initing.
02-19 15:30:06.659: D/qdhwcomposer(1596): hwc_setPowerMode: Setting mode 2 on display: 0
02-19 15:30:06.659: D/qdhwcomposer(1596): hwc_setPowerMode: Done setting mode 2 on display 0
02-19 15:30:06.659: W/Gonk(1596): Could not open boot animation
02-19 15:30:06.659: W/Gonk(1596): Show solid color frame for bootAnim
02-19 15:30:06.779: I/GeckoConsole(1596): Could not read chrome manifest 'file:///system/b2g/chrome.manifest'.
02-19 15:30:06.779: I/ServiceManager(296): service 'display.qservice' died

How (or even if) you want to handle CM's quirks I'll let you decide.
(In reply to Adam Farden from comment #17)
> Mozilla's bluetoothd and nfcd also don't compile, I simply removed them for
> now to get something to flash.

Could you please file two bugs for these daemons (with compiler error messages) and cc me? I'd see if I can fix this.
Flags: needinfo?(asa)
Depends on: 1209096
Summary: Allow B2G to build using device repos designed for CyanogenMod → [META] Allow B2G to build using device repos designed for CyanogenMod
Depends on: 1211870
Depends on: 1212943, 1213311
Current status: sony-aosp-l devices can build with a CyanogenMod base.

*You need to patch shinano/yukon to disable the auto kernel build and specify the kernel directory, as CM as its own kernel build.
* Gecko needs to be aware of medi offload metadata, a quick patch for build is Bug 1213311
* B2G's bluetoothd needs a patch, progress is at Bug 1212943

So far no regressions...
OK enabling `BOARD_USES_QCOM_HARDWARE := true` on our sony-aosp-l devices is going to be... problematic.

All of these devices use linux 3.10 kernel, which QCOM officially uses only on its 64bit SoCs. AFAIK there aren't any msm8974 devices that use the 3.10 kernel in production.

specifically ionalloc.cpp in display-caf/msm8974 still uses `heap_mask` whereas aosp msm8974 and caf msm8994 both use the (correct) heap_id_mask.

CAF why you no fix your bugs everywhere?!?!
Attached file QCOM HAL Bootloop
Either using msm8994 HALs (which works on Android), or hacking the msm8974 HALs with the correct definitions leads to the exact same bootloop. The backlight briefly flashes and then switches off.

This is the likely cause of the problem.

A quick check of Flame-l CAF HAL and it is also HWC_DEVICE_API_VERSION_1_3

Android M is HWC_DEVICE_API_VERSION_1_4 for msm8994 so we will absolutely need to handle the new HAL for both CM devices and also if we want to use the new 64bit Nexus devices for M / aarch64 bringup.

Michael this is likely something that will need to be addressed soon anyway, not only for CM based ports.
Flags: needinfo?(mwu)
Sure. Can you stub out the new 1.4 things in gecko/widget/gonk and see how far it gets? Everything new to 1.4 should be documented in . Haven't looked at it too closely but we might only need to add some callbacks to hwc_composer_device_1.
Flags: needinfo?(mwu)
I remember CAF contributed some 1.4 work though - so I would be surprised if we're not compatible with 1.4. This stuff is all queried at runtime so there's no problems supporting more than one. IIRC we're compatible with 1.1 and up. Flame-l isn't actually based on the lollipop base that's going to ship, so it's not a good reference for this.
OK so I reverted the HAL back to v1.3 but with no change, it still boot loops. I'll continue looking elsewhere tomorrow.
Attached file Kernel Bootloop
I've tried various unsuccessful things, but there's no change. I'll have to start digging into what else is changed by `BOARD_USES_QCOM_HARDWARE := true` in the frameworks as it doesn't seem to be the display HAL's problem.
Reducing what BOARD_USES_QCOM_HARDWARE enables give me a successful build. sony-l devices now have functional video decode, no more green/purple!
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.