ZTE Open nightly builds now available

[Daniel Roesler]

Howdy all,

I finally got around to making a nightly build script for the ZTE
Open. I've only tested these my US version of the ZTE Open (updated to
Version 02 before flashing), so I don't know if they work on the UK
version of the ZTE Open.

Downloads (builds older than 14 days will be removed):
https://daylightpirates.org/b2g_inari_nightly_builds/

Instructions and Code:
https://github.com/diafygi/b2g_inari_nightly

NOTE: I may have to change download servers for the builds if my
bandwidth gets used up, so please reference the github page for the
latest download location.

Avast!
Daniel

[Alexandre Lissy]

You may want to make use of
https://bugzilla.mozilla.org/show_bug.cgi?id=935059 to provide FOTA
updates package.

Le 28/12/2013 19:25, Daniel Roesler a �crit :

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
>

[Daniel Roesler]

Thanks, that would be great to generate nightly FOTA update.zip files.
However, I am not seeing the folder "target_files_intermediates" in my
build folder.

According to the wiki[1], I need to have a kernel binary in the
B2G/vendor/ folder in order to generate the update.zip. Does anyone
know where I can find that?

[1] - https://wiki.mozilla.org/B2G/Updating#Generating_a_complete_FOTA_update_zip_and_target_files_zip

On Sat, Dec 28, 2013 at 1:34 PM, Alexandre Lissy <ali...@mozilla.com> wrote:
> You may want to make use of
> https://bugzilla.mozilla.org/show_bug.cgi?id=935059 to provide FOTA
> updates package.
>

[Robert Kaiser]

Daniel Roesler schrieb:

> I finally got around to making a nightly build script for the ZTE
> Open. I've only tested these my US version of the ZTE Open (updated to
> Version 02 before flashing), so I don't know if they work on the UK
> version of the ZTE Open.

1) How are you able to distribute the binary blobs that AFAIK are not
allowed to be redistributed?

2) To prevent misunderstanding, please do not call them "inari" as that
code name is used for a slightly different (testing-only) device on
which those builds will not work correctly (just like the builds for the
inari do not work correctly on the ZTE Open) as the kernel modules are
different. The code name for the ZTE Open is ikura, so that probably
makes sense to be used there.

KaiRo

[Daniel Roesler]

On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
> Daniel Roesler schrieb:

>>
>> I finally got around to making a nightly build script for the ZTE
>> Open. I've only tested these my US version of the ZTE Open (updated to
>> Version 02 before flashing), so I don't know if they work on the UK
>> version of the ZTE Open.
>
>

> 1) How are you able to distribute the binary blobs that AFAIK are not
> allowed to be redistributed?

The custom boot binary was originally released for open
distribution[1], so including it in the repo isn't a license issue.

I'm not aware that a /system backup (backup-inari.zip) from my ZTE
Open cannot be included with the repo [2]. Can you please link to the
license agreement that must be accepted when purchasing the ZTE Open
that restricts system backups from being published?

All the other binary is compiled from the b2g source, which is open source.

[1] - http://sl.edujose.org/2013/10/adapted-boot-image-for-use-with-b2g.html
[2] - https://developer.mozilla.org/en-US/Firefox_OS/Preparing_for_your_first_B2G_build#Configuring_a_build_using_a_system_backup

>
> 2) To prevent misunderstanding, please do not call them "inari" as that code
> name is used for a slightly different (testing-only) device on which those
> builds will not work correctly (just like the builds for the inari do not
> work correctly on the ZTE Open) as the kernel modules are different. The
> code name for the ZTE Open is ikura, so that probably makes sense to be used
> there.

These are technically inari builds, since the command is "./config.sh
inari". This is the configuration recommended for the ZTE Open in the
wiki[3]. So, I suppose you could flash these builds to your true inari
device, but I don't have one of those so cannot confirm if it works.

[3] - https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/ZTE_OPEN#Device_support

>
> KaiRo

[Daniel Dressler]

2013/12/29 Daniel Roesler <dia...@gmail.com>:

> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>> Daniel Roesler schrieb:
>>>

>>> I finally got around to making a nightly build script for the ZTE
>>> Open. I've only tested these my US version of the ZTE Open (updated to
>>> Version 02 before flashing), so I don't know if they work on the UK
>>> version of the ZTE Open.
>>
>>

>> 1) How are you able to distribute the binary blobs that AFAIK are not
>> allowed to be redistributed?
>
> The custom boot binary was originally released for open
> distribution[1], so including it in the repo isn't a license issue.
>
> I'm not aware that a /system backup (backup-inari.zip) from my ZTE
> Open cannot be included with the repo [2]. Can you please link to the
> license agreement that must be accepted when purchasing the ZTE Open
> that restricts system backups from being published?

The problem is under the Berne Convention copyright is automatic and
restrictive by default. Without an explicit license allowing us the
right to redistribute we are not allowed to distribute the binaries.
The evil goes deep. It's not just a matter of getting ZTE's permission
since they are in turn dependent on their upstream: the SoC
manufacturer and related companies. Even Google has not gotten
redistribution rights for all their phone's parts.

You might have encountered a similar situation if you used linux with
a broadcom wireless a few years back. The wireless required a binary
blob which no linux distribution was allowed to include on the install
CD. What we ended up doing was writing a program which would download
the windows driver and extract the binary blob.

So what we could do is if ZTE has a working zip on their site we can
have the build script download that and extract the relevant files.
The risk of course is not that anyone on this list will get mad but
rather that ZTE or their upstream will sue you.

Daniel

[Alexandre Lissy]

Le 29/12/2013 17:24, Daniel Dressler a �crit :

> 2013/12/29 Daniel Roesler <dia...@gmail.com>:
>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>>> Daniel Roesler schrieb:
>>>>

>>>> I finally got around to making a nightly build script for the ZTE
>>>> Open. I've only tested these my US version of the ZTE Open (updated to
>>>> Version 02 before flashing), so I don't know if they work on the UK
>>>> version of the ZTE Open.
>>>
>>>

