Database Info

Toolchain / Wakeup Lag

Various developers have noticed differences in the amount of lag between different toolchains. Dkcldark reported having a toolchain that nearly eliminates this problem, and was able to share with me how he built it using ct-ng. In essence, the versions and options selected in the arm-iphone sample config for ct-ng produce a toolchain that seems to give much better results. A binary package for linux-x86 is available here. I find that my device is typically ready to use after sleep in about one second, running a kernel built with this toolchain and my fast-stepup and OC modifications, and this is similar to the worst-case behavior for stock kernels. Hopefully this will be helpful to others who want to build kernels - I'm going to try other gcc versions with ct-ng without changing any other options and see what results I have with them.
Results (linked to a toolchain download when a kernel has been built successfully):
binutils 2.19.1, gcc 4.3.4, newlib: about 1s lag on wakeup
binutils 2.19.1, gcc 4.4.3, newlib: kernel panic at UI startup

Good work Unhelpful! Glad you decided to share this with everyone rather than keeping it to yourself and ignoring people.

Excellent work! Thank you SO much for sharing . I know JAC is already making a kernel using this toolchain for the Vibrant. Your work is MUCH appreciated

Thanks..
Honestly, friend... Thank you. I wanted to start looking at kernel sources and trying to build them or at least follow the changes.. I really appreciate your openness with what you've found.

Good find.

[WARNING] Compiler optimizations!

I just noticed this again and it worries me alot! Devs here are usually posting their changes as being different than others, more even about compiler optimizations and yet most of you make huge mistakes.
Personally I've been running Gentoo linux for about ten years now and what I learned from running different setups with space limitations is that one should NEVER use -Os and -O3 together as this will not only take much more time to compile it also GROWS executables.
-Os is basically the same as -O3, but it adds some flags that won't benefit executable size vs memory usage.
In general executables compiled with only -Os are nearly as optimized as -O3/2 and resulting in smaller executable. While compiled with -O3 uses more memory allocation for extra speed. While using both together will result in larger executables, more memory usage AND much longer compile times vs just -O2.
So devs can you all please remove -Os from your "optimizations" and leave just -O2? Bragging about "more compiler optimizations" really fails if you fail to understand why the -Ox optimizations levels have been added in the first place... Which is to NOT use them together!
Also -O3 might introduce more IO operations, which might have a negative effect on our snappies.

The choice: Summarised
-O2 is the default optimization level. It is ideal for desktop systems because of small binary size which results in faster load from HDD, lower RAM usage and less cache misses on modern CPUs. Servers should also use -O2 since it is considered to be the highest reliable optimization level.
-O3 only degrades application performance as it produces huge binaries which use high amount of HDD, RAM and CPU cache space. Only specific applications such as python and sqlite gain improved performance. This optimization level greatly increases compilation time.
-Os should be used on systems with limited CPU cache (old CPUs, Atom ..). Large executables such as firefox may become more responsive using -Os.
Click to expand...
Click to collapse
From: http://en.gentoo-wiki.com/wiki/CFLAGS

Quote from the wiki articale you provided:
"Note that only one of the above flags may be chosen. If you choose more than one, the last one specified will have the effect."

tincmulc said:
Quote from the wiki articale you provided:
"Note that only one of the above flags may be chosen. If you choose more than one, the last one specified will have the effect."
Click to expand...
Click to collapse
My point is that in general people here seem to use "-Os -O3", which is dumb really as it had no benefits. -O2 should be better performance wise on our phones.

great post, thank you man!

Now silently pray for our devs to change their -O3 -Os to -O2.
Or I might need to do my own branch of "optimized" nightlies.
For example what you declare with -march=A -mcpu=B will intact be -march=A -mtune=B.
edit: I think the gcc compiler even throws a warning about l2p etc.

Wouldn't the best choice be just -Os? I would have thought that optimising for systems with limited cache would be appropriate for portable devices.

Pipe Merchant said:
Wouldn't the best choice be just -Os? I would have thought that optimising for systems with limited cache would be appropriate for portable devices.
Click to expand...
Click to collapse
I highly doubt executable sizes on our phones are big enough to benefit from -Os.
In the case of my router at home -Os doesn't give any benefit at all, in fact packet inspection is slightly slower vs -O2.

Optimize Options using the GNU Compiler Collection

