23/Sep: Kernel Source

[Guest Jon_V]

I've updated the repository at

https://github.com/jvaughan/san-francisco-kernel

with the new code from zte (branch 'zte/2.6.29')

You can see the commit / changes at

https://github.com/jvaughan/san-francisco-k...c3875625719336e

[Guest hecatae]

so if I've got that right, the TFT screen driver is Cypress?

http://www.cypress.com/?rID=40190

Edited December 11, 2010 by hecatae

[Guest gameSTICKER]

1. I've setup Ubuntu as described here (excluding downloading android repo): http://source.android.com/source/download.html
   
2. I've downloaded latest SanF source from ZTE's site
   

Now how do I go ahead and compile stock SanF kernel? So far I've not downloaded any source from Android repo, solely because I'm unsure which repo to download and how to combine SanF source code with android source.

Can someone be kind enough to guide me here onwards?

Edited December 12, 2010 by gameSTICKER

[Guest hecatae]

1. I've setup Ubuntu as described here (excluding downloading android repo): http://source.android.com/source/download.html
   
2. I've downloaded latest SanF source from ZTE's site
   

Now how do I go ahead and compile stock SanF kernel? So far I've not downloaded any source from Android repo, solely because I'm unsure which repo to download and how to combine SanF source code with android source.

Can someone be kind enough to guide me here onwards?

http://android.git.kernel.org/

To clone the entire platform, install repo, and run:

mkdir mydroid

cd mydroid

repo init -u git://github.com/jvaughan/san-francisco-kernel.git

repo sync[/codebox]


that would download the current san francisco kernel repo

[Guest gameSTICKER]

http://android.git.kernel.org/

To clone the entire platform, install repo, and run:

mkdir mydroid

cd mydroid

repo init -u git://github.com/jvaughan/san-francisco-kernel.git

repo sync[/codebox]

that would download the current san francisco kernel repo

Thanks for pointing Jon's repo. 2 question though...

1. After downloading Jon's repo, will I still need to download other parts from android official repo or is Jon's repo self sufficient?
   
2. Just for learning purpose, what would be the procedure if I want to start with ZTE's sources? I mean not the building procedure, i know I have to setup toolchains, lib-devels, pull config from phone and all. I mean how do I setup the sources properly? First download official Eclair AOSP branch and then add ZTE sources to it or what?
   

[Guest hecatae]

Thanks for pointing Jon's repo. 2 question though...

1. After downloading Jon's repo, will I still need to download other parts from android official repo or is Jon's repo self sufficient?
   
2. Just for learning purpose, what would be the procedure if I want to start with ZTE's sources? I mean not the building procedure, i know I have to setup toolchains, lib-devels, pull config from phone and all. I mean how do I setup the sources properly? First download official Eclair AOSP branch and then add ZTE sources to it or what?
   

1. as far as I can tell, Jon's repo is the ZTE Kernel Source

2. see above, Jon keeps his repo up to date with the ZTE Kernel Source

found another git https://github.com/zadintuvas/blade-eclair.git but it's old compared to Jon's

Setup your machine as in here http://source.android.com/source/download.html

Grab the source and unzip

then grab config.gz from our device, unzip and copy to .config under the kernel directory

then run make ARCH=arm CROSS_COMPILE=~/android/android-2.2.1_r1/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- $1

best information found in this thread so far

Edited December 12, 2010 by hecatae

[Guest hecatae]

Setup your machine as in here http://source.android.com/source/download.html

Grab the source and unzip

then grab config.gz from our device, unzip and copy to .config under the kernel directory

then run make ARCH=arm CROSS_COMPILE=~/android/android-2.2.1_r1/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- $1

best information found in this thread so far

[Guest gameSTICKER]

Just cloned Jon's repo, but it does not seem to be full kernel. Total size is under 90mb, just like ZTE sources, plus a number of folders referred in other android compilation guides seem missing. Does it mean I'll have do download Eclair AOSP repo?

EDIT: Thanks a lot! I'm going to download AOSP source and see how it goes.

Edited December 12, 2010 by gameSTICKER

[Guest hecatae]