>>> 1) How are you able to distribute the binary blobs that AFAIK are not
>>> allowed to be redistributed?
>>
>> The custom boot binary was originally released for open
>> distribution[1], so including it in the repo isn't a license issue.
>>
>> I'm not aware that a /system backup (backup-inari.zip) from my ZTE
>> Open cannot be included with the repo [2]. Can you please link to the
>> license agreement that must be accepted when purchasing the ZTE Open
>> that restricts system backups from being published?
>
> The problem is under the Berne Convention copyright is automatic and
> restrictive by default. Without an explicit license allowing us the
> right to redistribute we are not allowed to distribute the binaries.
> The evil goes deep. It's not just a matter of getting ZTE's permission
> since they are in turn dependent on their upstream: the SoC
> manufacturer and related companies. Even Google has not gotten
> redistribution rights for all their phone's parts.
>
> You might have encountered a similar situation if you used linux with
> a broadcom wireless a few years back. The wireless required a binary
> blob which no linux distribution was allowed to include on the install
> CD. What we ended up doing was writing a program which would download
> the windows driver and extract the binary blob.
>
> So what we could do is if ZTE has a working zip on their site we can
> have the build script download that and extract the relevant files.
> The risk of course is not that anyone on this list will get mad but
> rather that ZTE or their upstream will sue you.

This is already what is done for Nexus devices and for all of our
devices supported: we download blobs from website (Nexus) or from device
itself.

This also explains the issues we encounter with some devices, where we
do not have uptodate blobs to build a fully working image from scratch.

>
> Daniel

[an]

This is the kind of comment (not contesting it's technical correctness) that can ruin my holidays :) BTW when I build for zte open it's called "full_inari".
So what's the point of tapping ourselves on the shoulder instead of no one.

[Robert Kaiser]

Daniel Roesler schrieb:

> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>> 2) To prevent misunderstanding, please do not call them "inari" as that code
>> name is used for a slightly different (testing-only) device on which those
>> builds will not work correctly (just like the builds for the inari do not
>> work correctly on the ZTE Open) as the kernel modules are different. The
>> code name for the ZTE Open is ikura, so that probably makes sense to be used
>> there.
>
> These are technically inari builds, since the command is "./config.sh
> inari". This is the configuration recommended for the ZTE Open in the
> wiki[3]. So, I suppose you could flash these builds to your true inari
> device, but I don't have one of those so cannot confirm if it works.

The "inari" build configuration can be used to generate builds for the
inari (testing device) as well as the ikura (ZTE Open) - but the
resulting build only work on the one whose kernel etc. you used for
building. I know it's confusing, but that's what it is. I ran into the
same kind of issues when trying a build generated for inari on a ZTE
Open and found out it does not work correctly (it boots but e.g. wifi
isn't working) - I'm pretty sure it's the same the other way round.

KaiRo

[Daniel Roesler]

So should the MDN page be changed to the correct config setting?

On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:

> Daniel Roesler schrieb:
>
>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>>
>>> 2) To prevent misunderstanding, please do not call them "inari" as that
>>> code
>>> name is used for a slightly different (testing-only) device on which
>>> those
>>> builds will not work correctly (just like the builds for the inari do not
>>> work correctly on the ZTE Open) as the kernel modules are different. The
>>> code name for the ZTE Open is ikura, so that probably makes sense to be
>>> used
>>> there.
>>>
>>
>> These are technically inari builds, since the command is "./config.sh
>> inari". This is the configuration recommended for the ZTE Open in the
>> wiki[3]. So, I suppose you could flash these builds to your true inari
>> device, but I don't have one of those so cannot confirm if it works.
>>
>

> The "inari" build configuration can be used to generate builds for the
> inari (testing device) as well as the ikura (ZTE Open) - but the resulting
> build only work on the one whose kernel etc. you used for building. I know
> it's confusing, but that's what it is. I ran into the same kind of issues
> when trying a build generated for inari on a ZTE Open and found out it does
> not work correctly (it boots but e.g. wifi isn't working) - I'm pretty sure
> it's the same the other way round.
>

[Chris Mills]

Hi guys,

Feel free to pass corrections to me to implement, if needed. I wrote the current docs as they are because I was told the ZTE Open would work with Inari B2G builds. Let me know what is wrong and needs updating.

cheers,

Chris Mills
Senior tech writer || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills

On 30 Dec 2013, at 07:38, Daniel Roesler <dia...@gmail.com> wrote:

> So should the MDN page be changed to the correct config setting?

> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
>
>> Daniel Roesler schrieb:
>>
>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>>>
>>>> 2) To prevent misunderstanding, please do not call them "inari" as that
>>>> code
>>>> name is used for a slightly different (testing-only) device on which
>>>> those
>>>> builds will not work correctly (just like the builds for the inari do not
>>>> work correctly on the ZTE Open) as the kernel modules are different. The
>>>> code name for the ZTE Open is ikura, so that probably makes sense to be
>>>> used
>>>> there.
>>>>
>>>
>>> These are technically inari builds, since the command is "./config.sh
>>> inari". This is the configuration recommended for the ZTE Open in the
>>> wiki[3]. So, I suppose you could flash these builds to your true inari
>>> device, but I don't have one of those so cannot confirm if it works.
>>>
>>

>> The "inari" build configuration can be used to generate builds for the
>> inari (testing device) as well as the ikura (ZTE Open) - but the resulting
>> build only work on the one whose kernel etc. you used for building. I know
>> it's confusing, but that's what it is. I ran into the same kind of issues
>> when trying a build generated for inari on a ZTE Open and found out it does
>> not work correctly (it boots but e.g. wifi isn't working) - I'm pretty sure
>> it's the same the other way round.
>>

[Daniel Roesler]

All,

I've updated the repo[1] so that it downloads the binary backup for
the nightly build from ZTE's website (so there's no issue of copyright
in the repo).

[1] - https://github.com/diafygi/b2g_inari_nightly/commit/488d759

Happy New Year!
Daniel Roesler

On Thu, Jan 2, 2014 at 5:12 AM, Chris Mills <cmi...@mozilla.com> wrote:
> Hi guys,
>
> Feel free to pass corrections to me to implement, if needed. I wrote the current docs as they are because I was told the ZTE Open would work with Inari B2G builds. Let me know what is wrong and needs updating.
>
> cheers,
>
> Chris Mills
> Senior tech writer || Mozilla
> developer.mozilla.org || MDN
> cmi...@mozilla.com || @chrisdavidmills
>
>
>
> On 30 Dec 2013, at 07:38, Daniel Roesler <dia...@gmail.com> wrote:
>
>> So should the MDN page be changed to the correct config setting?

>> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
>>
>>> Daniel Roesler schrieb:
>>>
>>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>>>>
>>>>> 2) To prevent misunderstanding, please do not call them "inari" as that
>>>>> code
>>>>> name is used for a slightly different (testing-only) device on which
>>>>> those
>>>>> builds will not work correctly (just like the builds for the inari do not
>>>>> work correctly on the ZTE Open) as the kernel modules are different. The
>>>>> code name for the ZTE Open is ikura, so that probably makes sense to be
>>>>> used
>>>>> there.
>>>>>
>>>>
>>>> These are technically inari builds, since the command is "./config.sh
>>>> inari". This is the configuration recommended for the ZTE Open in the
>>>> wiki[3]. So, I suppose you could flash these builds to your true inari
>>>> device, but I don't have one of those so cannot confirm if it works.
>>>>
>>>

>>> The "inari" build configuration can be used to generate builds for the
>>> inari (testing device) as well as the ikura (ZTE Open) - but the resulting
>>> build only work on the one whose kernel etc. you used for building. I know
>>> it's confusing, but that's what it is. I ran into the same kind of issues
>>> when trying a build generated for inari on a ZTE Open and found out it does
>>> not work correctly (it boots but e.g. wifi isn't working) - I'm pretty sure
>>> it's the same the other way round.
>>>

[Julien Wajsberg]

Thanks a lot Daniel.

I can't test this now (I don't have my ZTE) but if this works you did
really better than what we had before ;)

Would love to see the "blob download" part integrated into our own build
system.

Le 03/01/2014 04:58, Daniel Roesler a écrit :
> All,
>
> I've updated the repo[1] so that it downloads the binary backup for
> the nightly build from ZTE's website (so there's no issue of copyright
> in the repo).
>
> [1] - https://github.com/diafygi/b2g_inari_nightly/commit/488d759
>
> Happy New Year!
> Daniel Roesler
>
> On Thu, Jan 2, 2014 at 5:12 AM, Chris Mills <cmi...@mozilla.com> wrote:
>> Hi guys,
>>
>> Feel free to pass corrections to me to implement, if needed. I wrote the current docs as they are because I was told the ZTE Open would work with Inari B2G builds. Let me know what is wrong and needs updating.
>>
>> cheers,
>>
>> Chris Mills
>> Senior tech writer || Mozilla
>> developer.mozilla.org || MDN
>> cmi...@mozilla.com || @chrisdavidmills
>>
>>
>>
>> On 30 Dec 2013, at 07:38, Daniel Roesler <dia...@gmail.com> wrote:
>>
>>> So should the MDN page be changed to the correct config setting?

>>> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
>>>
>>>> Daniel Roesler schrieb:
>>>>
>>>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at> wrote:
>>>>>
>>>>>> 2) To prevent misunderstanding, please do not call them "inari" as that
>>>>>> code
>>>>>> name is used for a slightly different (testing-only) device on which
>>>>>> those
>>>>>> builds will not work correctly (just like the builds for the inari do not
>>>>>> work correctly on the ZTE Open) as the kernel modules are different. The
>>>>>> code name for the ZTE Open is ikura, so that probably makes sense to be
>>>>>> used
>>>>>> there.
>>>>>>
>>>>> These are technically inari builds, since the command is "./config.sh
>>>>> inari". This is the configuration recommended for the ZTE Open in the
>>>>> wiki[3]. So, I suppose you could flash these builds to your true inari
>>>>> device, but I don't have one of those so cannot confirm if it works.
>>>>>

>>>> The "inari" build configuration can be used to generate builds for the
>>>> inari (testing device) as well as the ikura (ZTE Open) - but the resulting
>>>> build only work on the one whose kernel etc. you used for building. I know
>>>> it's confusing, but that's what it is. I ran into the same kind of issues
>>>> when trying a build generated for inari on a ZTE Open and found out it does
>>>> not work correctly (it boots but e.g. wifi isn't working) - I'm pretty sure
>>>> it's the same the other way round.
>>>>

[Daniel Roesler]

Thanks!

I'm still looking for some documentation on how to create update.zip file.
Has anyone been able to do that?

I think those might be easier for people to use than the flash.sh method
since you wouldn't need to set up adb in your computer (you'd just need to
copy the update.zip file to your microSD card and boot the phone into
recovery mode).

> >>> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
> >>>
> >>>> Daniel Roesler schrieb:
> >>>>
> >>>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at>
> wrote:
> >>>>>
> >>>>>> 2) To prevent misunderstanding, please do not call them "inari" as
> that
> >>>>>> code
> >>>>>> name is used for a slightly different (testing-only) device on which
> >>>>>> those
> >>>>>> builds will not work correctly (just like the builds for the inari
> do not
> >>>>>> work correctly on the ZTE Open) as the kernel modules are
> different. The
> >>>>>> code name for the ZTE Open is ikura, so that probably makes sense
> to be
> >>>>>> used
> >>>>>> there.
> >>>>>>
> >>>>> These are technically inari builds, since the command is "./config.sh
> >>>>> inari". This is the configuration recommended for the ZTE Open in the
> >>>>> wiki[3]. So, I suppose you could flash these builds to your true
> inari
> >>>>> device, but I don't have one of those so cannot confirm if it works.
> >>>>>

> >>>> The "inari" build configuration can be used to generate builds for the
> >>>> inari (testing device) as well as the ikura (ZTE Open) - but the
> resulting
> >>>> build only work on the one whose kernel etc. you used for building. I
> know
> >>>> it's confusing, but that's what it is. I ran into the same kind of
> issues
> >>>> when trying a build generated for inari on a ZTE Open and found out
> it does
> >>>> not work correctly (it boots but e.g. wifi isn't working) - I'm
> pretty sure
> >>>> it's the same the other way round.
> >>>>

[Alexandre Lissy]

Le 03/01/2014 13:41, Daniel Roesler a �crit :

> Thanks!
>
> I'm still looking for some documentation on how to create update.zip file.
> Has anyone been able to do that?

Are you referring to https://bugzilla.mozilla.org/show_bug.cgi?id=935059 ?

We already have some tools available that are used by this bug

>
> I think those might be easier for people to use than the flash.sh method
> since you wouldn't need to set up adb in your computer (you'd just need to
> copy the update.zip file to your microSD card and boot the phone into
> recovery mode).
> On Jan 3, 2014 3:40 AM, "Julien Wajsberg" <jwaj...@mozilla.com> wrote:
>
>> Thanks a lot Daniel.
>>
>> I can't test this now (I don't have my ZTE) but if this works you did
>> really better than what we had before ;)
>>
>> Would love to see the "blob download" part integrated into our own build
>> system.
>>