I haven't found a good source of discussion on this topic but has anyone experimented with gcc optimization flags when compiling the kernel or a ROM? I dug around and found sparse information on the subject and rarely is Android specifically mentioned. Just curious if anyone has 2 cents on the subject.
I've been trying to figure out how to implement using these flags in kernel compilation but I'm confused if you're supposed to put these in your makefile (both main one and the arch\arm\... makefile?)
is ffast-math preferred over some of the Linaro blog post flags ("We’ve switched from a base of -O2 -fno-strict-aliasing to -O3 -fmodulo-sched -fmodulo-sched-allow-regmoves.")
I've tried sifting through Linaro git repos to see anyone actually using any flags they mention but have yet to find anyone using them yet they say they do somewhere.
GCC Optimization Flags Reference http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Optimize-Options.html
Some background information on the Linaro blogs about -o3 make flag
Compiler flags used to speed up Linaro Android 2011.10, and future optimizations
People trying out the latest Linaro Android builds may notice they’re faster than the older versions. One of the reasons for this is that we’re using a new set of compiler flags for this build.
We’ve switched from a base of -O2 -fno-strict-aliasing to -O3 -fmodulo-sched -fmodulo-sched-allow-regmoves.
To optimize application startup, we’ve also switched the linker hash style to GNU (ld --hash-style=gnu), and patched the Android dynamic linker to deal with those hashes.
Getting rid of -fno-strict-aliasing enables rather efficient additional optimizations – but requires that the code being compiled follows some rules traditionally not enforced by compilers.
Given the traditional lack of enforcement, there’s lots of code out there (including, unfortunately, in the AOSP codebase) that violates those rules.
Fortunately, gcc can help us detect those violations: With -fstrict-aliasing -Werror=strict-aliasing, most aliasing violations can be turned into built time errors instead of random crashes at runtime. This allowed us to detect many aliasing violations in the code, and fix them (where doable with reasonable effort), or work around them by enabling -fno-strict-aliasing just for a particular subdirectory containing code not ready for dropping it.
-O3 enables further optimizations not yet enabled at -O2, including -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone.
While some of them are probably not ideal (e.g. -finline-functions tends to increase code size, thereby also increasing memory usage and, in a bad case, reducing cache efficiency), overall -O3 has shown to increase performance.
-fmodulo-sched and -fmodulo-sched-allow-regmoves are fairly new optimizations not currently automatically enabled at any -O level. These options improve loop scheduling – more information can be found here.
We optimized further by adding link-time optimizations in some relevant libraries, and by using -ffast-math in selected parts of the code. -ffast-math is a bit dangerous because it can cause math functions to return incorrect values by ignoring parts of the ISO and IEEE rules for math functions (parts that make optimizations harder, or that simply require additional checks that slow down things considerably), so it should usually not be used for an entire build – but enabling it for parts of the code verified to not rely on exact ISO/IEEE rules can produce quite a speedup.
We also added the option to specify extra optimizations in a board specific config – so now our Panda builds are optimized specifically for Cortex-A9 CPUs while the iMX53 builds optimize for Cortex-A8 instead of relying on the least common denominator.
We also experimented with Graphite related optimizations, such as -fgraphite-identity, -floop-block, -floop-interchage, -floop-strip-mine, -ftree-loop-distribution and -ftree-loop-linear – those optimizations can rearrange loops to allow further optimizations. We’ve turned them back off for the release because they introduced some stability problems, and the benefit seemed minimal.
However, chances are they will come back in a future build. They can help make more efficient use of multi-core CPUs (with the addition of -ftree-parallelize-loops) once the compiler knows how to to threading (currently, Android is built using a generic arm-eabi targeted compiler that has no knowledge of the underlying OS).
Other possible future improvements – though probably not as efficient as the ones already made, or the switch to -ftree-parallelize-loops for multi-core boards – include seeing what effect a switch between ARM and Thumb2 instructions has on performance (enabling the right mode in the right modules), identifying places where the increased code size of -O3 actually hurts, and add the likes of -fno-inline-functions there, identifying further performance critical parts that can handle -ffast-math, fixing the aliasing violations we’ve worked around this time, and – of course – switching to gcc 4.7 when it becomes usable.
​

make -o3 -o -fmodulo-sched -o -fmodulo-sched-allow-regmoves -Wl,--hash-style=gnu -Werror=strict-aliasing ARCH=arm CROSS_COMPILE=~/(toolchain path)/bin/arm-linux-gnueabihf- zImage modules -j 4
is this how you'd do a make according to the instructions on the linaro blog? This is the only way I could do it for it to actually run something but it doesn't tell me that it's passing these flags

[WIP] Compile Android (5.x) with Qualcomm LLVM 3.7.1 for Qualcomm CPU

