yashsingh1/xdaforums huggingface dataset:
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
[MENTION=6224324]ralfbergs[/MENTION] pn incomming

[MENTION=7539994]GodzillaMonster[/MENTION] Pretty sure. I extracted the partitions from the UPDATE.APP and flashed them trough fastboot in order to get a copy of the files via adb. It was the right version. I did not have tried multiple versions of the hwcomposer yet. To my point of understanding this is a very device specific library. I could however try if one from another build would work.

Meanwhile:

__int64 __fastcall HwcPartialUpdates::UpdateSourceLayer(__int64 a1, _QWORD *a2)
{
__int64 v2; // x22@1
_QWORD *v3; // x20@1
unsigned __int64 counter; // x19@1
signed __int64 bufferOffset; // x2@2
unsigned int *junkArray; // x4@2
__int64 v7; // x1@2
__int64 v8; // x2@2
__int64 v9; // x3@2
__int64 v10; // x4@2
_DWORD *v11; // x9@3
__int64 v12; // x17@5
unsigned int v13; // w24@5
__int64 rect; // [xsp+40h] [xbp+40h]@5
__int64 v16; // [xsp+48h] [xbp+48h]@5
__int64 rhs; // [xsp+50h] [xbp+50h]@1
__int64 v18; // [xsp+78h] [xbp+78h]@7
__int64 v19; // [xsp+80h] [xbp+80h]@3
__int64 v20; // [xsp+88h] [xbp+88h]@3

v2 = a1;
v3 = a2;
android::Region::Region((android::Region *)&rhs);// Region::Region(const Rect& rhs)
counter = 0LL;
if ( v3[8] ) // if 16 byte block count != NULL
{
do
{
bufferOffset = 16 * counter++; // read next 16 bytes
junkArray = (unsigned int *)(v3[9] + bufferOffset);
v7 = *junkArray;
v8 = junkArray[1];
v9 = junkArray[2];
v10 = junkArray[3];
android::Region::addRectUnchecked((android::Region *)&rhs);// void Region::addRectUnchecked(int l, int t, int r, int b)
}
while ( v3[8] > counter );
}
android::Region::intersect();
v11 = (_DWORD *)(v19 + 16 * (v20 - 1));
if ( v11[2] - *v11 <= 0 || v11[3] - v11[1] <= 0 )
{
v13 = 0;
}
else
{
v12 = v3[7];
rect = v3[6];
v16 = v12;
v13 = (unsigned __int8)android::Rect::intersect(&rect, v2, &rect);// android::Region::intersect(android::Rect const&)
if ( v13 )
{
HwcPartialUpdates::UpdateSourceCrop(v2, v3, &rect);
HwcPartialUpdates::UpdateDisplayFrame(v2, v3, &rect);
}
else
{
v13 = 1;
}
}
android::Region::~Region((android::Region *)&v18);
android::Region::~Region((android::Region *)&rhs);
return v13;
}

I'm still not that sure what exactly v3 is but I could try to insert a second if statement as binary patch. it seems that in this segfault case v3[8] is not empty but the adress v3[9] + 0 does not exists. Btw it passes this position a few times in advance during the bootanimation. It's not that it doesn't work at all. If I'd know excatly what v3 is (probably hwc_layer_1 which is some frameBufferTarget), then I could fix the source which causes that segfault.

PS in order to try different vendor blobs I'd need these files from any 6.0* GRA-L09 ROM:

lib/hw/gralloc.hi3635.so

lib64/hw/gralloc.hi3635.so

lib/hw/hwcomposer.hi3635.so

lib64/hw/hwcomposer.hi3635.so <--- md5sum: f637a9873dc24c47cd5ae62c4a886d22 (my version)

lib/libui.so

lib64/libui.so

lib/libsync.so

lib64/libsync.so

lib/libion.so

lib64/libion.so

It's more easy to ask than just trying to find every available img with the hope thatany of them contain a slightly different version.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
v3 is assigned the address of the incoming a2 parameter . By my calculation v3[8] points to the 9th QWORD (8 bytes long) in that structure (ie: the 64th to the 72nd byte). hwc_layer_1 has lots of unions in it, but since it is 96 bytes long, and ends in padding on 32-bit devices from 84 to 96, would estimate that v3[8] is pointing to the around the hwc_region_t surfaceDamage item at the end of hwc_layer_1.