just been reading that stackrish built from 2.2.1 Froyo AOSP Repo and also built wifi drivers suitable for Eclair and Froyo

http://android.modaco.com/content/zte-blad...san-francisco/#

attached to linked post

[Guest Cass67]

I've updated the repository at

https://github.com/jvaughan/san-francisco-kernel

with the new code from zte (branch 'zte/2.6.29')

You can see the commit / changes at

https://github.com/jvaughan/san-francisco-k...c3875625719336e

Hi Jon,

Have you managed to compile a working kernel after the last 2 commits ?

On branch zte/2.6.29 i have issues compiling a working kernel ..

Changes to -- drivers/video/msm/lcdc_panel_wvga_oled.c file from

Commit - 9e53423cf408344a3074b3153a86290950fad6a4

Updates from ZTE's 2010-11-23 release (Touchscreen-related).

Breaks compile for me with error -

drivers/built-in.o: In function `lcdc_panel_probe':

/ZTE/kernel-2.6.29/san-francisco-kernel/drivers/video/msm/lcdc_panel_wvga_oled.c:1537: undefined reference to `LcdPanleID'

make: *** [.tmp_vmlinux1] Error 1

If i revert that file to one prior to this update i can compile fine .. well after fixing one other issue, a lonley #endif from arch/arm/mach-msm/include/mach/camera.h

http://pastebin.com/FT9Hgg2M for the git diff to repair this from current head..

Please let me know if i should be using another branch or patchset to enable a clean compile.

Compiling kernels for zte blade is new to me and im still unsure of the proper working branch to use .. i figured zte/2.6.29 was the correct one to use ..

Cheers

Edited December 16, 2010 by Cass67

[Guest kallt_kaffe]

Hi Jon,

Have you managed to compile a working kernel after the last 2 commits ?

On branch zte/2.6.29 i have issues compiling a working kernel ..

Changes to -- drivers/video/msm/lcdc_panel_wvga_oled.c file from

Commit - 9e53423cf408344a3074b3153a86290950fad6a4

Updates from ZTE's 2010-11-23 release (Touchscreen-related).

Breaks compile for me with error -

drivers/built-in.o: In function `lcdc_panel_probe':

/ZTE/kernel-2.6.29/san-francisco-kernel/drivers/video/msm/lcdc_panel_wvga_oled.c:1537: undefined reference to `LcdPanleID'

make: *** [.tmp_vmlinux1] Error 1

If i revert that file to one prior to this update i can compile fine .. well after fixing one other issue, a lonley #endif from arch/arm/mach-msm/include/mach/camera.h

http://pastebin.com/FT9Hgg2M for the git diff to repair this from current head..

Please let me know if i should be using another branch or patchset to enable a clean compile.

Compiling kernels for zte blade is new to me and im still unsure of the proper working branch to use .. i figured zte/2.6.29 was the correct one to use ..

Cheers

Here's the files I've changed in the latest ZTE source. It fixes the camera and the lcd driver issues. You could skip the touchscreen driver changes and the overclocking changes if you want, they are not needed to get a working kernel.

changedfiles.zip

[Guest Cass67]

Here's the files I've changed in the latest ZTE source. It fixes the camera and the lcd driver issues. You could skip the touchscreen driver changes and the overclocking changes if you want, they are not needed to get a working kernel.

Thank you .. those files look nice.

Did we miss a patch or two to apply to teh tree wrt LCDPanleID ? Or are ZTE releasing bad code?

Just to confirm zte/2.6.29 is the proper tree to use ?

Cheers

[Guest oh!dougal]

I'm sorry, but I must question the validity of the comments coming back from ZTE.

A certain amount of linguistic confusion and commercial sensitivity is understandable.

Factual DISinformation is a different matter, however.

Chipinfo ...

Wifi

AR6002 (not sure why the MAC address is a Samsung though)

...

And then from http://www.opulan.com/pt/AR6002.htm one discovers

The Atheros AR6002 features breakthrough power efficiency for mobile WLAN solutions, enabling high performance Wi-Fi to be integrated into mobile devices with efficiency and ease. The AR6002's extremely low power consumption overcomes the key obstacle to designers looking to add Wi-Fi capability in mobile and handheld products.