Use Qualcomm Snapdragon LLVM Compiler 3.7.1 (https://developer.qualcomm.com/mobi...-performance/snapdragon-llvm-compiler-android) for Android Lollipop 5.x for devices with Qualcomm CPU
As far as I know nobody has done that yet. Except me
This changes the toolchain for CLANG from the default one which comes with Android (aCLANG) to the Qualcomm Snapdragon LLVM Compiler 3.7.1 (qCLANG) mentioned above. The toolchain will be used for almost all places where the default Android CLANG (aCLANG) is used for compiling TARGET MODULES. BUT ONLY if "USE_CLANG_QCOM := true" is set. Otherwise it is using aCLANG. So you can merge this commit and the build will be the same as before except you specifically define "USE_CLANG_QCOM := true"!
WARNING READ CAREFULLY: It is possbile that using this toolchain, especially with the optimizations flags, will introduce BUGS!
DONT SPAM QUALCOMM FORUM PLEASE!
I would suggest: IF YOU USE IT DONT MAKE BUG REPORTS FOR YOUR ROM OR KERNEL OR ANY APPS. Make reports in this development thread. The ROM compiles, boots and starts. Also if Bionic and other modules are compiled with Qualcomm Snapdragon LLVM Compiler 3.7.1 (qCLANG).
Androbench, Antutu, Basemark 2.0 , Geekbench 3, Vellamo are 'completing' the benchmarks. This is a work in progress. There is confirmation that it works for Sony Z Ultra and Samsung Galaxy Note 4 and after some months of testing everything seems good on my personal device.
At the moment this is only tested with Qualcomm Snapdragon 800 but in theory this should also work with any Krait and even Scorpion CPU. According to Documentation there is also support for armv8/aarch64 (Snapdragon 810) and you should gain a real performance bump but support is not yet implemented! If you have a Snapdragon 810 device and want to try this out contact me please.
Install instructions:
You have to make an account in order to download the toolchain!
You need to download the toolchain and extract it to {your android dir}/prebuilts/clang/linux-x86/host/*
Merge/Cherry-Pick this commit: https://github.com/mustermaxmueller/compiler-rt/commit/774cabb50dced5b7acf62af331480397d3a0d12f
Merge/Cherry-Pick this commit: https://github.com/mustermaxmueller/android_build/commit/894f0793d998395e0c15b9ad7a39b277e3aca006
Merge/Cherry-Pick these commits:
https://github.com/mustermaxmueller...mmit/05e2a338b2b66f30d86687c3de4e48d30a2db8d4
https://github.com/mustermaxmueller...mmit/5f4eadfe1bbb5184d650cc9eef8f2306fefc7cdf
You need the Qualcomm Snapdragon LLVM Compiler 3.5 for this to work!!!
OR
Make changes to frameworks/rs/driver/runtime/build_bc_lib_internal.mk like stated here: http://forum.xda-developers.com/showpost.php?p=59626153&postcount=47
Merge/Cherry-Pick this commit: https://github.com/jgcaaprom/android_prebuilt_ndk/commit/98100b2cbeb681698be6093ef964bd1f4414a71f
Set "USE_CLANG_QCOM := true" e.g. in Boardconfig.mk
OPTIONAL (set these options in your Boardconfig.mk):
USE_CLANG_QCOM_VERBOSE := true (If you want to be certain that qclang is used. You will see extra verbose output while compiling.)
USE_CLANG_QCOM_LTO := true (use LTO; not working at the moment)
CLANG_QCOM_COMPILE_ART := true (compile art with qclang)
CLANG_QCOM_COMPILE_BIONIC := true (compile bionic with qclang)
CLANG_QCOM_COMPILE_MIXED := true (compile defined modules with qclang)
CLANG_QCOM_USER_MODULES += (Here you can overwrite which modules should be compiled with qCLANG instead of GCC)
CLANG_QCOM_FORCE_COMPILE_ACLANG_MODULES += (Here you can overwrite which modules should be compiled with aCLANG instead of qCLANG)
Make a clean compile! Also delete ccache!
Annotation:
First boot and every boot after cleaning cache will take up to 15min! Just be patient even if it seems that device is stuck at optimizing apps.
Should also work with Android 6.0 but not tested yet!
You should only get measurable performance benefits if you compile Bionic with CLANG!
Documentation for the toolchain: {your android dir}/prebuilts/clang/linux-x86/host/llvm-Snapdragon_LLVM_for_Android_3.7/prebuilt/linux-x86_64Snapdragon_LLVM_ARM_37_Compiler_User_Guide.pdf
The Flags "-muse-optlibc" and "-ffuse-loops" are not Documented. (http://pastebin.com/PZtk6WHB)
The implementation is not beautiful but it works
HOST is compiled with aCLANG because qCLANG does not understand x86
You can make performance and size comparisons by removing/commenting "USE_CLANG_QCOM := true"
I could have made the installation easier by uploading the toolchain to Github but I do not know if I am allowed to. And I am no lawyer so...
TODO:
-Make more performance comparisons to aCLANG and GCC.
-Compile Android with qCLANG wherever possible. http://www.linuxplumbersconf.org/20...ations/1131/original/LP2013-Android-clang.pdf and https://events.linuxfoundation.org/sites/events/files/slides/2014-ABS-LLVMLinux.pdf
Development Thread: http://forum.xda-developers.com/and...-compile-android-5-0-2-qualcomm-llvm-t3035162
Credits:
[email protected] for looking at the first commit
[email protected] people whom stuff i used
[email protected] where i learned alot
[email protected] for finding out that you need libllvm3.6 (obsolete)
XDA:DevDB Information
Compile Android with Qualcomm LLVM 3.7.1 for devices with Qualcomm CPU, Tool/Utility for all devices (see above for details)
Contributors
MusterMaxMueller
Version Information
Status: Testing
Created 2015-02-19
Last Updated 2015-11-22

reserved

another reserved

Let me be the first to say CONGRATULATIONS FOR THIS, u rock man =) lets try these things, and thank you for sharing!

I've disabled clang for art and bionic entirely, so it just compiles with GCC. I wonder which would be better, since compiling with GCC allows for more optimizations such as graphite.

frap129 said:
I've disabled clang for art and bionic entirely, so it just compiles with GCC. I wonder which would be better, since compiling with GCC allows for more optimizations such as graphite.
Click to expand...
Click to collapse
Yes, we have to measure and compare
I hope together we can get the manpower to verify/test what is better. That is why i started this thread.
According to linaro, graphite doesnt make that big difference. too lazy to search for the link right now.
I suck at c and the compiler stuff but in my understanding the LTO implementation of CLANG also sounds very interesting.
will update OP.

MusterMaxMueller said:
Yes, we have to measure and compare
I hope together we can get the manpower to verify/test what is better. That is why i started this thread.
According to linaro, graphite doesnt make that big difference. too lazy to search for the link right now.
I suck at c and the compiler stuff but in my understanding the LTO implementation of CLANG also sounds very interesting.
will update OP.
Click to expand...
Click to collapse
Well, Graphite does somewhat improve memory(RAM) use, and using the latest ISL and CLooG (as seen in sabermod) has only increased this. There are other options, for example Polly (The clang/LLVM equivalent of graphite) could be used for better optimization. And I didnt know that Clang implemented LTO differently, Ill look into that.

Interesting at least, will check it out...

fixing stuff
fixed some stuff and may have a solution for compiler-rt and libc++
if everything works well i will update in 3h.

MusterMaxMueller said:
fixed some stuff and may have a solution for compiler-rt and libc++
if everything works well i will update in 3h.
Click to expand...
Click to collapse
I haven't gotten around to trying the SnapDragon LLVM, but since Qualcomm didn't release their source code, I compiled my own LLVM using stock LLVM sources with AOSP patches and some extra features enabled such a polly and libffi. https://github.com/frap129/host-llvm_3.5-prebuilt.git There's the link if anyone wants to test.

Got around to implementing this into my builds, and it seems that Qcom LLVM has all the same problems as my LLVM that I compiled (host not working, compiler_rt problems).
EDIT: Also, testing Link Time Optimizations (LTO)

frap129 said:
Got around to implementing this into my builds, and it seems that Qcom LLVM has all the same problems as my LLVM that I compiled (host not working, compiler_rt problems).
EDIT: Also, testing Link Time Optimizations (LTO)
Click to expand...
Click to collapse
All fixed well except for HOST which wont work with qCLANG. look at my new commit. im sure will help you with your problems.
There were also some derps...
will update OP. already uploaded to github. took longer then i thought. my pc needs more ram.
also did some performance and stability testing. all seems good so far
will upload proof-of-concept rom with good performance. but building takes some time. need more ram
if you have llvmgold.so compiled would you mind sharing?

MusterMaxMueller said:
All fixed well except for HOST which wont work with qCLANG. look at my new commit. im sure will help you with your problems.
There were also some derps...
will update OP. already uploaded to github. took longer then i thought. my pc needs more ram.
also did some performance and stability testing. all seems good so far
will upload proof-of-concept rom with good performance. but building takes some time. need more ram
if you have llvmgold.so compiled would you mind sharing?
Click to expand...
Click to collapse
Nope, but I can compile it if you want. Also, for the LTO implementation, add the flag -lto as well, and make sure you add it to linker (LD ) flags

I have just compiled CM12 with QCOM llvm.. Build is booting and running fine, however the android progress circle indicator has some occasional animation issues that were not present before.
Might check the commit later.. Maybe an Ofast flag is the reason for this?

WhiteNeo said:
I have just compiled CM12 with QCOM llvm.. Build is booting and running fine, however the android progress circle indicator has some occasional animation issues that were not present before.
Might check the commit later.. Maybe an Ofast flag is the reason for this?
Click to expand...
Click to collapse
Thanks for trying and reporting back.
I have the same issues with animation circle. I think it might be fvectorize-loops but could be Ofast and i have no idea which module is causing this. Maybe libpng.
in the past i had the same problem with one of archidroids optimizations but cant remember which one it was
still having performance issues with art if compiled with qCLANG. made some changes and will test tonight or tomorrow.

frap129 said:
Nope, but I can compile it if you want. Also, for the LTO implementation, add the flag -lto as well, and make sure you add it to linker (LD ) flags
Click to expand...
Click to collapse
thx,
if you wouldnt mind compiling i would appreciate. i hope its compatible.

MusterMaxMueller said:
thx,
if you wouldnt mind compiling i would appreciate. i hope its compatible.
Click to expand...
Click to collapse
Im getting some random errors with GCC when im building LLVM now for some reason. I'll resync the source and try again later

MusterMaxMueller said:
Thanks for trying and reporting back.
I have the same issues with animation circle. I think it might be fvectorize-loops but could be Ofast and i have no idea which module is causing this. Maybe libpng.
in the past i had the same problem with one of archidroids optimizations but cant remember which one it was
still having performance issues with art if compiled with qCLANG. made some changes and will test tonight or tomorrow.
Click to expand...
Click to collapse
Got the animation issue fixed by removing all math related flags like -ffast-math and -funsafe-math-optimizations..
Also, I've replaced all -Ofast flags with -O3 (because Ofast includes the ffast-math flag, which is the issue here)
Will check later which flags may be reapplied without causing the issue again.
The build has been running smooth and stable for more than 24 hours. However, I can't report an extremely big difference in ui responsiveness. But the rom zip size has increased by 2mb, so the changes have indeed been applied. :good:

WhiteNeo said:
Got the animation issue fixed by removing all math related flags like -ffast-math and -funsafe-math-optimizations..
Also, I've replaced all -Ofast flags with -O3 (because Ofast includes the ffast-math flag, which is the issue here)
Will check later which flags may be reapplied without causing the issue again.
The build has been running smooth and stable for more than 24 hours. However, I can't report an extremely big difference in ui responsiveness. But the rom zip size has increased by 2mb, so the changes have indeed been applied. :good:
Click to expand...
Click to collapse
thanks for testing!
could you maybe test which module is causing the problems? so we can only disable fast_math where its needed. i guess it might be libpng?
regarding perfomance:
did you use my second commit? this should have some minor improvements in some cases. but actually decrease in some others... i need to look up how to make better and automated benchmarking. the way i do it at the moment is to time consuming.
anyone knows something i could use for automated benchmarking? for example just a zip i could copy/flash and then run via terminal? dont want to have to write my own
or something else, any suggestions?
i made some changes and am now compiling with the qcom libs which comes with the toolchain and finally got the special optimized copy function working. see "-arm-opt-memcpy" in the doc.
i hope this will give some performance improvements. wish some luck
at first it gave some problem because everytime i use the qcom libs i have to make sure libgcc isnt used.
i try to think about a cleaner solution because at the moment the way i do it is a dirty hack
then i will upload to github

MusterMaxMueller said:
thanks for testing!
could you maybe test which module is causing the problems? so we can only disable fast_math where its needed. i guess it might be libpng?
regarding perfomance:
did you use my second commit? this should have some minor improvements in some cases. but actually decrease in some others... i need to look up how to make better and automated benchmarking. the way i do it at the moment is to time consuming.
anyone knows something i could use for automated benchmarking? for example just a zip i could copy/flash and then run via terminal? dont want to have to write my own
or something else, any suggestions?
i made some changes and am now compiling with the qcom libs which comes with the toolchain and finally got the special optimized copy function working. see "http://forum.xda-developers.com/showthread.php?t=3038250" in the doc.
i hope this will give some performance improvements. wish some luck
at first it gave some problem because everytime i use the qcom libs i have to make sure libgcc isnt used.
i try to think about a cleaner solution because at the moment the way i do it is a dirty hack
then i will upload to github
Click to expand...
Click to collapse
I used the two commits in OP.
libpng can't be the reason for this, as many Lollipop drawables, including the animation were talking about, are actually vector drawables, not png ones.
So the module that these vector drawables refer to returns broken numbers that make the animation look weird.
I think the safest way would be to skip ffast-math and Ofast completely, because the animation might just be THE ONE bug we actually see and notice. I don't want to imagine what else might happen in certain background processes, including the risk of broken data and random bugs.
By the way, looking forward to testing the qcom libs, along with lto.
How to add lto to the build?

arter97 Pie Software Collection for the Mi Pad 4

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
arter97 Pie Software Collection for the Mi Pad 4​
/* Summary */
Stock software stack on this Mi Pad 4 is horrendous and full of retarded junks top to bottom.
This is a project to replace most of the software stack on the Mi Pad 4.
This is done by reworking the entire kernel and the vendor image, and providing a custom TWRP recovery with f2fs support.
Please read the entire post to get an idea how to use as this ain’t like other ROMs/kernels on this forum.
(Please don’t quote this entire post and spam the thread.)
/* System */
You may use Android Pie-based GSI images. Oreo is not supported. MIUI is obviously not supported. (Are you f***ing serious?) Compatibilities between other source-built ROMs targeting clover(Mi Pad 4) specifically is not guaranteed and most likely to cause issues.
You can also use Paranoid Android for Mi Pad 4, which is recommended for best performance.
/* Kernel */
The kernel is fully rebased to the latest Pie CAF tag, which is a different base from the stock Oreo CAF tag, not to mention most of Xiaomi’s ultra-poor-quality codes are gone.
- To mitigate the horrendous touch latency, numerous touch panel optimizations were made.
- Mi Pad 4 is using eMMC instead of UFS. Numerous changes were made to improve its performance including the enforcement of f2fs filesystem and optimizations to CFQ I/O scheduler.
- 3/4 GB of RAM is quite insufficient these days. zram is activated with updated LZ4 compression algorithm to provide a better memory management along side revamped lowmemorykiller.
- Touch boost is set aggressively due to the reality of most ROMs lacking QPerformance. This improves responsiveness.
- Kernel module support is disabled to make it a bit lighter.
- WireGuard is supported.
- Automatically sets correct Android version and security level to prevent booting issues caused by keymaster.
- Double-tap-to-wake is enabled by default.
- A whole lot more that I forgot.
/* Vendor */
For the best compatibility with Pie ROMs, Pie vendor must be used. To make this happen, the entire vendor firmware is ported from the Mi A2. This process took me weeks to debug and make it stable to this point.
Since this is the only one of its kind on the Mi Pad 4, the software experience with this vendor image will be quite different from other ROMs.
Also, an overlay is integrated to give the correct corner overlay for rounded corners.
Unfortunately, it’s not bug-free, but way beyond usable. Bugs will be listed below.
/* Recovery */
As I said, f2fs is enforced. Reason for this will be explained below.
You must format your userdata partition(erasing everything on the device) to f2fs before using this project.
You cannot use existing TWRP for 2 reasons:
a) The TWRP kernel won’t support f2fs.
b) TWRP’s mkfs.f2fs tool is outdated.
A custom TWRP is also provided, powered by my kernel and the latest mkfs.f2fs tool. You must use it to format /data to f2fs before using this project.
/* Harmony */
The whole kernel and the vendor image is meant to be used together. If you mix one another(e.g. using my kernel on other vendor image or vice versa), you will definitely encounter issues. Please don’t.
To make the experience consistent and since you’re locked with the kernel/vendor combination anyways, I decided to force f2fs. Please be extremely cautious when you want to test out other kernels that claims to support f2fs. If the f2fs version isn’t inline with my kernel, you may experience random panics, or even worse - data corruption.
It’s extremely recommended for you to wipe the entire /data back to ext4 if you want to switch from using this project.
/* Instructions */
You must be familiar with fastboot.
- Download kernel, vendor and TWRP from the link below.
*.img.xz is for fastboot. Extract the .xz files before feeding it to fastboot. *.zip is for TWRP.
- Download an Android Pie based GSI of your choosing.
- Flash kernel by ‘fastboot flash boot /path/to/kernel/image’.
- Flash TWRP by ‘fastboot flash recovery /path/to/recovery/image’.
- Flash vendor by ‘fastboot flash vendor /path/to/vendor/image’. This process will take about 5 minutes(it took 275 seconds for me).
- Enter TWRP by ‘fastboot boot /path/to/recovery/image’.
- Do ‘Wipe > Format Data’. This will automatically wipe to f2fs.
- Follow the instructions you got from the GSI ROM developer and flash system image.
- Reboot.
- Leave feedback.
Note about Magisk
Due to a (supposed) Magisk bug with f2fs. You must flash Magisk after the first initial setup to avoid memory leaks(which ultimately causes the kernel to shutdown). After Magisk is installed, reboot again after confirming Magisk Manager is installed.
/* Disclaimer */
Your warranty is now void.
I am not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed. Please do some research if you have any concerns about features included in this project before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you. Hard. A lot.
/* Warning */
I won’t be granting permissions to redistribute or extract files from this project to serve others, without actually contributing something to this project.
You will be reported to XDA forum moderators.
Making mirrors, re-uploading to another servers are also prohibited with no exceptions.
/* Thanks to */
TheCrazyLex
xboxfanj
joshuous
jjajjaroni - for reporting bugs ahead of public release
nathanchance - for android-linux-stable
/* Downloads and links */
arter97.com
Kernel source
XDA:DevDB Information
arter97 Pie Software Collection for the Mi Pad 4, ROM for the Xiaomi Mi Pad 4
Contributors
arter97
ROM OS Version: 9.x Pie
Version Information
Status: Beta
Created 2019-01-13
Last Updated 2019-03-07