>> Le 03/01/2014 04:58, Daniel Roesler a �crit :

>>> All,
>>>
>>> I've updated the repo[1] so that it downloads the binary backup for
>>> the nightly build from ZTE's website (so there's no issue of copyright
>>> in the repo).
>>>
>>> [1] - https://github.com/diafygi/b2g_inari_nightly/commit/488d759
>>>
>>> Happy New Year!
>>> Daniel Roesler
>>>
>>> On Thu, Jan 2, 2014 at 5:12 AM, Chris Mills <cmi...@mozilla.com> wrote:
>>>> Hi guys,
>>>>
>>>> Feel free to pass corrections to me to implement, if needed. I wrote
>> the current docs as they are because I was told the ZTE Open would work
>> with Inari B2G builds. Let me know what is wrong and needs updating.
>>>>
>>>> cheers,
>>>>
>>>> Chris Mills
>>>> Senior tech writer || Mozilla
>>>> developer.mozilla.org || MDN
>>>> cmi...@mozilla.com || @chrisdavidmills
>>>>
>>>>
>>>>
>>>> On 30 Dec 2013, at 07:38, Daniel Roesler <dia...@gmail.com> wrote:
>>>>
>>>>> So should the MDN page be changed to the correct config setting?

>>>>> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
>>>>>
>>>>>> Daniel Roesler schrieb:
>>>>>>
>>>>>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at>
>> wrote:
>>>>>>>
>>>>>>>> 2) To prevent misunderstanding, please do not call them "inari" as
>> that
>>>>>>>> code
>>>>>>>> name is used for a slightly different (testing-only) device on which
>>>>>>>> those
>>>>>>>> builds will not work correctly (just like the builds for the inari
>> do not
>>>>>>>> work correctly on the ZTE Open) as the kernel modules are
>> different. The
>>>>>>>> code name for the ZTE Open is ikura, so that probably makes sense
>> to be
>>>>>>>> used
>>>>>>>> there.
>>>>>>>>
>>>>>>> These are technically inari builds, since the command is "./config.sh
>>>>>>> inari". This is the configuration recommended for the ZTE Open in the
>>>>>>> wiki[3]. So, I suppose you could flash these builds to your true
>> inari
>>>>>>> device, but I don't have one of those so cannot confirm if it works.
>>>>>>>

