My laptop has been acting strange for the past week or so. It was having trouble starting up and during builds it would suddenly stop and then when I would go to investigate why it failed, I'd get random "Segmentation faults" using simple things like "ls". When I looked at the logs it show disk errors at the "ATA" level. Yesterday was the "straw" that broke the camels back when my laptop refused to boot.
Luckily, I had a thumb drive with an installable version of UbuntuMate 14.04. I formatted everything and installed it. It seems to be OK but I lost everything. It's not really that big of deal though cause everything I need can be found on the web. I just hope my laptop remains stable...
It's going to take me awhile to get up and running with builds. Got to set up the build environment again and sync CM again. Lot's to do...
I just hope the it's not a hardware issue.
I have a build for the Huawei P9 lite on the device that I built an tested before the issues started and I'll try to get it uploaded soon...
Tuesday, October 11, 2016
I decided it was time to rebuild everything and workout any issues with the build system and as it turns out there weren't any issues so... awesome. I also made several changes to help out battery life/performance.
|My Huawei P9 Lite with a Samsung style theme...|
- Got the 2nd set of cores (4 - 7) scaling; before it was pegged out over 2ghz.
- Set the minimum frequency of the gpu so it can scale. Before, I had manually set it at max for testing...
- Set the minimum frequency of the ram (ddr) so it can scale.
- Set the default ddr scaling frequency to "mali_ondemand". This takes care of most of the "tearing" on the screen.
NOTE: If you have any experience with "governors" and frequencies and want to experiment you can adjust frequencies for the ddr and gpu here:
and the cpu here:
I also decided to go through framework/res overlay and add anything that might be useful for this device.
- Enabled adaptive brightness
- Enabled all tethering
- Wifi hotspot
- Disabled hardware button configs
I had a chance to test the sensors and it seems that the lux,prox,acc and orientation sensors are all functioning while the gryo,airpressure and thermal sensor are not working. However the thermal-daemon is up and running and it is reporting temperatures. I'm planning to write a standard sensors lib for all the sensors but I checked on the gyro sensor and even when turned on, it's not reporting data. In fact it hangs while trying to get_data. So, I'll need to hunt it down in the kernel and see what's stalling it out.
Also, although I have not tested it. The issue with wifi not saving passwords is most likely fixed in this build. If it is not please let me know.
I have looked at the "deep sleep" issue closely. It seems that during the resume process "local_enable_irq" hangs starting here:
I've tried to re-arrange the resume process to bypass the hang but to no avail. When I first started this project, I wanted to download the kernel directly from the Huawei but all the links I tried failed so I used a repo that someone had already modified. The next thing I'll try is to revert those changes and see if it helps.
Download on the download page as always...
Thursday, October 6, 2016
A few days ago when I first got the modem online I was thrilled. If you been keeping up with my blog then you know how difficult it's been. That feeling quickly wore off when I realize that the RIL was unstable. It seemed to be fine for a few minutes after boot but then the signal would become irratic and then making calls would be nearly impossible. Accessing data would also be a problem. I was reviewing the ril log when I noticed that the second modem was online and it was detecting signal strength? I don't have a second sim in there so why would it be doing anything at all. I started to think that I needed to find a why to turn off the second modem. I looked all over the place. Hisi's RIL class does have a method for setting the active modem but it's not implemented in our RIL class. So, I was considering implementing but then last night I decided to compare and contrast the different prop values per device, in the phone.prop from stock. That's when I found it.
This property completely stablized the RIL for me. Now, keep in mind that I only have one sim. For dual sim situations you may need to remove this from the build.prop or change it to something like persist.radio.multisim.config=dual . I suspect that it will, by default enable both modems by default by just removing the property...
Also some of the sensors have been fix thanks to surdu_petru@xda. I have not tested them all but the accellerometer/orientation sensor and the proximity sensor are working.
The installation instructions have changed please read them carefully!
Download on the download page.. ;)
Tuesday, October 4, 2016
I was reviewing the out put from dmesg on stock when I saw "do_modem check" from init. This was nothing new, I had seen this before in the init scripts. Since it's not an external binary found in bin, xbin or sbin I figure this is an internal function that Huawei programmed in to init. Then I noticed something that I had not noticed before. After the "do_check_modem" dmesg said something like "do_check_modem success. Wake up modem". Then some process, "modem_sysboot_start" starts talking about /nvm:20/modem_nv/Nv.bin. So, I figure that init is loading some firmware into kernel space to start the modem. It seems that there must be a path that could be used to load this firmware. So I dug around in the kernel for a while and I finally found it. It was the simplest solution. All I had to do was write 1 to /sys/devices/platform/his_modem/modem_sysboot_start . Then the kernel driver uploaded it's firmware from default paths and kicked up the modem. Why Huawei built this into init instead of using a simple line in the init scripts, I do not know.
I've got some tweaking to do on the time of the initialization of the modem and the start of rild. Sometimes rild starts without it's prop entries and has to be restarted... I will probably be releasing an update soon..
Oh, and thanks to XePeleato, I ended up using his RIL class and it does work!
Sunday, October 2, 2016
I'm a big fan of "The Matrix" movies and so I feel as If I have taken the red pill. It's been along time since I had to work with smali code but I figured that the best way to get the RIL code was to reverse engineer (RE) it out of telephony-common.jar . I found a file "RIL.java" which is the common ril found in that project, and , once I converted the smali code to java, I noticed ( what seemed to be ) significant differences. So, I thought the challenge would be to rework this code into code that would work with CM but, in navigating around my RE code, I saw alot of abstract classes and custom classes proceeded with the prefix 'hw'. So, I started to suspect that just reworking this RIL class was not going to do it. There was much more involved here.
"You've been living in a dream world Neo" -Morpheus
The file "hwTelephony-common.jar contains the actual RIL class (HwHisiRIL.java) that just inherits from RIL.java in "telephony-common.jar and they have modified the RIL.java class to implement an abstract class which allows them to call functions in HwRILReferenceImpl.jar. This is just the beginning, these classes depend on the entire "Hw" framework; that is to say all of the jars in "/system/framework". Despite the challenges, I thought that perhaps I could get the framework working in CM. So, I spend a couple of days trying to get it running only to realize that it would never work. Then I thought that I could synthesize a working RIL Class by substituting fake info in situations where these 3 classes reached out beyond them selves. So I spent a few days doing that and again I am foiled.
"I bet your feeling a bit like Alice tumbling down the rabbit hole..." -Morpheus
So for the past week or so I've attempted several approaches to getting the RIL working but have made ZERO progress. Now, it starting to make me miserable so, I've got to climb out of the rabbit hole for awhile. Have a little time to absorb what I've learned and let my mind work on the question marks. In the mean time, I'll be trying to work on other things...