That item is one of these:

typedef struct hwc_region {
size_t numRects;
hwc_rect_t const* rects;
} hwc_region_t;

I imagine the loop index is v3[8] and v3[9] points to the rectangle. It's spinning through the rectangles and adding them to the display list.

The header file https://source.android.com/devices/halref/hwcomposer_8h_source.html mentions something about HWC_DEVICE_API_VERSION_1_5 which is also commented out/adjusted in the code in your repository.. could be be some hints there.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Wow thx a lot. I'd wish I'd be more familiar with that.

The API version is reported as 1.4 with some not implemented calls (which are required according to the header file) maybe they made a frankenstein api. I will take a look.

So... surfaceDamage.numRects is > 0 and:

is not the case. It doesn't contain any to my point of understanding (first iteration -> SEGV).

hm... These lines in HWComposer.cpp?:

disp.framebufferTarget->visibleRegionScreen.numRects = 1;
disp.framebufferTarget->visibleRegionScreen.rects = &disp.framebufferTarget->displayFrame;

It's the only thing which alters numRects to something else than 0 and rects to something else than NULL
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] AD2076:
Is it ok if I extract the files from the phone? I am running B370 FF Edition from Blackball.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
I think that should be fine. However I'm not 100% sure why these vendor files are not public available for download maybe send via a covered channel.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
I think we're looking for surfaceDamage.numRects, so I'm not entirely sure that is the right bit.

If we are dealing with an API level of 1.4, then it is quite likely that the surfaceDamage is not set properly or initialized at all. If so, it will generate random results. The comment in the header file seems to imply it is an optimization to show which parts of the screen have been altered.. maybe to prevent the whole buffer from being updated.

You mentioned numRects is > 0. What is its value in your tests?

I feel that this bit of code can be ignored - probably easiest to force numRects to zero if you can.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
I forced it to 0 and NULL and I've seen the android menu bar at the top. Pressed the volume key and got a segfault (surfaceflinger) again. I have to look at the runtime value again but as far as I remember it was very high.

hwc_layer_1 has a reference to framebufferTarget somewhere which is part of a Disp* struct. That was just a guess. It may be what we're looking for.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
Understood. The rectangle list structure is used in lots of places for different things. It will not necessarily end up in the surfaceDamage member of this hwc_layer_1.

Is the new segv in the same location? If so, the call stack should be different.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Naa still the same. I forgot to copy back some vendor files. I really wonder what they have done. A.e.

mHwc->getActiveConfig and

mHwc->setActiveConfig

are not implemented but this is stated as required in the API 1_4 description. For these that's not an issue but still...
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
Curious. I should be impossible to get into that loop if you set numRects to zero. So I would expect any SEGV in the same place to have a different caller (one you haven't patched).

If the blob's code (the assembler you posted) is trying to access that rectangle list, it means the blob is supporting API level 1.5. You mentioned you had to drop things to 1.4? Could this be the main problem you are having (1.5 blob, 1.4 calls to blob).

The way they've set this up is to pre-allocate more space than is required in these structures, and then fill up the end of them with new things as the API level increases.

So, if the code-that-calls-the-blob doesn't set up these areas of the structure properly, and the code-that-is-the-blob expects them to be filled properly, then things will go bang.

Sooo if the blob is 1.5, then the code calling the blob has to also be 1.5... or.. bang :)
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
The 2 functions (getActiveConfig and setActiveConfig) are missing in the vendor blob. Thats from hwcomposer.h:

--> getActiveConfig caused a segfault so I replaced the call and set the var to 0 or -1 doesn't seem to make any difference.

--> setActiveConfig was never called.

That's why I think they made a frankenstein hwc if it really supports 1_5.

hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_5)

returns false while everything below returns true.

I uncommented all the checks for 1_5 as it seems that this is the only feature which comes with this version. I get exactly the same segfault.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
The frankenstein theory seems possible, given this situation.

Shall we try modifying the blob to make it impossible for that loop to be entered? If you send me the binary I can patch it for you.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Should probably work then. I will send it. thx :)

I'm trying to do it as well at the same time - have to learn this. I replaced 80 22 40 F9 (LDR x0, [x20,#0x40]) with 00 00 80 D2 (MOV x0, #0)

It doesn't enter the loop anymore, however it also doesn't draw anything on the screen now. Maybe we should add further if condition.