/* Bugs */
- Phone calls won't work
- Fingerprint sensor and GPS on the Mi Pad 4 Plus doesn't work
- For the Wi-Fi variant, the device may get confused and think it’s a phone. Not a big deal.
- Didn’t notice anything else.

/* Changelog */
20190810
This update is made with Paranoid Android in mind.
Go checkout the updated Paranoid Android thread.
Vendor image:
Base firmware updated from V10.0.8.0.PDIMIXM to V10.0.10.0.PDIMIXM
Camera hacks removed and reworked to fix camera on many ROMs
Kernel:
Fixed a commit mismerge that broke deep-sleep
Linux v4.4.188 merged
Wi-Fi drivers updated to 5.1.1.73Q
Bunch of memory allocations from various subsystems were reworked to perform much better (thanks to Sultan)
32-bit vDSO added for improving performance on arm32 programs
Backported speculative page fault to improve system performance
Latest f2fs-stable merged
Switched to zswap/vnswap approach
- Ditched conventional zram swap approach and taken zswap+vnswap for more efficient memory operations
- Backported zsmalloc memory allocator from mainline
- Backported zswap compressed page cache from mainline
- Samsung's Galaxy S9 memory modifications merged for better swapping efficiency tuned for Android
- This new kernel's memory management will be drastically different from existing kernels
20190428
Vendor image:
Base firmware updated from V10.0.1.0.PDIMIFJ to V10.0.8.0.PDIMIXM
Added missing goodix touch firmware
General LTE network stability improvements
Kernel:
Various changes from Proton kernel by kdrag0n
- Use flatmem to save kernel memory usage
- Use optimized memcmp
- Optimize rbtree
- Disable erratum 843419 properly
- Delay vmstat updating interval to avoid jitter
- Disable I/O stat accounting completely for lower overheads
- Reverted a cpuidle change for possible fix for power consumption regression during sleep
- Faster crypto algorithms ported(chacha20, sha2, crc32)
A bit lower power consumption by using WFE for long delays
Add accelerated crc32 routines
Use -O3 for input drivers for avoiding overheads
Various changes made to f2fs rapid GC to make it more efficient
dirty_expire_centisecs set to 30 seconds to reduce flash wearouts and power consumption
Various changes merged from the Razer Phone 2 and Snapdragon 855
Kernel is now built with -O3 optimization flag
Use CONFIG_HZ = 300
- This changes context switching interval from 10ms to 3.33ms
- Pixel used this for years and Google recommends other vendors to do the same for fewer jitters
Removed RTB(interrupt) logging entirely
Wi-Fi drivers updated to 5.1.1.71C
Linux v4.4.179 merged
ExFAT support added(ROM-side support required too)
Idle power consumption improved
Camera drivers stability improved
LA.UM.7.2.r1-06700-sdm660.0 merged
LV.HB.1.1.5-10310-8x96.0 merged
LA.HB.1.1.8-03910-8x96.0 merged
20190223
Fixed an issue causing kernel panics to enter dump mode
Fixed a f2fs merge durp causing issues from the recovery and potentially long-term performance on daily usage
RWSEM priority-aware enhancement merged from CAF
Added CIFS(SMB) support (requested by @currowth)
LA.HB.1.1.5-11310-8x96.0 merged (some minor bug fixes)
20190221
Paranoid Android breakage from 20190128 fixed
A totally new kernel base merged - LV.HB.1.1.5-10010-8x96.0
- Total of 471 commits and about 20,000 lines of code difference
- A lot has changed ranging from scheduler, memory management, GPU and panel handling, MMC device driver, ION, audio subsystem, cpuidle, binder and a whole lot more
Kernel configuration fixed for proper scheduler operation
Background Wi-Fi HAL scanning issue fixed
LA.UM.7.2.r1-05900-sdm660.0 merged
Linux v4.4.175 merged
Mainline f2fs fixes merged
WireGuard updated to 20190123
seccomp disabled in favor of less system-call overheads
Minor issue with f2fs rapid GC fixed
IRQ balancer settings updated to include MMC and USB interrupts for better overall smoothness
20190128
Bunch of stuffs missed from previous port were applied
Fixed video recording
Booting issues fixed for ROMs with 2019 security patch level
MTP fixed
Wi-Fi drivers' inconsistencies fixed
Merged Linux 4.4.172
Enabled ULPS for lower power consumption
Merged several changes from Sultan's kernel
- GPU performance improved with corrected priority
- Faster display wake-up
- Lower power consumption
20190123
Fixed an error causing Wi-Fi to not function for some users
Merged Linux 4.4.171
Disabled MMC SPI CRC for better eMMC performance
Removed brightness remapper to fix adaptive brightness
Compiler updated to GCC 2019.01
20190114
Initial release

