yashsingh1/xdaforums huggingface dataset:
[Xperia Z5 General] zacharias.maladroit:
Nice ! Great work :)

The more features this device can offer - the better,

as soon as cyanogenmod has a certain set of functionality (well, right now that's the microSD since internal storage is filled up way too fast with my music & movies I watch on the go),

the kernel sorely needs a recompilation with UberTC - I don't know what Google hasn't switched to a more optimized Toolchain meanwhile. :confused:

CyanogenMod's (and AOSP's) smooth but once you've tried a kernel with optimized toolchain and compiler flags - you never want to go back :)

Thanks

emerge maven-bin did it (Gentoo user), mvn rings familiar though,

yeah, jack might cause some issues,

I'm hearing a *click* noise a few moments after sound has been played through the speakers - power management/energy saver might be kicking in when that happens,

but that appears rather archaic.

alright, will set those to disabled on the next build(s) to be sure

Thanks

Not sure if it's already included in init or startup scripts, but I saw it being mentioned on gerrit among other options

lpm_levels.sleep_disabled=0

I used that before on my kernels to cut down battery consumption, but perhaps it needs a few upstream changes to work efficiently in lower power modes.

Also there's some potential issues during bootup when the LPM modes are enabled by default (longer bootup, hang, etc.), so I guess that's why Sony set it that way,

but it's of no use staying disabled since it appears to work fine on AOSP (CyanogenMod probably, too).

Okay, so that coherent_pool=2M works without trouble ? Default from upstream (AOSP) is 8M but that's rather large, perhaps 6M is enough - there might be some implications for driver functioning, memory fragmentation and performance.

Green light from here, too - so CyanogenMod works on the Z5, too (besides Z5 Compact and Premium) :cowboy:

Great stepping stone to get other ROMs set up and the ball rolling :cool:

Thank you
[Xperia Z5 General] :
Z,

my first build with pool @ 8m resulted in an initial boot of almost 10 minutes. 2m is the "default" from official MM release.

The clicking is present on my build/phone too, i though it was a hint as to what's wrong with the mic.

I'll give a go with uber but my understanding is rom and kernel side both need that optimizatition to really notice benefit?

[MENTION=6584695]CTXz[/MENTION]

These are my current brightness settings

Must be overridden in platform specific overlays -->
<integer-array name="config_autoBrightnessLevels">
<item>64</item>
<item>128</item>
<item>170</item>
<item>220</item>
<item>256</item>
<item>384</item>
<item>512</item>
<item>768</item>
<item>1024</item>
<item>1536</item>
<item>2048</item>
<item>4096</item>
<item>6144</item>
</integer-array>

<!-- Array of output values for LCD backlight corresponding to the LUX values
in the config_autoBrightnessLevels array. This array should have size one greater
than the size of the config_autoBrightnessLevels array.
This must be overridden in platform specific overlays -->
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>10</item>
<item>32</item>
<item>64</item>
<item>80</item>
<item>96</item>
<item>112</item>
<item>128</item>
<item>144</item>
<item>176</item>
<item>196</item>
<item>208</item>
<item>224</item>
<item>255</item>
</integer-array>

<!-- Minimum screen brightness setting allowed by the power manager.
The user is forbidden from setting the brightness below this level. -->
<integer name="config_screenBrightnessSettingMinimum">10</integer>

<!-- Screen brightness used to dim the screen while dozing in a very low power state.
May be less than the minimum allowed brightness setting
that can be set by the user. -->
<integer name="config_screenBrightnessDoze">112</integer>

<!-- Screen brightness used to dim the screen when the user activity
timeout expires. May be less than the minimum allowed brightness setting
that can be set by the user. -->
<integer name="config_screenBrightnessDim">10</integer>

Adaptive brightness is still horrible, what am i missing?

Tap to wake doesn't work., Z there should be a device associated with that?

With re-sync external storage is still porked, i'm gonna go with the sloppy option for now.

Volume seems limited, HW, Volume kicks when using MX Player with SW decoder though :good:

Derp with ubertc aarch64-kernel 6.0

In file included from include/linux/compiler.h:54:0,
from include/uapi/linux/stddef.h:1,
from include/linux/stddef.h:4,
from /storage/sxZ5_dev/kernel/madkow/include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/page-flags.h:8,
from kernel/bounds.c:9:
include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc6.h: No such file or directory
#include gcc_header(__GNUC__)

