One of the goals for the Flame was for developers to be able to rebuild and reflash all of the open-source software on the device, including the kernel. In particular: 1. We might prefer to use a prebuilt kernel by default, since most developers won't change it and the sources are large, but it should at least be possible to add the kernel source and do a TARGET_NO_KERNEL=false build (the way keon is currently built). 2. If anything special needs to happen for flashing, such that the bootloader will accept the resulting boot.img, flash.sh should do it.

ni'ing Jishnu. I'm not sure the legal implications. I don't think we can distribute the boot image nor the system image publicly. I believe we can distribute is the gecko/gaia layers.

(In reply to Jed Davis [:jld] from comment #0) > One of the goals for the Flame was for developers to be able to rebuild and > reflash all of the open-source software on the device, including the kernel. > > In particular: > > 1. We might prefer to use a prebuilt kernel by default, since most > developers won't change it and the sources are large, but it should at least > be possible to add the kernel source and do a TARGET_NO_KERNEL=false build > (the way keon is currently built). This is currently the case. Switching TARGET_NO_KERNEL to false indeed builds a kernel, and if one makes use of the /proc/config.gz pulled from the device, we are able to build some kernel. For now, I was not able to make it booting, even after making sure |fastboot oem unlock|. This may be due to secure boot. We are also able to build a signed kernel by toggling the right make variable in device/t2m/flame/BoardConfig.mk (for instance, |TARGET_BOOTIMG_SIGNED := true|), this produces a boot.img which is signed.

Also, what about WiFi driver? I see a bad vendor/t2m/flame/proprietary/wifi/pronto_wlan.ko :(

I also tried another way: - get boot.img from v10E image - extract zImage from boot.img: |abootimg -x boot.img| - copy kernel to prebuilt blobs: |cp zImage vendor/t2m/flame/proprietary/kernel| - tune device/t2m/flame/BoardConfig.mk: - TARGET_NO_KERNEL := false - TARGET_PREBUILT_KERNEL := vendor/t2m/flame/proprietary/kernel Then build, you get a boot.img file, that cannot boot.

The ramdisk we build lacks some files compared to the ramdisk from the device: - boot.ver - init.rc

Distributing the boot image isn't a problem. We can distribute everything in there as long as we have the source to go with it.

(In reply to Alexandre LISSY :gerard-majax from comment #5) > The ramdisk we build lacks some files compared to the ramdisk from the > device: > - boot.ver > - init.rc I tried copying those files from the existing ramdisk and installing them with PRODUCT_COPY_FILES in device/t2m/flame/flame.mk, and they're added to the ramdisk, but the bootloader still refuses to load it. (This is with `TARGET_BOOTIMG_SIGNED := true` and `fastboot oem unlock`.) There are also some differences in the files that exist in both ramdisks; I haven't investigated in detail (and I suspect we're not even getting that far).

I looked into the differences between msm8610_defconfig after processing by the `make defconfig` step, and the config in /proc/config.gz. Compared to the Qualcomm config, the Flame disables these: CONFIG_LEDS_MSM_GPIO_FLASH=y CONFIG_NFC_QNCI=y and enables these, which are recognized by the kernel source in the manifest (tag caf/b2g_jb_3.2, rev 4f49d97): CONFIG_BOUNCE=y CONFIG_HIGHMEM=y CONFIG_NFC=y and also enables these, which do not correspond to anything in that version of the kernel source: CONFIG_AS3647=y CONFIG_BOSCH_BMA2X2=y CONFIG_HI258=y CONFIG_NFC_PN544_MSM=y CONFIG_SENSORS_ST480_ECOMPASS=y

I've made progress: the boot.img needs to contain a device tree (see system/core/mkbootimg/bootimg.h). If I extract the device tree blob from the phone (by hexdumping, computing offsets, and using dd), drop it into device/t2m/flame, and add `BOARD_MKBOOTIMG_ARGS= --dt device/t2m/flame/devicetree` to BoardConfig.mk, the image is booted… and immediately whitescreens. The device can be unbricked from that state with the usual power-on/volume-down routine and the original boot.img. I don't know that I can get any more information out of it, without access to a serial port or some other debugging interface.

Also, it's not the initrd. Or the load addresses, for that matter. Using the same mkbootimg command line except for the --kernel and --ramdisk arguments: My kernel, my initrd: fails. My kernel, their initrd: fails. Their kernel, their initrd: works. Their kernel, my initrd: works. When it's crashed in this way, it appears on USB with the same IDs as when it's working (but adb doesn't work).

(In reply to Jed Davis [:jld] from comment #10) > Also, it's not the initrd. Or the load addresses, for that matter. Using > the same mkbootimg command line except for the --kernel and --ramdisk > arguments: > > My kernel, my initrd: fails. > My kernel, their initrd: fails. > Their kernel, their initrd: works. > Their kernel, my initrd: works. > > When it's crashed in this way, it appears on USB with the same IDs as when > it's working (but adb doesn't work). When you say that it works, you mean that device boots instead of getting back to fastboot immediately, but that it probably panics? (stuck on white screen).

According to dmesg, the expected device tree source would be arch/arm/boot/dts/msm8610-v2-qrd-skuaa.dts

(In reply to Alexandre LISSY :gerard-majax from comment #11) > (In reply to Jed Davis [:jld] from comment #10) > > My kernel, my initrd: fails. > > My kernel, their initrd: fails. > > Their kernel, their initrd: works. > > Their kernel, my initrd: works. > > When you say that it works, you mean that device boots instead of getting > back to fastboot immediately, but that it probably panics? (stuck on white > screen). Boots and then crashes, yes. (In reply to Alexandre LISSY :gerard-majax from comment #12) > According to dmesg, the expected device tree source would be > arch/arm/boot/dts/msm8610-v2-qrd-skuaa.dts There are some Flame-specific changes to that file in the blob that was shipped, including the addition of a "qcom,mdss_dsi_tianma_tm040ydh65_ili9806c_wvga_video" node, which seems to be needed to successfully drive the display. The actual source for the DTB might be in the actual kernel tree, which we still need to find. If not, applying the diffs from the output of `dtc -I dtb -O dts` seems to be a simple matter of determining which integers in the changes are actually phandles.

(In reply to Jed Davis [:jld] from comment #13) > The actual source for the DTB might be in the actual kernel tree, which we > still need to find. If not, …then that should be fixed, because the original DTS files are licensed by the Linux Foundation under the GPL.

I can take this bug, but I'll need to know the point of contact for obtaining the kernel source.

(In reply to Jed Davis [:jld] from comment #13) > (In reply to Alexandre LISSY :gerard-majax from comment #11) > > (In reply to Jed Davis [:jld] from comment #10) > > > My kernel, my initrd: fails. > > > My kernel, their initrd: fails. > > > Their kernel, their initrd: works. > > > Their kernel, my initrd: works. > > > > When you say that it works, you mean that device boots instead of getting > > back to fastboot immediately, but that it probably panics? (stuck on white > > screen). > > Boots and then crashes, yes. I misread this question. “Works” = boots normally; “fails” = starts to boot and then crashes.

Perhaps Francis can help you, Jed.

hi Jed, may i know you need the whole kernel source code? or can you let me know any specific files so that i can contact T2M and see if they can provide them w/o any concern.

(In reply to Francis Lee [:frlee] from comment #18) > hi Jed, > > may i know you need the whole kernel source code? or can you let me know any > specific files so that i can contact T2M and see if they can provide them > w/o any concern. The need is to be able to rebuild some fully working image from scratch.

(In reply to Francis Lee [:frlee] from comment #18) > may i know you need the whole kernel source code? or can you let me know any > specific files so that i can contact T2M and see if they can provide them > w/o any concern. Yes, we require all of the kernel source. See comment #19 and comment #6.

hi all, T2M promised to share kernel source code to us asap. once it's shared, Viral will have a quick test on it. and let us know if everything is correct.

(In reply to Francis Lee [:frlee] from comment #21) > hi all, > > T2M promised to share kernel source code to us asap. once it's shared, Viral > will have a quick test on it. and let us know if everything is correct. Please make them also fix the build system so that we can produce fully working images, including: - boot.img - recovery.img - system.img The lack of recovery that I can rebuid myself makes me unable to test FOTA on this device, for example (because the keys in their recovery are not testkeys).

Here's the kernel source code from partner https://github.com/t2m-foxfone/kernel_msm Here's recovery source code https://github.com/t2m-foxfone/platform_bootable_recovery

viral has just provided them in comment 23

(In reply to viral [:viralwang] from comment #23) > Here's the kernel source code from partner > https://github.com/t2m-foxfone/kernel_msm > > Here's recovery source code > https://github.com/t2m-foxfone/platform_bootable_recovery Thanks for those ! I'm having a look at the manifest also, and I see quite a lot of differences comparing to what we have. Could we make sure that our flame.xml matches their foxfone xml and that everything that can be upstreamed to us gets pull-requested ?

There may be a better way to accomplish this. This is activated by the next patch....

With this patch, and attachment 8418405 [details] [diff] [review], and using the previously mentioned remote to check out 7de060778bcc06b32698ec92dfec11039f7c721d in my kernel/ tree (revision obtained from the contents of /proc/version), I can use build.sh and flash.sh to flash the boot.img, and the phone boots normally. 802.11 works, but I haven't tried telephony. I also haven't tried reflashing system.img. There are several items in this patch where I'm not sure if I'm doing things the right way.

Confirm that building works: > $ adb shell dmesg | grep gcc > <5>[ 0.000000] Linux version 3.4.0-g71e70c6-00044-g7de0607 (alex@portable-alex) (gcc version 4.7 (GCC) ) #2 SMP PREEMPT Wed May 7 10:51:30 CEST 2014

I would like to use CAF first, here's the reason For developers, I think it will be reasonable to make CAF works, they don't want to induce the partner change and have different behavior. This is same way as we did in other projects. That's why we already work on CAF for a while. Any feedback is welcome :)

(In reply to viral [:viralwang] from comment #29) > I would like to use CAF first, here's the reason > For developers, I think it will be reasonable to make CAF works, they don't > want to induce the partner change and have different behavior. This is same > way as we did in other projects. > That's why we already work on CAF for a while. > > Any feedback is welcome :) I have no problem with that. Meanwhile, I trashed all my local changes, reused those from Jed, and I have: - own built boot.img that works - own build system.img that works There are also some changes needed to get sdcard devices corrects. I can get Bluetooth to work, WiFi, and setting the correct properties I have mozril working and placing calls.

repo diff generated, with mozril working and sdcard working.

We also have to do the core/Makefile change for the INTERNAL_RECOVERYIMAGE_ARGS variable, otherwise it can't boot. Using the recovery repository provided by T2M I have something that boots, but getting quite a log of errors when it boots: mainly, issues with mounting /cache and /misc.

Fixed the recovery fstab bits. Do not forget to fastboot flash cache out/target/product/flame/cache.img at first also. Then I'm getting errors when recovery boots because of missing icons.

With recovery booting correctly, apart from icons errors.

Fixing missing files

Hey, when we have builds we can share, can someone let me know? I'm working on an add on to allow flashing your phone, just blocking on not having public builds. I'll work with rel eng on getting nightly builds put up on an FTP server.

i believe comment 29 answers your question. remove my ni.

device/t2m/flame/flame.mk also lacks adding librecovery to the PRODUCT_PACKAGES. Without this, we are unable to reboot in recovery mode from Gecko (used to apply FOTA, perform factory reset).

I think this recovery comes from partner should work. https://github.com/t2m-foxfone/platform_bootable_recovery

Adding librecovery package, fixing recovery /system mount

(In reply to viral [:viralwang] from comment #39) > I think this recovery comes from partner should work. > https://github.com/t2m-foxfone/platform_bootable_recovery The recovery does work quite well, we just lack librecovery added in PRODUCT_PACKAGE definition to make Gecko able to reboot in recovery mode :).

Viral, could you have a look at my patch ? So far, I'm able to rebuild and get quite a lot of things working with those changes: - boot.img with uptodate kernel - recovery.img that works to apply FOTA built with gecko-update-fota make target - system.img with mozril working

Rebased on the latest flame.mk changes, I now have MP3 playback working :)

Hi Michael, Could you help on check the patch? I think it will be proper to have your comment. Thank you.

(In reply to viral [:viralwang] from comment #44) > Hi Michael, > > Could you help on check the patch? > I think it will be proper to have your comment. > Thank you. Viral, this patch is not for a pull request, but rather to propose a start base to open bugs and do PR.

I think the missing images ressources are in bootable/recovery/res/ (using t2mobile remote). One can add them to flame.mk.

We need some blobs for gps: > $ find backup-flame/system/ | grep libgps > backup-flame/system/lib/libgps.utils.so > $ find backup-flame/system/ | grep libloc > backup-flame/system/lib/libloc_xtra.so > backup-flame/system/lib/libloc_core.so > backup-flame/system/lib/libloc_ds_api.so > backup-flame/system/lib/libloc_eng.so > backup-flame/system/lib/libloc_api_v02.so

Not a regression, so this is not a QA blocker.

(In reply to Jed Davis [:jld] from comment #27) > Created attachment 8418406 [details] [diff] [review] > Patch to device/t2m/flame/ to build kernel and boot.img from source. > > With this patch, and attachment 8418405 [details] [diff] [review], and using > the previously mentioned remote to check out > 7de060778bcc06b32698ec92dfec11039f7c721d in my kernel/ tree (revision > obtained from the contents of /proc/version), I can use build.sh and > flash.sh to flash the boot.img, and the phone boots normally. > > 802.11 works, but I haven't tried telephony. I also haven't tried > reflashing system.img. > > There are several items in this patch where I'm not sure if I'm doing things > the right way. WiFi works because your a picking the exact same kernel. As soon as we change a bit and that vermagic changes, we are stuck because of the blob. This is sad, since as documented in bug 1009396, it seems the sources for this driver are available.

Device tree is handled in T2M's platform/build fork: https://github.com/t2m-foxfone/platform_build/blob/foxfone-one/core/Makefile#L426

There might be things we'd need (or want) from https://github.com/t2m-foxfone/platform_vendor_qcom_msm8610 (== device/qcom/msm8610) as well. This might reduce the number of things that need to be patched in device/t2m/flame.

Comment on attachment 8418405 [details] [diff] [review] Patch to build/ to include DeviceTree blobs in boot.img. This approach is just wrong, I think.

Please find attached a patch that should help. It's directly cherry-picked from T2M's repo, and it comes from CAF. It should fix the issue as soon as we switch back BOARD_KERNEL_SEPARATED_DT to true in device/t2m/flame/BoardConfig.mk

Michael, what should we do for repo hosted on T2M's github ? Is it fine to clone them ?

Comment on attachment 8427707 [details] Link to Github https://github.com/mozilla-b2g/platform_build/pull/54 AFAIK, the flame manifest doesn't use the master branch of platform_build.

(In reply to Alexandre LISSY :gerard-majax from comment #54) > Michael, what should we do for repo hosted on T2M's github ? Is it fine to > clone them ? Generally we can point anywhere as long as we point to specific commits or tags. I'm not sure T2M will want to manage pull requests and reviews coming into their repos though - so that might be a reason to fork into mozilla-b2g.

(In reply to Jed Davis [:jld] from comment #51) > There might be things we'd need (or want) from > https://github.com/t2m-foxfone/platform_vendor_qcom_msm8610 (== > device/qcom/msm8610) as well. This might reduce the number of things that > need to be patched in device/t2m/flame. I tried doing a build with T2M's repos for device/qcom/msm8610/ and build/. It failed because the "study_image" makefile target added in https://github.com/t2m-foxfone/platform_build/commit/840322f doesn't exist. I tried reverting that commit, but the build failed somewhere else. So it's not quite that simple.

(In reply to Michael Wu [:mwu] from comment #55) > Comment on attachment 8427707 [details] > Link to Github https://github.com/mozilla-b2g/platform_build/pull/52 > > AFAIK, the flame manifest doesn't use the master branch of platform_build. Gasp you're right. Sorry, I'll fix the PR.

Comment on attachment 8427707 [details] Link to Github https://github.com/mozilla-b2g/platform_build/pull/54 >https://github.com/mozilla-b2g/platform_build/pull/54

(In reply to Michael Wu [:mwu] from comment #56) > (In reply to Alexandre LISSY :gerard-majax from comment #54) > > Michael, what should we do for repo hosted on T2M's github ? Is it fine to > > clone them ? > > Generally we can point anywhere as long as we point to specific commits or > tags. I'm not sure T2M will want to manage pull requests and reviews coming > into their repos though - so that might be a reason to fork into mozilla-b2g. We discuss the source code issue with partner and here's the release plan. Partner will push their source code to github when they release their base image. I think we can just use their repository directly to build our own image. It means we can get the updated source code by "./config.sh flame" once we have updated base image. Partner will also provide the tag to us to understand the difference for each release.

(In reply to viral [:viralwang] from comment #61) > (In reply to Michael Wu [:mwu] from comment #56) > > (In reply to Alexandre LISSY :gerard-majax from comment #54) > > > Michael, what should we do for repo hosted on T2M's github ? Is it fine to > > > clone them ? > > > > Generally we can point anywhere as long as we point to specific commits or > > tags. I'm not sure T2M will want to manage pull requests and reviews coming > > into their repos though - so that might be a reason to fork into mozilla-b2g. > > We discuss the source code issue with partner and here's the release plan. > Partner will push their source code to github when they release their base > image. > I think we can just use their repository directly to build our own image. > It means we can get the updated source code by "./config.sh flame" once we > have updated base image. > > Partner will also provide the tag to us to understand the difference for > each release. How do we handle the case were we need to perform some hacks ? We just fork it and it's on our side to ensure to keep synced?

Device tree stuff has been merged: https://github.com/mozilla-b2g/platform_build/commit/42c224f4304c10166739fd9e25b2db1036410bd8 We still have to work on building the kernel itself.

(In reply to Alexandre LISSY :gerard-majax from comment #62) > (In reply to viral [:viralwang] from comment #61) > > (In reply to Michael Wu [:mwu] from comment #56) > > > (In reply to Alexandre LISSY :gerard-majax from comment #54) > > > > Michael, what should we do for repo hosted on T2M's github ? Is it fine to > > > > clone them ? > > > > > > Generally we can point anywhere as long as we point to specific commits or > > > tags. I'm not sure T2M will want to manage pull requests and reviews coming > > > into their repos though - so that might be a reason to fork into mozilla-b2g. > > > > We discuss the source code issue with partner and here's the release plan. > > Partner will push their source code to github when they release their base > > image. > > I think we can just use their repository directly to build our own image. > > It means we can get the updated source code by "./config.sh flame" once we > > have updated base image. > > > > Partner will also provide the tag to us to understand the difference for > > each release. > > How do we handle the case were we need to perform some hacks ? We just fork > it and it's on our side to ensure to keep synced? I'm thinking we should keep the partner's github as the formal release for developers/end users If those hacks are proper to be included in formal release, it should feedback to partner to do so. If not, I think it need to fork in mozilla side. (maybe for test only?) I think we should keep the manifest of flame comes from partner to reduce the maintain effort.

Comment on attachment 8419459 [details] [diff] [review] flame-master-mozril-recovery.patch Review of attachment 8419459 [details] [diff] [review]: ----------------------------------------------------------------- ::: build/core/Makefile @@ +694,4 @@ > @echo Modifying ramdisk contents... > $(hide) rm -f $(TARGET_RECOVERY_ROOT_OUT)/init*.rc > $(hide) cp -f $(recovery_initrc) $(TARGET_RECOVERY_ROOT_OUT)/ > + # $(hide) -cp $(TARGET_ROOT_OUT)/init.recovery.*.rc $(TARGET_RECOVERY_ROOT_OUT)/ This isn't necessary — the prefixed "-" means to ignore errors, which happens: cp: cannot stat ‘out/target/product/flame/root/init.recovery.*.rc’: No such file or directory make: [out/target/product/flame/recovery.img] Error 1 (ignored) @@ +698,2 @@ > $(hide) cp -f $(recovery_binary) $(TARGET_RECOVERY_ROOT_OUT)/sbin/ > + # $(hide) cp -rf $(recovery_resources_common) $(TARGET_RECOVERY_ROOT_OUT)/ This is what's breaking — bootable/recovery/res was replaced with a symlink in commit 241892c: https://codeaurora.org/cgit/quic/la/platform/bootable/recovery/commit/?h=b2g_jb_3.2&id=241892cac47e97d1d83d5bca7dba3d0a254cbbe4 (the commit message doesn't reference a bug or otherwise explain why it was done, but it seems to be present only on the b2g_jb_3.2 branch). There are a few other things that make the build succeed: * adding -H to the cp flags (but see also the use of find(1) on the same path elsewhere in the makefile) * reverting the commit in bootable/recovery (but that might break something else) * adding a trailing / to the definition of recovery_resources_common

I think I can get to a working boot image from here, once I know what we can do with the sdcard fixes — we really do need to modify files under device/qcom for this (or else use gonk-patches, or monkeypatch the makefile variables to pull fstab.qcom and vold.fstab from device/t2m/flame instead, but I don't think either of those would pass review). Also, I'm still running into the problem where I can't escape from the Camera app, even with the SD cards are correctly detected and used.

This is the third approach mentioned in comment #65. Note that this meaning of a trailing slash is specified by POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12 I haven't tested this change other than observing that the right files are copied to the right place. Do we have any kind of automated regression testing (for devices where FOTA already works)?

Any thoughts on how to deal with the device/qcom parts of attachment 8419459 [details] [diff] [review], so that the SD cards can be recognized? As far as I can tell, the only part we actually need is to change the partition number from 20 to 30 in fstab.qcom. We can add files and init.*.rc actions in device_t2m_flame, of course, but I don't know if there's a good way to replace or modify an existing file. (Empirically: if vold is given a partition of wrong type, it logs errors about it and seems to ignore everything following in the fstab, which is why having the wrong number for the internal storage prevents the external SD card from working. If it sees two entries with the same mountpoint, it seems to ignore them both and handle others normally.)

(In reply to Jed Davis [:jld] from comment #69) > We can add files and init.*.rc actions in device_t2m_flame, of course, but I > don't know if there's a good way to replace or modify an existing file. …but we can copy device/qcom/msm8610/AndroidBoard.mk into device/t2m/flame under another name and change its LOCAL_PATH, include it instead of the original, and thus change where fstab.qcom is copied from. And that works, technically, but I don't know if it's good style.

(In reply to Jed Davis [:jld] from comment #69) > Any thoughts on how to deal with the device/qcom parts of attachment 8419459 [details] [diff] [review] > [details] [diff] [review], so that the SD cards can be recognized? As far > as I can tell, the only part we actually need is to change the partition > number from 20 to 30 in fstab.qcom. > > We can add files and init.*.rc actions in device_t2m_flame, of course, but I > don't know if there's a good way to replace or modify an existing file. > > (Empirically: if vold is given a partition of wrong type, it logs errors > about it and seems to ignore everything following in the fstab, which is why > having the wrong number for the internal storage prevents the external SD > card from working. If it sees two entries with the same mountpoint, it > seems to ignore them both and handle others normally.) Yes, this is part of the upcoming patches I have pending.

(In reply to Jed Davis [:jld] from comment #68) > Created attachment 8429695 [details] > Link to Github pull-request: > https://github.com/mozilla-b2g/b2g-manifest/pull/186 Maybe we can also switch bootloader and recovery at the same time?

Now that the device tree stuff landed, using kernel_msm repo from t2m we get a proper boot.img from a kernel point of view. We still lack the init.rc. This one lives in system/core/rootdir, and its copy is controlled by TARGET_PROVIDES_INIT_RC. This variable is forced to true in gonk-misc/b2g.mk however it's not true for Flame for now. Setting it to false I get a bootable boot.img.

Comment on attachment 8418406 [details] [diff] [review] Patch to device/t2m/flame/ to build kernel and boot.img from source. Review of attachment 8418406 [details] [diff] [review]: ----------------------------------------------------------------- This is not a formal review of course, just a way to keep track of the current status of this topic. boot.ver and init.rc are useless :) ::: AndroidBoard.mk @@ +1,5 @@ > include device/qcom/msm8610/AndroidBoard.mk > + > +# FIXME: Why do we need to set this here? It should already be set in BoardConfig. > +BOARD_KERNEL_SEPARATED_DT := true > +include device/qcom/common/generate_extra_images.mk We do not need this anymore. ::: BoardConfig.mk @@ +2,5 @@ > > TARGET_NO_BOOTLOADER := true > + > +TARGET_NO_KERNEL := false > +KERNEL_DEFCONFIG := msm8610_defconfig This can also be removed @@ +3,5 @@ > TARGET_NO_BOOTLOADER := true > + > +TARGET_NO_KERNEL := false > +KERNEL_DEFCONFIG := msm8610_defconfig > +BOARD_KERNEL_CMDLINE := console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 androidboot.bootloader=L1TC000110E0 Same ::: flame.mk @@ +1,5 @@ > $(call inherit-product, device/qcom/msm8610/msm8610.mk) > > PRODUCT_COPY_FILES := \ > + device/qcom/msm8610/audio_policy.conf:system/etc/audio_policy.conf \ > + device/t2m/flame/init/init.rc:root/init.rc \ Can be removed with bug 1016934

https://github.com/mozilla-b2g/platform_build/commit/6e2a3b589d1e8cc1d9df25f5e630ce30a0aa39f3 (attachment #8429694 [details])

And to answer comment #73: I've confirmed that, with the patch from bug 1016934 and t2m's branch of system/core, I can revert the part of the device/t2m/flame patch that adds the init.rc and boot.ver and still get a working image.

Comment on attachment 8429695 [details] Link to Github pull-request: https://github.com/mozilla-b2g/b2g-manifest/pull/186 Just need the mirrors..

Updating jld's pull request to use the new remotes.

(In reply to Alexandre LISSY :gerard-majax from comment #78) > Created attachment 8435572 [details] > Switching to CAF kernel with Flame branch > > Updating jld's pull request to use the new remotes. Looks good to me.

(In reply to Jed Davis [:jld] from comment #79) > (In reply to Alexandre LISSY :gerard-majax from comment #78) > > Created attachment 8435572 [details] > > Switching to CAF kernel with Flame branch > > > > Updating jld's pull request to use the new remotes. > > Looks good to me. Merged: https://github.com/mozilla-b2g/b2g-manifest/commit/6bb75ece2159f39af2860528cfefc5a58155baa5

I did a build on a fresh clone, kernel builds.

<5>[ 0.000000] Linux version 3.4.0-g6d29b67 (alex@portable-alex) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Mon Jun 9 14:59:23 CEST 2014

Taking jld's pull request. We can now just switch this instead of hacking around. Please note the resulting boot.img will not yet be bootable. We will need to land the device tree stuff after this.

(In reply to Alexandre LISSY :gerard-majax from comment #82) > <5>[ 0.000000] Linux version 3.4.0-g6d29b67 (alex@portable-alex) (gcc > version 4.7 (GCC) ) #1 SMP PREEMPT Mon Jun 9 14:59:23 CEST 2014 Once attachment 8436910 [details] lands, and bug 1016940 lands, anybody should be able to reproduce this :)

Comment on attachment 8436910 [details] Build flame kernel Just delete the line.

(In reply to Alexandre LISSY :gerard-majax from comment #83) > Please note the resulting boot.img will not yet be bootable. We will need to > land the device tree stuff after this. Can we just delete both lines in the same commit, or at least the same PR, to avoid having a state where `./build.sh && ./flash.sh` would brick the phone? (flash.sh will skip boot.img if it doesn't exist.)

(In reply to Jed Davis [:jld] from comment #86) > (In reply to Alexandre LISSY :gerard-majax from comment #83) > > Please note the resulting boot.img will not yet be bootable. We will need to > > land the device tree stuff after this. > > Can we just delete both lines in the same commit, or at least the same PR, > to avoid having a state where `./build.sh && ./flash.sh` would brick the > phone? (flash.sh will skip boot.img if it doesn't exist.) You're right, I'll do both at once.

After I downloaded the kernel image I built by myself. the display of the phone was malfunction. I can adb shell, b2g-ps can see b2g related processes. I think the driver of display may be wrong.

Not sure what's the difference between t2m and mozilla kernel, but we met bug 1054131 and bug 1045504 if we use ./flash.sh to flash boot.img built in our side.