978888 - [Flame]figure out how to create "Flame" builds manually

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Similar to bug 885901, we need to have builds for the foxphone aka "Flame" device.  This is the reference phone.

It appears that we need instructions on how to build before we can build automation, hence this bug.

Comment 1

[Armen [:armenzg]]

Who's going to provide the steps?

Comment 2

[Tony Chung [:tchung]]

(In reply to Armen Zambrano [:armenzg] (Release Engineering) (EDT/UTC-4) from comment #1)
> Who's going to provide the steps?

ping Viral and Thomas Tsai.  Can you guys help?

Comment 3

[viral [:viralwang]]

I'm not sure if what I should provide now.
Since we didn't have necessary source code from partner yet, we can not have complete environment to build full image (system.img, userdata.img).
I can now provide the steps to build our gecko/gaia only, is that what you want?

Comment 4

[Tony Zhao]

We(T2M) already provide source code that you guys can complete environment, viral and Dimi may working on that.

Comment 5

[viral [:viralwang]]

Attachment: some necessary patches to build gecko/gaia

Here's the build steps for flame.
We still not get workable source codes and can not have complete nightly build. 
Please be note that only used for gecko/gaia flash.

1) git clone git://github.com/mozilla-b2g/B2G.git .
2) apply patch "flame.patch"
3) ./config flame
4) enter build folder and apply patch "build.patch”
5) enter device/qcom/common and apply patch device_qcom_common.patch
6) connect device with USB cable
7) ./build.sh

It's not a good way to build the code, just a temporal solution so far.

Comment 6

[Michael Wu [:mwu]]

I've put up a flame port.

This port is only for gecko/gaia flashing. librs_jni still needs to be removed from device/qcom/common/common.mk - CAF will be removing it for us, but it will take a few days for the changes to be visible.

./config.sh flame
./build.sh

Comment 7

[Asa Dotzler [:asa]]