Tried the header shenannigans but no dice use below 6
[Xperia Z5 General] zacharias.maladroit:
In theory yes, but when using an optimized kernel the effect strangely is also quite noticeable on Android

whereas on Desktop Linux I haven't seen such a huge difference when optimizing kernels via flags

It's a feature :p

It also didn't work properly on Sony's Stock ROM for me and on Stock it's known to be a battery drainer (how about on AOSP ?)

so I don't really bother anymore - yeah it would be nice to have it working ...

Perhaps taking a look at Leo (Xperia Z3) and how they do it ?

Thermanager might play a clear role in this (e.g. having read about brightness "throttling" once the phone is getting somewhat hot)

Otherwise it might be a hardware issue (or limitation) :(

(rather software, perhaps higher polling rate of the driver on the system or even driver side, or something like that might help, as side-effect however might increase battery consumption)

M, it has been for me like that since I started to use self-made kernels and even kernels that are built during AOSP (https://github.com/SonyAosp/platform_manifest ),

the prebuilt kernel that comes along when following the instructions at http://developer.sonymobile.com/kno...aosp-marshmallow-for-unlocked-xperia-devices/ worked fine (6.0.1_r10 afaik was the pre-built kernel I tested back then and the kernel was from end of February, somewhat outdated compared to the freshly baked ROM)

so it could be that upstream kernel-changes broke it meanwhile

otherwise only [MENTION=359497]jerpelea[/MENTION] or [MENTION=489838]kholk[/MENTION] might know why that (double-tap-to-wake) is failing.

The signal even is clearly being recognized by the Kernel (take a look at dmesg output) but it's not waking up the screen :confused:

Feedback of the toolchain (specific gcc version) used however could prove useful,

so if anyone has built a recent AOSP (http://developer.sonymobile.com/kno...aosp-marshmallow-for-unlocked-xperia-devices/) and uses the prebuilt kernel - NOT the AOSP from https://github.com/SonyAosp/platform_manifest ,

it would be good to know if tap-to-wake still works

I might give that a go - it's good to have access to external storage, how "hacky" it anyhow might seem.

So your 128 GB card gets detected or shown from the system ? Or there's also no sign,

only some output on dmesg and the manual mounting works ?

It's annoying that specifically the larger cards that would be most beneficial won't work :eek:

Last time I tried AOSP the card was still being shown in system, even if non-functional,

a 64 GB card however worked but now seemingly cards in general aren't automagically being detected and shown

Haha - yes, that 200% volume amp is sweet :good:

A little further in we could add FauxSound that should also give some amp (but also hissing and noise on the higher levels)

---------- Post added at 01:33 AM ---------- Previous post was at 01:31 AM ----------

Advanced Boot and Booting into Recovery works great, btw :)
[Xperia Z5 General] :
Z,

something interesting, while testing out krabby's aosp build i formatted my card in house, but now while my card reads in that build [exfat] it's broken again in my own build and not registering. This is the interesting part

before the aosp formatting the card, the entire card/block/device was mmcblk1 <-- working for cm13 with sloppy mount / not working with aosp

after aosp format the card/block/device was mmcblk1p1 <-- not working at all cm13 / working in aosp

So yeah, vold seems fubar in cm13 maybe?

I'm going to run another build after tinkering a bit, the card size being the culprit doesn't seem unreasonable but hmm.

https://bitbucket.org/UBERTC/aarch64-linux-android-5.3-kernel :good:

Getting stranger! after compiling kernel with the above toolchain , now mmcblk1 and mmcblk1p1 are back. xD

Probably just a fluke but wierd.

Okay, i'm not imagining it, switching toolchains to ubertc version mentioned actually did result in mmcblk1 mmcblk1p1 being present.
[Xperia Z5 General] CTXz:
[MENTION=3037651]zacharias.maladroit[/MENTION] The hotplugging tweaks were adjusted by a sonyCM member to work with sony AOSP kernel latest thermal manager configs
[Xperia Z5 General] zacharias.maladroit:
Okay, he should know it better from experience :)

Is something wrong with my phone or why is AOSP and CM draining that fast ?

It's completely vanilla (just flashed) and now just drained 21% in 9 hours in Airplane Mode :eek:

This is a different Firmware from my Service Provider (the previous one was Russian) but there shouldn't be such a difference between the bootloaders or background data, no ?

Is this also something you guys observed ? If yes, it could be either a kernel or ROM regression
[Xperia Z5 General] CTXz:
? All good here ;)
[Xperia Z5 General] :
Z,