/* Fundraiser */
After consulting with 2 forum moderators, I got a clarification that fundraiser is acceptable with some terms like transparency and a rough timeline.
A fundraiser is opened for me to purchase a Mi Pad 4 Plus LTE. This particular variant was chosen since it's extremely likely for me to make Mi Pad 4 non-Plus LTE and Mi Pad 4 Plus Wi-Fi model supported during the process.
Within a month after the goal is met and the device is shipped, I'll work to make the current kernel and vendor image working on the Mi Pad 4 Plus LTE. After this is done, I anticipate other variants to be supported as well. In the unlikely event that it ends up otherwise, I'll work on some members on the community to get logs and test. It'll be way easier then since both LTE and fingerprint sensor will be working on my project.
While I will try my best to keep up with my goal, do note that it is entirely possible that it could not be done(which is extremely unlikely). You're making a donation after all. Just note that donation doesn't give you rights to force me to do anything with the received device.
The price for the lowest end Mi Pad 4 Plus LTE seems to be around $295 with a seller that would actually use DHL for shipment, which is required as the standard Ali-Express shipping usually takes 20~30 days.
There's another 10% importing tax in Korea on top of $295 which would make the total around $330. I've opened a fundraiser for $350 to avoid possible headaches like PayPal and bank's fee for withdrawing the money back to my credit card.
With that said, here's a fundraiser's link.
You can see the progress of the fundraiser as well.
https://fundrazr.com/81RpR8

