Fairphone 2 support for B2G-Installer, landed!

B2G OS Building and Porting
#41

Recovery got built successfully, that is strange, they are very similar. At
least they are produced the same way. It means that if you flash just
boot.img out of a build tree on top of your broken blobfree flash, it
boots, right?

#42

Can you clean only the .img files in that folder and retry? Maybe we have a
nasty race condition that breaks building ā€¦ Also, if that still does not
work, please use the VM to perform the operations, just to be extra
cautious this is not a mac side effect :frowning:

#43

No. Had to flash system as well otherwise it still didnā€™t boot.

Done. I cleaned out all img files and restarted from scratch. And now i see all 4 .img files but hold your self.
-Now flashing gives out a errorā€¦ http://pastebin.com/CHMfw9JR

Screenshot 2016-09-19 15.56.26.png2191Ɨ832 320 KB

#44

We cannot see the size of your partitions. Please use the VM, there are too many variables there to know what is really broken ā€¦

#45

the vm is not able to flash due to a known problem that after restarting the device to fastboot mode it doesnā€™t recognize it because it gets a new nameā€¦ so i have to test the flashing on my osx but as you can see it causes the same build problem in the vmā€¦
size on osx:
boot.img - 15MB
data.img - 209.5MB
recovery.img - 13.5MB
system - 255.4MB

and the same behavour in the VM if i remove the 3 .img files and restart the process it generates 4 .img files correctlyā€¦

so i proved that it behaves exactly the same on both linux VM and native OSX.

#46

I am not sure what you are talking about. Is this the USB IDs ? The VM is supposed to be configured properly for them, as following:

If your fastboot IDs are not the same, then you should change them.

For the size, can you get the byte-exact ones? Here there is rounding applied and I cannot trust that :confused

#47

on osx:
boot.img - 15ā€™249ā€™408 Byte
data.img - 209ā€™481ā€™852 Byte
recovery.img - 13ā€™846ā€™528 Byte
system.img - 255ā€™448ā€™740 Byte
on vm in tmp/:
boot.img - 15ā€™249ā€™408 bytes
data.img - 209ā€™481ā€™852 bytes
recovery.img - 13ā€™846ā€™528 bytes
system.img - 255ā€™448ā€™740 bytes
on vm in B2G/out (blobfull):
boot.img - 15ā€™351ā€™808 bytes
userdata.img - 209ā€™481ā€™852 bytes
recovery.img - 13ā€™948ā€™928 bytes
system.img - 320ā€™272ā€™024 bytes

#48

Ok, verify by flashing the images produced by the VM :slight_smile:

#49

ok.

  1. i flashed the tmp/b2g-installer .img files
  2. rebooted - nothing happened
  3. i flashed boot.img from B2G/outā€¦FP2/boot.img
  4. rebooted - nothing happened
  5. i flashed system.img from B2G/outā€¦FP2/system.img
  6. rebooted - nothing happened
  7. i flashed - system & boot .img from tmp/b2g-installer
  8. rebooted - nothing happened as previous state in step 2.
  9. i flashed - system.img from B2G/outā€¦FP2/system.img
  10. rebooted - boot successful

donā€™t know why the first time this didnā€™t work because im sure i have done the exactly sameā€¦
But now it looks like the boot.img partitions of b2g-installer causes the problem aloneā€¦

the size of boot.img from B2G/outā€¦FP2/boot.img is 15ā€™351ā€™808 bytes so slightly biggerā€¦

#50

Ok, so ONLY boot.img is the culprit here? Right. When you are referring to tmp/b2g-installer, is that from your OSX run or from within the VM?

#51

the vm.
im able to flash manual and with ./flash.sh in vm but the b2g-installer has a problem that may be caused by my special parallels vm host. I will have to test if other vm software worksā€¦

#52

Ok, please collect:

  • Content of Object in the log for this line: B2G Installer: Calling mkbootimg with Object { kernel: "/Users/FirefoxNightly/Library/Cacheā€¦", ramdisk: "/Users/FirefoxNightly/Library/Cacheā€¦", output: "/Users/FirefoxNightly/Library/Cacheā€¦", dt: "/Users/FirefoxNightly/Library/Cacheā€¦", cmdline: "console=ttyHSL0,115200,n8 androidboā€¦", pagesize: "2048", base: "0x00000000" } bootstrap.js:104, the paths are stripped and we might miss some infos ;
  • Content of the build log for: rm out/target/product/FP2/boot.img && ./build.sh out/target/product/FP2/boot.img 2>&1|tee boot.img.log

This should expose us the arguments to mkbootimg we need to check that we have all the exact same ones. The difference could be the dt.img. I fear you will have to hack very low level to verify what happens here ā€¦

#53

No please stop adding more variables to the problem, it is already complex enough to debug this :(. Stick to the VM with VirtualBox, this is what was working for sure for everyone.

#54

Crap! thatā€™s is very very different than what you have on the other: system.img - 320'272'024 bytes. I am starting to wonder if the difference in size would not come from missing blobs!

@atilag I remember you killed some blobs in your PR to fix the path, are you sure you have not killed some important ones?

@Novski would you mind to share me the working and the non working boot.img ? I will compare their content :slight_smile:

#55

whait. If we roll up this with Juan i wold like to ask for a pause.
The thing is that FP has updated their repo and made a new git where we are able to get the blobs more easy and eventualy also the updates more comformitableā€¦
its this one: https://github.com/FairphoneMirrors
Maybe (and i wold like to hear what you guys think of that idea) its better to change nowā€¦