check this on sepolicy

SELinux: Get rid of taimport (and ta_data_file)

m
[Xperia Z5 General] zacharias.maladroit:
Impressive !

You're fast :D

That result didn't turn up in my search - I guess I'll need to accumulate quite a few changes and then compile a new build

Thanks !

Oh, by the way, double-tap-to-wake does work - with the following commit reversed (as suspected):

https://github.com/sonyxperiadev/kernel/commit/17576a2c2ab38956292ba449529efa199375e6db kitakami: update touchpad wake code

Rebooting into recovery (now cyanogenmod's recovery) is still broken:

I used initramfs from the built kernel and used it on my custom kernel and it errors out (notification led flashing red after restart and attempt to get into recovery)

Sony really keeps things interesting :/
[Xperia Z5 General] :
Z,

yeah cyanogenmod recovery is useless for our purposes, but twrp build seems to flub it in the same round as a systemimage build so build twrp with recovery variant flag, then clobber and run build like mormal, make sure you have hardware/sony/init in place, testing tappy now

also syncing omni since vold issue is not making sense to me on cm
[Xperia Z5 General] zacharias.maladroit:
M,

since you're mentioning vold: I forgot yesterday to post that the current version of exfat appears to be 1.2.9

just google for exfat 1.2.9 and github and you should have the newest version (might contain some fixes).

I haven't build twrp yet but likely will take a look in the weekend and see how it goes,

thanks for the tip
[Xperia Z5 General] :
Z,

i already have latest in kernel, on a good note, i am a happy tapping fool ! :silly: :good:
[Xperia Z5 General] zacharias.maladroit:
:cool:

Now if we only could push down battery consumption further when d2tw is enabled,

it drains quite a bit :eek:

I also prefer to use d2tw instead of the power button this should significantly extend the device's lifetime and it's more convenient (to prevent breaking of the power button - unless of course you use the fingerprint scanner :p)

https://github.com/sonyxperiadev/device-sony-common/commit/0fe3770f1900c86076e5a47cafa75693fd6b5b80 common: Fix tad_static denials

okay, so that's the commit that introduced that change

I wonder what's wrong about that argument :confused:

( init: cannot setexeccon('u:r:tad:s0'): Invalid argument )

is CyanogenMod not understanding that permission level (is the security domain non-existent) ?

You don't see those messages on your phones/ports ?
[Xperia Z5 General] :
[MENTION=6584695]CTXz[/MENTION] 's sources are pretty square, did you do your own vendor/proprietary pull or are you running a build straight from repo sources only? I recommend the latter.

Androplus has OC/UV work done in his source, which was my next target after figuring out the exfat/mounting issue.

m
[Xperia Z5 General] zacharias.maladroit:
I followed [MENTION=6584695]CTXz[/MENTION] 's approach and pulled proprietary files for the Z5,

it matches quite closely the build for suzuran (Z5 compact)

what do you mean with "straight from repo sources only" ?

I saw that satsuki differs and relies more on the AOSP files, so that's probably what you mean ?

There's again issues with loading the firmware for venus

this indicates that (still) the firmware blobs for AOSP don't work and will have to be replaced by Stock ones

This might also appear in your logs & could indicate that the camera (video recording ?) or other functionality therefore isn't working properly

The large microSD card is being recognized (shown in log, not sure whether it's due to recent changes I added),

so it must be an issue from system's (vold, permissions handling ?) side rather than kernel

Here are the sources of the current kernel I'm running on this CM build right now:

Sun-Kernel_LA.BF64.1.2.2_rb4.7_02.04.2016_I.1

it got some power management and efficiency fixes but they are pretty worthless right now with macaddrsetup and tad_static throwing tantrums every few seconds

OC/UV didn't work and was broken (e.g. allowing values up to 170-300 mV of undervolting; arrays broken or values missing ?)

Tommy-Geenexus mentioned that it's being handled in-kernel (or even in-hardware) so not sure how much of an effect the settings in the kernel and then from userspace would have

Still it would be good to have :good:

Anyway - I'm out, got other things to do - spent (al)most all of the day to get CM working and troubleshooting several things

---------- Post added at 07:53 PM ---------- Previous post was at 07:43 PM ----------

Give https://github.com/AudioGod/Gods-Ke...mmit/cc4f969e5d9f90478982f9ec3f7f6494627ba7ff a try

drivers might still fail though,

gcc 4.9 works fine, 5.3 also might start causing trouble ...
[Xperia Z5 General] CTXz:
I've switched fully to AOSP blobs, just use the ones on git
[Xperia Z5 General] zacharias.maladroit:
I'm using the approach that you did - so that mostly should be using AOSP blobs (except the audio stuff),

there's something off with the venus firmware , it errors out - last time I tried the "stock" firmware (Lollipop afaik ?) worked and the firmware initialized correctly,

didn't appear to have worked with "stock" firmware from Marshmallow though.

Concerning the Cam: we might need to wait for Sony to release support for the Z5 series and their Experimental AOSP camera

http://xdaforums.com/showpost.php?p=66225421&postcount=92

http://developer.sonymobile.com/201...-camera-available-for-experienced-developers/

http://www.androidheadlines.com/2016/01/sony-calls-on-developers-with-experimental-aosp-camera.html

Standby time is actually insane: 12 hours 0-1% Airplane mode , 7 hours 1-2% in RIL idle - double-tap-to-wake, tap-to-sleep was enabled all the time,

PowerNap + XPosed might help against some wakelocks but this excellent.

I wonder why Double-tap-to-wake drains that much in Sony's Firmware (virtually EVERY feature or non-feature drains) :confused:

[MENTION=5864662]moonbutt74[/MENTION] You mentioned that a different toolchain made the SD card detection work better,

did you use additional optimization switches, modifications to the driver ?

what is the toolchain you're using now ?

Thanks
[Xperia Z5 General] :
Z,

current toolchain as mentioned earlier, https://bitbucket.org/UBERTC/aarch64-linux-android-5.3-kernel

so apparently toolchains can have wierd effects, cause breakage, even though the kernel appears to compile "correctly"?

I am not passing any optimizations, i am compiling a concatenated,compressed zImage-dtb.gz

Regardless of the whole monolithic thing i have enabled module loading, forced loading/unloading, and versioning support.

Sony used tuxera exfat module on the 0fficial releases

1|root@satsuki:/ # modinfo /system/lib/modules/texfat.ko
filename: /system/lib/modules/texfat.ko
alias: fs-texfat
license: Commercial. For support email exfat-support@tuxera.com
description: Read/Write exFAT driver
author: Tuxera Inc. & Anton Altaparmakov
depends:
vermagic: 3.10.84-perf-g19d6d92 SMP preempt mod_unload modversions aarch64

snooping around through github with search term texfat seems to show some makefiles using gzipped texfat release versions as part of the build, i'm guessing the module also needs to be signed and so have module sig checking in kernel as well. But the free exfat seems to do fine as again i can sloppy mount the volume. so i'm still on the fuse exfat thought. i have to scare up a 32 gb card fat32/vfat format to see if it really is vold screwing up.

m
[Xperia Z5 General] CTXz:
I'm sure that this is not due to the toolchain but sonys recent shift away from the ol' mkbootimage script and going for a dtb system
[Xperia Z5 General] zacharias.maladroit:
M,

yeah, certain, specific gcc versions can cause wide breakage and then with the next it works fine again,

there are quite some interesting stories related to that on LKML (the Linux Kernel Mailing List)

the funny thing (or stupid, depending on how you look at it) is,

that this doesn't work on Sony's "stock" kernel - the proprietary modules or some other part prevent it - and that it nevertheless works well :confused:

Also there's broken "non-trusted" handling in Sony's bootloader (or software) from what I read on the forums which prevents certain modifications from working that actually should work

== phone shows Sony screen for a moment, then notification led flashes red a few times == dead :silly:

This is a big no-no with "open devices", but that's how the corporate world ticks, I guess ...

okay, so that doesn't account for it - but partially also could,

depending on how the "default" optimization settings are set in Makefile:

https://gcc.gnu.org/gcc-5/changes.html

which actually should break things but it looks like gcc 4.8, 4.9 is nevertheless causing some breakage - there are floating around some patches to fix that (which I've now included)

one of them is included already in Makefile.

The Makefile is still setting it to gnu89, though:

HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89

KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security \
-fno-delete-null-pointer-checks \
-std=gnu89

so if gcc 5.3 fixes it - it comes down to a compiler bug (call it bug, regression, error, ...) that meanwhile got fixed,

sometimes there are backports of these fixes to previous versions.

Let's see how the compiled kernel with gcc 5.3 is faring

well, we could try using texfat since that appears to be superior to exfat (transaction-safe fat, looks like it uses atomic commits or a journal file internally), which

guarantees faster recovery after a crash, consistency:

naming the kernel version like Sony's Kernel and force-load the modules + allow disagreeing of module symbols,

it however only would be a matter of time until it breaks - silent breakage would be more severe though (it appears to work but causes data issues such as corruption).

Yeah exfat should do it, if it's not enough we could still revert to other filesystems,

e.g. there's ntfs-3g support (the tools are already included in CM), ext4 without journal and tweaks also is nice - it's quite mature,

it's only a matter that the ROM recognizes it and uses it

Well, that would be nice to know !

I wonder how vold can be forced to do a rescan of the devices - perhaps a few attempts and then it would succeed (e.g. after a timeout) ?

Thanks !
[Xperia Z5 General] zacharias.maladroit:
okay, I'll give that toolchain another try (I used a previous version from beginning of March, things could have improved/changed meanwhile),

I tried various combinations including that toolchain, reverting of commits, compiling the vanilla kernel and previous versions of the kernel

but no dice - both the 64GB and 128GB card are NOT being detected - there's no trace in dmesg output

(it's detected on AndroPlus' TWRP though)

Thanks

the dtb approach doesn't work here, also tried out compiled kernels with a separately created dt.img (previous approach on AOSP) that used to work on AOSP,

but now doesn't

This device clearly has a mind of its own and some kind of personality :eek:

Thanks though
[Xperia Z5 General] CTXz:
[MENTION=3037651]zacharias.maladroit[/MENTION] and [MENTION=5864662]moonbutt74[/MENTION]

One of you reported that you can manually mount the sdcard via terminal or something in that direction. If so we could atleast for the begin make a init script that takes care of exactly that. Additionally we could add a sd mount overlay. If init isn't working we could make a deffered initcall. Note that a deffered initcall isn't working well wit selinux though
[Xperia Z5 General] zacharias.maladroit:
[MENTION=6584695]CTXz[/MENTION]

Agreed,

an init script that reminds vold of its job should be great :)

Trololol:

can't write to any filesystem properly on the microSD (128 GB samsung EVO+),

have tested ntfs + exfat (file corruption, but filesystem appears to be fine ?)

Following Google it appears to be a long-standing and known issue with these kind of cards (microSD XC, 2012, 2013; referring to RPi & ARM Threads).

Either this and there's one or more potential software issues lurking in the code or it's a hardware (firmware ?) issue :(

The question is why the card works in Sony's Stock ROM (well, I mostly only used it for reading rather than writing - so that might have gone unnoticed so far :rolleyes: )

M,

the card seemingly gets detected reliably with the following settings (adapted to satsuki):

CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE=y
CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE_NAMES="msm8994-v2.0-kitakami_satsuki_generic msm8994-v2.1-kitakami_satsuki_generic"

build should be something like:

Yeah, outside custom kernel builds work fine,

custom builds also fail due to fips and hw rng features which I had to previously remove (still have to) to get the kernel compile at all.

I'm sure the DTB build can be included in the CM scripts but the question is then if it works

thanks, probably will include this

Got a similar result with Total Commander, the sdcard was displayed but it kind of needed root permissions ?

could other apps, such as e.g. Mx Player, VLC; or audio players read from the microSD ?

They probably requested permissions - but afterwards it should have worked, right ? :confused:

How's that strip procedure going ?

does

export STRIP=aarch64-linux-android-strip

reduce code size a lot ?

Thanks guys :)