The game-changing power efficiency delivered by the AR6002 significantly extends battery life. In fact, the AR6002 consumes 70% less power in active mode than competitive solutions and near-zero power in standby. The AR6002 further extends battery-life with its industry-leading throughput which allows the chip to remain in low power states longer.

So, the WiFi chip in the Blade does have a standby mode.

However ...

reply from zte re wifi sleeping, not sure it really helps!

That's comes from our developers. for you issue about the " Blade Sleeping "

In most cases it's not a hardware limitation. It's about power consumption. ...

WIFI module is special. The chip has a limitation. It must be totally powered off and brought up again when the phone wakes up.

...

And ZTE "developers" claim that it doesn't have a standby mode, and must be switched off in sleep ...

Hmmmm.

[Guest rjm2k]

I'm sorry, but I must question the validity of the comments coming back from ZTE.

A certain amount of linguistic confusion and commercial sensitivity is understandable.

Factual DISinformation is a different matter, however.

And then from http://www.opulan.com/pt/AR6002.htm one discovers

So, the WiFi chip in the Blade does have a standby mode.

However ...

And ZTE "developers" claim that it doesn't have a standby mode, and must be switched off in sleep ...

Hmmmm.

I don't think there is anything there that suggests it can stay connected in standby mode, the real issue is that they are putting it in standby/switching it off when the wifi sleep policy is set to never. I don't know where that setting gets picked up and applied, could be android, kernel or the wifi driver itself.

[Guest oh!dougal]

I don't think there is anything there that suggests it can stay connected in standby mode, the real issue is that they are putting it in standby/switching it off when the wifi sleep policy is set to never. I don't know where that setting gets picked up and applied, could be android, kernel or the wifi driver itself.

Firstly, you are confusing things by conflating two distinct matters.

