Source codes

[Guest targetbsp]

Is it that they are stopping support on the Blade and kill it off... and instead focus on the Skate... a lot of questions like that pop into my mind...

My 2cents...

I doubt they want to kill it off considering this: http://android.modaco.com/topic/344797-25-million-blades-sold-zte-wants-to-sell-5-million/

It's possible though they want the Skate to have the better OS and the blade not to, to increase the Skates value over the Blade. Cause it's kinda lacking there atm!

[Guest t0mm13b]

I doubt they want to kill it off considering this: http://android.modaco.com/topic/344797-25-million-blades-sold-zte-wants-to-sell-5-million/

It's possible though they want the Skate to have the better OS and the blade not to, to increase the Skates value over the Blade. Cause it's kinda lacking there atm!

Dunno about the Skate considering Orange has locked that down tight and hard now that they realized through the Blade modders community such as this, that it was easy to unlock their San Francisco handset and modify it and hack it which resulted in Orange losing profit as a result (may be small money in ZTE's eyes but to Orange themselves - it must have been a lot!).

In a nutshell I think ZTE shot themselves in the foot! Did Orange report back to ZTE and say something like this, "Hey, your blade ... there's a freaking community out there that has this handset unlocked and using it on other networks and modifying it etc" with ZTE's response being like "Oh! Okie, let's tighten the screws and f..k the blade community and release the Skate that would be even harder to unlock and oh yeah while wer're at it, release the source for the Skate but f..k the blade"? (These are my line of thinking...could be wrong here...who knows)

So much for statistics that they want to sell x million handsets if they tighten the screws on it which will have the effect of people not buying the handset and the sales plummet!

[Guest targetbsp]

Maybe they just bodged the release. "Eek, it's September! we promised to release some source code. *looks around desperately and grabs a random file* here's some!"

And they'll mend it once they realise.

I'm in an optimistic mood today lol

[Guest t0mm13b]

Maybe they just bodged the release. "Eek, it's September! we promised to release some source code. *looks around desperately and grabs a random file* here's some!"

And they'll mend it once they realise.

I'm in an optimistic mood today lol

lol! :D

[Guest Chris Banks]

With the ZTE Libra coming out on the 9th September running 2.3 and I assume with the same kernel as the leak, wont we be getting (should be getting) the new kernel source code for the blade soon anyway?

Or am I getting mixed up like usual..

[Guest wbaw]

It isn't clear to me what the time limits are for distributing source code. Section 3 of GPLv2 states that the source code (or offer of providing it on a non-profit basis) must accompany the object code/executable. Which seems to indicate that either the code (clause 3a) or the offer of non-profit access (clause 3b) should be distributed with the phone itself (or software update). If ZTE are opting for 3b, though, what defines when the source should be provided? Should it be within a day or two, or within months, years or decades? There must be case history that helps with this. I'm not an expert - does anyone have the data to hand? I'm also a bit confused about the deadline of 1st September in this particular case - was that date simply the one promised by ZTE's representative ZTE_SeanJacko in his post here or is there some hard deadline imposed by law?

It's pretty clear, either 3a or 3b apply to Android device makers & anybody selling their phones. They must either include source code, or a written offer of how to get the source code, along with the phone (which contains a compiled executable copy of the GPL code). ZTE do neither. There isn't a time limit imposed other than that the offer must be valid for at least 3 years (if they go for option B ), but that's a bit irrelevant in this case as they didn't include any written offer with the phone (at least when I bought mine).

There is a vendor FAQ for vendors that want to make sure they're following the GPL: http://gpl-violations.org/faq/vendor-faq.html The easiest way to comply fully would seem to be to include source code on a disc with each phone. Opting for the written offer, (option b under section 3) seems to make it more complicated.

As the blog I linked to in my previous post says, it could easily get very messy if any of the Linux kernel copyright holders are particularly mercenary, because of section 4. That says that anybody that violates the license loses all rights granted by the license to redistribute that software. All the other Linux kernel copyright holders would need to agree to let them redistribute Linux or any derivative of it ever again & that isn't possible due to the number of copyright holders on the Linux kernel. Releasing the source code late after the license has already been violated wouldn't be enough to allow them to continue distributing Linux. Nobody wants that outcome (except maybe a few greedy Linux kernel copyright holders), it's a worst case scenario, but I can't find any legal flaws in that argument (I'm not a lawyer), it seems consistent with the busybox case & the legal position taken by FSF lawyers.

As it is, GPLv2 is pretty broken for the Linux kernel & other very large GPL projects with a similar copyright system (each contributor keeps their own copyright), because of section 4 being so harsh. The danger of vendors being sued into oblivion seems quite real. That part was an unintended consequence of the license. GPLv3 seems fairer in that respect, but it'd probably be very hard for Linux to change license now.

http://www.fsf.org/news/android-termination-upgrade-gplv3

Edited September 2, 2011 by wbaw

[Guest The Soup Thief]

With the ZTE Libra coming out on the 9th September running 2.3 and I assume with the same kernel as the leak, wont we be getting (should be getting) the new kernel source code for the blade soon anyway?

Or am I getting mixed up like usual..

That's (to my naive eyes) a good point - when they unleash the Libra is there gonna be another bucket of slop delivered set of kernel source code released? This will be a bit more blade friendly than this morning's shipment presumably? If they've been compliant (in their own special way) this time, maybe they will next time too?

[Guest burstlam]

Just download the source from ZTE and again disappointing

ZTE just give us piece of crap. no doubts.

Can't compile even for Skate as several files are missing.

For the blade, still need to rebuild the board files to get the AR wifi and BT chipset works.)

[Guest Simon O]

it even doesn't compile as it for the skate lol

According to HCDRJacob, Tom_G says the code does build.

[Guest Phoenix Silver]

According to HCDRJacob, Tom_G says the code does build.

yes just grab the missing files from caf

[Guest t0mm13b]

Just download the source from ZTE and again disappointing

ZTE just give us piece of crap. no doubts.

Can't compile even for Skate as several files are missing.

For the blade, still need to rebuild the board files to get the AR wifi and BT chipset works.)

