My phone is the BLU Life One, Android 4.4.4. Kernel 3.10.28. Build KTU84P. Custom build version BLU_XO11Q_V04_GENERIC 14-08-2015 12:15. Model Number BLU LIFE ONE. Processor info. Qualcomm Technologies, Inc MSM8916
EDIT:
Forget & ignore all mentions of my script(s) to keep the microsd from umounting. Whatever is causing this problem is stopped if the microsd is remounted as read-only.
If you adb shell into your phone then type "mount" you should see all mounts related to your microsd card. For my phone, that is sdcard1.
Code:
/dev/fuse /storage/sdcard1 fuse ro,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
/dev/block/vold/179:65 /mnt/media_rw/sdcard1 vfat ro,dirsync,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
You'll need root, then do:
Code:
mount -o ro,remount /mnt/media_rw/sdcard1
mount -o ro,remount /storage/sdcard1
That's it. Since 99% of the time I'm just listening to music not actively needing write-access to the microsd, this works perfect for me. I use this app: play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en to manage 2 scripts. One to mount it as read-only like the commands above, and another to mount it read-write again(just change "ro" to "rw"). If you want, you can jump to update#23 for the kernel source of this phone http://forum.xda-developers.com/showpost.php?p=64906734&postcount=8 and continue reading to follow my adventures of trying to update the kernel.
Code:
echo -------------------------
id
echo -------------------------
cd /storage/sdcard1
while true; do
ls -la . > ./ls_la.log 2>&1
sleep 1
ls -la . >> ./ls_la.log 2>&1
sleep 1
rm ./ls_la.log
sleep 10
done
First, note that the "/storage/sdcard1" is where my phone mounts the microSD to. Your phone might be different, be sure to change it to wherever your phone mounts the microSD to. That last adb shell command to run the script will hang because it's an infinite loop. You'll just have to yank out the usb-cord of your phone to break the connection. On my phone, the script continues to run. I know this because using a file-manager on the phone I can constantly refresh the file list on my microSD and see the logfile appear and disappear in 10-second intervals.
So with all this I start the music in my musicplaying app(poweramp in my case), press the power button to turn off my screen.... press the power button again to turn on the screen and see the lockscreen.... then leave my phone alone. Within 10 seconds, the screen goes off by itself if I don't enter a pin... and the music will play without any glitches or interruptions.
CONS
If my phone ever reboots, I need to go back to a PC with "adb" so I can rerun the command. This app: play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en ....can run the script but the user the script is started with doesn't have write-permissions to the microSD card for whatever reason. I have this problem because my phone is NOT rooted. I rooted it once before, but then used SuperSu's option to "unroot" and since then haven't been able to root again. If you have root, I'm sure a command like "su -c '/data/local/tmp/crazy_sdcard_wakelock.sh'" would start the script as root and it'll be able to write to the microSD. ......I rarely reboot my phone, so this isn't a big issue for me.
How did I come up with this?
Random googling about this problem lead me to a bunch of people talking about it on different devices with different symptoms: code.google.com/p/android/issues/detail?id=22763 , but more or less the same core issue. When the screen is off for awhile(for me it's 30mins), the microSD is unmounted apparently by faulty power-management in Android's OS or Manufacturer's hardware or whatever and if you're like me with tons of music on the microSD... your musicplayer(PowerAmp or whatever), stops working. So I started thinking about all the ways to prevent the microSD card from unmounting. On my home PC, running Linux mint, a mounted USB device cannot be unmounted if there's a bash process that is using it; i.e. if I open a terminal and "cd" to a directory on the usb-drive, I cannot unmount it until I exit that bash shell. That's why in the above script I do the cd command to the microSD card hoping for the same effect on Android. Then you see the infinite loop of "while true", where I repeatedly do:
I run "ls -la" to print out all details of files & folders at the root-level of the microSD card and save the output to a logfile.
I pause for 1 second.
I run "ls -la" command again, and append the already existing file so now the list is in that file twice.
I pause again for 1 second.
I delete the file
Pause for 10 seconds... then do it all again, and again, and again...
With a shell process having the microSD as its CWD and the constant opening, writing, deleting of a file every 10 seconds, along with the PowerManagerWakelock app and the periodically CPU usage reporting.... I've been doing this for a full day and the music never stops, no sdcard unmounting. This is the microSD I'm using: amazon.com/SanDisk-Mobile-MicroSDXC-Memory-Adapter/dp/B0081EAK34
I haven't done any testing to try and narrow stuff down to see if I truly need all 3 of these things to be running, but I don't care. It works for me and my battery life doesn't seem to be draining any faster than normal.
I'm posting this solution so maybe the hackers on this forum can understand exactly why my solution is working and maybe write an apk that'll do all this stuff by just tapping a button.
UPDATE:
Got root back by booting into TWRP(Installed before I removed root the first time) and flashing a SuperSU.zip to the device. Disabled the "Show CPU usage" and the solution still works. Using the PowerManagerWakeLock app by itself does _NOT_ work. So right now it's WakeLock+Script that seems to be working. Who knows, maybe the script will work all by itself. But I haven't tried it yet. Now if I reboot my phone, I can use the script-manager app mentioned above to run the script as root and it does keep the microSD mounted and everything works. I also added the "date" command to my script so in case it stops working, the scriptManager's console will show me the last time it worked before problems occurred. But, so far so good no problems and my buyer's regret on this phone is long gone. I hope other people see this post because I see a lot of people complaining about similar problems with other Android phones.
If this works for you, please reply and say so!
UPDATE#2
Just spent the whole day listening to uninterrupted music using only the script. So there you go! I was trying to find a way to do this without root using the ScriptManager app, I tried copying the /system/bin/sh file to /data/local/tmp and setting the sticky bit on it; but sticky bit logic doesn't seem to work for me on Android. So if you don't have root, you have to launch the script via "adb shell" command on a PC and don't reboot or do anything that stops the script.
UPDATE#3
So it appears that both Poweramp playing music and the script are required. If I stop playing music the script starts getting I/O Errors and "Transport endpoint is not connected" errors after like 4 hours or so. Kinda lame. And when this happens I have to reboot the phone to get the sdcard back. I suppose this means, be careful if you set the phone's camera to write to the microSD. You might find out later that photos and videos you thought you were capturing didn't actually get saved to the microSD. Should probably have camera save to internal memory then later on copy to microSD using the filemanager and verify that the copy actually worked before deleting from internal memory.
UPDATE#4
In an attempt to keep the sdcard mounted even if there's no music playing, I decided to add the "du" command thinking that command needs to do a lot to the sdcard to get its info. The result? After 3 to 4 hours, the card still went offline and all of its content erased! Luckily, I made a backup because I knew I was dealing with sdcard problems on this phone. So, what I think needs to happen now is to write a script that can somehow detect if the phone is idle for about 2 hours. Idle in this context means, screen off for 2 hours and no music playing... to automatically unmount the sdcard safely instead of whatever happened that causes me to lose everything. Or maybe after detecting idle-state, unmount & remount the sdcard to wake up whatever hardware/software components went to sleep. If that works, then perhaps just keep remounting the sdcard every 2 hours the phone is in an idle state. But so far, my original solution works in that as long as you're listening to music & running the script above there will be no interruptions for at least 8 hours straight.
UPDATE#5
Well, I can now reproduce 100% the sdcard umounting. If I set my phone's display to go off in 2mins of idle time, and immediately lock with pin. Then start Poweramp and listen to tunes, once the screen goes out the music will stop in less than 20 seconds and the sdcard is gone. If I run that script above, then the music continues and the sdcard is still there... so definitely that script is doing something. I see nothing suspicious running logcat while all this is happening other than the normal calls to PowerManager:
D/DisplayPowerController( 839): requestPowerState: screenState=0, useProximitySensor=false, screenBrightness=102, screenAutoBrightnessAdjustment=0.0, useAutoBrightness=true, blockScreenOn=false, waitForNegativeProximity=false
D/PowerManagerService( 839): updateScreenStateLocked: mDisplayReady=true, newScreenState=0, mWakefulness=0, mWakeLockSummary=0x1, mUserActivitySummary=0x0, mBootCompleted=true
D/PowerManagerService( 839): updateIsPoweredLocked: wasPowered=true, mIsPowered=true, oldPlugType=2, mPlugType=2, mBatteryLevel=100
Click to expand...
Click to collapse
I'm learning a lot of stuff about Android and sdcards in this phone. Informative commands, like:
dumpsys mount & dumpsys power, Also interesting processes:
[email protected]_LIFE_ONE:/ # ps |grep sdcard
media_rw 255 1 4144 1160 ffffffff b6f404ac S /system/bin/sdcard
media_rw 258 1 3528 432 ffffffff b6f7b4ac S /system/bin/sdcard
media_rw 260 1 3528 432 ffffffff b6f6d4ac S /system/bin/sdcard
media_rw 8948 1 4208 1204 ffffffff b6f5e4ac S /system/bin/sdcard
[email protected]_LIFE_ONE:/ # print `cat -v /proc/255/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-l^@/data/media^@/mnt/shell/emulated^@
[email protected]_LIFE_ONE:/ # print `cat -v /proc/258/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-w^@1023^@-d^@/mnt/media_rw/uicc0^@/storage/uicc0^@
[email protected]_LIFE_ONE:/ # print `cat -v /proc/260/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-w^@1023^@-d^@/mnt/media_rw/usbotg^@/storage/usbotg^@
[email protected]_LIFE_ONE:/ # print `cat -v /proc/8948/cmdline`
/system/bin/sdcard^@-u^@1023^@-g^@1023^@-w^@1023^@-d^@/mnt/media_rw/sdcard1^@/storage/sdcard1^@
[email protected]_LIFE_ONE:/ #
Click to expand...
Click to collapse
Still looking around to see if I can figure out why it unmounts, or prevent it from unmount, or immediately remount it as soon as it disappears. I've noticed that when the glitchy-unmount happens, the status in "dumpsys mount" does not update. It still shows /storage/sdcard1 as mounted.
UPDATE#6
Okay, getting closer to narrowing it down. Definitely the music stops and sdcard problems when I tamper with the process related to the sdcard. From the example above, PID 8948, /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1. If I send that process a kill -9, the process immediately respawns with a new PID but within the next 20secs the music will skip. If I send a kill -STOP to that process, the music will halt completely and the sdcard access will be messed up within 20 seconds. I can return normal sdcard access by sending kill -CONT to the process. I've haven't verified it yet, but I bet something happens to that process when the sdcard unmounts suddenly and everyone is complaining about the problem. My 100% repro to make the sdcard unmount has stopped working so I can't quickly verify any changes in any attributes to files in /proc/$PID/. I've also just found this nice website with informative stuff: hxxp:\\source.android.com/devices/storage/config-example.html
UPDATE#7
So after a lot of research, I extracted the boot.img(/dev/block/bootdevice/by-name/boot) from this device, unpacked it, edited init.qcom.rc to start the sdcard service for the microSD using a different binary I named sdcard_studio6. I pull this file from my wife's BLU Studio6 phone. From just about any other android device I had around, the sdcard binary would complain about a missing symbol or something. I couldn't just replace the original sdcard binary, because doing that would mount the external microSD but won't mount the internal phone memory and logcat would be overflowing with fuse errors from sdcard. So I have to leave the original sdcard binary to work with all the other mounts, but only modify the service/deamon for the external storage. After rebooting the phone and running "ps|grep sdcard", sure enough I see the sdcard_studio6 binary handling the microSD. Interestingly enough, the custom_boot.img created by my editing was only 7 megs. Compared to the 32 meg one I got from doing dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot.backup.img That was worrying, but apparently it works fine.
NOTE: I feel it's important to point out that the command "fastboot" can be used in 2 ways for booting. "fastboot flash boot /path/on/your/PC/to/boot.img" or "flashboot boot /path/on/your/PC/to/boot.img". The first command actually writes the change into your phone's memory, the 2nd command just uses the file to boot up the phone temporarily and holding down the power button for a few seconds to force powerdown & reboot will cause the phone to go back and use the image that's in the phone's internal memory. One of the times I did this i forgot to give mkbootimg a bunch of important options like --cmdline, --base, --pagesize, --ramdisk_offset, etc. When I booted the phone with the image I created, the phone was stuck on the white BLU logo screen and neither fastboot nor adb could detect the phone. Had I flashed that image into the phone, instead of temporarily loading it, the phone would have continued to use the bad boot.img and without fastboot or adb, I think I would have had a nice $189.99 brick. Moral, don't flash a boot.img permanently until you've booted up in temporary mode and used the phone a bunch and you're sure everything works. At the minimum, be sure adb or fastboot can still see it so you have some hope if things screw up later.
Unfortunately, this didn't solve the unmounting problem. I've started checking dmesg and noticed that when the sdcard disappears, it's shortly after these messages:
<3>[ 1864.773535] mmc1: data txfr (0x00200000) error: -84 after 0 ms
<6>[ 1864.773559] sdhci: =========== REGISTER DUMP (mmc1)===========
<6>[ 1864.773568] sdhci: Sys addr: 0x00000100 | Version: 0x00002e02
<6>[ 1864.773577] sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000100
<6>[ 1864.773586] sdhci: Argument: 0x053deb54 | Trn mode: 0x0000003b
<6>[ 1864.773594] sdhci: Present: 0x03280206 | Host ctl: 0x00000017
<6>[ 1864.773603] sdhci: Power: 0x0000000d | Blk gap: 0x00000000
<6>[ 1864.773611] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
<6>[ 1864.773619] sdhci: Timeout: 0x0000000a | Int stat: 0x00000000
<6>[ 1864.773628] sdhci: Int enab: 0x03ff800b | Sig enab: 0x03ff800b
<6>[ 1864.773636] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
<6>[ 1864.773645] sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
<6>[ 1864.773653] sdhci: Cmd: 0x0000123a | Max curr: 0x00000000
<6>[ 1864.773662] sdhci: Resp 1: 0x4c363447 | Resp 0: 0x00000900
<6>[ 1864.773670] sdhci: Resp 3: 0x00000900 | Resp 2: 0x30dac0c1
<6>[ 1864.773677] sdhci: Host ctl2: 0x0000000b
<6>[ 1864.773686] sdhci: ADMA Err: 0x00000003 | ADMA Ptr: 0xadac0018
<6>[ 1864.773693] ----------- VENDOR REGISTER DUMP -----------
<6>[ 1864.773704] Data cnt: 0x0001fe00 | Fifo cnt: 0x0001f600 | Int sts: 0x000c0000
<6>[ 1864.773714] DLL cfg: 0x07e76400 | DLL sts: 0x000001e4 | SDCC ver: 0x1000002e
<6>[ 1864.773725] Vndr func: 0x00010a1e | Vndr adma err : addr0: 0x009dca00 addr1: 0x00000000
<6>[ 1864.773749] Test bus[0 to 3]: 0x0000c846 0x000020ce 0x00007018 0x01c002f2
<6>[ 1864.773760] Test bus[4 to 7]: 0x00473fd8 0x0005c038 0x40000000 0xf923ffcb
<6>[ 1864.773771] Test bus[8 to 11]: 0x47fc1604 0x40a00002 0x2e03e089 0x00000cc0
<6>[ 1864.773782] Test bus[12 to 15]: 0xe04f0408 0x842501a0 0x0d000040 0x00000a88
<6>[ 1864.773794] Test bus[16 to 19]: 0x00020002 0x0102808c 0x138f369e 0x00002895
<6>[ 1864.773804] mmc1: clk: 200000000 clk-gated: 0 claimer: mmcqd/1 pwr: 12
<6>[ 1864.773814] mmc1: rpmstatus[pltfm](runtime-suspend:usage_count:disable_depth)(0:0:0)
<6>[ 1864.773820] sdhci: ===========================================
<3>[ 1864.781982] mmcblk1: error -84 transferring data, sector 87944020, nr 256, cmd response 0x900, card status 0xb00
<3>[ 1865.997717] mmc1: mmc_blk_reset: failed to reset -110
<3>[ 1865.997747] end_request: I/O error, dev mmcblk1, sector 87944020
<3>[ 1865.997776] end_request: I/O error, dev mmcblk1, sector 87944028
<3>[ 1865.997801] end_request: I/O error, dev mmcblk1, sector 87944036
<3>[ 1865.997824] end_request: I/O error, dev mmcblk1, sector 87944044
<3>[ 1865.997848] end_request: I/O error, dev mmcblk1, sector 87944052
<3>[ 1865.997871] end_request: I/O error, dev mmcblk1, sector 87944060
<3>[ 1865.997894] end_request: I/O error, dev mmcblk1, sector 87944068
<3>[ 1865.997917] end_request: I/O error, dev mmcblk1, sector 87944076
<3>[ 1865.997941] end_request: I/O error, dev mmcblk1, sector 87944084
<3>[ 1865.997963] end_request: I/O error, dev mmcblk1, sector 87944092
<3>[ 1865.998491] mmc1: sdhci_cmd_irq: AUTO CMD err sts 0x00000002
<3>[ 1866.002930] mmcblk1: error -110 sending status command, retrying
<3>[ 1866.005329] mmcblk1: error -110 sending status command, retrying
<3>[ 1866.007776] mmcblk1: error -110 sending status command, aborting
<3>[ 1866.018346] mmc_sd_detect(mmc1): Unable to re-detect card (-123)
<6>[ 1866.018411] mmc1: card 0007 removed
<3>[ 1866.205666] FAT-fs (mmcblk1p1): Directory bread(block 1133940) failed
<3>[ 1866.205720] FAT-fs (mmcblk1p1): Directory bread(block 1133941) failed
<3>[ 1866.205770] FAT-fs (mmcblk1p1): Directory bread(block 1133942) failed
<3>[ 1866.205811] FAT-fs (mmcblk1p1): Directory bread(block 1133943) failed
<3>[ 1866.205849] FAT-fs (mmcblk1p1): Directory bread(block 1133944) failed
<3>[ 1866.205888] FAT-fs (mmcblk1p1): Directory bread(block 1133945) failed
<3>[ 1866.205932] FAT-fs (mmcblk1p1): Directory bread(block 1133946) failed
<3>[ 1866.205971] FAT-fs (mmcblk1p1): Directory bread(block 1133947) failed
Click to expand...
Click to collapse
I should also note this entire issue with the sdcard doesn't happen with my old 32GB card, only with the 2 brand new sandisk 64gig cards that I bought to test this out. It's difficult for me to believe that both of these 64gig sdcards are defective. And both didn't come from the same place. One from amazon.com the other from walking into a Target store in San Francisco and buying it. And both these cards work fine in other devices. Still working on some kind of solution.
UPDATE#8
I noticed that sdcard binary on my phone actually prints out usage:
Code:
[email protected]_LIFE_ONE:/ $ /system/bin/sdcard
no source path specified
usage: sdcard [OPTIONS] <source_path> <dest_path>
-u: specify UID to run as
-g: specify GID to run as
-w: specify GID required to write (default sdcard_rw, requires -d or -l)
-t: specify number of threads to use (default 2)
-d: derive file permissions based on path
-l: derive file permissions based on legacy internal layout
-s: split derived permissions for pics, av
So I tried editing my init.qcom.rc to start with more threads; like 14.... still the problem remains that a screen off will cause the music to stop eventually.
UPDATE#9
Sending kill -STOP to the vold process seems to be working!
After messing with the sdcard binary for awhile I saw this link: hxxp://android.stackexchange.com/questions/75277/vold-makes-my-sd-card-disappear , and started researching /system/bin/vold. I do actually remember seeing vold & MountService unmount the card in logcat at least once. I thought about disabling vold in the init scripts, but it appears it's super important and disabling it will just make everything fail. I tried killing the process but it will restart and I suspect it'll eventually be needed again. I did notice that if I have music playing and I adb shell, su, "/system/bin/vold root", my music player will stop and I have to hit the play button again. I have a theory now that there are actually 3 issues here happening all at the same time confusing people and 2 of them are sorta red herrings.
Theory 1) If you buy a no-name-brand sdcard you might have problems. Don't do that, try to get a good card like those class 4 or even class 10. Having a low quality microSD can send you down the path of madness. It's just a red herring; get a good card before reaching any conclusions that you phone has any problems.
Theory 2) I now suspect some microsd card reading errors are normal. e.g. <3>[ 1864.781982] mmcblk1: error -84 transferring data, sector 87944020, nr 256, cmd response 0x900, card status 0xb00
, is probably something that'll happen from time to time and the underlying filesystem drivers and/or AndroidOS normally recovers from them as long as it doesn't happen way too often. This is the 2nd red herring I think people should just ignore unless there's a whole bunch close together all the time. In which case I think the microSD card is bad or your phone is bad. I think the phone being bad is very unlikely unless you bought a cheap counterfeit junk phone like..... "HTM Demon". Yes, "M", not "C". I have one from Aliexpress. It's junk.
Theory 3) For some reason unrelated to anything else, vold randomly decides the microsd is idle and tells the MountService to unmount it. When that happens, then you get:
<3>[ 1866.018346] mmc_sd_detect(mmc1): Unable to re-detect card (-123)
<6>[ 1866.018411] mmc1: card 0007 removed
<3>[ 1866.205666] FAT-fs (mmcblk1p1): Directory bread(block 1133940) failed
Click to expand...
Click to collapse
....and these are serious errors, but these errors didn't cause the unmounting. It's the vold unmounting that happened first which then creates these errors.
So, now I have 2 scripts: stop_vold.sh & resume_vold.sh
Code:
#
#This script stops the vold process. Not kill it, just suspend it so it cannot do anything.
#
ps vold
VOLD_PID=$( ps vold | grep -v PID | busybox awk '{print $2}' )
echo "[*] Sending KILLSTOP signal to PID $VOLD_PID"
kill -STOP $VOLD_PID
if [ $? -eq 0 ]
then
echo "[*] Success"
else
echo "[*] Problem sending KILLSTOP"
exit 1
fi
Then resume_vold.sh
Code:
#
#This script resumes the vold process.
#
ps vold
VOLD_PID=$( ps vold | grep -v PID | busybox awk '{print $2}' )
echo "[*] Sending KILLCONT signal to PID $VOLD_PID"
kill -CONT $VOLD_PID
if [ $? -eq 0 ]
then
echo "[*] Success"
else
echo "[*] Problem sending KILLCONT"
exit 1
fi
You need to be root to have permissions to suspend the vold process.
Also, you need busybox to be installed for that "awk" command. Most of those rooting kits out there have the busybox binary. Just make sure it's in /system/bin or /system/xbin, owned by root with permissions rwxr-xr-x.
Side Effects of a stopped vold process:
Here's what I've noticed so far. To avoid these issues, make sure to resume vold before doing any of the following:
- Since the vold process, apparently responsible for important storage/volume changes, is stopped...... if you do anything that makes Android call to vold to update storage info... it'll hang and go into a soft-reboot cycle. Soft, because while it keeps rebooting itself trying to get unstuck you can be in an adb-shell and it won't disconnect. The restart-loop can be fixed by either sending a kill -CONT to the vold process or holding down the power button on your phone for 10 seconds to force it to power-down for real. Then on bootup everything will be back to normal. So, connecting the phone to a PC or attempting to mount or unmount the sdcard in Settings->Storage->Un/MountSdCard is probably going to lead to trouble if vold is stopped when you attempt them.
- App installs/updates will cause the phone to freeze for about 45 seconds.
That's it, I think I like this solution the most. No more file writing every 10 seconds and no problems leaving the device to play 6 hours of music uninterrupted then sit idle for another 4 hours. I'll update this post again if I find a problem, but if not then I'm happy with this solution. -^_^-
UPDATE#10
After about 2 days, this stopped working. Instead of the microSD card unmounting, all the content just becomes invisible and phone says the card is 0kb used and 0kb available. After resuming the vold process, Unmounting and remounting in the Settings->Storage will report damaged card. Rebooting the phone makes the card work again and show all its content. Coincidentally, this is also when I added a bunch more music beyond the 32gig used marked. I'm starting to think the reason phone manufactures say the phone can support up to 32GB when bigger cards are detectable by Android, is because they know anything more than 32gb is like overclocking a CPU. You might be able to get a bit more performance but you also might just run into more errors. None of these microSD card problems happen with my 32gb card. Maybe if I got a class 10 64gb card this would work better. The fact that my ls-la script is still a working solution gives me hope that there's a more elegant solution to be found.
dmesg:
<3>[ 6732.453920] mmcblk1: error -84 transferring data, sector 27308860, nr 256, cmd response 0x900, card status 0xb00
<6>[ 6733.198026] mmc0: Deferred resume completed
<3>[ 6733.664116] mmc1: mmc_blk_reset: failed to reset -110
<3>[ 6733.664147] end_request: I/O error, dev mmcblk1, sector 27308860
<3>[ 6733.664177] end_request: I/O error, dev mmcblk1, sector 27308868
<3>[ 6733.664202] end_request: I/O error, dev mmcblk1, sector 27308876
<3>[ 6733.664228] end_request: I/O error, dev mmcblk1, sector 27308884
<3>[ 6733.664252] end_request: I/O error, dev mmcblk1, sector 27308892
<3>[ 6733.664276] end_request: I/O error, dev mmcblk1, sector 27308900
<3>[ 6733.664300] end_request: I/O error, dev mmcblk1, sector 27308908
<3>[ 6733.664324] end_request: I/O error, dev mmcblk1, sector 27308916
<3>[ 6733.664348] end_request: I/O error, dev mmcblk1, sector 27308924
<3>[ 6733.664371] end_request: I/O error, dev mmcblk1, sector 27308932
<3>[ 6733.664997] mmc1: sdhci_cmd_irq: AUTO CMD err sts 0x00000002
<3>[ 6733.669428] mmcblk1: error -110 sending status command, retrying
<3>[ 6733.672022] mmcblk1: error -110 sending status command, retrying
<3>[ 6733.674442] mmcblk1: error -110 sending status command, aborting
<3>[ 6733.684124] mmc_sd_detect(mmc1): Unable to re-detect card (-123)
<6>[ 6733.684186] mmc1: card 0007 removed
<6>[ 6734.164388] mmc1: new ultra high speed SDR104 SDXC card at address 0007
<6>[ 6734.164978] mmcblk1: mmc1:0007 SL64G 58.2 GiB
<6>[ 6734.166085] mmcblk1: p1
Click to expand...
Click to collapse
Notice how the card disappears and apparently is re-detected after about 1 second, but it's empty and with 0kb capacity.... and during all this vold is still suspended so maybe that's why everything about the card is zero.
logcat:
I/AudioFlinger( 221): BUFFER TIMEOUT: remove(4096) from active list on thread 0xb3f5e008
D/PowerManagerService( 912): updateWakeLockWorkSourceInternal: lock=1113296440 [AudioMix], ws=null
E/ffmpegdecoder.c( 1190): Can't open file /storage/sdcard1/myuzik/ToniChilds/Toni Childs - House Of Hope.mp3 err=-1 Operation not permitted
E/DecoderBase( 1190): native_open returned error=0
E/Pipeline( 1190): Failed to open decoder
E/Pipeline( 1190): com.maxmpz.audioplayer.decoder.DecoderBase$ll1: Can't open file /storage/sdcard1/myuzik/ToniChilds/Toni Childs - House Of Hope.mp3
E/Pipeline( 1190): at com.maxmpz.audioplayer.decoder.DecoderBase.ll1l(":30)
Click to expand...
Click to collapse
I wish I could find whatever that "mmc" process is. Still looking for answers...
UPDATE#11 is below in another comment. http://forum.xda-developers.com/showpost.php?p=64522019&postcount=4
That is all.
You mentioned having root access on this phone. How'd you get root? I've been searching forever for this exact model of the Life One and this is the only thread that makes mention of it.
areyouahobo said:
You mentioned having root access on this phone. How'd you get root? I've been searching forever for this exact model of the Life One and this is the only thread that makes mention of it.
Click to expand...
Click to collapse
towelroot, I think. I tried all kinds of rooting exploits for all kinds of phones... but it was towelroot that first caused SuperSU to prompt me Grant or Deny, then suddenly I had root.
I have a suspicion that it was a mix of towelroot, a file called "mt6589_rooting_pkg.zip" and do a google search for android rooting using this exploit CVE-2014-3153 . I wish I knew exactly which one, but I was just trying everything really fast. I didn't even notice SuperSU.apk getting installed. Just suddenly it popped up and I had root after trying all those exploits.
I can tell you though, that I did _not_ use Kingroot.
UPDATE#11
Research has taught me that the mmc thing is a kernel module (specifically linux/source/drivers/mmc/card/block.c) and if I want to update it, I need to modify the kernel image. Looking around, it appears that nobody really does that... what they do instead is simply compile from source using the config from the phone. So, I got boot.img then using mkboot command split the boot.img file into ramdisk and kernel. Using binwalk, found where the gzip part of the kernel was and gunzipped it, giving me an uncompressed kernel. Searching this uncompressed kernel image again with binwalk, located another gzip within. gunzipped that and I got the Kernel config. Comment at the top said "Linux/arm 3.10.28 Kernel Configuration", so I went to kernel.org and downloaded the source of kernel 3.10.28. In the downloaded linux source's directory, I copied the kernel-config I got from the kernel image and placed it in this dir as ".config" so the kernel would compile with the right options. I left everything else as default when asked. Wouldn't build because of some line containing __devinit but various googling for the error and I discovered some kernel devs actually submitted a patch to remove it, so I removed it from my source. Then it failed to compile because of some missing firmware blobs. PR1593801-s3203_n_dsx8232_JTOUCH.img and PR1593801-s3203_n_dsx8232_TTOUCH.img.
What I did then, was create a 250 byte file containing only the number "8" over and over again, then another file containing the number "9" over and over. Named them the above JTOUCH and TTOUCH images respectively and compiled the kernel. I then used a hexeditor to examine where in the uncompressed kernel image those 8s and 9s ended up. First, I noticed that the 2 files were concatenated together with no compression or encryption or padding or delimiting bytes in between. Then I noticed all the function names & bytes that appeared just before the 8s and just after all the 9s. I compared it to the kernel image from my phone and was able to deduce the general area of the 2 firmwares. I then notice a block of function names that didn't match anything else in the file, a block of functions starting with "msm8x16_wcd_*" then suddenly a block of functions starting with "wcd_mbhc_*". I concluded to extract this area of the kernel image and split on those function names to create the firmware images. The cool thing here is, even if I'm wrong on the split since they're concatenated together with no delimit mark... it didn't really matter where I chose to split them as long as I just don't misjudge the start of the first firmware and end of the 2nd. Or I could be wrong about this and somewhere else in the kernel the offset and length of the firmware is stored and referenced during bootup.
So then I "make clean" and rebuilt the kernel.
Code:
ARCH=arm SUBARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make
For this you gotta be sure you have arm-linux-gnueabi-gcc on your machine.
Then using mkbootimg --kernel /path/to/newly/built/zImage --ramdisk /path/to/old/ramdisk/extracted/from/boot.img/ramdisk.gz --dt /path/to/old/extracted/dt.img, created a boot.img containing the newly compiled kernel and the old ramdisk & dt.img
.....and..... it would have been amazing if this had worked, but of course it failed to boot, because I have no idea how to generate another dt.img that this phone needs and apparently using the old one from the boot.img I got doesn't work. I don't even get a chance to "adb shell logcat" or "adb shell dmesg" to see what went wrong. The phone goes into a fast reboot cycle. The while BLU logo screen appears for about a second then the screen goes blank and phone reboots, over and over. Maybe BLU has custom kernel modifications for the phone, who knows. I would have like it to boot up even if wifi, camera and all kinds of stuff was broken.
UPDATE#12
The size of the firmware is indeed stored in the kernel. I did a bunch of tests changing the size of the 2 fake imgs and I kept finding the little-endian representation of the sizes next to each other, always matching and just about in the same spot. i.imgur.com/smahbf4.png, so now I'm trying to find this same area in the real kernel. I've also noticed that I was sorta wrong about the no delimiters between the firmwares. Sometimes there is, sometimes there isn't. Through many tests increasing/decreasing the length of the function names that appear before my fake firmware as well as changing the size of the firmware itself, the kernel appears to be maintaining some kind of 4-byte-alignment. There is always 2 nulls after the function name and then the first firmware starts, and the beginning of the firmware must always be at an offset divisible by 4. The compile process add/removes padding zeroes just before the function name to maintain these rules. Even when the 2nd firmware starts, if it's not a place divisible by 4 then zeroes get padded between the first firmware and the 2nd one to force the 2nd firmware to start at a place divisible by 4.
This was annoying at first, but I now realize that these rules significantly narrow down exactly where the firmware will be in the real kernel image and I can sorta verify my guesses by finding the sizes in the binary that match. I've also noticed that the area containing the image sizes seems to have the value 0xC0 at every 4th byte, as you can see from the image. I suspect this area of the image is some kind of table-of-contents for all the files in the image.
UPDATE#13
So, after a bunch of attempts at booting the kernel and the phone rebooting immediately. I began to suspect that perhaps the kernel is signed in someway and some SHA1/CRC/etc didn't match so the phone bailed out without even trying to boot. To test this theory, I opened up the original zImage-format kernel image extracted from the phone... went to the center of the file and changed 3 bytes(that were not zero) arbitrarily to something else. My thinking here is this should be enough to fail any kind of kernel-signing process but not enough to completely ruin the boot up process. I was happy to see that the phone still proceeded to boot up even with those 3 bytes changed. I didn't use the phone enough to find out exactly what I broke by altering, but this at least made me confident that the entire image isn't somehow signed which would mean there's no hope of me getting anything to boot on it besides the one it came with. Then I went to try some other ways of creating the zImage. First, I used binwalk on the original zImage to tell me when the gzip archive starts for extracting the kernel image. I used dd to create a file that containing all bytes _before_ the gzip header and called that file zImage_header_bytes.bin. I then took the arch/arm/boot/Image file from my own kernel build process, gzipped it, and appended it to the zImage_header_bytes.bin file, then made a boot.img from it. Phone didn't boot. Then, I noticed that my make file has a "Image" and "zImage" target. So what I did then is "make zImage", then deleted the uncompressed Image, then ran "make zImage" again. Noticed that the build process must first create an Image then do whatever it does to make "zImage". So, I did this again but I took the original uncompressed kernel image and copied it arch/arm/boot/Image, then typed "make zImage" again. The result was a zImage file that was bigger than the one the build-process normally made which told me it used the original uncompressed Image file to create the zImage. I then tried making a boot.img out of this and... it still failed to boot. I then went back to my original kernel extraction process:
[email protected] ~/tmp1/initfiles $ binwalk originalboot/kernel
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
16619 0x40EB gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
[email protected] ~/tmp1/initfiles $ dd if=originalboot/kernel skip=16619 bs=1 | gunzip > /dev/null
6600989+0 records in
6600989+0 records out
6600989 bytes (6.6 MB) copied, 9.34924 s, 706 kB/s
gzip: stdin: decompression OK, trailing garbage ignored
[email protected] ~/tmp1/initfiles $
Click to expand...
Click to collapse
The trailing garbage message reminded me that I actually threw away some bytes when retrieving the uncompressed image so now I'm working on figuring out the "footer" file, such that I can take my custom uncompressed image, gzip it and put the original header & footer on it. Though, if that were the case then I would have expected my trick of slipping in a different Image into the kernel build process to be made into zImage... would have given it the correct header & footer and should have booted up.... I dunno. Still trying. I'm convinced that, at the very least, I should be able to compile from source the same kernel that's already running on the phone and get the phone to boot up. Maybe it'll crash/freeze and I'll never get a chance to enter my pin, but I should at least be able to get past the initial white BLU logo and into the animated colorful video BLU logo where "adb shell" becomes available and allow me to look at dmesg & logcat for further errors to work on.
UPDATE#14
android.googlesource.com/kernel/msm.git/+/android-msm-dory-3.10-kitkat-wear , so I downloaded this kernel because it seemed much closer to the kernel already on the device. It has files that the kernel.org one does not. e.g., msm8916-sim.dts & msm8916-smp2p.dtsi because in my phone's settings screen the processor info says MSM8916. Also, going into the sound directory and running "find . -name '*.c' -exec grep -E msm8x\|wcd {} \; | grep static" reveals pretty much all the function names that I see the extracted kernel occupying the firmware blob area. I now strongly suspect that those firmware blobs are more or less the result of compiling the files in sound/soc/codecs. So I went ahead and built this kernel. A couple of errors about missing header files, but it's really that they're in a different folder. So I had to copy around 3 or 4 .h files. Then there was a complaint about a multiple declaration of a function, I simply appended a "1" to the function name in .c file defining the function a 2nd time. At the end, there was a complaint: "drivers/net/wireless/wcnss/wcnss_wlan.c:808: undefined reference to `wcnss_rf_read_reg'", I don't know what to do about that so I just commented out and changed the code around there so it wasn't called. I'm sure that brakes wifi, but my goal was to just boot the phone up even if wifi is broken. I can fix that later. So I eventually got my zImage, and I used it and the old dt.img to build a custom boot.img and ....... this time it took the phone much longer before giving up and rebooting! It was like it was just about to load the animated-coloful-logo. It's not the kernel size either, this custom zImage and the resulting boot.img are both smaller than my other custom_boot.img where I only alter the ramdisk contents... and that one does boot up the phone just fine. This makes me think that the phone progressed further in the start-up process before running into a fatal error. The fact that so much msm8196 stuff is in this kernel makes me think it has a much better chance at working. It even has a target like this:
Code:
ARCH=arm SUBARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make msm8916_defconfig
and unlike the kernel.org tar files, this one has arch/arm/boot/dts/qcom/msm8916*
I actually might try copying all the extra files from android.googlesource.com kernel into the plain vanilla one. The coloful animated logo has sound, so maybe trying to load the sound related stuff is why it crashed.
UPDATE#15
More progress! android-msm-angler-3.10-marshmallow-dr , doesn't crash at all. What happens is the while BLU logo screen appears then, very slowly fades to dark from the center out as if someone physically broke the screen. Like a black square slowly fades in at the center of the screen and grows larger until the whole screen is very dark greyish/black. "adb devices" and "fastboot devices" cannot detect the device. I have to hold the power button down for 10 seconds to force a power-down. This is good news because that means my attempts to boot a custom kernel are working. I might not know the exact configuration needed, but it's not a kernel-signing problem and it's not a problem with how I'm compiling and creating my zImage. The kernels are loading and executing, they just don't do the right thing. It wouldn't compile though without a few changes, I had to comment out the "tp_log_debug" and "tp_log_err" calls in hw_tp_common.c and in direct-io.c I had there was a function call that returned a value the code never used, "cmpxchg(&sb->s_dio_done_wq, NULL, wq)", the compiler gave a warning about it and then said something about some warnings will become errors due to compile flags somewhere. I just changed that code to do something harmless:
Code:
if(cmpxchg(&sb->s_dio_done_wq, NULL, wq)) {
wq = wq;
}
That way the return value of cmpxchg is being used in the if-statement and the "wq = wq" doesn't actually change anything. I just used a variable, "wq", that was declared earlier in the function. Oh and disable anything like CONFIG_EXT3 because stuff related to it gave compile errors. As far as I can tell from running the "mount" command in adb-shell, this phone only uses vfat, ext4 and "fuse". So yeah, there's hope! This kernel is 3.10.73 according to its Makefile.... I still really wish I could generate a dt.img from this source code. That dtbTool never works for me. Keeps saying "0 unique dtb" or something. I'm also getting a better idea of why I seem to be having better luck with these, h t t p android.googlesource.com/kernel ...the "msm" section has a description indicating it's for Qualcomm chipset which my BLU phone is definitely telling me in the Settings screen. My guess is BLU took this base kernel and made some changes perhaps. I don't see a 3.10.28-msm on googlesource.com. That would probably be the best thing to try.
UPDATE#16
More progress again! Now trying stuff with "android-msm-seed-3.10-marshmallow". This the only kernel were I only have to make a small one-line code change.
Code:
./kernel/sched/fair.c:static inline int select_best_cpu(struct task_struct *p, int target, int reason, int sync)
The compile failed because a declaration of this function was missing the "sync" parameter. Everywhere else in the file it had the sync value but I had to add it there. And in ./arch/arm/mach-msm/Kconfig the section "config PHYS_OFFSET" kept rewriting the .config PHYS_OFFSET to 0x00200000 even when I changed it to 0x80000000 to match the img_info I got from mkboot extracting the original boot.img. I had to add the line "default "0x80000000" if ARCH_MSM8916" so it would compile with the correct base address.
Also, Found this tool: /github.com/mypalmike/csplitb , that allows me to extract dtb files out of the dt.img that I got from mkboot pulling files out of the original boot.img. So now that I have a file called msm8916-0000.dtb in a dir called "dtbfiles", the command mkbootimg_tools/dtbToolCM -2 -o custom_dt.img -s 2048 -p k/android-msm-seed-3.10-marshmallow/scripts/dtc/ dtbfiles/ will produce a dt.img for the current kernel I'm compiling(3.10.49) and then I created a custom boot.img out of all this to attempt booting up the phone. I should note here it was important to use dtbToolCM, not the regular dtbTool. The regular will make a dt.img but when that's use to make a boot.img then "fastboot boot custom_boot.img", it'll complain "Failed remote: dtb not found". Only the dtbToolCM does it so that complaint doesn't occur. So after all this... I still get the growing fade-to-black square... but now I got a kernel that compiled with very minimal modifications and a dt.img that I believe matches the new kernel I'm trying to run. Now I just gotta think about what else I can look into. The phone doesn't have to work perfectly, just boot up enough that adb-shell works so I can look at logcat/dmesg for other error messages to work on.
Stay tuned!
UPDATE#17
More progress yet again! So I found out that the exact version of gcc used for a particular version of android are kept as static binaries on googlesource.com. Because binwalk on the original boot.img->kernel->extracted_gunzipped_kernel showed me the linux header and gcc 4.7, I decided to download that toolchain's tarball from "android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/" to compile from now on. So I kept getting that fade-to-black screen. I looked carefully at my .config. Simply copying the .config I extracted from the boot.img into the kernel-source root works, but it asks me a ton of questions and rewrites stuff. I finally noticed one thing that looked important to me and was set by the new kernel "CONFIG_AUTO_ZRELADDR=y". The .config from the boot.img left this unset. When I changed it to "=n", the build failed with arm-eabi-4.7/bin/arm-eabi-ld:--defsym:2: syntax error. I reran the "make zImage" but this time like:
Code:
ARCH=arm SUBARCH=arm CROSS_COMPILE=../../arm-eabi-4.7/bin/arm-eabi- make zImage V=1
That V=1 makes it print out the exact commands it's running to do stuff, so I saw the problem:
Code:
../../arm-eabi-4.7/bin/arm-eabi-ld -EL --defsym _kernel_bss_size=1312864 --defsym zreladdr= -p --no-undefined -X -T arch/arm/boot/compressed/vmlinux.lds arch/arm/boot/compressed/head.o arch/arm/boot/compressed/piggy.gzip.o arch/arm/boot/compressed/misc.o arch/arm/boot/compressed/decompress.o arch/arm/boot/compressed/string.o arch/arm/boot/compressed/hyp-stub.o arch/arm/boot/compressed/lib1funcs.o arch/arm/boot/compressed/ashldi3.o -o arch/arm/boot/compressed/vmlinux
See how zreladdr has no value set to it? A search for zreladdr in all of the kernel source showed me arch/arm/mach-msm/Makefile.boot had a hardcoded list of various ZRELADDRs for different chipsets but MSM8916, for my phone, was missing. I googled "MSM8916 zreladdr" and found various Makefile.boot that did have MSM8916, set as 0x80008000. Great! So I added that value to my Makefile.boot and ran the make-command again, it built the zImage without a problem! ....but still, fade-to-black-graphic-corruption. I also toyed around with changing the ZRELADDR randomly and it definitely had an effect. If I make it 0x00008000 the phone would crash & reboot immediately. If I made it 0xA0000000 the phone would hang. When it's 0x80008000, it would do the fade-to-black. One of these 3 things would happen for random values of ZRELADDR. This really made me think my problems are related to having an incorrect ZRELADDR for this new kernel. From reading about it, I learned ZRELADDR is where the kernel gets copied to after it's decompressed somewhere else in memory. Corruption can happen if the place it's being copied to overlaps with other important memory. So I started thinking that maybe the value 0x80008000 doesn't work for this phone for whatever reason. Again I felt the need to prove to myself that this kernel is actually running. Since everyone out there seems to have it set to 0x80008000 I decided to leave the value as that and run make menuconfig, go into kernel-hacking and I noticed a "CONFIG_BOOT_PRINTK_DELAY", that'll slow down the each message being printed by the kernel by N milliseconds. N being what you give on the kernel cmdline, e.g. "boot_delay=250". If my kernel did get uncompressed and started running, then putting a boot_delay=250 should definitely delay when my screen fades to black. I went ahead an enabled the delay, added to boot.img-creation process the 250 millisecond delay and again attempt to run it. To my delight, the phone did take much longer before the fade-to-black occurred! Then I set the boot_delay=0 and tried booting the exact same custom_boot.img again. This time the fade-to-black was immediate. Excellent, so this kernel is getting unpacked and starts to run... prints out some messages... then something goes wrong. At this point, I'm sure professionals have a UART cable to do a serial-connection and actually see what the messages are. I'm sure something very helpful is in there, but I don't have such a cable.
I'm still thinking of what to do.... I feel like I'm close. Even if I don't ultimately figure this out I've gained a ton of knowledge in this quest.
Hopefully I'll be back with another update!
UPDATE#18
Further down the rabbit hole! So when I have display problems on my Linux PC, I usually have to do something like video=vesa on the kernel cmdline temporarily while I try to get some kind of proprietary video-driver-binary-blob to load. I just noticed that /proc/cmdline has more stuff in it than what was supplied when I assembled the bootimg using mkbootimg.
androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci androidboot.emmc=true androidboot.serialno=88e9844f androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_otm1284a_720p_video
Click to expand...
Click to collapse
The only thing that the mkboot reported after extracting stuff from the original boot.img stops after androidboot.bootdevice. That's also the only stuff I give mkbootimg when combining the zImage, ramdisk and dt.img into customboot.img. Everything starting at androidboot.emmc is coming from... I have no idea. But the one thing that really caught my attention was qcom,mdss_dsi_otm1284a_720p_video! I never put any kind of value like that in my custom-kernel. Maybe that's the problem? To verify it, I ran the strings command on the uncompressed original kernel and sure enough the string was in that kernel image, but not in mine. Then, I searched the ramdisk and dt.img. The dt.img file also has the string in it! While looking around to learn more about dt.img, I discovered the command "dtc -I dtb -O dts msm8916-0000.dtb > ./msm8916.dts" will give me the human readable source; and it works the other direction too. So now I can go from dt.img-->.dtb--->dts and back again! I looked at the source and there was a huge section label "qcom,mdss_dsi_otm1284a_720p_video" with all kinds of stuff that definitely looked like it's describing how to control the screen. Hmm, so if the kernel is asking for a dt-entry that doesn't exist maybe the screen gets messed up? I know for sure my kernel doesn't have that string in it so probably whatever it's doing is wrong. I changed the name of this entry in the dts, then compiled it back into a dt.img and booted up the original boot.img hoping that now the name is changed, the original kernel wouldn't find it and the screen would fade to black. That would make me feel confident that the problem I was having is related to kernel & dt.img not matching screen-mode. Unfortunately, even with the name change the device booted up properly and the /proc/cmdline still showed the same normal-named video-mode. "Hmm..." I thought, then I noticed the width & height values. I changed the height from the original value(1280) to like 640. That worked! After the white-BLU-logo, at about the time the screen would fade to black for my kernel... original kernel started the animated-logo but it was half cut-off at the bottom by a big blue square and when the Android-UI showed up, all the icons and everything were shrunk down to fit in the top-half of the screen! OK THEN! So even though I changed the name, the kernel still found it. Next experiment, completely delete the entry from the dt.img. I did that...and the result was the screen faded to black after the white-BLU logo, just like my custom kernel does! So now I'm feeling pretty sure that my custom-kernel is requesting a video-mode not in the dt.img. The only place I see in the "make menuconfig" to supply this kind of info is CONFIG_CMDLINE, but the config file I extracted from the original boot.img does not use that. I then noticed an option for creating a "zImage-dtb" so I tried that but what it does is literally appends the .dtb file to the end of the zImage. I see the data in hexedit, but the kernel I got from the phone has that strings _AFTER_ it's been uncompressed. So I was expecting the dtb to be inserted into the Image AND THEN compressed into zImage-dtb. I tested it and zImage-dtb still doesn't boot my phone. Still looking around for another way to do this. If I can just push this custom-kernel to boot up enough for adb to kick-in, I can start actually looking at errors from dmesg, /proc/kmsg and logcat.
UPDATE#19
Step by Step!!! So after compiling my kernel and careful comparing of what I see in my hexeditor, I tracked down the file BLU-devs hardcoded that "qcom,mdss_dsi_otm1284a_720p_video" string in. drivers/video/msm/mdss/mdss_mdp.c . When I added a variable holding that string near the top of "static int mdss_mdp_get_pan_cfg(struct mdss_panel_cfg *pan_cfg)", my compiled kernel looked just like theirs in the same hex area. Maybe IDApro could disassemble this kernel and show me clearly what's going on, but I don't have that. What I do have is a fade-to-black screen. I thought to myself, what if I could put some code in here that'll stop the screen from fading out? Then I'd have an idea of what lines of code the kernel reached. I first wanted to do an infinite-loop, but looking at init/main.c I saw a thread started. I don't want any other threads interfering; I want everything to just halt. Google'd how to cause a kernel-panic and found, in hindsight is obvious, that causing a segfault will kill the whole process. Someone gave an example and I put it into my function:
Code:
static void screen_stay_on() {
int *p = 0;
printk("%d", *p); //invalid memory access, will cause segfault.
}
I tested this code right in the init function in the mdss_mdp.c and sure enough, the screen didn't fade out. It just stayed at the white-BLU logo. Excellent!!! I then moved screen_stay_on() into all the error-checking parts of the code, one-by-one, many-many-many recompiles and "fastboot boot custom_boot.img" for a few hours. Eventually I narrowed it down to this:
Code:
rc = of_property_read_u32(pdev->dev.of_node, "qcom,max-mixer-width", &mdata->max_mixer_width);
if (rc) {
pr_err("device tree err: failed to get max mixer width\n");
screen_stay_on();
return -EINVAL;
}
Okay!!!! So if it called my function then I know for sure the error message above must have been sent to the UART-console. Remember a few updates earlier I said I can decompile the dt.img->dtb->dts to actually see its source code? Well I checked the source and sure enough, "qcom,max-mixer-width" was missing! I google'd msm8916 qcom,max-mixer-width and found other dtsi(differnet from dts) with just about all the same values I have and qcom,max-mixer-width = <2048>;. So I just went ahead and added that value right above other values that the kernel was checking for. Recreated the dt.img and tried to boot again. The screen faded to black! So I solved that error!!!!! Now as it turns out, after moving my screen_stay_on() code to all error-handling within mdss_mdp.c I can now say for certain that no errors occur in that file. The main function in here is static int mdss_mdp_probe(struct platform_device *pdev), and by the time that function reaches the end it has called all the other functions in the file and they all must have succeeded without error, so I put the screen_stay_on() in the error-handling at the end and the screen still fades out, so probing for the screen is working. Also, in mdss_mdp_get_pan_cfg I put:
Code:
if(strcmp("dsi:0:qcom,mdss_dsi_otm1284a_720p_video", pan_name) == 0)
screen_stay_on();
The code did some processing beforehand that appears to remove the "1:" at the beginning, so by doing this and seeing that the screen didn't fade out informed me that the correct video-mode string was being sent. I guess it's in the bootloader because I didn't put it in the cmdline when creating the boot.img and I removed my variable containing that value from the code. This conclusion is further enforced in that nowhere in the kernel-source can I find a call to "mdss_mdp_probe", so I guess the bootloader is what called it. Now, the fact that this drivers/video/msm/mdss/, is in the "videos" folder and my kernel-config file has CONFIG_FB_MSM=y and CONFIG_FB_MSM_MDSS=y seems to indicate that if I slowly work my way through all the .c files in msm and mdss, I'll eventually succeed in getting the device to start up enough for adb-shell. I think this because based on timing, the screen seems to be the last thing before the animated screen shows up and the moment that appears(actually even like a split second before) adb-shell starts working. Stay tuned!
UPDATE#20
I shortened the crashing code into a one-liner, printk("%d crash me now!", *(int *)0); because it's easier to clean-up and remove when I'm done looking at a particular file.
So... the game has changed a bit. What I just found out by accident, is that if I remove "qcom,mdss_dsi_otm1284a_720p_video" from dt.img.. the stock kernel will fade out the screen, but if I wait long enough it will still boot up. The screen won't work but adb-shell does and I can see all the kmsg errors about not being able to setup the framebuffer.... and a devide-by-zero error somewhere. This means my newer kernel has 2 problems. One is the screen and the 2nd is something else because apparently starting up the screen is not a fatal error to Android. Sounds hopeless, but hold on! A couple of other things I've just discovered....
In the file mdss_mdp_splash_logo.c:
Code:
rc = mdss_mdp_splash_parse_dt(mfd);
if (rc) {
pr_err("splash memory reserve failed\n");
goto end;
}
if (!mfd->splash_info.splash_logo_enabled) {
rc = -EINVAL;
printk("%d crash me now!", *(int *)0);
goto end;
}
mfd->splash_info.splash_thread = kthread_run(mdss_mdp_splash_thread,
mfd, "mdss_fb_splash");
end:
return rc;
In the parse code, it sets mfd->splash_info.splash_logo_enabled to whatever it found by asking the dt.img for "qcom,mdss-fb-splash-logo-enabled"... at least it looks that way to me, however no matter how I manually added that to the dt.img this code kept saying no. Eventually, I just decided to remove that if-statement entirely forcing the code path to go start that splash thread. The result? After the while-BLU-logo, the screen went immediately blank then immediately blue! ....Hmm!
Above I said that even if I remove the main video-mode from the dt, the phone will still boot up just without a display, but there is an interesting detail here. When the stock-kernel tries to show the animated logo, the display blinks for a moment like it's switching modes(makes sense).... then fades out when apparently things didn't work out but continues the bootup process to allow adb-shell to work. My custom kernel just fades out without that blink. But I can cause a very similar looking blink by forcing that splash-thread to start. I also noticed that even with a stock-kernel AND stock dt.img, the screen does blink for a moment before starting the animated boot. If I use the stock kernel BUT a dt.img with _ALL_ splash-enable tags removed, then the screen blinks for a moment, the white logo is cut in half by a blue square on the lower half of the screen... then it fades out just like my custom-kernel.... but then suddenly the animated boot screen shows up and the phone works normally from there! I find that interesting too!
Also, there are comments in the file "./mdss/mdss_mdp_overlay.c" that suggest that this code where the switch from the bootloader logo to the animated one will happen - or at least is very imminent. Because the splash code that changed the screen blue was started in a kthread, I now suspect whatever code I'm looking for that starts the boot-animation will be a kthread started thing as well. In a way, that makes sense. The kernel shouldn't start the gui in its own main process.(pid 1 I assume, judging from init/main.c). I think I'm close. I'm hoping to solve this issue and reach an animated-boot-logo. But I still need another way to communicate what's going on because it doesn't appear that I can rely on the screen-fade to help me. That'll be especially true if I manage to fix stuff and reach the animated-boot-logo, but then the phone gets stuck there. I looked in the dt.img and saw what appeared to be the video region:
Code:
memory {
device_type = "memory";
reg = <0x0 0x0 0x0 0x0>;
#address-cells = <0x2>;
#size-cells = <0x2>;
[email protected] {
linux,reserve-contiguous-region;
linux,reserve-region;
linux,remove-completely;
reg = <0x0 0x86000000 0x0 0x800000>;
label = "external_image_mem";
};
The above "reg" section says image starts at 0x86000000 and is the size of 0x00800000. I hoped that was video-ram so I wrote code to set all the bits in that memory region
Code:
int i = 0
for(i = 0; i < 0x00800000; i ++)
*(char*)(0x86000000 + i) = 255 ;
...but I didn't see anything appear on screen.
I haven't given up, seeing the screen change blue from the splash-logo code gave me hope that this kernel can find & draw to the screen beyond the bootloader's hardcoded white-BLU logo.
UPDATE#20.b
To help avoid getting myself confused, I've gone into my ramdisk/init.rc and removed the bootanimation service completely. So now my device seems to boot up faster, straight from white-logo to android homescreen. A bunch of widgets are still loading though because they weren't ready in time. So now the stock-kernel with my custom-ramdisk boots straight to AndroidHomeScreen as fast as possible while my custom kernel fades out. This way I don't need to concern myself about the boot-animation working and keeps the scope of my problem smaller; just focus on getting android(the zygote service in init.rc?) to start up properly instead of the fade out. If it turns out that my custom kernel works as long as boot-animation is disabled, I can live without that feature.
UPDATE#20.c
Earlier I concluded that static int mdss_mdp_probe(struct platform_device *pdev) was called by the bootloader since I couldn't find any calls to it. That was wrong, I was searching the codebase for that exact string but I've since discovered that structs with similar variables/members are being used to share function-pointers and called from there. e.g.,
Code:
static struct platform_driver mdss_mdp_driver = {
.probe = mdss_mdp_probe,
.remove = mdss_mdp_remove,
.suspend = mdss_mdp_suspend,
.resume = mdss_mdp_resume,
.shutdown = NULL,
.driver = {
/*
* Driver name must match the device name added in
* platform.c.
*/
.name = "mdp",
.of_match_table = mdss_mdp_dt_match,
.pm = &mdss_mdp_pm_ops,
},
};
So now, any code call can do variableName->probe() to call mdss_mdp_probe. I'm looking for that now. I've also installed an app called "LiveBoot" by Chainfire that can save dmesg and kmsg to /cache/liveboot.log. Apparently it only starts up as soon as the /data partition is mounted. When I attempt to boot the kernel with this program, screen fade, wait a bit, reboot to TWRP, I don't see a /cache/liveboot.log file so it seems my custom kernel didn't make it far enough for that program to start logging.
UPDATE#20.d
A sidenote, the original problem I had with phone's microSD disappearing. I've updated the script I use to prevent that. I noticed that if the script is running when there is no music playing, it seems to cause issues with the microSD. And I keep forgetting to stop the script when music stops playing. So, in this updated script it won't write to the sdcard unless music is actually playing. That way all you have to do is remember to use the ScriptManager app from the PlayStore to start this script in the morning and for the whole day, listening to music shouldn't be a problem:
Code:
#increase read-ahead, supposedly this helps too.
echo -n 2048 > /sys/devices/virtual/bdi/179\:0/read_ahead_kb
echo -------------------------
id
echo -------------------------
cd /storage/sdcard1
while true; do
IS_SOUND_PLAYING=$( lsof | grep /dev/snd | grep pcm )
if [ -z "$IS_SOUND_PLAYING" ]; then
echo "[`date`] No sound detected"
else
echo "[`date`] Sound is playing"
ls -la . > ./ls_la.log 2>&1
sleep 1
ls -la . >> ./ls_la.log 2>&1
sleep 1
rm ./ls_la.log
fi
sleep 9
done
....and that probe code from my previous sub-update, traced back to generic probing code for all hardware in the linux-kernel world. When a device is probed isn't necessarily when it is used so that ended that chain of events. I'm looking at this problem from more than one angle.
Fixing the screen fade would be nice... but more important is getting access to the error-logs by:
- /fstab has this in its listening "/devices/platform/msm_hsusb /storage/usbotg vfat nosuid,nodev wait,voldmanaged=usbotg:auto", USBOTG implies serial-console over USB port. I need to buy a usbotg cable and give it a shot.
- Getting the phone to at least start up enough for liveboot app to save the logs to the /cache/liveboot.log file so I can reboot into stock and get the file, then I won't be trying a bunch of stuff blindly.
- Get CONFIG_FRAMEBUFFER_CONSOLE to work so that the bootloader will show the kernel-logs right away even if nothing else works and I'd have exact error messages to work on.
- Also editing the mdss_mdp entries in the dt.img to see if I can make the stock kernel fail like my custom kernel. Giving me more of an idea of what I should be looking for. Right now, I'm still of the mindset that the stock dt needs updating for the new kernel. I just don't know exactly what to change yet.
I hope to have a major'ish update next time!
UPDATE#21
Okay! So various Googling about Qualcomm and MSM8916 and I found a pdf on qualcomm's site pointing to https://codeaurora.org/projects/all-active-projects/android-msm ....I spent quite a bunch of time looking through the dozens of branches to find a kernel as close to 3.10.28 as possible and containing msm8916 files in arch/arm/configs/ , git cloning the entire thing is madness; way too big. So instead I found git commands for cloning only a specific branch and only the HEAD of that branch without history(I think).
git clone -b <tagName> --depth 1 <git://URL>
Click to expand...
Click to collapse
I couldn't find it, but I ran into another XDA post that did find it!!!! forum.xda-developers.com/android/development/rom-mokee-opensource-project-t2922088
https://www.codeaurora.org/cgit/qui...X_ANDROID_LNX.LA.3.7.2.1_RB1.04.04.04.157.010
Click to expand...
Click to collapse
If you click on "tree", you'll see the whole file/folder structure of the kernel. Also note that XDA post is for a different phone... but the same Android 4.4.x I have, same Kernel 3.10.28 my stock kernel is from and the same MSM8916 chipset! This is the closest I've seen so far.
So, given that url... to clone the exact branch/tag without downloading that gigantic repo..... click on summary and scroll to the bottom, you'll see a git clone URL, git://codeaurora.org/quic/la/kernel/msm-3.10 . Then notice that in the previous link there was an "h=LNX.LA.3.7.2.1_rb1", so in your terminal you type:
git clone -b LNX.LA.3.7.2.1_rb1 --depth 1 git://codeaurora.org/quic/la/kernel/msm-3.10
This will just download the files you see when you're in the tree tab; a quick download. In contrast, go ahead and try just doing a git clone without the depth or -b option and watch it take forever. So compiling this kernel using the .config I got from the boot.img will crash the phone. But, if I go force the splash-thread to run like in my previous updates... I get the familiar Linux penguin! No blue screen, and this kernel doesn't fade out the screen either! I think I've just gotten rid of one of my 2 problems! I tried enabling the FRAMEBUFFER_CONSOLE in .config and enabling the splash-screen, hoping that along with that linux-penguin I'd get kernel logs scrolling by(that's what happens for Linux on my PC). But that didn't happen.
UPDATE#21.b
So, in the upper-righthand corner of the page www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/Makefile is a dropdown, it looks like everything in that list starting with LNX.LA.3.7* has kernel 3.10.28. I might have to try all of them! I've also learned something else, there really was no hope for the other kernels I was trying to use. Once I notice this kernel behaving properly with the screen I ran "diff -r android-msm-seed-3.10-marshmallow/drivers/video/msm/mdss LNX.LA.3.7.2.1_rb1/drivers/video/msm/mdss", the differences are substantial and impossible to guess. Stuff like this:
171c192
< qpic_send_pkt(OP_EXIT_SLEEP_MODE, NULL, 0);
---
> qpic_panel_set_cmd_only(OP_EXIT_SLEEP_MODE);
176c197
< qpic_send_pkt(OP_ENTER_NORMAL_MODE, NULL, 0);
---
> qpic_panel_set_cmd_only(OP_ENTER_NORMAL_MODE);
181c202
< qpic_send_pkt(OP_SET_DISPLAY_ON, NULL, 0);
---
> qpic_panel_set_cmd_only(OP_SET_DISPLAY_ON);
Click to expand...
Click to collapse
Even with the fact I have very little idea how this code works, seeing functions with different names and different number of params confirms comments I read when ROM-devs say you need to use the right kernel for your device. The differences can be way to big to solve with changes to .config, and definitely too problematic without having a serial-console to see kernel messages during boot up. Realistically/cynically speaking, the chances that I'll get this to work are kinda low... but I have learned a lot making these attempts and the fact that despite the odds, I've made progress little by little, gives me hope to continue. I'll probably be trying a bunch of these kernels; it's gonna be awhile because it takes like 25mins to compile one and they usually have errors I have to fix by copying .h files to the correct directory. e.g., I always get complaints about msm_csid.h & msm_csiphy.h missing, but really they're just not in the dir that the compile-process is looking at. An with each of these kernels, I'll be retrying the FRAMEBUFFER_CONSOLE and watching /cache/liveboot.log for any entries.
And the penguin splash screen, I figured out how to get it without changing the code. The code is actually checking the fb_primary section, so in my dt.img I've added qcom,mdss-fb-splash-logo-enabled to that area and now even the stock kernel gets the Linux-penguin on startup, then the liveboot logs start scrolling by.
Code:
qcom,mdss_fb_primary {
cell-index = <0x0>;
compatible = "qcom,mdss-fb";
qcom,mdss-fb-splash-logo-enabled;
qcom,memblock-reserve = <0x83200000 0xfa0000>;
linux,phandle = <0x44>;
phandle = <0x44>;
}
Crossing my fingers for some luck here. I hoping for a booting kernel, or at least being able to see the kernel-logs of why it won't boot.
UPDATE#22
LNX.LA.3.7.c7 , whoa... this kernel hangs on the linux-penguin then silence for about 2mins..... then the phone's screen goes off and my Linux PC's dmesg suddenly does this:
Code:
[2238301.946062] usb 1-2: new high-speed USB device number 92 using xhci_hcd
[2238302.074180] usb 1-2: config 1 has an invalid interface number: 20 but max is 1
[2238302.074193] usb 1-2: config 1 has no interface number 1
[2238302.074604] usb 1-2: New USB device found, idVendor=05c6, idProduct=9006
[2238302.074607] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2238302.074610] usb 1-2: Product: QHSUSB__BULK
[2238302.074612] usb 1-2: Manufacturer: Qualcomm CDMA Technologies MSM
[2238302.074615] usb 1-2: SerialNumber: 1234567890ABCDEF
[2238302.075131] usb-storage 1-2:1.20: USB Mass Storage device detected
[2238302.075815] scsi host24: usb-storage 1-2:1.20
[2238303.074290] scsi 24:0:0:0: Direct-Access Qualcomm MMC Storage 1.00 PQ: 0 ANSI: 2
[2238303.075024] sd 24:0:0:0: Attached scsi generic sg1 type 0
[2238303.075591] sd 24:0:0:0: [sdb] 30785536 512-byte logical blocks: (15.7 GB/14.6 GiB)
[2238303.075725] sd 24:0:0:0: [sdb] Write Protect is off
[2238303.075732] sd 24:0:0:0: [sdb] Mode Sense: 0f 0e 00 00
[2228723.862956] usb 1-2: USB disconnect, device number 85
[2228726.011441] usb 1-2: new high-speed USB device number 86 using xhci_hcd
[2228726.202432] usb 1-2: New USB device found, idVendor=18d1, idProduct=d00d
[2228726.202443] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228726.202449] usb 1-2: Product: Android
[2228726.202453] usb 1-2: Manufacturer: Google
[2228726.202457] usb 1-2: SerialNumber: 88c8934f
[2228727.560892] usb 1-2: USB disconnect, device number 86
[2228759.996611] usb 1-2: new high-speed USB device number 87 using xhci_hcd
[2228760.125561] usb 1-2: New USB device found, idVendor=05c6, idProduct=9039
[2228760.125569] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228760.125574] usb 1-2: Product: Android
[2228760.125578] usb 1-2: Manufacturer: Android
[2228760.125581] usb 1-2: SerialNumber: 88c8934f
[2228786.600155] usb 1-2: USB disconnect, device number 87
[2228788.971409] usb 1-2: new high-speed USB device number 88 using xhci_hcd
[2228789.162432] usb 1-2: New USB device found, idVendor=18d1, idProduct=d00d
[2228789.162441] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228789.162446] usb 1-2: Product: Android
[2228789.162450] usb 1-2: Manufacturer: Google
[2228789.162454] usb 1-2: SerialNumber: 88c8934f
[2228790.051869] usb 1-2: USB disconnect, device number 88
[2228822.708616] usb 1-2: new high-speed USB device number 89 using xhci_hcd
[2228822.837663] usb 1-2: New USB device found, idVendor=05c6, idProduct=9039
[2228822.837669] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2228822.837672] usb 1-2: Product: Android
[2228822.837675] usb 1-2: Manufacturer: Android
[2228822.837677] usb 1-2: SerialNumber: 88c8934f
[2230472.557985] usb 1-2: USB disconnect, device number 89
[2238176.773860] usb 1-2: new high-speed USB device number 90 using xhci_hcd
[2238176.964854] usb 1-2: New USB device found, idVendor=18d1, idProduct=d00d
[2238176.964866] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2238176.964873] usb 1-2: Product: Android
[2238176.964878] usb 1-2: Manufacturer: Google
[2238176.964882] usb 1-2: SerialNumber: 88c8934f
[2238177.447102] usb 1-2: USB disconnect, device number 90
[2238297.707378] usb 1-2: new high-speed USB device number 91 using xhci_hcd
[2238297.837015] usb 1-2: New USB device found, idVendor=05c6, idProduct=9039
[2238297.837024] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2238297.837029] usb 1-2: Product: Android
[2238297.837033] usb 1-2: Manufacturer: Android
[2238297.837036] usb 1-2: SerialNumber: 88c8934f
[2238298.881636] usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd adb_Linux rqt 128 rq 6 len 256 ret -71
[2238298.882319] usb 1-2: USB disconnect, device number 91
[2238303.075855] sd 24:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[2238303.088454] sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 sdb15 sdb16 sdb17 sdb18 sdb19 sdb20 sdb21 sdb22 sdb23 sdb24 sdb25 sdb26 sdb27 sdb28 sdb29 sdb30
[2238303.093730] sd 24:0:0:0: [sdb] Attached SCSI disk
[2238314.750365] EXT4-fs (sdb23): mounted filesystem with ordered data mode. Opts: (null)
[2238327.410965] EXT4-fs (sdb25): recovery complete
[2238327.411781] EXT4-fs (sdb25): mounted filesystem with ordered data mode. Opts: (null)
[2238333.447632] EXT4-fs (sdb30): recovery complete
[2238333.448440] EXT4-fs (sdb30): mounted filesystem with ordered data mode. Opts: (null)
[2238339.389827] EXT4-fs (sdb24): recovery complete
[2238339.390653] EXT4-fs (sdb24): mounted filesystem with ordered data mode. Opts: (null)
And so far, it appears 5 different volumes are mounted! They appear to be the various partitions(boot, aboot(bootloader), recovery, etc). The phone couldn't be seen by adb or fastboot, makes sense because it appears to have switched into some mode emulating 5 USB drives. I looked through the files and all I saw were the system apks, bin dir, etc but no logs.
I... guess I just keep going! One of these kernels might actually boot this phone up!
UPDATE#22.b
Hmm.... I just realized something, all the partitions get mounted to the connected PC as read/write(first you have to be root on your Linux box though); even the system partition. So even if I didn't have an exploit to root this phone previously, booting up with this messed up kernel allowed me to create any arbitrary files in /system and when I reboot the phone to run it's built-in stock kernel, the file is still there and owned by root. I could have just copied the "su" binary out of SuperSU.apk and put it in /system/bin, then reboot the phone to stock-kernel. /system/bin/su would still remain there and it'd be owned by root and I could become root that way...... interesting strategy. Note that this only seems to work on a LinuxPC, on a macosx I just see a bunch of these appear in dmesg:
Code:
USBMSC Identifier (non-unique): 0x00000000 0x5c6 0x9091 0x0, 2
[0xffffff8023be5600](1)/(5) Device not responding
Also, I see lines like this during stock-kernel's bootup: ltr553_L5510.c ltr553_als_set_enable: enable = 1 which I assume goes alone with the stock-kernel's config CONFIG_PROJECT_L5510=y. I'm assuming L5510 is some kind of BLU internal project-ID for their work on this phone. I've noticed that some branches on msm-3.10, e.g. LA.BF64.1.1_rb1.9, contain a file /drivers/input/misc/ltr553.c . What I'm guessing is that BLU modified this file in some way for this phone. From googling around, it appears this LTR553 stuff is for the little light sensor on the front of the phone that is used when you set brightness to automatic. Probably also somehow used when the camera is trying to auto-adjust for lighting as well. I wanted to know which branches & kernel versions had ltr553, but using the WebUI for this took too long and I kept losing my place. I ultimately ended up cloning the entire repo to machine, and then running this command & script:
git branch -a | sed 's/ //g' |while read b; do bash ./search_ltr553.sh $b ; done > searchresults.log 2>&1
Click to expand...
Click to collapse
search_ltr553.sh containing:
Code:
echo "************** $1 *************"
git checkout -f $1
cat Makefile |grep SUBLEVEL.=
find . -name ltr553.c
echo "************* END $1 ********"
I grep the sublevel because I'm looking for "28", from 3.10.28... then the find command searches for ltr553.c. Probably could be faster by simply "ls /drivers/input/misc/ltr553.c", either it's there or it's not.
I didn't find any 3.10.28 kernels containing the ltr553 sensor module. I wanted to focus on kernels that containing the ltr553 code but those kernels aren't 3.10.28, and so far only 3.10.28 can start up the phone's LCD properly. Everything else seems to fade the screen to black.
Well, the attempts continue. I should probably note that I'm also emailing BLU periodically for the kernel source to this phone.
UPDATE#23
https://github.com/SMTDDR/BLULifeOne
Meh, anti-climatic finish. After emailing BLU several times they gave me the kernel source and the firmware images. It works, phone starts with no problems. In fact, they actually gave the kernel source to a lot of their devices. I'm downloading them all now, but it'll be awhile. It's a very slow download. Using "wget -r ftp://<username>:<password>@<IP_address>/"
I guess I'll just continue on trying to make 3.10.49 work, but now I'll have a working kernel-source to work from. Then I'll see if the sdcard-unmount issue still exists. Then try messing around with ./drivers/mmc/card/block.c because that looks like where the errors are coming from according to dmesg.
If I manage to make a progress, I'll just update the repo.
I hope someone out there learned something from all my posts here.
UPDATE#23.b
Oh, and I got the newer kernel to config the LCD properly. It turns out that 3.10.49 was ignoring my dt.img file, it seems to only pay attention to the dtb that is concatenated into the zImage. And I mean that literally, like "cat /path/to/zImage /path/to/msm8916.dtb > zImage-dtb". Then creating a boot.img from zImage-dtb without providing a --dt custom_dt.img , that works. First I compiled 3.10.49 as "make zImage-dtb". Then I ran csplitb.py --prefix msm8916- --suffix .dtb --number 4 D00DFEED /path/to/zImage-dtb. This gave me 46 dtb files. I put all these files in one dir and ran the command "file . -name '*.dtb' -exec bash ./to_dts.sh {} \;" and the script to_dts.sh contained only one line: ../k/LNX.LA.3.7.1.1_rb1.49/scripts/dtc/dtc -I dtb -O dts ./$1 > ${1%dtb}dts, so now I had all the .dts source code files. Then I ran: find . -name '*.dts' -exec grep "model = " {} /dev/null \;|grep Q to print out each filename and the chipset that it's for. The dts file I got from the stock-kernel's dt.img had this at the top: model = "Qualcomm Technologies, Inc. MSM 8916 QRD SKUI";, so that was what I was looking for. Found it as file msm8916-0011.dts, so I took that file... added the section "qcom,mdss_dsi_otm1284a_720p_video" from the stock dt.img and then went to the section called "qcom,[email protected]" and changed the value qcom,dsi-pref-prim-pan to equal the phandle value in the video-section I just added. Note, for all sections the phandle should be the same as linux,phandle ...also.. these values should be unique throughout the whole file! No 2 sections should have the same phandle or linux,phandle. Then created a dtb from this modified dts, LNX.LA.3.7.1.1_rb1.49/scripts/dtc/dtc -I dts -O dtb /path/to/modified.dts > fixedup_msm8916.dtb. Then took this .dtb and appended it to the zImage, cat /path/to/zImage /path/to/fixedup_msm8916.dtb > zImage-dtb. Then created the boot image, mkbootimg_tools/mkbootimg --kernel /path/to/zImage-dtb --ramdisk boot/custom_ramdisk.gz --cmdline "androidboot.hardware=qcom msm_rtb.filter=0x3F ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci" --base 0x80000000 --ramdisk_offset 0x01000000 -o custom_boot.img ....and the resulting custom_boot.img used with "fastboot boot custom_image.img" gave me the nice linux-penguin.
UPDATE#23.c
Download finished, if anyone wants these... give me some place to upload them to.
Code:
.Energy X E010Q
.Dash 5.0 D410
.Life Pure XL L260
.Life Play S L150
.Studio 5.0 S II D572
.Life Mark L0030EE
.Neo 3.5 S370
.Neo 4.5
.Dash M D030
.Life One L120
.Studio 5.0 HD LTE & Studio 6.0 LTE
.Advance 4.0 A270
.Dash C Music D390U-L
.Dash Music Jr D390
.Studio 5.0 C D536
.Studio XL D850Q
.Pure XL P0010UU
.Studio One
.LIfe One X L132
.Studio 5.5 S D630
.Studio Selfie S070Q
.Life One X010Q <------ This is the one that runs on my phone, even though it's labeled X010Q here, and my phone is X011Q.
.Studio Energy 2 S0090UU
.Life Play KitKat L100
.Studio 5.0 C E D536
.Studio C Mini D670
.Dash Jr D140
.Studio G Plus S510
.Vivo Air D980L
.Life 8 L280
.Studio 5.0 C HD D534
.MT6589
.Studio 5.0 S D570
.Life One M L131
.Studio 5.0 II D532
.Studio 5.0 D530
.Studio Energy D810
.Studio 5.5 D610
.Life One XL X030Q
.Dash 3.5 II D352
.Studio C
.Dash X D010
.Life View L110
.Vivo IV D970L
.Dash 3.5 D171
.Dash 4.5 D310
.Life Play 2 L190
.Studio 5.0 K D530K
About 26 gigs in total.
Anyways... off I go...
UPDATE#23.d
All that stuff I said to edit .dts file? Don't do that, make the changes in the dts & dtsi files in arch/arm/boot in the dts folder and its subfolder "qcom". It turns out that there are values reference from different files and when the whole thing is "compiled" into a dtb, things get IDs(phandle) or different values 'n stuff. Cut & paste from a dts that came from somewhere else directly into another dts that was decompiled from someplace else can lead to complicated problems. .e.g., I talked about copying the whole video section into the other dts... but what I didn't know was stuff like the following: There is a file for a different resolution called arch/arm/boot/dts/qcom/dsi-panel-otm1283a-720p-video.dtsi , inside this file is this line: qcom,mdss-dsi-panel-controller = <&mdss_dsi0>; and the file that imports this one with an #include statement, arch/arm/boot/dts/qcom/msm8916-qrd-skui.dtsi, does stuff like this:
Code:
&mdss_dsi0{
qcom,dsi-pref-prim-pan = <&dsi_otm1284a_720p_video>;
pinctrl-names = "mdss_default","mdss_sleep";
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
com,platform-reset-gpio = <&msm_gpio250>;
};
&dsi_otm1284a_720p_video{
qcom,cont-splash-enabled;
};
All those &name stuff gets resolved during compile and it appears phandle and linux,phandle are caculated as well. Just cutting and pasting dts stuff from one kernel to another, skipping the compile process, can cause you a headache if you don't know exactly what values came from where. It's best to just make the changes in the kernel's dts&dtsi source files, compile to zImage-dtb and then look at the result. For me, that dtb file is ultimately: arch/arm/boot/dts/msm8916-qrd-skui.dtb that's created during the zImage-dtb process. At least decompiling this file into a .dts and editing is safer since you know that you're at least starting with all the &name stuff replaced with the correct values. But just beware that some values in there might be referring to other values elsewhere in the file so just changing them without understand, will break relationships and almost definitely cause your device not to work.
UPDATE#24
So, right now I'm on git clone -b kk_rb5 --depth 1 git://codeaurora.org/quic/la/kernel/msm-3.10 kk_rb5, commit fe85dc23da0b36704f10b7d980017a5d82fabb8a kernel 3.10.40. It seems be the one that accepts the .config from the stock kernel while asking the least amount of questions. I still get my linux penguin on start up since I enable that in the dt files, then all the ext4 partitions get mounted on my PC.
I really want to see the boot messages, so far I've tried:
/proc/last_kmsg - I don't have and I see no where in menuconfig to enable it
Framebuffer-console - Doesn't work, even with BLU's kernel source the device just boots up normally and I see nothing. But, "adb reboot" and the whole device freezes for 2mins before the reboot happens.
CONFIG_PSTORE_CONSOLE , is suppose to give me /sys/fs/pstore/* a bunch of logs from a previous kernel boot. I get nothing. I think drivers have to register to be part of this with pstore_register().
github.com/Tasssadar/kernel/commit/b1c614341dbc04ec1ace604f0b4903944dd8aa9d , from this thread forum.xda-developers.com/showthread.php?t=1295621. I tried using my intuition to make these changes in my newer kernel(the code isn't exactly the same as the code that person modified), but didn't work. Phone just stays on white-BLU-logo, no penguin.
USBOTG, still haven't tried this.
UPDATE#24.b
Random googling about my phone's partitions mounting to my computer turned up some info. QHSUSB__BULK is a known issue with Android phones in specific situations. The productID seems to serve as an error code. With the kernel I'm working with now, I get:
Code:
[4039781.339003] usb 1-2: New USB device found, idVendor=05c6, idProduct=9091
[4039781.339010] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4039781.339013] usb 1-2: Product: QHSUSB__BULK
That Product ID (PID), 9091, is trying to tell me something. I don't see a chart out there telling me what all the error codes are. The only thing people talking are doing is to bring the phone into a state where they can flash it into a known good state. I don't want to flash my phone into a known good state, I want this kernel to work.
UPDATE#25
Whoa, so... the screen comes on but is blank... and... MY MUSIC APP PLAYS MUSIC WHEN THE HEADPHONES ARE PLUGGED IN!!!!!! Even the Volume buttons work!
This is amazing to me! That means this kernel is good enough to run, that Android starts up and PowerAmp can play music! ....from the external microSD card even!
I'm very shocked that adb still doesn't see the phone though.... that's odd.
The changes I made to reach this point, was comparing the dts & dtsi files that BLU sent me and slowly try to add missing sections to the new kernel, but not modify sections that already exist.
UPDATE#25.b
After some more testing, the configuration to get music playing is very specific. I have to go into the dts & dtsi files and remove splash screen, that means in the fb_primary section I remove qcom,mdss-fb-splash-logo-enabled; and in the file "msm8916-qrd-skui.dtsi" remove the part that adds qcom,cont-splash-enabled; to the selected video-mode:
Code:
&dsi_otm1284a_720p_video {
/* qcom,cont-splash-enabled; ....I'm commenting this out */
}
Then, in .config enable FRAMEBUFFER_CONSOLE & Peguin logo:
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
Click to expand...
Click to collapse
You won't see a peguin or any framebuffer showing you boot up logs. The white-BLU bootloader logo will flicker a few times then the screen will go blank. Then in about a minute or so my music app kicks in through the headphones.
UPDATE#26
Success! Got the logs! So, because the music files that are on my sdcard started playing, I knew that the microSD card must have mounted successfully. There's a file in the ramdisk called init.qcom.rc that's responsible for mounting that microSD so that script must have ran. So, I added another service below it:
service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
class late_start
service getdmesg /system/bin/getdmesg
class late_start
Click to expand...
Click to collapse
That getdmesg is just a bash script that I wrote, containing:
#!/system/bin/sh
sleep 45
dmesg > /data/local/tmp/dmesg.log
dmesg > /storage/sdcard1/dmesg.log
logcat -d *:d > /data/local/tmp/logcat.log
logcat -d *:d > /storage/sdcard1/logcat.log
sleep 5
reboot
Click to expand...
Click to collapse
And that's it. "fastboot boot custom_boot.img" and wait for sleeps to complete. The device reboots itself to the working kernel that's flashed on it(without the modification to init.qcom.rc) and the previous kernel's dmesg & logcat are indeed located at /data/local/tmp.
DMESG:
Code:
6>[ 0.000000] Booting Linux on physical CPU 0x0
<6>[ 0.000000] Initializing cgroup subsys cpu
<6>[ 0.000000] Initializing cgroup subsys cpuacct
<5>[ 0.000000] Linux version 3.10.40-g354f6d4-dirty ([email protected]) (gcc version 4.7 (GCC) ) #15 SMP PREEMPT Tue Feb 9 16:07:18 PST 2016
<4>[ 0.000000] CPU: ARMv7 Processor [410fd030] revision 0 (ARMv7), cr=10c5387d
<4>[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
<6>[ 0.000000] Machine: Qualcomm Technologies, Inc. MSM 8916 (Flattened Device Tree), model: Qualcomm Technologies, Inc. MSM 8916 QRD SKUI
<6>[ 0.000000] Node qcom,mdss_fb_primary memblock_reserve memory 83200000-841a0000
<6>[ 0.000000] cma: Found [email protected], memory base 0x86000000, size 8 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x86800000, size 78 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x8b600000, size 6 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x00000000, size 109 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x00000000, size 18 MiB, limit 0x90000000
<6>[ 0.000000] cma: Found [email protected], memory base 0x00000000, size 3 MiB, limit 0xffffffff
<6>[ 0.000000] cma: Found [email protected], memory base 0x83000000, size 18 MiB, limit 0xffffffff
<3>[ 0.000000] cma: CMA: failed to reserve 20 MiB
<6>[ 0.000000] cma: CMA: reserved 8 MiB at 0x86000000 for external_image_mem
I see this a couple of times too:
<4>[ 27.955392] mdss_fb_wait_for_fence: mdp-fence: sync_fence_wait timed out! Waiting 10 more seconds
Click to expand...
Click to collapse
LOGCAT:
Code:
/QC-QMI ( 284): qmi_ctl_tx_msg: qmi_qmux_tx_msg failed
E/QC-QMI ( 284): qmi_ctl_handle_request: qmi_ctl_tx_msg call failed
E/QC-QMI ( 284): qmi_qmux_open_connection: connection is disabled for conn_id=57
E/QC-QMI ( 284): qmi_qmux_tx_msg: failed to open inactive connd_id=57
E/QC-QMI ( 284): qmi_qmux: TX failed, connection inactive or in reset, conn_id=57, status_flags=4
E/QC-QMI ( 284): qmi_ctl_tx_msg: qmi_qmux_tx_msg failed
E/QC-QMI ( 284): qmi_ctl_handle_request: qmi_ctl_tx_msg call failed
E/USB_UICC( 240): Timeout! No signal received. Retry num = 22
E/VoldConnector( 1096): NDC Command {7 asec list} took too long (2430ms)
I/PackageManager( 1096): Deleting stale container for com.enfeel.birzzle-1
I/PackageManager( 1096): Deleting stale container for com.natenai.artofglow-2
I/PackageManager( 1096): Deleting stale container for com.ssb.droidsound-1
W/PackageManager( 1096): Unknown permission com.baidu.permission.QCCLOUD_PROVIDER in package com.android.contacts
W/PackageManager( 1096): Unknown permission com.android.firewall.READ_GRAVITY in package com.android.contacts
W/PackageManager( 1096): Unknown permission com.android.firewall.WRITE_GRAVITY in package com.android.contacts
W/PackageManager( 1096): Unknown permission com.android.firewall.READ_GRAVITY in package com.android.phone
W/PackageManager( 1096): Not granting permission android.permission.WRITE_SECURE_SETTINGS to package com.yahoo.android.locker (protectionLevel=50 flags=0x8be44)
W/PackageManager( 1096): Unknown permission com.android.vending.billing.IBillingAccountService.BIND2 in package com.google.android.gsf.login
W/PackageManager( 1096): Unknown permission android.permission.RECOVERY in package com.updatelogic.netready.da.svc
W/PackageManager( 1096): Unknown permission com.android.launcher.permission.READ_SETTINGS in package com.android.launcher3
W/PackageManager( 1096): Unknown permission com.android.launcher.permission.WRITE_SETTINGS in package com.android.launcher3
W/PackageManager( 1096): Unknown permission android.permission.INSTALL_DRM in package com.android.mms
W/PackageManager( 1096): Unknown permission android.permission.OBSERVE_GRANT_REVOKE_PERMISSIONS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.RECOVERY in package com.google.android.gms
W/PackageManager( 1096): Not granting permission android.permission.READ_DREAM_STATE to package com.google.android.gms (protectionLevel=2 flags=0x40c83ec5)
W/PackageManager( 1096): Unknown permission android.permission.PROVIDE_TRUST_AGENT in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.google.android.apps.enterprise.dmagent.permission.AutoSyncPermission in package com.google.android.gms
W/PackageManager( 1096): Not granting permission android.permission.PACKAGE_USAGE_STATS to package com.google.android.gms (protectionLevel=18 flags=0x40c83ec5)
W/PackageManager( 1096): Unknown permission android.permission.MANAGE_VOICE_KEYPHRASES in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.REAL_GET_TASKS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.READ_WIFI_CREDENTIAL in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.SCORE_NETWORKS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.CONTROL_INCALL_EXPERIENCE in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.USER_ACTIVITY in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.MODIFY_AUDIO_ROUTING in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.google.android.wearable.READ_SETTINGS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.INTENT_FILTER_VERIFICATION_AGENT in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.LOCAL_MAC_ADDRESS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.CHANGE_DEVICE_IDLE_TEMP_WHITELIST in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.BODY_SENSORS in package com.google.android.gms
W/PackageManager( 1096): Unknown permission android.permission.NOTIFY_PENDING_SYSTEM_UPDATE in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.android.voicemail.permission.READ_VOICEMAIL in package com.google.android.gms
W/PackageManager( 1096): Unknown permission com.google.android.gallery3d.permission.PICASA_STORE in package com.android.dreams.phototable
Now I can really debug this kernel and figure out what's going on.
UPDATE#26.b
So I got a bunch of these constantly happening in dmesg:
Code:
<3>[ 14.151255] mdss_dsi_reg_status_check: Read back value from panel is incorrect
<3>[ 14.151358] mdss_check_dsi_ctrl_status: Panel has gone bad, sending uevent - PANEL_ALIVE=0
Looking around the source code from where these error messages are coming from, I discovered that BLU-devs made a bunch of modifications to mdss_dsi_host.c , mdss_dsi.h, mdss_dsi_panel.c. I cannot simply copy the source file from the BLU kernel source into the new kernel because function definitions have changed and I have to think about how to apply their patches to the new kernel. e.g. in mdss_dsi_host.c:
mdss_dsi_buf_alloc(&ctrl->status_buf, SZ_4K);
//LINE <lcm> <DATE20141218> <read more register> limi.zhan
mdss_dsi_buf_alloc(&ctrl->status_buf_two, SZ_4K);
ctrl->cmdlist_commit = mdss_dsi_cmdlist_commit;
Click to expand...
Click to collapse
That 2nd line of code referencing status_buf_two was added by them. In my newer kernel, that same code looks like this:
mdss_dsi_buf_alloc(ctrl_dev, &ctrl->status_buf, SZ_4K);
ctrl->cmdlist_commit = mdss_dsi_cmdlist_commit;
Click to expand...
Click to collapse
Notice that the newer 3.10.40 kernel, the function mdss_dsi_buf_alloc() takes _THREE_ parameters rather than 2 from the original stock 3.10.28 kernel version. So, I have to patch it to look like this:
mdss_dsi_buf_alloc(ctrl_dev, &ctrl->status_buf, SZ_4K);
mdss_dsi_buf_alloc(ctrl_dev, &ctrl->status_buf_two, SZ_4K);
ctrl->cmdlist_commit = mdss_dsi_cmdlist_commit;
Click to expand...
Click to collapse
....I then get an error about that struct not containing any member status_buf_two and thus discover that BLU-devs also modified the .h file containing the definition of the struct to make sure that field existed, so I gotta go modify that too. This is the slow process I'm going through in hopes to solve this panel-error that I think is causing the display not to work. I also see errors related to wlan so I'm pretty sure the wifi is broken and I see usb related errors that are probably why adb/fastboot don't see the phone when this kernel starts the phone. This is going to take awhile.... but at least I have logs that I'm working from now.
UPDATE#26.c
adb sees the device now! The problem was this:
&usb_otg {
qcom,hsusb-otg-mode = <3>;
qcom,usbid-gpio = <&msm_gpio 110 0>;
pinctrl-names = "default";
pinctrl-0 = <&usbid_default>;
vbus_otg-supply = <&smb1360_otg_supply>;
};
Click to expand...
Click to collapse
That is located at the bottom of msm8916-qrd-skui.dts in the stock 3.10.28 kernel, and the BLU-devs commented that stuff out. I didn't see this at all in the newer 3.10.40 kernel so I just went on my way, but then I just noticed that the newer kernel's msm8916-qrd-skui.dtsi(NOTE the "i" at the end of this file, not the same as the .dts) did have the same usb_otg entry. I commented it out and now adb sees the device and I can adb-shell into it! I can't become root though, I've actually never been able to become root before the device fully starts up and the android-GUI appears.
UPDATE#27
So, after manually patching my newer kernel video driver files to match what appears to be the intents of the BLU-dev in the older kernel... the panel gets init'ed properly. Now, I got tired of having to wait for the reboot to the flashed-working kernel before I could pull the dmesg.log. I wanted root while my newer kernel was running. That way I could see dmesg right there and reboot directly back into fastboot-mode for my next attempts. Before, I said that when I ran "su" it'd always fail. I discovered that is the intentional design of the "su" binary from the SuperUser.apk. They want "su" to communicate with it and since my device isn't booting up enough for the AndroidGUI(zygote?) to start up, SuperUser.apk apparently can't work either. Probably because SuperUser.apk cannot display that "toast" message I normally see "Adb Shell has been granted root permissions".
After some research, I ran into this thread: forum.xda-developers.com/showthread.php?t=1463829 , they compiled a su that doesn't talk to SuperUser.apk. The link in that thread is broken, but this link: forum.xda-developers.com/showthread.php?t=1197486 has a ROM (version 0.8.1) that contains f-su according to the change-log. So I downloaded this ROM and extracted its contents, searched and found the "su" binary. I then booted up my phone with the working kernel, became root, and copied this su binary into /system/xbin as "ultimate_su" and chmod'ed it 4755(rwsr-xr-x). Then booted into the newer kernel.
When I ran ultimate_su at first, it segfaulted, but if I waited long enough... maybe about 45secs after boot... then it gave me root. Interestingly enough however, while uid did return info indicating I was root... "dmesg" command still said operation-not-permitted. What I had to do was run the SuperUser's su, and because I was already uid=0 from ultimate_su, then SuperUser's su gave me root without talking to the apk. In summary, 45secs after boot I did this to get fully-powered root: ultimate_su -c su.
The issue I'm dealing with now is the following:
<3>[ 1.618188] msm-tlmm-pinctrl 1000000.pinctrl: pin gp-13 already requested by 5-0038; cannot claim for 5-0070
<3>[ 1.618198] msm-tlmm-pinctrl 1000000.pinctrl: pin-13 (5-0070) status -22
<3>[ 1.618206] msm-tlmm-pinctrl 1000000.pinctrl: could not request pin 13 on device msm-pinctrl
<3>[ 1.618214] synaptics_rmi4_i2c 5-0070: Error applying setting, reverse things back
<3>[ 1.618221] synaptics_rmi4_i2c 5-0070: can not set pmx_ts_active pins
<4>[ 1.618632] synaptics_rmi4_i2c: probe of 5-0070 failed with error -22
Click to expand...
Click to collapse
I'm pretty confused on this one. I do know that in the msm8916-pinctrl.dtsi , there's this:
pmx_ts_int_active {
qcom,pins = <&gp 13>;
qcom,pin-func = <0>;
qcom,num-grp-pins = <1>;
label = "pmx_ts_int_active";
ts_int_active: ts_int_active {
drive-strength = <16>;
bias-pull-up;
};
};
Click to expand...
Click to collapse
If I change that 13 to a different number, then the error message still appears but it'll talk about that number instead of 13. I read stuff in this link elinux.org/EBC_Exercise_11a_Device_Trees , that taught me how to find pins that are free to use. Supposedly if I cat /sys/kernel/debug/pinctrl/1000000.pinctrl/pinmux-pins | grep "(MUX UNCLAIMED) (GPIO UNCLAIMED)" I get a list of pins I could use. For me, pin-50 was free so I changed the qcom,pins in pmx_ts_int_active to 50.... but I still got the error; just complaining about gp-50 instead of gp-13. Looking at the dts from the old working kernel, they also seem to be using the same pin with no problem. So I don't what to do yet... still researching & trying.
UPDATE#28
So, after awhile of staring at this error message I decided to see if I really even needed thsi "msm-tlmm-pinctrl". Turns out, that the older kernel compiles version 4 of this. CONFIG_PINCTRL_MSM_TLMM_V4=y , while my newer kernel seems to have the first version "CONFIG_PINCTRL_MSM_TLMM=y". So, I did a search for all *.c & *.h files containing the string "TLMM_V4"(case INsensitive) on the older kernel to get an idea of how/where this tlmm_v4 module was used....then I modified the following:
* modified my .config to V4.
* In arch/arm/mach-msm/Kconfig, section config ARCH_MSM8916, modified it to V4.
* In ./drivers/pinctrl/Kconfig, copied the V4 version into it from the Kconfig of the older kernel.
* In ./drivers/pinctrl/pinctrl-msm.c, there was an "#ifdef CONFIG_PINCTRL_MSM_TLMM_V4" block of code that had to be copied into my newer kernel source.
* Copied whole file ./drivers/pinctrl/pinctrl-msm-tlmm-v4.c to my newer kernel, because my newer kernel didn't have that file at all.
* In drivers/pinctrl/Makefile, added dependency to cause the v4.c code to compile: obj-$(CONFIG_PINCTRL_MSM_TLMM_V4) += pinctrl-msm.o pinctrl-msm-tlmm-v4.o
And for my troubles, I got the compile error:
Code:
drivers/pinctrl/pinctrl-msm-tlmm-v4.c:883:3: warning: initialization from incompatible pointer type [enabled by default]
error, forbidden warning: pinctrl-msm-tlmm-v4.c:883
Looking at the code at that line, and the struct it's initializingstruct msm_pintype_info in drivers/pinctrl/pinctrl-msm.h, there is indeed a difference in the pointer-type. It's actually a pointer to a function, but the function signature in the newer kernel has more parameters than the old... and there are some other things as well. It'll take time for me to figure out how to change this stuff without breaking other stuff or if I can just get TLMM_V4 wholesale and copy the entire .c & .h and whatever else is the TLMM_V4 version into my newer kernel.
UPDATE#28.b
I tried just copying over the files pinctrl-msm.c & pinctrl-msm.h from old kernel to the new one. Surprisingly it compiled, but the result was a phone that couldn't boot up, no adb-shell access and didn't progress enough to read init.qcom.rc allowing me to get it to dump dmesg to a file like I did before.
UPDATE#29
Okay, I surrender now. I cannot upgrade PINCTRL_MSM_TLMM to V4 without the boot process falling on its face and I can't see any error messages. This is probably where I'll be stopping unless I suddenly have a eureka moment in a dream or something.
It was fun and I did learn a lot trying all this. I hope someone finds some good info from my adventures of kernel tampering.