Reserved
Reserved 4

This device took an enormous amount of my time that it clearly didn't deserve.

Thanks!
To my knowledge Mipad4 will someday get MIUI Pie. Does that effect the vendor then or are you already decided sticking with ported one?

stunned said:
Thanks!
To my knowledge Mipad4 will someday get MIUI Pie. Does that effect the vendor then or are you already decided sticking with ported one?
Click to expand...
Click to collapse
I'm certain that general experience will be still better with mine even after Mi Pad 4 gets official Pie release.
It'll allow me to fix some bugs though.

Thanks arter. That is why I made a small donation to u knowing that u were working on clover.
Hope more people do the same to keep the motivation alive!
P.S. very nice thread title ?

@arter97 few bugs i found
1)wifi seems to be broken, it's turning off by itself and can't find any networks. (broken on both PA & pixelexp GSI)
2)file transfer broken, only charging is permitted, it keeps going back to charging only (able to test only on PA, on Pixel experience GSI, cant get pass the WIFI set up)

arter97 said:
And since the vendor image is rebased, this means anything other than what I’ve used is not supported.
Mi Pad 4 LTE, Mi Pad 4 Plus, Mi Pad 4 Plus LTE model is not supported. Only Mi Pad 4 Wi-Fi model is supported.
Click to expand...
Click to collapse
Hope you will have time and possibility to support mi pad 4 plus version in near future nice done.