Okie

Phoenix and I have been trying to get the sources to compile as it is, with slight modifications and running around like headless chickens.

The one matter of fact is this:

THE SOURCE IS BROKEN.

Don't even bother trying to "fix" it by putting in legacy .32 code into the .35 source base as that's then the kernel contaminated and will cause headaches for us all devs, and as usual, will prevent experiencing what should have been a smooth kernel.

Was reliably informed to use the kernel configuration from the leaked build with it, and made 3G split, as the leaked build is 2G split.Also, was told that the keypad had to be copied across from .32 source and "modified" to make it compile!

Yes, the missing files were there - sure no big deal, that was confined to the netfilter stuff, can easily be copied but that's not the point.

Alas, ZTE has let us down once again!

Edited September 2, 2011 by t0mm13b

[Guest sej7278]

Just download the source from ZTE and again disappointing

ZTE just give us piece of crap. no doubts.

Can't compile even for Skate as several files are missing.

For the blade, still need to rebuild the board files to get the AR wifi and BT chipset works.)

interestingly i got it to compile for skate using the .config that was ripped off a working OMC (attached as i can't find the thread on here) which is exactly the same as ripped from someone's backup of the SFR staraddict.

the msm7627_skate_defconfig file in the tarball is crap and a good 5 months older than what has shipped.

stock_config.gz

Edited September 2, 2011 by sej7278

[Guest Simon O]

Thanks sej7278 for the config!

[Guest Simon O]

yes just grab the missing files from caf

Oh :(

[Guest PhenomHTX]

http://wwwen.zte.com.cn/endata/magazine/mobileworld/2011/2/articles/201107/t20110704_241742.html

Operation System Android 2.2

[Guest sej7278]

Thanks sej7278 for the config!

turns out that was from an OMC after paul's superboot (replaces the whole boot partition!) which explains why its identical to the SFR which also installed superboot. so we still don't have a factory default config.gz

has anyone romdumped a phone before rooting it yet? we need someone who hasn't rooted to run "adb pull /proc/config.gz /tmp"

i wonder where paul got the superboot kernel from in the first place.

Edited September 3, 2011 by sej7278

[Guest Simon O]

turns out that was from an OMC after paul's superboot (replaces the whole boot partition!) which explains why its identical to the SFR which also installed superboot. so we still don't have a factory default config.gz

has anyone romdumped a phone before rooting it yet? we need someone who hasn't rooted to run "adb pull /proc/config.gz /tmp"

i wonder where paul got the superboot kernel from in the first place.

Pauls SuperBoot doesn't touch the kernel which is still the stock OMC kernel, so it shouldn't make any difference to the config. All that Paul has done to the boot.img is make it insecure and add some scripts to copy superuser into the system partition.

[Guest sej7278]

Pauls SuperBoot doesn't touch the kernel which is still the stock OMC kernel, so it shouldn't make any difference to the config. All that Paul has done to the boot.img is make it insecure and add some scripts to copy superuser into the system partition.

ok that's cool then, so essentially paul's just made a boot.img with superoot in, rather than just installing superoot manually, which means just a couple of files in /system have been changed.

it still means the SFR rip is pretty pointless though, as essentially it will now be running the OMC kernel lol!

[Guest PhenomHTX]

http://www.wayteq.hu/en/libra

Today i found auction of WayteQ-ZTE Libra , it cost 190 Euro in Poland and it has Android 2.2

Edited September 3, 2011 by PhenomHTX

[Guest t0mm13b]

Here's the attached config for the blade.

- PCMCIA stuff removed

- Infra Red stuff removed

- Extra drivers for Camera removed

- Sound via PCMCIA removed

- Built with 3G vmsplit

Runs like treacle - be warned - this could be down to the graphics part of the kernel (kgsl)....

might need further tweaking to get it back to acceptable levels. :)

B)

