Closed Bug 978888 Opened 6 years ago Closed 6 years ago

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

Categories

(Release Engineering :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 fixed)

RESOLVED FIXED
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: nhirata, Assigned: viralwang)

References

Details

Attachments

(6 files)

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
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)
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)
We(T2M) already provide source code that you guys can complete environment, viral and Dimi may working on that.
Summary: figure out how to create "Flame" builds manually → [Flame]figure out how to create "Flame" builds manually
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.
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?
(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?
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)
Same as last comment, this part is for manifest.
Thanks.
Attachment #8396194 - Flags: feedback?(mwu)
Attachment #8396193 - Flags: feedback?(mwu) → feedback+
Attachment #8396194 - Flags: feedback?(mwu) → feedback+
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)
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)
Hi Michael,

One more patch to enable bluez
Thanks!
Attachment #8399272 - Flags: review?(mwu)
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.
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+
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.
Attachment #8396193 - Flags: review?(mwu) → review+
Keywords: checkin-needed
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 → ---
Hi Chris,

I already pass it to you by mail, please notice me if it didn't work.
Thanks
Flags: needinfo?(vwang)
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)
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.
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.
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.
Attached 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)
Attachment #8407068 - Flags: review?(aki) → review+
Attachment #8407068 - Flags: checked-in+
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Blocks: 999058
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.