ZTE N880E & first ZTE ICS update

[Guest t0mm13b]

" I know this, you missed the point of my post. My idea is to debug the get_config output on msm7227a hardware, and use the existing omx armv6 libs with wrapper, as the qdsp is basically the same.

Edit:

Translating from armv7 code via debugging the output and translate into armv6 for a start, which brings about this.. how would you create a wrapper around the existing omx libs which are proprietary?! :)

I am not sure if this could actually be done, i.e. intercept the library load process for the omx libs, and somewhat inject a method in there... you'd want to be very knowledgeable on the armv6 instruction set and determine where/when and how to intercept, its easier on the x86 platform in relation to windows, this is where it can go wrong....supply the wrong address and possibly crash the entire handset... just saying, its far more difficult than you realize... :)

Just have a look here - library preloading... ftw?

Edit#2: Just after reading it, its confirmed, library preload is not supported:

Placing hooks and operating within the application was pretty cool but it was unfortunately not possible on Android: The loader (ld) does not support library preloading via LD_PRELOAD

Edited May 14, 2012 by t0mm13b

[Guest skywave]

Yes it is

http://www.xperiablo...engthy-preview/

No it isn't. Its the MSM7227A, the same SoC as the ZTE the rom in the OP is from.

http://www.themobileindian.com/news/6323_Entry-level-Sony-Tapioca-smartphone-spotted-online

http://pdadb.net/index.php?m=specs&id=3528&view=1&c=sony_xperia_st21__st21i_sony_tapioca

[Guest skywave]

The OPENMAX IL specification is online btw.

getExtensionIndex is on page 79

The OMX_GetExtensionIndex macro will invoke a component to translate from a

standardized OpenMAX or vendor-specific extension string for a configuration or a

parameter into an OpenMAX structure index. The vendor is not required to support this

command for the indexes already found in the OMX_INDEXTYPE enumeration, which

reduces the memory footprint. The component may support any standardized OpenMAX

or vendor-specific extension indexes that are not found in the master OMX_INDEXTYPE

enumeration.

This call is a blocking call. The component should return from this call within five msec.

The OMX_GetExtensionIndex macro is defined as follows.

#define OMX_GetExtensionIndex (

hComponent,

cParameterName,

pIndexType )

((OMX_COMPONENTTYPE*)hComponent)->GetExtensionIndex( \

hComponent, \

cParameterName, \

pIndexType)

3.2.2.10 OMX_GetConfig

The OMX_GetConfig macro will get a configuration structure from a component. This

macro can be invoked at any time after the component has been loaded. The

nParamIndex parameter indicates which structure is being requested from the

component. The caller shall provide the memory for the structure and populate the

nSize and nVersion fields before invoking this macro. If the configuration settings

are for a port, the caller shall also provide a valid port number in the nPortIndex field

before invoking this macro. All components shall support a set of defaults for each

configuration so that the caller can obtain the structure populated with valid values.

This call is a blocking call. The component should return from this call within five msec.

The OMX_GetConfig macro is defined as follows.

#define OMX_GetConfig (

hComponent,

nConfigIndex,

ComponentConfigStructure)

((OMX_COMPONENTTYPE*)hComponent)->GetConfig( \

hComponent, \

nConfigIndex, \

ComponentConfigStructure)

The parameters are as follows.

Parameters Description

hComponent

[in] The handle of the component that executes the call.

nIndex

[in]

The index of the structure to be filled. This value is from the

OMX_INDEXTYPE enumeration.

ComponentConfigStructure

[in,out]

A pointer to the IL client-allocated structure that the

component fills.

Section 3.3.9 describes the corresponding function that each component implements.

[Guest stare_spb]

Edit:

Translating from armv7 code via debugging the output and translate into armv6 for a start, which brings about this.. how would you create a wrapper around the existing omx libs which are proprietary?! :)

I am not sure if this could actually be done, i.e. intercept the library load process for the omx libs, and somewhat inject a method in there... you'd want to be very knowledgeable on the armv6 instruction set and determine where/when and how to intercept, its easier on the x86 platform in relation to windows, this is where it can go wrong....supply the wrong address and possibly crash the entire handset... just saying, its far more difficult than you realize... :)

Just have a look here - library preloading... ftw?