(In reply to Michael Wu [:mwu] from comment #6)
> I've put up a flame port.
> 
> This port is only for gecko/gaia flashing. librs_jni still needs to be
> removed from device/qcom/common/common.mk - CAF will be removing it for us,
> but it will take a few days for the changes to be visible.
> 
> ./config.sh flame
> ./build.sh

This worked for me until I got to flash.sh which doesn't see a supported device. Suggestions?

Comment 8

[Michael Wu [:mwu]]

(In reply to Asa Dotzler [:asa] from comment #7)
> This worked for me until I got to flash.sh which doesn't see a supported
> device. Suggestions?

This is currently a gecko/gaia only port. So do |./flash.sh gecko| and |./flash.sh gaia|.

Comment 9

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

I found init.rc doesn't import init.b2g.rc,
and this seems to be related to TARGET_PROVIDES_B2G_INIT_RC flag is true.

However I don't know who should control this flag.

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

We need 1.4 builds for both Flame and Open C.  Are they on two different gonks?  If so, I recall that there is some sort of connection between the gonk layer and the gecko layer.  Would this prevent us from using the Gecko/Gaia and placing it on the other?

Comment 11

[viral [:viralwang]]

Attachment: update device-flame to build system.img to enter homescreen with wifi enable

Hi Michael,

I'm thinking we can have a first build to enter home screen.
We can focus on digging which functions didn't ready after that.

Since there are some dependencies need to fix for each function, I'm not sure if it's the best way to have the night build.
Thank you in advance.

Comment 12

[viral [:viralwang]]

Attachment: update flame.xml to build system.img to enter homescreen with wifi enable

Same as last comment, this part is for manifest.
Thanks.

Comment 13

[viral [:viralwang]]

Comment on attachment 8396193 [details] [review]
update device-flame to build system.img to enter homescreen with wifi enable

Hi Michael,

Could you please help to check if it's fine to put it on mozilla-b2g?
Thanks!

Comment 14

[viral [:viralwang]]

Comment on attachment 8396194 [details] [review]
update flame.xml to build system.img to enter homescreen with wifi enable

review for mozilla-b2g!

Comment 15

[viral [:viralwang]]

Attachment: add dbus-daemon to enable bluez

Hi Michael,

One more patch to enable bluez
Thanks!

Comment 16

[viral [:viralwang]]

Comment on attachment 8396193 [details] [review]
update device-flame to build system.img to enter homescreen with wifi enable

Hi Michael,

I also add some config for bluez and update BOARD_SYSTEMIMAGE_PARTITION_SIZE in this patch!
Thanks.

Comment 17

[Michael Wu [:mwu]]

Comment on attachment 8396194 [details] [review]
update flame.xml to build system.img to enter homescreen with wifi enable

Generally it's convenient to have the bug number in the PR title.

Comment 18

[viral [:viralwang]]

Comment on attachment 8396193 [details] [review]
update device-flame to build system.img to enter homescreen with wifi enable

Hi Michael,

I have updated the patch according you suggestions.
But we still need "WCNSS_qcom_cfg.ini" in extract-files.sh
Please help to review it again.

I also update bug number in other 2 patches.
Thanks.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://github.com/mozilla-b2g/device-flame/commit/92f9b79e3a5ecf24cb0f66e20d5292b300f8cac9
https://github.com/mozilla-b2g/b2g-manifest/commit/7d79915da0063d70c121afe63de68d2b2682602b
https://github.com/mozilla-b2g/platform_build/commit/f6a198295f65ac38f8511803654a3583a1c666af

Comment 20

[Chris AtLee [:catlee]]

Viral, I believe we still need the backup-flame files before we can do a build. Where can we get these?

Comment 21

[viral [:viralwang]]

Hi Chris,

I already pass it to you by mail, please notice me if it didn't work.
Thanks

Comment 22

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

https://drive.google.com/a/mozilla.com/file/d/0B_0LdM1CVycISjNUZUJQeFFzQlE/edit?usp=sharing

openssl dgst -sha512 backup-flame.tar.xz 
SHA512(backup-flame.tar.xz)= 9df4442b86160a4ea060b8a3ce5c56f2094cca4f362420af82fe00b5a675d8b438c35af7b1e0dd8875f542517b62007554c9a590a1a3934d023f0f7ee2af5110

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Fyi : bug 994246 is fixed.

Comment 24

[Chris AtLee [:catlee]]

Thanks Naoki. Is this tarball different than the one Viral sent?

Comment 25

[Chris AtLee [:catlee]]

Nearly there. Build is currently failing because it can't find DEVICE in .config.

mwu, why aren't we setting DEVICE here? Every other target we build sets it, and automation uses it to find where to look in out/target/product for the generated binaries.

Comment 26

[Tony Chung [:tchung]]

(In reply to Chris AtLee [:catlee] from comment #25)
> Nearly there. Build is currently failing because it can't find DEVICE in
> .config.
> 
> mwu, why aren't we setting DEVICE here? Every other target we build sets it,
> and automation uses it to find where to look in out/target/product for the
> generated binaries.

Guys, any more updates here?   we're expecting a load of Flames to arrive next week and it would be good to have tested and have builds ready by then.  It's urgent that QA begins testing 1.4 builds on a Flame ASAP, since feature complete date is very near.

Comment 27

[Michael Wu [:mwu]]

(In reply to Chris AtLee [:catlee] from comment #25)
> Nearly there. Build is currently failing because it can't find DEVICE in
> .config.
> 

.config should not be read directly. load-config.sh should be sourced in order to obtain the proper variables. I've asked Naoki to put in a fallback DEVICE setting in bug 995036 so DEVICE will always be defined if you source load-config.sh.

Comment 28

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Bug 995036 landed. Catlee can you repull the b2g repo and see if you can build please?

Comment 29

[Chris AtLee [:catlee]]

No, it still won't work.

flame doesn't have DEVICE set in config.sh. If PRODUCT_NAME deprecates DEVICE, then it should be set for other devices like tarako, nexus, etc.?

Comment 30

[Chris AtLee [:catlee]]

(In reply to Michael Wu [:mwu] from comment #27)
> (In reply to Chris AtLee [:catlee] from comment #25)
> > Nearly there. Build is currently failing because it can't find DEVICE in
> > .config.
> > 
> 
> .config should not be read directly. load-config.sh should be sourced in
> order to obtain the proper variables. I've asked Naoki to put in a fallback
> DEVICE setting in bug 995036 so DEVICE will always be defined if you source
> load-config.sh.

This isn't a good solution for automation. We need a programmatic way for tools to know where to look for the generated bits. Our automation tools are mostly written in python, and having to source load-config.sh just to get the proper value of $DEVICE is really hacky.

Why can't we make config.sh output consistent values instead of coding logic into load-config.sh?

Comment 31

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I am not sure what tarball Viral had sent.  Mine is based off of 10D-1.  I pulled and built a build myself.

There are issues with the build after flashing the device; I believe that it's more code related than it may be build related.  In case you are wondering: Bug 996513, Bug 994577, bug 994463.  I don't think it's something releng has to worry about, but just in case you want to track it I am providing you the info.

Comment 32

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Attachment: 339.html

Here's a temp patch to fix the issue.

Comment 33

[Michael Wu [:mwu]]

(In reply to Chris AtLee [:catlee] from comment #30)
> This isn't a good solution for automation. We need a programmatic way for
> tools to know where to look for the generated bits. Our automation tools are
> mostly written in python, and having to source load-config.sh just to get
> the proper value of $DEVICE is really hacky.
> 

If you don't want to source load-config.sh, you can put the PRODUCT_NAME fallback logic on the automation side. Switching to PRODUCT_NAME is unfortunate, but it's necessary to properly support newer device ports.

Comment 34

[Michael Wu [:mwu]]

Comment on attachment 8406933 [details]
339.html

r- as we should make sure we can support future ports that will be using PRODUCT_NAME.

Comment 35

[Chris AtLee [:catlee]]

Attachment: fall back to PRODUCT_NAME if DEVICE isn't set

let's workaround this for now. It's not clear if we can change how all the devices use DEVICE/PRODUCT_NAME without causing bustage.