t0mm13b_optimized.config.gz

Edited September 3, 2011 by t0mm13b

[Guest Zunex]

Does anyone working on this now? I mean on the kernel. You can count on me as a tester :)

[Guest wbaw]

Runs like treacle - be warned - this could be down to the graphics part of the kernel (kgsl)....

might need further tweaking to get it back to acceptable levels. :)

B)

I noticed yesterday the one that Geno compiled is slower than the stock gsf kernel, animations aren't smooth, benchmark scores a little lower, it does run bit like treacle. I'll be happy just to have the new wifi driver working on cm7 though.

[Guest Phoenix Silver]

Does anyone working on this now? I mean on the kernel. You can count on me as a tester :)

Yes t0mm13b and me

As written we have made the kernel boot in cm7 but it's really slow

More work to do before it will be acceptable

Ho honey Kiss :D

[Guest rjm2k]

if there are real problems with this source it may be worth mentioning it to the PR guys on here, and for those developers who have access to my mailing list send your issues directly to the ZTE guys too. It doesn't really present ZTE as a professional software company if they cant do something as simple as keeping track of the working code. Something that the PR guys may want to try and get across to ZTE is that the GPL says that ZTE have to release the exact source used to compile their kernel, not just some random version that has been changed/broken since it was originally released, so they really need to release for any Blade which had Gingerbread and the Skate as seperate snapshots of the same source at the different times they were released.

Edited September 4, 2011 by rjm2k

[Guest t0mm13b]

if there are real problems with this source it may be worth mentioning it to the PR guys on here, and for those developers who have access to my mailing list send your issues directly to the ZTE guys too. It doesn't really present ZTE as a professional software company if they cant do something as simple as keeping track of the working code. Something that the PR guys may want to try and get across to ZTE is that the GPL says that ZTE have to release the exact source used to compile their kernel, not just some random version that has been changed/broken since it was originally released, so they really need to release for any Blade which had Gingerbread and the Skate as seperate snapshots of the same source at the different times they were released.

The base source is .32 am afraid, with tiny bits of .35 thrown in for a good measure.

Its not a real .35 kernel source unlike CAF, HTC, or LG.....

If it was, the internal structural changes would have reflected the true .35 sources, but no, the board code for the Blade and Skate bears uncanny resemblance to .32.

In other words, ZTE failed to deliver the goods.

This could be, perhaps, false advertising, mis-leading, mis-representing the source... I do not know... Would not be surprised if they actually used the June 11 release of .32 baseline code, changed the top level Makefile version from .32 to .35 and pass it off as 2.6.35.7....Just my thoughts.... B)

Or is it as Phoenix and I have done on previous occasion, difficult to get the real/true .35 (read CAF sources, 35.7,35.9,35.10,35.11) to boot up?!

Editing this as gathering my thoughts into this posting, there's two dead give-aways in this so-called .35 sources, a 101 brief intro - there's a lot of hardware interaction to various parts of the board, the way the board pulls up the hardware is controlled by GPIO which is General Port Input Output for short - that basically, sends a pulse/signal in binary form to tell the hardware pieces such as touchscreen, usb, keyboard etc to kickstart it or perform a initialization on it. In .32, that routine called GPIO is used using a variant - called GPIO_ENABLE, GPIO_DISABLE, GPIO_PULLUP, GPIO_PULLDOWN. Under .35 sources, the routine was renamed to GPIO_CFG_ENABLE, GPIO_CFG_DISABLE, GPIO_CFG_PULLUP, GPIO_CFG_PULLDOWN etc.. that is consistent across the .35.7, .35.9, .35.10, and .35.11 which we, Phoenix and I, have worked on.

That's the first clue in this dead-giveaway.

The second clue is that there's a graphics layer in the kernel called kgsl, that underwent massive internal structural changes in the .35 series. In the current incarnation of the source that ZTE released a few days ago, no change in there - its basically the same structure used in the June release and it is still outside of kernel layer and easily consumed for developer use. In fact, from version .35.9 upwards, kgsl has become more isolated and not for general developer use - in other words, it became more "intimate" or extremely cosy and huddled within the kernel level.

These are the two clues that I have summarized which highlights and indicates and backs up what I am saying.

Just saying....

:)

Edited September 4, 2011 by t0mm13b