>>>>>> The "inari" build configuration can be used to generate builds for the
>>>>>> inari (testing device) as well as the ikura (ZTE Open) - but the
>> resulting
>>>>>> build only work on the one whose kernel etc. you used for building. I
>> know
>>>>>> it's confusing, but that's what it is. I ran into the same kind of
>> issues
>>>>>> when trying a build generated for inari on a ZTE Open and found out
>> it does
>>>>>> not work correctly (it boots but e.g. wifi isn't working) - I'm
>> pretty sure
>>>>>> it's the same the other way round.
>>>>>>

[Gabriele Svelto]

Hi Daniel,

> I'm still looking for some documentation on how to create update.zip
file.
> Has anyone been able to do that?

besides the bug mentioned by Alexandre we have the existing
functionality documented here:

https://wiki.mozilla.org/B2G/Updating

Gabriele

[an]

How about, for the sake of sanity, rename any upgrade path for this device to "zte_open"?
Everything else is just technical details, really. I mean zte open has been a total failure from the user/developer perspective maybe it's time for some sanity.
This is no criticism towards someone in particular but having the docs specify that if you want to build for zte open you must choose inari and now having some guy explain that the builds for inari (which actually work on the phone) have some "defect" because the "real" code name is ikura either make him look like an idiot or Mozilla, and I tend to believe it's not him.

Comments like "I know it's confusing, but that's what it is" while they may work within a corporate environment don't go particularly well with the real world, where people actually pay a really high price for a really low end device just because it's labeled a "developer/open" device which it is not.

So, the phone is garbage (as hardware), the kernel&all is proprietary and the OS building components are not exactly sure because we deal with conflicting "code" names.
Call me I'm insane...

[Daniel Roesler]

On Fri, Jan 3, 2014 at 11:55 AM, Gabriele Svelto <gsv...@mozilla.com> wrote:
> Hi Daniel,
>
>
>> I'm still looking for some documentation on how to create update.zip file.
>>
>> Has anyone been able to do that?
>
>
> besides the bug mentioned by Alexandre we have the existing functionality
> documented here:
>
> https://wiki.mozilla.org/B2G/Updating

That's what I was looking at when I mentioned building an update.zip
earlier in this thread[1]. It says, "The default target in the B2G
build system will generate a FOTA update.zip / target files zip when
the kernel binary has been copied to the appropriate location under
vendor/. This enables boot image, recovery image, and update.zip
generation."[2]

After the build, I can't find any update.zip or even the
"target_files_intermediates" folder, so I'm assuming I don't have the
kernel binary in the correct place.

What files constitute the "kernel" that's needed?

Do I just need to copy the downloaded update.zip /system from the ZTE
website download into another folder beside "backup-inari"?

Do I need to run config.sh or build.sh with a special argument (as it
says in Alexandre's bug comments[3])?

[1] - https://groups.google.com/d/msg/mozilla.dev.b2g/dENpc-7Fbi4/o1nR6_UeW6cJ
[2] - https://wiki.mozilla.org/B2G/Updating#Generating_a_complete_FOTA_update_zip_and_target_files_zip
[3] - https://bugzilla.mozilla.org/show_bug.cgi?id=935059#c72

>
> Gabriele
>

[Daniel Roesler]

Howdy Alexandre,

I'm getting a "make: *** No rule to make target
`gecko-update-fota-full'. Stop." error when I try to run "./build.sh
gecko-update-fota-full". Is there something else I should be doing?

On Fri, Jan 3, 2014 at 6:53 AM, Alexandre Lissy <ali...@mozilla.com> wrote:
> Le 03/01/2014 13:41, Daniel Roesler a écrit :
>> Thanks!

>>
>> I'm still looking for some documentation on how to create update.zip file.
>> Has anyone been able to do that?
>

>>>>>> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
>>>>>>
>>>>>>> Daniel Roesler schrieb:
>>>>>>>
>>>>>>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at>
>>> wrote:
>>>>>>>>
>>>>>>>>> 2) To prevent misunderstanding, please do not call them "inari" as
>>> that
>>>>>>>>> code
>>>>>>>>> name is used for a slightly different (testing-only) device on which
>>>>>>>>> those
>>>>>>>>> builds will not work correctly (just like the builds for the inari
>>> do not
>>>>>>>>> work correctly on the ZTE Open) as the kernel modules are
>>> different. The
>>>>>>>>> code name for the ZTE Open is ikura, so that probably makes sense
>>> to be
>>>>>>>>> used
>>>>>>>>> there.
>>>>>>>>>
>>>>>>>> These are technically inari builds, since the command is "./config.sh
>>>>>>>> inari". This is the configuration recommended for the ZTE Open in the
>>>>>>>> wiki[3]. So, I suppose you could flash these builds to your true
>>> inari
>>>>>>>> device, but I don't have one of those so cannot confirm if it works.
>>>>>>>>

>>>>>>> The "inari" build configuration can be used to generate builds for the
>>>>>>> inari (testing device) as well as the ikura (ZTE Open) - but the
>>> resulting

>>>>>>> build only work on the one whose kernel etc. you used for building. I
>>> know

>>>>>>> it's confusing, but that's what it is. I ran into the same kind of
>>> issues
>>>>>>> when trying a build generated for inari on a ZTE Open and found out
>>> it does
>>>>>>> not work correctly (it boots but e.g. wifi isn't working) - I'm
>>> pretty sure
>>>>>>> it's the same the other way round.
>>>>>>>

[Alexandre Lissy]

Le 04/01/2014 06:01, Daniel Roesler a �crit :

> Howdy Alexandre,
>
> I'm getting a "make: *** No rule to make target
> `gecko-update-fota-full'. Stop." error when I try to run "./build.sh
> gecko-update-fota-full". Is there something else I should be doing?

Did you take and applied the patches ?

>
> On Fri, Jan 3, 2014 at 6:53 AM, Alexandre Lissy <ali...@mozilla.com> wrote:

>> Le 03/01/2014 13:41, Daniel Roesler a �crit :

>>> Thanks!
>>>
>>> I'm still looking for some documentation on how to create update.zip file.
>>> Has anyone been able to do that?
>>
>> Are you referring to https://bugzilla.mozilla.org/show_bug.cgi?id=935059 ?
>>
>> We already have some tools available that are used by this bug
>>
>>>
>>> I think those might be easier for people to use than the flash.sh method
>>> since you wouldn't need to set up adb in your computer (you'd just need to
>>> copy the update.zip file to your microSD card and boot the phone into
>>> recovery mode).
>>> On Jan 3, 2014 3:40 AM, "Julien Wajsberg" <jwaj...@mozilla.com> wrote:
>>>
>>>> Thanks a lot Daniel.
>>>>
>>>> I can't test this now (I don't have my ZTE) but if this works you did
>>>> really better than what we had before ;)
>>>>
>>>> Would love to see the "blob download" part integrated into our own build
>>>> system.
>>>>

>>>> Le 03/01/2014 04:58, Daniel Roesler a �crit :

>>>>> All,
>>>>>
>>>>> I've updated the repo[1] so that it downloads the binary backup for
>>>>> the nightly build from ZTE's website (so there's no issue of copyright
>>>>> in the repo).
>>>>>
>>>>> [1] - https://github.com/diafygi/b2g_inari_nightly/commit/488d759
>>>>>
>>>>> Happy New Year!
>>>>> Daniel Roesler
>>>>>
>>>>> On Thu, Jan 2, 2014 at 5:12 AM, Chris Mills <cmi...@mozilla.com> wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> Feel free to pass corrections to me to implement, if needed. I wrote
>>>> the current docs as they are because I was told the ZTE Open would work
>>>> with Inari B2G builds. Let me know what is wrong and needs updating.
>>>>>>
>>>>>> cheers,
>>>>>>
>>>>>> Chris Mills
>>>>>> Senior tech writer || Mozilla
>>>>>> developer.mozilla.org || MDN
>>>>>> cmi...@mozilla.com || @chrisdavidmills
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 30 Dec 2013, at 07:38, Daniel Roesler <dia...@gmail.com> wrote:
>>>>>>
>>>>>>> So should the MDN page be changed to the correct config setting?

>>>>>>> On Dec 29, 2013 4:04 PM, "Robert Kaiser" <ka...@kairo.at> wrote:
>>>>>>>
>>>>>>>> Daniel Roesler schrieb:
>>>>>>>>
>>>>>>>>> On Sun, Dec 29, 2013 at 7:24 AM, Robert Kaiser <ka...@kairo.at>
>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 2) To prevent misunderstanding, please do not call them "inari" as
>>>> that
>>>>>>>>>> code
>>>>>>>>>> name is used for a slightly different (testing-only) device on which
>>>>>>>>>> those
>>>>>>>>>> builds will not work correctly (just like the builds for the inari
>>>> do not
>>>>>>>>>> work correctly on the ZTE Open) as the kernel modules are
>>>> different. The
>>>>>>>>>> code name for the ZTE Open is ikura, so that probably makes sense
>>>> to be
>>>>>>>>>> used
>>>>>>>>>> there.
>>>>>>>>>>
>>>>>>>>> These are technically inari builds, since the command is "./config.sh
>>>>>>>>> inari". This is the configuration recommended for the ZTE Open in the
>>>>>>>>> wiki[3]. So, I suppose you could flash these builds to your true
>>>> inari
>>>>>>>>> device, but I don't have one of those so cannot confirm if it works.
>>>>>>>>>