Yup, I meant some kind of library preloading technique, not direct injection hacks which sure are near to impossible.

Edit#2: Just after reading it, its confirmed, library preload is not supported:

OK. Next idea: patch libstagefright, by replacing the get_config and getextensionindex requests with debugged data?

[Guest t0mm13b]

Yup, I meant some kind of library preloading technique, not direct injection hacks which sure are near to impossible.

OK. Next idea: patch libstagefright, by replacing the get_config and getextensionindex requests with debugged data?

My understanding is the proprietary omx libs are crapping out with the two said un-implemented functions - refer to post #18 on this thread on the previous page.

E/QCvdec ( 115): Error: get_config Not Implemented

and

E/QCvdec ( 115): get_extension_index: Error, Not implemented

[Guest stare_spb]

My understanding is the proprietary omx libs are crapping out with the two said un-implemented functions - refer to post #18 on this thread on the previous page.

and

Your understanding is not fully correct. That's not the omx libs which are crapping out, but a code in a libstagefright which tries to access those unimplemented functions. So the obvious solutions seems to be patch this code, replacing the actual calls with data retrieved from msm7227a hardware.

[Guest t0mm13b]

Your understanding is not fully correct. That's not the omx libs which are crapping out, but a code in a libstagefright which tries to access those unimplemented functions. So the obvious solutions seems to be patch this code, replacing the actual calls with data retrieved from msm7227a hardware.

The error tag identifier points to Qualcomm libs right?

[Guest skywave]

The error tag identifier points to Qualcomm libs right?

Yeah but stare_spb is right. OMXnoddeInstance (part of libstagefright tries to access those two methods, get unimplemented back so it moves on to the next codec. Which is the software codec. The obvious hack is indeed to try to get revert back omxnodeinstance to try to workaround these two methods, by for example revert those two commits i put in the big post.

But there could be tremendous sideeffects of that, they were commited in Feb 2011. Quite resonable to assume they are used all over in ICS and upcoming NDK apps.

Edited May 14, 2012 by skywave

[Guest stare_spb]

The error tag identifier points to Qualcomm libs right?

You mean QCvdec? You mean some code in propietary qcom libs requests unimplemented functions in some other propietary libs? Seems highly unlikely. I may not fully getting your poing, though, correct me if you think so. My understanding is that errors is caused by libstagefright code such as:

mComponent->GetConfig = GetConfigWrapper;

mComponent->SetConfig = SetConfigWrapper;

mComponent->GetExtensionIndex = GetExtensionIndexWrapper;

[Guest skywave]

There is a very very tiny chance though, that there is an updated QDSP5 Openmax wrapper somewhere in some gingerbread rom. But then again its more likely that qualcomm kept these changes in an ICS branch.

[Guest t0mm13b]

You mean QCvdec? You mean some code in propietary qcom libs requests unimplemented functions in some other propietary libs? Seems highly unlikely. I may not fully getting your poing, though, correct me if you think so. My understanding is that errors is caused by libstagefright code such as:

mComponent->GetConfig = GetConfigWrapper;

mComponent->SetConfig = SetConfigWrapper;

mComponent->GetExtensionIndex = GetExtensionIndexWrapper;

My bad, I must have mistook the error tag identifier as the proprietary libs.. :)

Bloody black boxes... :D

[Guest t0mm13b]

@stare_spb:

Is this what you're thinking of - page 124 of my favourite book. Interpositioning - replace a global c library function with your own, as in this case, override the omx lib's unimplemented methods with a call to a library for example, 'omxFooLib' in which it returns a spoofed or constant value to satisfy the libstagefright? But beware, omx could break somewhere if it calls 'omxFooLib' for the function get_extension_index and get_config

Just saying, that you're correct so far, but what does those two functions return on a pure ICS running ARMv7 chipset? - if its pointers of some sort to some omx structure that could be trouble? Or does it return a block of memory allocated or does it return 0 for success? (ICS can be recompiled for that handset and simply add a logcat to dump whatever it is returning for those two calls?)

Edited May 14, 2012 by t0mm13b

[Guest h1989826]

so good ! i hope the orange v880 also can run wp

[Guest KonstaT]