.text:0000007F95FCE590 LDR X0, [X20,#0x40]
.text:0000007F95FCE594 CBZ X0, loc_7F95FCE5CC
.text:0000007F95FCE598
.text:0000007F95FCE598 loc_7F95FCE598 ; CODE XREF: _ZN17HwcPartialUpdates17UpdateSourceLayerEP11hwc_layer_1+64j
.text:0000007F95FCE598 LDR X3, [X20,#0x48]
.text:0000007F95FCE59C UBFM X2, X19, #0x3C, #0x3B
.text:0000007F95FCE5A0 MOV X0, X21 ; this
.text:0000007F95FCE5A4 ADD X19, X19, #1
.text:0000007F95FCE5A8 ADD X4, X3, X2
.text:0000007F95FCE5AC LDR W1, [X3,X2]
.text:0000007F95FCE5B0 LDR W2, [X4,#4] ; int top
.text:0000007F95FCE5B4 LDR W3, [X4,#8] ; int right
.text:0000007F95FCE5B8 LDR W4, [X4,#0xC] ; int bottom
.text:0000007F95FCE5BC BL ._ZN7android6Region16addRectUncheckedEiiii ; android::Region::addRectUnchecked(int,int,int,int)
.text:0000007F95FCE5C0 LDR X1, [X20,#0x40]
.text:0000007F95FCE5C4 CMP X1, X19
.text:0000007F95FCE5C8 B.HI loc_7F95FCE598
.text:0000007F95FCE5CC
.text:0000007F95FCE5CC loc_7F95FCE5CC

I think we need to check if [X1, X2] or X4 is a valid address as well at this point: CBZ X0, loc_7F95FCE5CC
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] Kostyan_nsk:
Guys, I'm afraid you're digging too deep.

I would recommend you to start all over again and make device tree from scratch.

Get rid of prebuilt libraries and binaries, especially from JNI libraries and Huawei framework.

It's a very bad idea to use prebuilt surfaceflinger, libgui, libui and so on.

Leave only device-specific services and libraries (lib/hw). If some binary or library requires undefined symbol in aosp library, don't replace whole library with prebuilt one, make a shim library instead of it.

At this moment it looks more like porting aosp framework to emui rom, instead of building aosp. Replacing libraries is like a snowball - every replaced library will require a few more ones...

And btw, I wasn't seeing your recent logs, but what I saw had a bunch of "page record was not found" errors. This means that linker can't find something in used libraries...

You have to change your approach for build method.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
I changed that approach 2-6 weeks ago already. I don't have any missing page records or any other critical errors in the logs right now. I stopped to post them since it's just to much. So they are pretty outdated and meanwhile I know about what you explain. Btw. libui + libsync + libion seem to have a minor impact on the provided hwcomposer compatibility. I'm looking forward to replace them with the cm libs.

The libs were the problem right now is ARE required to get graphic driver running. There's no workaround except writing an own hwcomposer which is supposed to be implemented by the vendor only. I could get this one working but then "At this moment it looks more like porting aosp framework to emui rom, instead of building aosp" that would be the case. Right now I'm trying to make the surfaceflinger from cyanogenmod able use the libraries which are provided only by the vendor or meant to be implemented by them.

Why? A few required vendor libs are the only issue right now. and even when not it's just about altering the proprietary (6.0) files.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
OK it seems that this segfault is caused by

HWC_NUM_DISPLAY_TYPES = 3 in libhardware/include/hardware/hwcomposer_defs.h

I took some time and spawned tons of debug messages into the surfaceflinger (Just another try to find the initial cause) since I wasn't allowed to ptrace it. on HWComposer.cpp in prepare it enumerates this value and performs some actions on them. All is fine for #1 and #2 on #3 we have this segfault in the hwcomposer.

Edit: ok seems that this doesn't occur each time but this line is responsible:

int err = mHwc->prepare(mHwc, mNumDisplays, mLists);

I added log messages one line before to see the values which cause the segfault later(remember the assembly) this is the state on segfault:

all previous logs during the bootanimation look like:

[B] ,==< 0x0001d594 cbz x0, 0x1d5cc[/B]
.---> 0x0001d598 ldr x3, [x20, 0x48] ; [0x48:4]=0 ; 'H'
||| 0x0001d59c lsl x2, x19, 4
||| 0x0001d5a0 mov x0, x21
||| 0x0001d5a4 add x19, x19, 1
||| 0x0001d5a8 add x4, x3, x2
||| 0x0001d5ac ldr w1, [x3, x2] <--SEGV
||| 0x0001d5b0 ldr w2, [x4, 4] ; [0x4:4]=0x10102
||| 0x0001d5b4 ldr w3, [x4, 8] ; [0x8:4]=0
||| 0x0001d5b8 ldr w4, [x4, 0xc] ; [0xc:4]=0
||| 0x0001d5bc bl sym.android::Region::addRectUnchecked
||| 0x0001d5c0 ldr x1, [x20, 0x40] ; [0x40:4]=1 ; '@'
||| 0x0001d5c4 cmp x1, x19
`===< 0x0001d5c8 b.hi 0x1d598
[B] `--> 0x0001d5cc add x19, x29, 0x78[/B]

[MENTION=7539994]GodzillaMonster[/MENTION]

May it be possible that it's not the surfaceDamage but visibleRegionScreen member of DisplayData.framebufferTarget (hwc_layer_1)?
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] AD2076:
http://xdaforums.com/showpost.php?p=68872310&postcount=3

The changelog mentions some graphical issues, maybe new libraries/blob can help?
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
Hmm.. I would be surprised.. the 4294967295 numRects seems to support the notion that that area of the struct is not initialized.

Are you certain the call stack at the SEGV is exactly the same even when numRects is zero? Is it possible the routine is being called from somewhere else after you've set the numRects to zero?
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] fisher6:
I have to agree with this post. Not saying that implementing your own hwcomposer wouldn't work but I think it is easier to follow the general flow described in the quote above. I know from experience that working with AOSP is much easier than CM for the P8. That said, when i was working on CM 12 for the P8, I managed to get it to initialise the GPU drivers and boot without any issues. On AOSP MM,*I even played some YT videos and games without any major glitches. In any case, my P8 has been dead for weeks and I'm waiting for a new one before I can start looking at this stuff again.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Do some of you read - I did the last 2-6 weeks. Also hwcomposer isn't essentially a part of the GPU driver it just makes use of it.

The libs for 5.0 are completely different and I remember that it wasn't that problematic for 5.0. No one tried it with 6.0 yet as far as I know without patching the kernel in order to use the new GPU driver (which loads fine). It's a HWC/Surfaceflinger issue and now tell me how to not replace HWC (which is per definition from google a vendor specific library) and make it boot ;) The issues are there and exactly the same with copied as well as with compiled dependencies.

The rest of the copied dependencies (vendor libs) were eighter required and did not caused any further issues (very minor amount) or they are just there on the original huawei rom and not part of the compiled version where it shouldn't matter to copy them at this point.

In order to "follow the quotes" I can just repeat I have to find out what they changed in their surfaceflinger and apply these changes to the CM sourcecode to make it able to use the HWC.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] AD2076:
Glad to know you are still working on it.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Ok... apparently It's possible to just disable the hwc. by moving out the vendor library. I'm not sure how much performance impact it has and I don't like this solution but hey - touchscreen does react I can get trough the welcome screen and end up with a functional ui :)

uhhh I need to enable vsync somehow.

[IMG="gra_l09"]http://dl-1.va.us.xda-developers.com/3/8/8/8/8/9/3/IMG_20160928_175109.jpg?key=rBOTDM025cQt7NvxUpLiEg&ts=1475078332[/IMG]
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] user_x25:
Awesome, this way you could test some solutions easier.... Nice job!