>>>>>>>> The "inari" build configuration can be used to generate builds for the
>>>>>>>> inari (testing device) as well as the ikura (ZTE Open) - but the
>>>> resulting
>>>>>>>> build only work on the one whose kernel etc. you used for building. I
>>>> know
>>>>>>>> it's confusing, but that's what it is. I ran into the same kind of
>>>> issues
>>>>>>>> when trying a build generated for inari on a ZTE Open and found out
>>>> it does
>>>>>>>> not work correctly (it boots but e.g. wifi isn't working) - I'm
>>>> pretty sure
>>>>>>>> it's the same the other way round.
>>>>>>>>

[Robert Kaiser]

The thing there is that the *config setting* is correct, "inari" there
works for both the actual inari (testing) devices and the ZTE Open
(ikura). The generated builds only work on one of them, though, based on
what device your backed-up /system files come from.

KaiRo


Chris Mills schrieb:

[Julien Wajsberg]

Le 03/01/2014 21:47, an a écrit :
> How about, for the sake of sanity, rename any upgrade path for this device to "zte_open"?
> Everything else is just technical details, really. I mean zte open has been a total failure from the user/developer perspective maybe it's time for some sanity.
> This is no criticism towards someone in particular but having the docs specify that if you want to build for zte open you must choose inari and now having some guy explain that the builds for inari (which actually work on the phone) have some "defect" because the "real" code name is ikura either make him look like an idiot or Mozilla, and I tend to believe it's not him.

AFAIK all the Mozilla code is the same for inari/ikura.

What's different is the various binary blobs, and thus the final builds.

--
JUlien

[Chris Mills]

Ack, this sounds complicated. I’m not sure how best to communicate this.

So the ZTE OPEN eBay devices are ikura, and the other ones are inari, or have I got that wrong? I’ve mainly written the MDN ZTE page from the point of view of the eBay devices, so perhaps I should add a section about non-eBay ZTE devices?

Chris Mills
Senior tech writer || Mozilla
developer.mozilla.org || MDN
cmi...@mozilla.com || @chrisdavidmills

On 4 Jan 2014, at 13:58, Robert Kaiser <ka...@kairo.at> wrote:

> The thing there is that the *config setting* is correct, "inari" there works for both the actual inari (testing) devices and the ZTE Open (ikura). The generated builds only work on one of them, though, based on what device your backed-up /system files come from.
>
> KaiRo
>
>
> Chris Mills schrieb:

[Julien Wajsberg]

AFAIK all ZTE Open are Ikura.

But I just learnt like you that the ebay and Movistar devices are
different...

Le 06/01/2014 11:00, Chris Mills a écrit :
> Ack, this sounds complicated. I’m not sure how best to communicate this.
>
> So the ZTE OPEN eBay devices are ikura, and the other ones are inari, or have I got that wrong? I’ve mainly written the MDN ZTE page from the point of view of the eBay devices, so perhaps I should add a section about non-eBay ZTE devices?
>

> Chris Mills
> Senior tech writer || Mozilla
> developer.mozilla.org || MDN
> cmi...@mozilla.com || @chrisdavidmills
>
>
>

> On 4 Jan 2014, at 13:58, Robert Kaiser <ka...@kairo.at> wrote:
>
>> The thing there is that the *config setting* is correct, "inari" there works for both the actual inari (testing) devices and the ZTE Open (ikura). The generated builds only work on one of them, though, based on what device your backed-up /system files come from.
>>
>> KaiRo
>>
>>
>> Chris Mills schrieb:

[an]

On Monday, January 6, 2014 12:00:48 PM UTC+2, Chris Mills wrote:
> Ack, this sounds complicated. I’m not sure how best to communicate this.
>
>
>
> So the ZTE OPEN eBay devices are ikura, and the other ones are inari, or have I got that wrong? I’ve mainly written the MDN ZTE page from the point of view of the eBay devices, so perhaps I should add a section about non-eBay ZTE devices?

Actually if you do a search for ikura on Bugzilla you only get the ones for zte open in the Spanish speaking countries.
Depends whom you ask... :)

[joui...@gmail.com]

Hi Daniel! Can you make these builds flashable on the new 1.1.0b2 update for the Zte Open?

Thank you! great work!

[Daniel Roesler]

Yep, on it.

[Daniel Roesler]

I have been trying for the past few days to compile using the new ZTE 1.1 release as the backup-inari reference folder. However, I am running across the same boot loop issue that everyone else seems to be facing[1].

I have opened a Bug #965180 to track this reboot loop issue. Until it gets fixed, I have stopped my auto-nightly build script :(

[1] - https://groups.google.com/forum/#!msg/mozilla.dev.b2g/-HgDlr4pJtM/5XV_eteNhy4J
[2] - https://bugzilla.mozilla.org/show_bug.cgi?id=965180

[pazos]

Hi Daniel. I asume that you have version 1.0.1 installed on your phone. You'll need to upgrade it via ZTE upgrade *before* install new builds with other blobs.

Some partitions are upgraded by ZTE upgrades but not via ./flash.sh (like the bootloader or the modem firmware, and you need to have the same version installed.

I don't know why, maybe kernel signing changes between 1.0.1 & 1.1.0?

ZTE says that info is confidential, I'm not going to buy another ZTE in the rest of my life (I hope everybody think the same)

[Abhiram Chintangal]

> ZTE says that info is confidential, I'm not going to buy another ZTE in the rest of my life (I hope everybody think the same)

I think so too , I am currently running my custom build of firefox os
on the Open. In my case I had to downgrade to the older-firmware with
clockworkmod and
then flash it with my build.
--
Abhiram Chintangal

[Daniel Roesler]

<rant>
I'm not disappointed at all in ZTE. This phone is dirt cheap, so what
can you expect for support? For $80, I definitely expected to be
hacking constantly to get it working.

The one I am very disappointed in is Mozilla.

The ZTE Open is their flagship phone and there are many more of them
out there than any other Firefox OS phone. If developers got a bad
taste from that device, they would like write off Firefox OS as a
flop.

I expected Mozilla to be hacking right along side us, but it's almost
as if no one at Mozilla even owns a ZTE Open or can confirm that the
problems we are experiencing since 1.1 even exist.

Why should I have to file a bug report about the reboot loop issue?
This is a blocking bug that prevents app developers (for the most
popular phone) from upgrading to more recent versions. Not only should
it have existed, it should have been marked as critical.

Also, why do we have to download Eduardo's modified boot image (thanks
for that, by the way)? There should be a build patch/script that
unpacks and modifies the ZTE official boot.img to get a compatible
boot.img.

