I’m trying to build cm-11 for the flame so we can run fennec on top of it.
I’m aware that it might be easier to build AOSP for it, but by the time I started it cyanogenmod seemed to be nicely documented and looked like the easier way from me. By now I am able build everything and I have all the device images.
The problem I’m facing is that neither the boot.img nor the recovery.img are bootable. I always get stuck in the bootloader. I got some help from @gerard-majax and I mad sure the dt.img is build and included in the final recovery.img.
I also tried to dissect the original recovery and my cm-recovery, but I can’t tell what is causing the issue.
An other thing I noticed while playing around was, when I extracted the original recovery from the flame and created a new recovery image with the extracted parts, the image wouldn’t boot either.
If I flash the original recovery everything works, if I flash the repacked recovery with exactly the same parts, it doesn’t boot.
This is probably a hint that something is missing. Can you diff the working and non working images?
What exactly should I diff?
I did abootimg -x recovery.img which gave me bootimg.cfg, initrd.img, zImage and then I created a new image with abootimg --create crecovery.img -k zImage -f bootimg.cfg -r initrd.img. Beside from that I have the cm-recovery.img and it’s ramdisk contents.
jovan@android-build-machine:~/flame_base_image$ abootimg -i recovery.img
Android Boot Image Info:
* file name = recovery.img
* image size = 8423424 bytes (8.03 MB)
page size = 2048 bytes
* Boot Name = ""
* kernel size = 5880520 bytes (5.61 MB)
ramdisk size = 1277913 bytes (1.22 MB)
* load addresses:
kernel: 0x00008000
ramdisk: 0x01000000
tags: 0x00000100
* cmdline = console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37
* id = 0x3ab62df2 0x3eee6236 0x0d54a8f1 0x072d4663 0x4e48926e 0x00000000 0x00000000 0x00000000
jovan@android-build-machine:~/flame_base_image$ abootimg -i temp/crecovery.img
Android Boot Image Info:
* file name = temp/crecovery.img
* image size = 8423424 bytes (8.03 MB)
page size = 2048 bytes
* Boot Name = ""
* kernel size = 5880520 bytes (5.61 MB)
ramdisk size = 1277913 bytes (1.22 MB)
* load addresses:
kernel: 0x00008000
ramdisk: 0x01000000
tags: 0x00000100
* cmdline = console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37
* id = 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000Doing so, where is your dt.img ? Look into B2G installer sources to check how it is handled 
This are the options which are passed to mkbootimg in the b2g-installer:
but I’m not sure how I should include the dt.img. As you can see in the image info, the recovery images both only consist of a kernel and a ramdisk. I extract these two parts an create a new image with them.
Yeah, device tree as a separate image is something that is from QC tooling, and I guess CM are re-using some of those. But AOSP back in those days would not have a way to set DT as QC tools.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1235459#c25
So CM’s mkbootimg supports the inclusion of an dt.img, therefore I tried to build a new recovery image from the parts I extracted from the original recovery image and the dt.img the flame base image provided. The result was a working recovery image!
This made me try the following other combinations:
- all the parts of the cm-recovery + the dt.img I built with CM
- all the parts of the cm-recovery + the original dt.img of the flame
1 is still not bootable, but 2 now starts to boot, the “ThunderSoft” logo appears and then the screen goes dark. Unfortunately adbd still doesn’t start and therefore I don’t know what went wrong, but this leads to the conclusion:
- the dt.img gets build, but not correctly. How can I find out what wents wrong?
- The recovery is still not functional, could I move the start of adbd to the beginning of init.rc to make sure it is running when the boot process gets stuck?
@TitanNano Will be better to start from AOSP. When I start to building android for flatfish I did the same mistake - trying to build CM first. Patches which working on AOSP not working at all on CM 
If you wish I’m OK to help with AOSP builds
@I just had to notice that is CM is dead now, so yea I guess thats the best idea.
Depends. CyanogenMod Is Dead, but Its Successor is Lineage OS (fork of the original CM)
yes I know but I think with all this it’s easier to just use AOSP
Yeap, all patches in android tree are based on AOSP source so you don’t have to fix all errors manually just identify the correct version of droid from manifest files Before few mounts I had build environment for flame but the repo is gone with my old HDD 
@TitanNano you have to start from pure AOSP. After that you have to add flame related stuff device/framework/vendor etc…
So i’m using android-4.4.2_r1 and this manifest:
<?xml version="1.0" ?>
<manifest>
<include name="default.xml"/>
<remote name="t2m" fetch="git://github.com/t2m-foxfone/"/>
<remote name="b2g" fetch="git://github.com/mozilla-b2g/"/>
<remove-project name="platform/hardware/qcom/display"/>
<project name="device-flame" path="device/t2m/flame" remote="b2g" revision="kitkat"/>
<project name="codeaurora_kernel_msm" path="kernel" remote="b2g" revision="t2m-flame-3.4-kk"/>
<project name="kernel_lk" path="bootable/bootloader/lk" remote="b2g" revision="foxfone-one-v1.4"/>
<project name="platform/vendor/qcom/msm8610" path="device/qcom/msm8610" revision="b2g_kk_3.5"/>
<project name="platform/vendor/qcom-opensource/wlan/prima" path="vendor/qcom/opensource/wlan/prima" revision="b2g_kk_3.5"/>
<project name="hardware_qcom_display" path="hardware/qcom/display" remote="b2g" revision="flame-kk"/>
</manifest>
What do you think?
Looks like ok
@Neo2SHYAlien I started building now, but I get this error:
make: *** No rule to make target 'system/bluetooth/data/main.conf', needed by 'out/target/product/flame/system/etc/bluetooth/main.conf'. Stop.
Do you know whats missing here?
@TitanNano Obviously system/bluetooth/data/main.conf missing from your files. Did you extract proprietary blobs from firefox os ? Usually this is done by script placed in device folder in your case extract-files.sh
Checkout for this file in the flame (mine is now battery off, and I’m lazy to charge it) If you dont find it just comment/remove this line in build file