a - the user preference setting not being obeyed (and ZTE's reluctance to understand that)

and

b - ZTE's false claim that wifi MUST be either on or "totally powered off", ie that it has no standby mode.

Now, ask yourself what would the function of a "standby mode" be. Why would it exist at all?

Why would Atheros proudly trumpet this claim, if a better result could come from the powering off that ZTE claim to be doing? (Using absolutely zero power.)

Did you spot that the AR6002 spec sheet (pdf linked from the page linked above) claims "• Host Wakeup for system-level power savings" -- so that the host (the phone) can be woken by incoming wifi traffic? This thing is about maintaining connections with minimal power consumption. It ain't just on/off control!

So why would ZTE "developers" pass on false information? Did it really come from anyone who knew what they were talking about?

They told us "The chip has a limitation. It must be totally powered off and brought up again when the phone wakes up."

Which has to be recognised as a whopping great porky.

[Guest Arr Too]

They told us "The chip has a limitation. It must be totally powered off and brought up again when the phone wakes up."

Which has to be recognised as a whopping great porky.

To be fair, you must also consider that what the spec sheet says and what the unit actually does in specific setups can be different. Has anyone got the latest errata sheet for that unit?

Edited December 16, 2010 by Arr Too

[Guest oh!dougal]

To be fair, you must also consider that what the spec sheet says and what the unit actually does in specific setups can be different. Has anyone got the latest errata sheet for that unit?

True, but that data seems to be from 2008. I'd hope it was performing up to claims by now!

[Guest rjm2k]

Firstly, you are confusing things by conflating two distinct matters.

a - the user preference setting not being obeyed (and ZTE's reluctance to understand that)

and

b - ZTE's false claim that wifi MUST be either on or "totally powered off", ie that it has no standby mode.

Now, ask yourself what would the function of a "standby mode" be. Why would it exist at all?

Why would Atheros proudly trumpet this claim, if a better result could come from the powering off that ZTE claim to be doing? (Using absolutely zero power.)

Did you spot that the AR6002 spec sheet (pdf linked from the page linked above) claims "• Host Wakeup for system-level power savings" -- so that the host (the phone) can be woken by incoming wifi traffic? This thing is about maintaining connections with minimal power consumption. It ain't just on/off control!

So why would ZTE "developers" pass on false information? Did it really come from anyone who knew what they were talking about?

They told us "The chip has a limitation. It must be totally powered off and brought up again when the phone wakes up."

Which has to be recognised as a whopping great porky.

I don't think anyone is 100% sure either way, the article below suggests that Host Wakeup is used to improve power consumption in normal running rather than sleep mode in android terms, ie when the phone itself is not asleep, the wifi can go into semi-sleep in order to save power, only powering up fully when there is actual data to transfer.

http://urgentcomm.com/networks_and_systems...fi_chip_110207/

To me the easiest issue to resolve is to make sure that the wifi sleep policy is taken into account. I have attempted to communicate all of this to ZTE and they have responded by saying that they are trying to improve the wifi and we have had results in that some of the roms we are seeing have better wifi performance / reconnects. I still don't think that the wifi sleep policy is being taken into account from what I hear from people on here.

[Guest oh!dougal]

...

To me the easiest issue to resolve is to make sure that the wifi sleep policy is taken into account. I have attempted to communicate all of this to ZTE and they have responded by saying that they are trying to improve the wifi and we have had results in that some of the roms we are seeing have better wifi performance / reconnects. I still don't think that the wifi sleep policy is being taken into account from what I hear from people on here.

Indeed the sleep policy should be the easiest issue to communicate.

But they don't seem to respond on that specific concern, do they?

[Guest rjm2k]

Indeed the sleep policy should be the easiest issue to communicate.

But they don't seem to respond on that specific concern, do they?

It looks like it's probably an android thing rather than ZTE

http://code.google.com/p/android/issues/li...amp;cells=tiles

eg

http://code.google.com/p/android/issues/detail?id=7421

http://code.google.com/p/android/issues/detail?id=9781

I think this link suggests a fix has been put in the MSM kernel tree for Broaccom, maybe there is a similar issue for Atheros

http://android.git.kernel.org/?p=kernel/ms...6315de15633361c

Also various threads on CM about it and fixes etc

http://code.google.com/p/cyanogenmod/issues/detail?id=1598

Edited December 16, 2010 by rjm2k

[Guest Sven Killig]

Setup your machine as in here http://source.android.com/source/download.html

Grab the source and unzip

then grab config.gz from our device, unzip and copy to .config under the kernel directory

then run make ARCH=arm CROSS_COMPILE=~/android/android-2.2.1_r1/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- $1

I come from the Nexus One and am used to try out a kernel with

fastboot boot Z:\ZTE_Kernel_Eclair_General\arch\arm\boot\zImage

but that doesn't seem to work on the Blade (black screen). Is it supposed to work or how is it done on the Blade?

Edited December 19, 2010 by Sven Killig

[Guest Cass67]

I come from the Nexus One and am used to try out a kernel with

fastboot boot Z:\ZTE_Kernel_Eclair_General\arch\arm\boot\zImage

but that doesn't seem to work on the Blade (black screen). Is it supposed to work or how is it done on the Blade?

Sounds like if you get a black screen then it worked somewhat .. if things dont work for me then i get no change from the green android chap ... maybe you have to add proper ramdisk to the equation ?

boot <kernel> [ <ramdisk> ] download and boot kernel

Never did it but thats from help.. Scuse me if im wrong .. id suspect fastboot on blade to work same as n1 though !!

[Guest Sven Killig]

You could skip the touchscreen driver changes and the overclocking changes if you want, they are not needed to get a working kernel.

What do your overclocking changes do?

[Guest oh!dougal]

What do your overclocking changes do?

Functionally --

RLS3

* New overclocking code, no more overclocking addons. Boots at 600MHz but can be overclocked with SetCPU. Be careful with the "Set on Boot" checkbox until you know a speed is stable. The new code does not degrade 3D performance. It also overclocks the memory bus even at stock speed so please report any strangeness at stock speed (that goes away if you flash the "original_kernel" addon). Expect Qudrant scores above 500 even at moderate overclocking.

http://android.modaco.com/content/zte-blad...ls3-2010-12-18/

[Guest Sven Killig]

It also overclocks the memory bus even at stock speed so please report any strangeness at stock speed (that goes away if you flash the "original_kernel" addon).

Thanks :) How do I disable this memory bus overclocking at stock speed?