Anyway, extremely disappointed in Mozilla. The lack of developer
support for the ZTE Open will probably be the poison pill that kills
Firefox OS's momentum.
</rant>

On Wed, Jan 29, 2014 at 6:49 AM, Abhiram Chintangal
<abhiram.c...@gmail.com> wrote:
>> ZTE says that info is confidential, I'm not going to buy another ZTE in the rest of my life (I hope everybody think the same)
>

> I think so too , I am currently running my custom build of firefox os
> on the Open. In my case I had to downgrade to the older-firmware with
> clockworkmod and
> then flash it with my build.
> --
> Abhiram Chintangal

[an]

AFAIC Daniel is 100% right though ZTE's secrecy on everything regarding this stupid phone which *they* marketed as a developer phone on eBay is plain idiotic. Where is the partner?

[Daniel Roesler]

And since in engineering school they tell you to never come with half
a thing. Here's my proposal for a solution:

Since apparently no Mozilla developers have ZTE Opens, I will
personally buy up to 5 ZTE Opens for any Mozilla developers that can
work to support flashing custom builds to the device.

Any takers?

> On Wed, Jan 29, 2014 at 6:49 AM, Abhiram Chintangal
> <abhiram.c...@gmail.com> wrote:

>>> ZTE says that info is confidential, I'm not going to buy another ZTE in the rest of my life (I hope everybody think the same)
>>

>> I think so too , I am currently running my custom build of firefox os
>> on the Open. In my case I had to downgrade to the older-firmware with
>> clockworkmod and
>> then flash it with my build.
>> --
>> Abhiram Chintangal

[pazos]

@Daniel: Mozilla has no control over the bootloader, the kernel, the radio firmware, because its not part of B2G. IMO Its not mozilla's fault but provider fault. ZTE does not complain with any opensource licenses at all.

I'm currently mergin some geeksphone init scripts to device-inari tree in order to fully build boot.img from B2G sources. (extracting the kernel from the device is pretty trivial). I already made a pull request to add proximity sensor support and I'm waiting for merge.

But none of those things will keep us to have some problems between versions, because they are *NOT COMPATIBLE AT ALL*

If you want to provide custom builds to people over the net you should notify the version which was used to pick the blobs. I would suggest to update all the phones to new 1.1.0B02 firmware and then rebuild the whole B2G (first remove the backup-inari folder to be sure that all the blobs are picked from your phone).

[Daniel Roesler]

What I don't understand:

Mozilla has so much to lose from a bad ZTE Open experience. It is
their flagship device! It's the _only_ native Firefox OS device you
can buy now, and it's extremely cheap so developers can easily try
Firefox OS out.

I'd guess that there's an order of magnitude more app developers
trying Firefox OS on the ZTE Open than all other devices combined. If
they get frustrated, you have basically killed your entire app
developer community. That's a huge price to pay. Mozilla has way more
to lose than ZTE does. So why isn't Mozilla stepping up to make up for
ZTE's lack of support?

Finally, not having control over the kernel/firmware never stopped
anyone from figuring out how to make it work. Android modders have
been dealing with that crap for years, and they still keep cranking
out upgrades just fine. So I don't think that's a valid excuse when
your project's future is on the line.

[pazos]

link to version 1.2 based on 1.0.1 from ZTE > http://ul.to/zsta3kfw
link to version 1.2 based on 1.1.0 from ZTE > http://ul.to/2jwkruhj

Both built by me, installable through fastboot or cwm recovery. If you look inside the zip you'll found a lot of zte crap files that explain why are NOT compatible?

Early adopters who build B2G based on 1.0.1 blobs need to upgrade the firmware to 1.1.0 before trying to flash any rom based on 1.1.0 blobs.

Mozilla just need to update their wiki to suggest all their users to switch to the lastest firmware with fastboot enabled, just to make sure anyone could flash any B2G build (yours , mine or another one) whithout this bootloop issue, which, I repeat, it is NOT mozilla's fault

[an]

On Wednesday, January 29, 2014 10:08:55 PM UTC+2, Daniel Roesler wrote:


> Finally, not having control over the kernel/firmware never stopped
>
> anyone from figuring out how to make it work. Android modders have
>
> been dealing with that crap for years, and they still keep cranking
>
> out upgrades just fine. So I don't think that's a valid excuse when
>
> your project's future is on the line.
>

Asking Mozilla to hack their "partner"? How about a community driven FirefoxOS-mod that could also help porting to other devices?

[Daniel Dressler]

Mozilla cannot, and in some cases even ZTE cannot. The mods on XDA are
almost all violating various copyrights.

The entire mobile SOC ecosystem is built on binary blobs and
"propreitary" binary kernel modules. The blobs are there to feed and
bootstrap the SOC's devices, the blob itself is the hardware's
firmware. The "propreitary" modules are often derivatives of the
kernel released without source.

The last point is something I feel like ranting on.

In the kernel we export various symbols/functions. Some of these are
marked GPL_ONLY and to access them at compile time you must declare
your module GPL.

Now you might think that provided you do not use GPL_ONLY symbols then
your module does not need to be under GPL. This is not the case. The
only thing GPL_ONLY means is that if you use those then the kernel
devs are 99% sure your module is a derivative work of the kernel and
must be distributed under the GPL. Its still dead easy to make a
derivative of the kernel without those symbols. The reason things
continue is because the kernel community is betting that violators
will come in line given time.

Unless we own a copyright claim on the linux kernel we cannot even
threaten to sue to the those modules under GPL. You must own the
copyright on something to sue over it.

Even if we did have grounds to sue there is no clear target. ZTE is
not withholding the sources from us, if they have access to the source
its been granted by their upstream under the condition ZTE will not
pass it on. I bet in turn the SOC manufacturer does not even have all
the rights to release the module under GPL, there is just that much
copyright violation in the supply chain.

Now back to those binary blobs. There is nothing we can do about them
without the hardware manufacturer's permission. Remeber ages ago when
you had to use b43-fwcutter to get broadcom chips to work under linux?
The issue was broadcom was not allowing reditribution of the
hardware's firmware.