Inviato dal mio HUAWEI GRA-L09 utilizzando Tapatalk
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
I updated the main post and will start to fix the obvious issues. At the moment I'd not like to use it like this ;)

Some of them may be easy to fix but I'm done for today.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] lespaul79:
great work and effort, my congratulations on their progress and achievements wish you luck on your project.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] lataldragon:
Mega work, thank you ever advance for this Cyanogenmod Rom, no matter how long it will take. Thank you thank you thank you :D :good::good::good::good::good:
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Just got WiFi to work :)

I have a few errors reported in the logs but I'm able to use the internet via any hotspot.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] AD2076:
What about RIL?
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
RIL wil take quite a while that one seems complicated at the first glance.

RIL and Backlights are probably next. But the audio is annoying as well.

I have a few other projects as well at the moment the progress may go slow. But anyway feel free to contribute The git should have the latest state.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] GodzillaMonster:
Well done. Kudos to you for your effort, determination and skill.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Got the audio output to work

Mic, Ril and probably backlight and we might have something basically functional.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] fpippo1999:
Great! :good:
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] erayrafet:
Check this out

http://www.meticulus.co.vu/2016/10/huawei-p9-lite-ril-up-and-running.html?m=1
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Thx missed that page.

The solution 1:1 doesn't change anything but it may be something very close to this.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] Kostyan_nsk:
Your device doesn't support CDMA2000 and doesn't have VIA CBP 8.2D modem on board.

