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

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
a year ago

People

(Reporter: nhirata, Assigned: viralwang)

Tracking

other
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(b2g-v2.0 fixed)

Details

Attachments

(6 attachments)

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.
Assignee: nhirata.bugzilla → nobody

Comment 1

5 years ago
Who's going to provide the steps?
(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?
Flags: needinfo?(vwang)
Flags: needinfo?(ttsai)
(Assignee)

Comment 3

5 years ago
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?
Flags: needinfo?(vwang)
Flags: needinfo?(ttsai)

Comment 4

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

Updated

5 years ago
Summary: figure out how to create "Flame" builds manually → [Flame]figure out how to create "Flame" builds manually
(Assignee)

Comment 5

5 years ago
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

5 years ago
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
(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

5 years ago
(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|.
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.
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?
(Assignee)

Comment 11

5 years ago
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.
Attachment #8396193 - Flags: feedback?(mwu)
(Assignee)

Comment 12

5 years ago
Same as last comment, this part is for manifest.
Thanks.
Attachment #8396194 - Flags: feedback?(mwu)

Updated

5 years ago
Attachment #8396193 - Flags: feedback?(mwu) → feedback+

Updated

5 years ago
Attachment #8396194 - Flags: feedback?(mwu) → feedback+
(Assignee)

Comment 13

5 years ago
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!
Attachment #8396193 - Flags: review?(mwu)
(Assignee)

Comment 14

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

review for mozilla-b2g!
Attachment #8396194 - Flags: review?(mwu)
(Assignee)

Comment 15

5 years ago
Hi Michael,

One more patch to enable bluez
Thanks!
Attachment #8399272 - Flags: review?(mwu)
(Assignee)

Comment 16

5 years ago
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.

Updated

5 years ago
Attachment #8399272 - Flags: review?(mwu) → review+
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.
Attachment #8396194 - Flags: review?(mwu) → review+
(Assignee)

Comment 18

5 years ago
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.

Updated

5 years ago
Attachment #8396193 - Flags: review?(mwu) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed

Updated

5 years ago
Blocks: 991393
Viral, I believe we still need the backup-flame files before we can do a build. Where can we get these?
Status: RESOLVED → REOPENED
Flags: needinfo?(vwang)
Resolution: FIXED → ---
(Assignee)

Comment 21

5 years ago
Hi Chris,

I already pass it to you by mail, please notice me if it didn't work.
Thanks
Flags: needinfo?(vwang)
(Assignee)

Updated

5 years ago
Blocks: 994577
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
Flags: needinfo?(catlee)
Flags: needinfo?(aki)
Thanks Naoki. Is this tarball different than the one Viral sent?
Flags: needinfo?(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.
Flags: needinfo?(mwu)

Updated

5 years ago
Flags: needinfo?(aki)
(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.

Updated

5 years ago
Depends on: 995036
(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.

Updated

5 years ago
Flags: needinfo?(mwu)
Bug 995036 landed. Catlee can you repull the b2g repo and see if you can build please?
Flags: needinfo?(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.?
Flags: needinfo?(catlee) → needinfo?(mwu)
(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?
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.
Posted file 339.html
Here's a temp patch to fix the issue.
(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.
Flags: needinfo?(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.
Attachment #8406933 - Flags: review?(mwu) → review-
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.
Attachment #8407068 - Flags: review?(aki)

Updated

5 years ago
Attachment #8407068 - Flags: review?(aki) → review+
Attachment #8407068 - Flags: checked-in+
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Blocks: 999058
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.