Building B2G OS for Flamingo (Xperia E3)

B2G OS Building and Porting
#61

hi. where you able to step over that issue?

#62

Hi! I think the issue may be related to this: https://android.googlesource.com/platform/build/+/5ff9c81b6c0f23dfbc08c95c1294b3b37110ecf0^! but I haven’t succeeded yet in building, so I’m not sure that would help


#63

Building instructions!

It appears I finally made it! Let’s see how to sort that out.

Setup
I used a (quite old) Ubuntu 16.04 pc. Prerequisites installed according to MDN.

Tools

The device
I used a Sony Xperia E3 (model D2203, codename Flamingo). I flashed it with firmware 18.5.0.C.25 (RB2 Customized CE1). I used XperiFirm to get the official Sony firmware and used FlashTool to flash it.
Notice that this configuration can probably be obtained by using Emma, the official Sony flashing tool, after unlocking the device (see http://developer.sonymobile.com/open-devices for details) but for some reason that wasn’t working for me.
Of course, ADB debug via USB has to be enabled from the Developer menu (again, more info on Sony’s website).

B2G OS codebase setup
I followed instructions as on MDN (with a repository updated to August 29th). I used ./config.sh flamingo-l.
The build will request to download Sony’s software binaries (providing the appropriate link) which for me were SW_binaries_for_Xperia_AOSP_L_MR1_v19a.zip and to place those into B2g/download-sony folder.
The build fails to pull all needed data from the device (possibly because the device is not rooted?) so that’s has to be done manually as per https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS/Preparing_for_your_first_B2G_build#Proprietary_Blobs. (Notice that data should be empty and the correct command to back-up vendor is adb pull /vendor/. <backup target dir>/vendor -r).
Moreover, the building process incorrectly put the backup into backup-tianchi instead of backup-flamingo. Till the issue is fixed, use backup-tianchi as <backup target dir> (inside the main B2G folder).

Codebase Fixing
An issue prevented me from building successfully. Early in the build I got a series of libnativehelper/JNIHelp.cpp:310: error: unsupported reloc 43-like errors.
The issue is described in https://oopsmonk.github.io/blog/2016/06/07/android-build-error-on-ubuntu-16-04-lts which shows how to patch B2G/build/core/clang/HOST_x86_common.mk (at least until that’s fixed in the codebase).
To be extra-sure I also patched x86_64.mk in the same folder, adding the given line to CLANG_CONFIG_x86_LINUX_HOST_EXTRA_ASFLAGS (I don’t know whether that was necessary).
(The issue looks similar to another one I found in an older version of the repository, and which apparently has already been fixed: https://android.googlesource.com/platform/build/+/5ff9c81b6c0f23dfbc08c95c1294b3b37110ecf0^!.)

Flashing
When the build is done, to just flash won’t do. I got Open device BL from http://forum.xda-developers.com/xperia-e3/development/ftf-device-18-5-c-0-19-t3136514 and flashed it on my device using the “previous release” of FlashTool, v. 0.9.18.6 (the new one won’t do here). (Notice that this may be equivalent to use the device with Sony’s unlocked bootloader, flashed through Emma. Again, I had to find an alternative way.) Then I flashed B2G with ./flash.sh, and that made the trick.

Extra notes
I used an under-spec’ed pc (with only 2GB RAM). The only issue I had (apart from geological building times) was a failure of the build at some point. That wasn’t due to a specific issue I guess, but to hardware limitations. Running the build again with ./build.sh -j1 succeeded. In analogous situations, try running the build again (with less threads) before beginning to look for bugs.

may be of interest to @lissyx @lapineige @kskarthik @Novski

2 Likes
#64

I’m going to upload the build somewhere, possibly on XDA, since the build is not suitable for the B2G add-on. What’s the best way to provide it? What should I include in it?

I guess that those from the B2G/out/target/product/flamingo are necessary: system.img, userdata.img, recovery.img, boot.img, and cache.img.
What about ramdisk.img, ramdisk-recovery.img, and kernel (with no .img)?
Sould I include the flash.sh script too?

1 Like
#65

Well there is no reason we should not be able to handle Sony devices. It’s just that we need more code to handle it :slight_smile:

I would be happy if someone tries.

Mozilla Discourse a Ă©crit :


enrico_ghiorziEnrico

August 30

I'm going to upload the build somewhere, possibly on XDA, since the build is not suitable for the B2G add-on. What's the best way to provide it? What should I include in it?

I guess that those from the B2G/out/target/product/flamingo are necessary: system.img, userdata.img, recovery.img, boot.img, and cache.img.

What about ramdisk.img, ramdisk-recovery.img, and kernel (with no .img)?

Sould I include the flash.sh script too?

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

Envoyé depuis Firefox OS
#66

you can provide it here too. Link to your file location.

#67

That is surprising. Can you elaborate on the issue ?

That might be expected: we do have “DEVICE=tianchi” in extract-files.sh for flamingo.

platform/build is already something we do fork, right? So we could just cherry-pick that fix.

I can confirm, if you unlock and perform upgrade with Emma, it will show you the proper bootloader. This is documented on Sony’s website.

It would be great if you could file bugs for all the issues we should fix. And since you fixed them, issue patches :slight_smile:

I am not a big fan of hosting the build on XDA. Instead, we should really add AOSP devices support into B2G Installer, this would benefit all the Sony devices and Nexus ones.

#68

And Adam confirms it is a typo, so you should just do a PR to fix this :slight_smile:

#69

The problem is that the legal status of proprietary blobs is ambiguous, that’s why we’d better use “unofficial” channels to share non-blobfree builds.

I’ll do that, sure!

That would surely be a better solution. Unfortunately I have no idea on how to do that, and the proprietary blob issue is a delicate matter.

#70

I share your concerns, that is why handling in B2G Installer is the best solution.

I can guide you through this and maybe @TitanNano can help too?

Basically the problem is that we need to be able to solve two separate issues:
(1) identify the blobs (this is done at build system level, check the “blobfree” make target in gonk-misc/Android.mk)
(2) extract them (this is done in the addon itself, using adb pull for devices where we have no external sources)

I have been thinking about that problem for a while. The good thing is that Nexus and Sony AOSP devices have a external, internet sources of blobs. The bad thing is that they do not share a common format: Sony releases a simple ZIP file and makes you accept the license BEFORE downloading, while Google releases a shell script that bundles a compressed archives and makes you accept the licences AFTER downloading, when extracting.

So for (1), I think we can already re-use the logic we have in place for those devices.

But for (2), we need to update the addon to make it able to get the blobs from another source than a device, namely internet. This is some hacking for sure, but I don’t think it is too hard. I had no time to work on this though, and I really want other people to hack on the addon so that it is not only relying on myself, so I also would like to see someone else doing this for that purpose of sharing ownership: it is never a good thing that only one person owns something :).

We can take this into another thread if you would like, no need to pollute this one.

#71

I’m not able to hack the add-on to make this, but I’ll file a bug about that at least, so that it’ll be more visible.

I agree it’s worth the effort though: Sony’s AOSP devices are many, popular and easy to hack, and blobs are provided by Sony itself. Toghether with Nexus, those are the easiest devices to target.

#72

That has been done: https://bugzilla.mozilla.org/show_bug.cgi?id=1299476

I can’t seem to find it
 is https://github.com/mozilla-b2g the correct repository? Can you see the file we are looking for?

I can’t replicate it now easily (I should start everything anew) but the folder it created is 60MB large (most stuff is in /system/etc/firmware), while the manual backup one is 1.3GB. I think it caused a build error, but I don’t remember the exact error message anymore. Anyway I think it’s related to not having the open bootloader at the time.

#73

No it’s not surprising, we really just need the firmware modem from the device. Everything else is coming from the ZIP file.

#74

It’s a bit hidden behind the level of includes, but here it is:

#75

I made a new build today for E3. To notice:

  • when starting from a device already running B2G OS (based on Android L), the blob retrieving phase fails complaining the device doesn’t run the correct Android KitKat version. Which is kind of weird. The issue can be solved, if already having a good lamingo-KitKat backup, by commenting out the part triggering the download. Everything from then on goes smooth!
  • Unfortunately the lockscreen slider seems broken: I cannot unlock the lockscreen anymore. This prevents me from further testing.
  • All issues found in previous build seems now to be fixed.
#76

That is not weird, that is on purpose. In the past, we had way too much problems because of people pulling blobs from previous B2G images, but those were not the blobs with the fixes. This resulted in endless loops of bug fixed being reopened.

Well people should start digging and fixing the code 


1 Like
#77

Anything raised in the logs ?

#78

In the build log? Sorry I didn’t look at that. The build seemed to end without errors, but I don’t know what may have happened during the build.

That’s good to me then, it makes sense!

#79

I mean in adb logcat.

#80

do you know how to use logcat? I made some tests yesterday. Its quite easy

plug the device and run adb devices to be shure your device is connected.
then adb logcat and off it goes. ctrl + c stops it