So after some problems setting the build environment I successfully ran my first build. Repo sync is incredibly slow and unstable from my home network so I finally decided to run the build on a hosted server I have around.
Followed all steps from @NicoM’s wiki and finally got the build.
Now I’m wondering how to properly flash the resulting .img files as I’m pretty new to android’s partitions, filesystems and boot process in general. Is it necessary to flash the recovery.img? I’m currently using TWRP, can’t I just keep this? Or do I specifically need the one from CM?
I tried to use this commands (no recovery.img flashed):
The adb logcat not working may be caused by adb authentication (enabled by default). If the RSA key of the computer is not known (and it’s not since we just flashed with a fresh build) adb connection won’t work. adb Auth can be overriden adding this to default.prop:
ro.adb.secure=0
I will try to manually regenerate the boot.img with this modification and give it another try. Maybe then we could see the boot logs…
I also didn’t manage to make it work yet. I don’t know if there’s another way to debug the generated boot.img, but some virtual device/emulator would be useful for sure.
In the meanwhile I managed to have the repos synced on my desktop, so now I can do builds and deploy faster. I’m trying to play around with different .mk files and following the CM porting tutorial from scratch to get an idea of what we’re actually doing
I’m also looking at the Fairphone Open OS source as I think we could get some valuable info from there for the CM build.
@NicoM, @Roboe: Which prebuilt kernel are you using in this blobs folder? Did you extract it from the device? Did you also try to build from source? Could it be broken?
I’m also concerned about the partition scheme. I could not get a clear picture of which partitions and filesystems currently exist on the device. I read this should be on /proc/mtd or /proc/emmc, but neither of them exist on my device… I could however get some info from /proc/partitions and /proc/last_kmsg. Then I compared this to the recovery.fstab generated by extract-files.sh and it doesn’t make much sense to me.
I think we should take a closer look to the files generated by extract-files.sh as there’s a lot of stuff there that might be breaking the boot.
So after several tries with re-assembling different boot.img files (for example I tried to use the kernel from FP Open an re-assemble the image) still couldn’t make it work. I found out several things tough:
After running a build I tried to run the images with emulator. This complained that system.img uses yaffs2 filesystem. I read yaffs2 is used in older devices and newer ones use ext4 (see more later on this post). I tried to move it into a ext4 filesystem and reassemble the image. emulator does not complain anymore but the system still doesn’t boot. I’m not familiar with AOSP debug, but this tool could help us with debugging the build.
Then I tried to use stock boot.img from FP Open with the system.img I built. Not surprisingly, the system doesn’t work but it restarts itself after a few seconds into recovery mode. When I use the boot.img from my build it justs gets stuck on the Fairphone logo screen (no reboot). This tells me somehow our boot.img breaks even before trying to load system.img, maybe?
I also tried to build with brunch fp2 instead of breakfast m8 and mka. This generates a cm-12.1-xxxxxxxx-UNOFFICIAL-fp2.zip file which contains all the image files and would allow to install from the recovery or the Updater app without using fastboot. This complained about a wrong recovery.fstab and exited with error (the file syntax in this file is not even correct). In my previous post I assumed this file was generated by extract-files.sh, but I realized later it comes from @Roboe’s git repo. Then I extracted the recovery.fstab from FP Open OS recovery.img and and it looks completely different:
I used this file and the build was successful and the zip generated. However, when I try to install the zip from recovery it complains about:
This package is for device fp2; this device is FP2.
I’m wondering if the device name we use could be also breaking things, but not really sure how to change this. FP Open uses “FP2” as device name instead.
Looking closer to the recovery.fstab extracted from FP Open in I see it uses ext4 for the system, cache and data partitions. Then there’s four emmc partitions: boot, bootselect, recovery and misc. I’m wondering if the problem might be related to the fact we’re not using the right filesystems/partition layout for our images.
I’m afraid I don’t have the knowledge to go much further, as I see many variables and steps that could affect the resulting images and many of these I don’t completely understand. Hopefully someone else with more experience can provide insight on any of these.
What makes me sad a little is the missing support from Fairphone officials that should also be interested in another working alternative operating system :-/.
First of all thanks for the great work you are doing!
I don’t have any experience with building roms, but I would like to contribute if I can. I will set up my build environment this evening so I can try to compile the image myself. This way at least I could help testing.
I get your point and I think some support from Fairphone would certainly speed up things. However, from my understanding Fairphone as a company can’t focus their business on creating AND maintaining 4 or 5 different OS for a single device. It’s already great that they released the code for the Fairphone Open OS and delivering regular updates for both the standard and Open Android versions…
This is already a big step forward. We can use this as a reference to build a CM port (which is indeed based on Android). Actually is one of the things I’m currently looking at. Take in account that most manufacturers don’t even provide any source or proprietary binaries, and as far as I know CM images have been always built and maintained by the CM community, not the manufacturers.
I think it’s not that they’re not interested, it’s just that they cannot afford to hire a whole team of developers to port every ROM out there to the FP2. It’s just a too big investment in time, work and money for something that maybe only a few users would potentially use.
From my perspective I think the work has to be done now by the community. If eventually we manage to have a more or less stable CM running on the FP2 we could attract more developers, users and the company itself into it, but I would not expect it to be the other way around.
@Roboe: Good! Sometimes I feel I’m just trying random things without fully understand what’s going on, but I guess it takes some time to get familiar with the whole thing. Hopefully you can find out something else.
@Pentanch: Thanks for trying! Any contribution/feedback is welcome. I also never built roms until a few days ago, nor I am an expert in Android stuff, but I hope if everyone contributes with their part of knowledge we could make things work.
I have a few questions… Which images did you try? FP2 images? emulator is contained in the Android SDK or where?
I tried this too. I don’t know if any official boot.img should work. FPOS one doesn’t allow root access, and FPoOS one has some specific FPoOS configs too, I think. So, my next step forward was to try to build the CM boot.img successfuly, including the kernel.
Woa! I didn’t try that. What files contains the ZIP? I guess it contains the system.img extracted and maybe, boot.img extracted too.
That file comes from the initial work @keesj did, and it looks like an skeleton file (probably generated by mkvendor.sh). There are instructions for regenerating it in the CM port guide. I think we should thoroughly check it too, and the FPoOS one seems to be a good start point (or may work as is).
Yes, that’s it. I renamed FP2 to fp2 because lowercase is the standard (and we must follow the standard naming for making FP2 an officialy supported device in the future). Maybe I did wrong thinking too early about the future. But I know we somehow can add FP2 as a compatible target for flashing, but I don’t know how to automate that right now (adding a getprop("ro.build.product") case manually to META-INF/com/google/updater-script should be enough)
We’re newbies all here, trying to learn by tinkering, trying and sharing. I signed in in the CM IRC to question experts whenever necessary. I suggest you to do the same and actually ask something (mostly about the boot.img, the recovery.fstab, partitions and kernel), because my time is suddenly limited right now.
PD: Also… ¿eres español/hispano? I’m from Madrid, so we can treat minor doubts in Spanish by private messaging if you wish,
and I really thought before: “I don’t need CM, I can live with the limitations FPOS comes with (with Xposed and root)”.
Now, I think it’s the only way for us to get newer Android versions and good new features if we manage the FP2 to be an “official” CM device.
I’m not an Android developer at all ( ), but I’ll try my best!
Maybe this one helps, I heard that Ubuntu Touch is based on CM 12.1 (?)
The sources are on GitHub I think and their newest Image (?) has a boot.img inside, maybe you can look into this one for the fstab problems?
Oh, and I found this one, kaibutsu began to create a device config but unfortunately he didn’t say how much works.
To be an official CM device, the port should pass the Google Compatibility Test Suite, which is the same requisite some future Android 7 for FP2 wouldn’t meet. But we can have an unofficial port…
Wo! Thank you for that! Will take a look right now,
No, they were the CM images I built. The emulator tool should come with either with the Android SDK or Android Studio. The interesting part came when I did as you suggested: [quote=“Roboe, post:110, topic:10399”]
we somehow can add FP2 as a compatible target for flashing, but I don’t know how to automate that right now (adding a getprop(“ro.build.product”) case manually to META-INF/com/google/updater-script should be enough)
[/quote]
I worked around the name check so the ZIP file can be installed from the recovery. I don’t get the error regarding the uppercase name anymore, but it fails next with the same error as emulator did before: system.img does not contain an ext4 filesystem.
So I’m guessing this could be a problem. I’m not even sure that the “manual” installation with fastboot is correct either even that it reports no errors, since the device doesn’t seem to allow yaffs2 images. There’s some tools to unpack/repack different image format, but I could not try any yet.[quote=“retsifp, post:111, topic:10399”]
Maybe this one helps, I heard that Ubuntu Touch is based on CM 12.1 (?)Ubuntu Touch • Linux mobile OS that gives you pure freedom
The sources are on GitHub
[/quote]
I’m also looking into other ports for FP2. The recovery.fstab from Ubuntu Touch looks pretty much the same as the one from FPoOS (also ext4 filesystems), but still I’m not sure where this file is used in the build and how it affects the resulting images.
Yes, the FPoOS’s recovery.fstab is the way to go. I think it will affect the step when it creates the flashable images, which may result in semiworking images, maybe? Don’t know. Worth trying,
I used the Android image repacking tools before and are very straightforward, but I think it’s better to build them again with the proper fstab
Thanks to the wiki I finally managed to get my build environment set up.
Tried a brunch fp2 yesterday (with the recovery.fstab from the FPoOS).
After changing the META-INF/com/google/android/updater-script I could flash it via TWRP.
Boot didn’t work (I’m just getting the FP logo but boot doesn’t continue).
I’m gonna have a look at the boot.img now.
I’m playing with the TARGET_OTA_ASSERT_DEVICE on BoardConfig.mk right now to solve this (I got that property from falcon device, as noted in this CM blog post). Will push it to the repo if it works as expected.
Did you achieve something? Could you access the ADB logs at that state? (i.e. adb logcat)
I’ll probably extract the kernel from FPoOS and push it to the repo too. I don’t know what kernel version @keesj used on his initial CM work and if it’s making troubles for us. We should maintain the kernel and blobs of the same FPoOS version, just in case, until we have something running.
Edit: Inspecting the device configs I found something very shameful… the target board platform is not set! That should be msm8974, as in the m8. Now it is obvious why builds didn’t work,
Fixing it now…
Edit2: Changes pushed. I also tidied up the BoardConfig.mk file as in the m8 one.
Get the changes by cding into device/fairphone/fp2 and git pulling. Ensure your changes are saved to avoid conflicts (you can git stash before pull, and git stash pop after; this will avoid screwing up the git history if there’s some conflict with your previous changes, if any).
…or just repo sync -c --force-sync and say good bye to any change you did.
Edit3: Seems like the new config doesn’t like the dtbtool we copied before from the m8, because CM states to have some of its own. Remove it before building:
You can read some experienced ROM builder documentation while I fix the build I’ve just broken, (well, it didn’t work before, anyway, to be fair…) It went all good, ZIP file generated, let’s try,
Edit: I built it without blobs…
In file included from hardware/qcom/audio/default/post_proc/bundle.c:26:0:
hardware/qcom/audio/default/post_proc/bundle.h:21:33: fatal error: sound/audio_effects.h: No such file or directory
#include <sound/audio_effects.h>
^
compilation terminated.
Tried to update BoardConfig.mk with the properties of the one to the FP Open OS 16.07.1, but still the same error. This should have be done anyway, so one down.
Edit: I misspelled BoardConfig.mk as BuildConfig.mk. It is a recurring error of mine, sorry.
), but I’ll try my best! 
(well, it didn’t work before, anyway, to be fair…)