You might have messed up something in .rc files or properties because libvia-ril.so is not have to be used.

Compare with logcat from stock rom, if there's the same error, then just ignore it.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
How? these files, configs and init.rc modem related stuff comes from the stock rom... oh wait in the kernel (which may be used for multiple devices) they have actually mentioned 2 modem types. balong (which reports ~ is ready on boot) and via. I've seen another dev had choosen rild.libpath=/system/lib64/libbalong-ril.so instead of rild.libpath=/system/lib64/libvia-ril.so. That may be what I've messed up. But I got these props somehow from the stock.

I'd prefer not to reflash everything stock just to look at the logs.

Edit:

I got the props from "one" section of phone.prop. It seems that huawei created a single prop file for all their modems and they are referenced by hex values. ~500+ sections. I'm trying to find any reference in the stock files but was not lucky so far. Howevery they almost all look pretty similar with only minor changes. I might be able to just correct that path.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Hm now I see the signal strength symbol and a "only emergencies" message as well as the provider of the sim card. Not sure about what's up now (Need to find a activated nano sim card to test it)

Edit: ok found and old one from germany. Got the roaming icon, signal strength, received configuration sms, can receive incoming calls, can make outgoing calls (sending sms doesn't seem to work yet)

The send sms issue is something located in the framework doesn't look that bad.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] lespaul79:
you're getting, my congratulations
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] user_x25:
Awesome. Keep this way, it's fantastic!

Inviato dal mio HUAWEI GRA-L09 utilizzando Tapatalk
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] Tarumahr:
Thanks to all developer for HARD WORK!!! You are THE BEST!!!!!!!!!!!!!!
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
I'm not sure how critical this error is. after that it tries to check some url and then:

10-05 20:44:06.474 3271 5462 D NetworkMonitor/NetworkAgentInfo [MOBILE (LTE) - 102]: Probably not a portal: exception java.net.SocketTimeoutException

10-05 20:44:06.480 3271 3323 D ConnectivityService: NetworkAgentInfo [MOBILE (LTE) - 102] validation failed

It may be just the simcard I'm using. Have to get a nano sim version of my regular one.

Edit:

It may be better to use the open source rild and this seems not that hard to archive.

The only issue is that the modem driver (libbalong-ril.so) partially depends on not implemented functions in libril.so where rild does that as well when replacing (libril.so). I will try to implement the missing functions ind libril and use:

From CM:

Telephony framework

rild

libril.so

librilutils.so

libreference-ril.so (if possible)

...

From the vendor:

configs

libvia-ril.so (vendor specific)

libbalong-ril.so (vendor specific)

libbalong-ril-1.so (vendor specific)

Using all the files from the vendor works up to some point where I'm not 100% sure if it is 100% functional (network). It's also the more dirty solution.

Edit:

Ok I was able to create some shim libs (did not knew about them that brings some new possibilities) and the balong driver seems to accept it most likely. I will rebuild the telephony framework from the original and not patched source and check if this works. The rild communicates with the framework and I siwtched it to a patched version where the dev tried to use all the files just like me before.

Edit2:

mehh doesn't really work that well. I will use the vendors files for now.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] MonkeyBadger:
Job?

Great work on the ROM. Just a silly question you mentioned you are working on this full time? Are you mega rich? :-p If not you should set up a way for us to reward you.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
It's something similar to google where devs have some time to do their own stuff. This is also for educational purposes. I'd not say it's my job but I got time for this which may be limited. I don't earn much so I'd be happy about a reward but I don't really expect it. I'm happy when I get this device to run 100%.
[Huawei P8 ROMs, Kernels, Recoveries, & Other Devel] nexolight:
Could someone with the stock rom on a GRA_L09 (single sim version) installed give me the output of "adb shell getprop" That would be helpful :)