There was a second ICS update for N880E the other day. Not much new except this ZTE live wallpaper was now included. Anyone who's watched MWC/CES videos of upcoming ZTE devices should be familiar with this. It took a small modification to make it work in Blade and it still only works in some ZTE devices.

Spinning 3D shrooms, wtf ZTE. :D

MushroomDay.apk

http://www.mediafire...cg13i98fglcr2k9

[Guest shmizan]

probably what they ate when they put the .35 kernel sources out :P

[Guest jeddy1]

Nice live wallpaper :)

[Guest agpoli]

There was a second ICS update for N880E the other day. Not much new except this ZTE live wallpaper was now included. Anyone who's watched MWC/CES videos of upcoming ZTE devices should be familiar with this. It took a small modification to make it work in Blade and it still only works in some ZTE devices.

Spinning 3D shrooms, wtf ZTE. :D

I did watch the videos, great live wallpaper :D

Thanks for it!

Edit: ICS update is 258MB? Thats big.

Edited May 26, 2012 by agpoli

[Guest GoGokh]

There was a second ICS update for N880E the other day. Not much new except this ZTE live wallpaper was now included. Anyone who's watched MWC/CES videos of upcoming ZTE devices should be familiar with this. It took a small modification to make it work in Blade and it still only works in some ZTE devices.

Spinning 3D shrooms, wtf ZTE. :D

MushroomDay.apk

http://www.mediafire...cg13i98fglcr2k9

Thanks for this, its very smooth with cm7!

[Guest Shonk]

Nice wallpaper runs sweet on the latest moldova gb

[Guest jetx2x]

is the n880e ext4?

[Guest KonstaT]

ZTE released a 3.0.8 kernel source for Acqua series (ATLAS_40 board) today.

http://support.zte.c...?newsId=1002102

Unzipped it couple of times and mirrored here:

http://www.mediafire...qw69ikyl51skd59

It seems they've started from scratch with the 3.x.x kernel. I quickly ported blade board files and tried to compile it but ran into several problems. It would require some serious forward porting to get touchscreen, sensors, camera, leds, etc working. Hopefully someone who actually knows something about kernel development can take a look. :P

[Guest Zunex]

ZTE released a 3.0.8 kernel source for Acqua series (ATLAS_40 board) today.

http://support.zte.c...?newsId=1002102

Unzipped it couple of times and mirrored here:

http://www.mediafire...qw69ikyl51skd59

It seems they've started from scratch with the 3.x.x kernel. I quickly ported blade board files and tried to compile it but ran into several problems. It would require some serious forward porting to get touchscreen, sensors, camera, leds, etc working. Hopefully someone who actually knows something about kernel development can take a look. :P

I think you should open a thread for 3.x.x kernel development.. more ppl will see it.

[Guest KonstaT]

I think you should open a thread for 3.x.x kernel development.. more ppl will see it.

People will find it here, and it's also the kernel source for this device. If I expected any 3.x.x kernel development for Blade, I would open a thread for it. ;) From what I can understand, making this work on Blade would require about the same amount of work as porting a 3.x.x kernel from Code Aurora - it's not very likely to happen.

It was more of a FYI post if someone wants to poke around.

[Guest Zunex]

People will find it here, and it's also the kernel source for this device. If I expected any 3.x.x kernel development for Blade, I would open a thread for it. ;) From what I can understand, making this work on Blade would require about the same amount of work as porting a 3.x.x kernel from Code Aurora - it's not very likely to happen.

It was more of a FYI post if someone wants to poke around.

Too bad. Nothing useful?

[Guest unrandomsam]

Just that little change of CPU requires huge changes in the hardware, plus, it has bigger screen, not to mention the radio stuff (CDMA instead of GSM). Basically, it IS a new phone. But what I can't get, is the NAND 4Gb (Gigabit) or 4GB (Gigabyte)? That factor does matter!

The whole point of MSM7227A / MSM7627A is that it is pin compatible with the MSM7227/MSM7627 (It can even run in a legacy mode to support directly ARM11 stuff).

Radio stuff swap 7627 for 7227 and replace a few bits but you can pretty much keep the same design. (One of the big advantages of Qualcomm for OEM's).

People who understand radio stuff (e.g Nokia use a non integrated chipset and then deal with the baseband themselves but there is not many companies capable of such (lumia 900 for example).