Thank you for you work with this (weird) device!
- Performance seems to be so so good, at least for now, the touch latency also seems to be better.
- Wifi is stable for now (It didn't work on the first boot, but I rebooted and it worked).
- File transfer works randomly for me (I'm trying to get logs and dmesg right now).
And just a little of OT: What do you think about zstd? I was using that algorithm with a flash kernel in Taimen and, in my humble opinion, it works very well, maybe it's a placebo, but I think multitasking was a little better.
PS: best post name evear, lol.

onliner said:
Thank you for you work with this (weird) device!
- Performance seems to be so so good, at least for now, the touch latency also seems to be better.
- Wifi is stable for now (It didn't work on the first boot, but I rebooted and it worked).
- File transfer works randomly for me (I'm trying to get logs and dmesg right now).
And just a little of OT: What do you think about zstd? I was using that algorithm with a flash kernel in Taimen and, in my humble opinion, it works very well, maybe it's a placebo, but I think multitasking was a little better.
PS: best post name evear, lol.
Click to expand...
Click to collapse
I am stucked.

onliner said:
Thank you for you work with this (weird) device!
- Performance seems to be so so good, at least for now, the touch latency also seems to be better.
- Wifi is stable for now (It didn't work on the first boot, but I rebooted and it worked).
- File transfer works randomly for me (I'm trying to get logs and dmesg right now).
And just a little of OT: What do you think about zstd? I was using that algorithm with a flash kernel in Taimen and, in my humble opinion, it works very well, maybe it's a placebo, but I think multitasking was a little better.
PS: best post name evear, lol.
Click to expand...
Click to collapse
zstd is ratio oriented algorithm. lz4 is speed and latency oriented algorithm.
Unless you're really starving on memory like Samsung, using zstd for swap is a really bad idea.

For those having Wi-Fi issues, I need an actual logs to debug the issue.
I have 2 devices on my hand and neither of them have an issue with Wi-Fi, alongside 5 other testers.

arter97 said:
For those having Wi-Fi issues, I need an actual logs to debug the issue.
I have 2 devices on my hand and neither of them have an issue with Wi-Fi, alongside 5 other testers.
Click to expand...
Click to collapse
there you go arter, if you need other specific logs let me know

xzr3b0rnzx said:
there you go arter, if you need other specific logs let me know
Click to expand...
Click to collapse
mac adress is read from wrong path and thats why it fails

Thanks very much for this brilliant project
Waiting for mi pad 4 lte

rcstar6696 said:
mac adress is read from wrong path and thats why it fails
Click to expand...
Click to collapse
i didnt alter anything, what should i do to solve this?

@arter97 you're a legend bro, great job. One thing I noticed is that adaptive brightness fails in pitch dark room. The screen stays completely dark. Other than that everything else works great.