It is 100% legal to not allow free distrobution of firmware blobs. The
saving grace is that blobs are often not tied to a kernel's version so
we don't need to source to upgrade kernels.

Sorry for the rant. The gist is Mozilla cannot distribute a working
build because they are not allowed to.

Daniel

2014-01-29 Daniel Roesler <dia...@gmail.com>:

> What I don't understand:
>
> Mozilla has so much to lose from a bad ZTE Open experience. It is
> their flagship device! It's the _only_ native Firefox OS device you
> can buy now, and it's extremely cheap so developers can easily try
> Firefox OS out.
>
> I'd guess that there's an order of magnitude more app developers
> trying Firefox OS on the ZTE Open than all other devices combined. If
> they get frustrated, you have basically killed your entire app
> developer community. That's a huge price to pay. Mozilla has way more
> to lose than ZTE does. So why isn't Mozilla stepping up to make up for
> ZTE's lack of support?
>

> Finally, not having control over the kernel/firmware never stopped
> anyone from figuring out how to make it work. Android modders have
> been dealing with that crap for years, and they still keep cranking
> out upgrades just fine. So I don't think that's a valid excuse when
> your project's future is on the line.
>
>

> On Wed, Jan 29, 2014 at 11:33 AM, pazos <pazi...@gmail.com> wrote:

[Julien Wajsberg]

Le 29/01/2014 21:08, Daniel Roesler a écrit :
> What I don't understand:
>
> Mozilla has so much to lose from a bad ZTE Open experience. It is
> their flagship device! It's the _only_ native Firefox OS device you
> can buy now, and it's extremely cheap so developers can easily try
> Firefox OS out.
>
> I'd guess that there's an order of magnitude more app developers
> trying Firefox OS on the ZTE Open than all other devices combined. If
> they get frustrated, you have basically killed your entire app
> developer community. That's a huge price to pay. Mozilla has way more
> to lose than ZTE does. So why isn't Mozilla stepping up to make up for
> ZTE's lack of support?
>

You miss something here: you don't necessarily need to upgrade your
phone to build apps. Some APIs might need this but that's usually more
certified API, and sometimes maybe privileged APIs.

So while I quite agree with what you're saying (personal opinion, not
Mozilla's opinion), you're not exactly right here.
--
Julien

[Ernesto Acosta]

Hi Daniel:

I was looking on your site GitHub you're having problems with the Bug #965180. My question is Is there the same problem in the latest build of version 1.3? Is that I got this file[1] and want to upgrade my ZTE.

Thanks

[1] https://daylightpirates.org/b2g_inari_nightly_builds/b2g_inari_v1.3_latest.tar.gz

[Ernesto Acosta]

I tried to install that version that I mentioned, but the phone constantly reboots. Luckily, I was able to return to the official version of ZTE. Hey Daniel, in the compilations is available for 1.3 Is there any I can use?

[Daniel Roesler]

> Hey Daniel, in the compilations is available for 1.3 Is there any I can use?

Not if you have upgraded to the 1.1 ZTE firmware. The boot.img used in
the available download is based on the old 1.0 ZTE firmware, and I
can't seem to build a nightly (with or without the old custom
boot.img) that doesn't do the reboot loop. See
https://bugzilla.mozilla.org/show_bug.cgi?id=965180

I will not have time to troubleshoot for a few weeks, but if you can
reproduce the bug, I would love to have someone help troubleshoot
since no one at Mozilla has a ZTE Open.

[Chris Mills]

On 6 Feb 2014, at 22:01, Daniel Roesler <dia...@gmail.com> wrote:

>> Hey Daniel, in the compilations is available for 1.3 Is there any I can use?
>

> Not if you have upgraded to the 1.1 ZTE firmware. The boot.img used in
> the available download is based on the old 1.0 ZTE firmware, and I
> can't seem to build a nightly (with or without the old custom
> boot.img) that doesn't do the reboot loop. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=965180
>
> I will not have time to troubleshoot for a few weeks, but if you can
> reproduce the bug, I would love to have someone help troubleshoot
> since no one at Mozilla has a ZTE Open.

I’ve got one, and would be happy to help troubleshoot. I’ve not attempted to update it yet (I use my Keon mostly.)

[Marek Raida]

I unfortunately agree with the fact, that it is actually Mozilla and its FirefoxOS effort which is hurt the most from current ZTE Open mess... :-((
Fix it somehow with ZTE and get back damaged reputation could be even more important than continuing development on new features for the moment.... :-(((

[pazos]

@Daniel: Did you read any of my posts here?

I resume:
- bootloader changed between 1.0 & 1.1
- bootloader checks for kernel signature (rebooting if it does NOT match)

- kernel is inside boot.img and boot.img changes too between 1.0 & 1.1
- now, the only way you have to build a working B2G flasheable from 1.1.0B02 is modifying boot.img from 1.1 accordly to sl.edujose.org instructions.

I'm actually working on generating boot.img from the device tree itself (merging init scripts from zte's boot.img) and getting the kernel (and other blobs like charger binary) from the device. This is the ONLY solution for the bootloop issue, because we can't control which version the user has installed on his/her phone

look here https://groups.google.com/forum/#!msg/mozilla.dev.b2g/rAWVSNDDHnU/HtZ4CqOoH7QJ

[linuxh...@gmail.com]

Can you provide me flashable zip file of 1.3 for ZTE Open(UK)?
I've tried every file and also tried to flash from Fastboot but always sitting on Fox after flash :D
Thanks :)

[faus...@gmail.com]

Could you provide a 1.3 zip image, as you did with the 1.2 zip image?

[pazos]

Yes I can but I can't give support for it right now. There are some annoying bugs in all custom builds for zte open:

- camera does NOT work with newer blobs: https://bugzilla.mozilla.org/show_bug.cgi?id=973689
- we need a modified boot.img that matches with the blobs we are using: https://bugzilla.mozilla.org/show_bug.cgi?id=967713
- needed initialization for proximity sensor: https://bugzilla.mozilla.org/show_bug.cgi?id=948846

And the big annoying bug: https://bugzilla.mozilla.org/show_bug.cgi?id=932359
that can be reproduced in any zte open (even in zte releases)

I think is better to start filling specific bugs for our devices (first read all open bugs). After fixing it It will be easier for us to build lastest B2G branch