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.
Related
Got a strange problem....
If I press up/down volume when the phone is supposed to be locked it turns the screen on. Obviously if my phone is in my pocket this is going to happen all the time and waste the battery etc.
Any ideas how I can prevent this from happenning?
cheers.
Thats a feature, not a bug
I know on MIUI-rom you can turn it off in settings, which rom are you using?!
I'm using Shadow Hawk v2.1
Looked everywhere for a setting, just can't find it.
I never tried that rom, but in the thread where to download shadow hawk you should have a look in the feature list
Code:
*Wake phone with volume keys (thanks to lowveld)
tangerine0072000 said:
Got a strange problem....
If I press up/down volume when the phone is supposed to be locked it turns the screen on. Obviously if my phone is in my pocket this is going to happen all the time and waste the battery etc.
Any ideas how I can prevent this from happenning?
cheers.
Click to expand...
Click to collapse
Hmmm...Maybe you can turn off this option from within RCMix tweaks, if you enabled it from there. I've never used that ROM, but i understand that it uses RCMix tweaks and it would do you good to find out if there is a volume wake setting in there. If there isn't, i have the fix for it, and i can give it to you if you're willing to try it. First let me know if you can find anything in the RCMix tweaks.
Cheers
thanks chaps, I had a look in RC tweaks initially before posting, but there is nothing in there that refferences the volume controls.
by the way, what was the fix ?
tangerine0072000 said:
by the way, what was the fix ?
Click to expand...
Click to collapse
Well, the solution is to replace android.policy.jar with the attached file.
This is located in system/framework
Use root explorer or es file explorer with root access, mount system as r/w and replace the said file in the above folder with the one below. Reboot. That's it...your volume buttons will just function as normal volume rocker, and will not wake the phone up anymore.
P.S. : While i don't expect any problem at all, i would highly recommend taking a nandroid backup, and also backing up your original android.policy.jar in case something goes wrong, or you want to revert back to volume rocker wake... Do post back if it works for you.
CLICK TO DOWNLOAD
thanks for the info, I got the download. I tried mounting through these apps, but can't find an option for it. Do I need to mount read/write via the ADB ?
Not done this procedure before.
thanks,
I managed to replace the file using 'root explorer'. Did a reboot, but still got the problem with the volume switching the screen on.
so in my infinate wisdom I thought I might as well put the orignal file back which I did and rebooted. Then the phone wouldn't boot, stuck on HTC logo.
Then I thought I would restore my nandroid back (which I made last night). Phone will only still boot to HTC screen. Doh !
Did this serveral times, formating, clearing cache, restoring backup, but still no joy.
You should read this thread!
edit:
another guide
think I have corrupted cache as I know get....
E:Can't open /cache/recovery/log comming alot when trying to do anything in recovery mode.
tangerine0072000 said:
think I have corrupted cache as I know get....
E:Can't open /cache/recovery/log comming alot when trying to do anything in recovery mode.
Click to expand...
Click to collapse
did you read the guides of my last post? they are may solving your problems!
really wiered.
when I do 'dmesg | grep mmc0' I just get the command prompt...
~ # dmesg | grep mmc0
dmesg | grep mmc0
~ #
I contined to perform 'mke2fs /dev/block/mmcblk0p27'
~ # mke2fs /dev/block/mmcblk0p27
mke2fs /dev/block/mmcblk0p27
mke2fs 1.40.8 (13-Mar-2008)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
76912 inodes, 307196 blocks
15359 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
38 block groups
8192 blocks per group, 8192 fragments per group
2024 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185
Writing inode tables: done
Writing superblocks and filesystem accounting information:
done
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override
~ #
then tried to install my rom which failed part way through.
I am now getting some response from ADB, no errors that I can see.
~ # dmesg | grep mmc0
dmesg | grep mmc0
<3>[ 6.994781] mmc0: No card detect facilities available
<6>[ 6.995300] mmc0: Qualcomm MSM SDCC at 0x00000000a0500000 irq 98,0 dma 7
<6>[ 6.995544] mmc0: Platform slot type: MMC
<6>[ 6.995666] mmc0: 4 bit data mode disabled
<6>[ 6.995819] mmc0: 8 bit data mode enabled
<6>[ 6.996032] mmc0: MMC clock 144000 -> 50000000 Hz, PCLK 96000000 Hz
<6>[ 6.996154] mmc0: Slot eject status = 0
<6>[ 6.996398] mmc0: Power save feature enable = 1
<6>[ 6.996520] mmc0: DM non-cached buffer at ffa0f000, dma_addr 0x0c2c8000
<6>[ 6.996765] mmc0: DM cmd busaddr 0x0c2c8000, cmdptr busaddr 0x0c2c8300
<6>[ 7.150024] mmc0: new high speed MMC card at address 0001
<6>[ 7.151672] mmcblk0: mmc0:0001 M4G2DE 2.10 GiB
No WiFi - wlan0 device can't be found. "dhdsdio_probe_attach: si_attach failed!".
Hi all,
I have a UK Sensation XE that I've had for 18 months. My WiFi has not worked for many months, maybe a year. I am pretty sure the problem first started on GB, because I remember doing an OTA update to stock ICS and hoping it would fix the problem and it didn't.
I just started trying to seriously fix the problem a few days ago. Since then, I have researched on here and Google for hours and hours, and tried every suggestion I could find. I have done lots of diagnostics.
What I've discovered is that the WiFi driver does load, but it reports in dmesg that it can't find the device. Therefore it does not create wlan0. Therefore wpa_supplicant cannot load.
Everything else on the phone works OK - 2G/3G, Bluetooth, USB, etc. Just WiFi is broken.
I am wondering if maybe my WiFi hardware is bust. But then again, I do see the same symptoms on other posts - like this one and this one. The first of those two posts reported it worked for him when he went back to Stock 2.2, suggesting there was some software cause.
dmesg shows the following (I've edited a bit in the middle so to not make this message too long - full dmesg output is in attached txt) :
Code:
gannet_setup
gannet initialized OK
[WLAN] ## wifi_probe
[WLAN][WRN] wifi_set_power = 1
pyramid_wifi_power: 1
EXT4-fs (mmcblk0p22): re-mounted. Opts: user_xattr,barrier=0,data=ordered
[WLAN] wifi_set_carddetect = 1
pyramid_wifi_set_carddetect: 1
mmc2: Slot status change detected (0 -> 1)
[WLAN] Dongle Host Driver, version 5.90.125.120
mmc2: queuing unknown CIS tuple 0x91 (3 bytes)
mmc2: new high speed SDIO card at address 0001
[WLAN] alloc static buf at cf9c0000!
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
EXT4-fs (mmcblk0p22): re-mounted. Opts: user_xattr,barrier=0,data=ordered
mmc2: CMD53: Data timeout
mmc2: SDCC PWR is ON
mmc2: SDCC clks are ON, MCLK rate=48000000
mmc2: SDCC irq is enabled
===== SDCC-CORE: Register Dumps @base=0xd08a6000 =====
.. cut a bunch of Reg= values ..
mmc2: PIO mode
mmc2: xfer_size=4, data_xfered=0, xfer_remain=4
mmc2: got_dataend=0, prog_enable=0, wait_for_auto_prog_done=0, got_auto_prog_done=0
[COLOR="Red"][WLAN][WRN] dhdsdio_probe_attach: si_attach failed!
[WLAN][WRN] dhdsdio_probe: dhdsdio_probe_attach failed
[WLAN][WRN] dhd_module_init: wifi_fail_retry is true
[WLAN] ## wifi_remove
[WLAN][WRN] wifi_set_power = 0
pyramid_wifi_power: 0
[WLAN] wifi_set_carddetect = 0
pyramid_wifi_set_carddetect: 0
mmc2: Slot status change detected (1 -> 0)
mmc2: card 0001 removed
[WLAN] ## wifi_remove leave
[WLAN] module init fail, try again!
[/COLOR]pyramid_wifi_power: 1
pyramid_wifi_set_carddetect: 1
mmc2: Slot status change detected (0 -> 1)
[WLAN] Dongle Host Driver, version 5.90.125.120
I have attached a longer section of dmesg output, starting at boot and going a bit past the last reference to WLAN. The above dmesg snippet starts on line 760 of the attached dmesg txt file. I attached the fuller log in case the dmesg output shows some other error, not tagged WLAN, that I don't recognise as being a problem.
The bcmdhd.ko module is loaded OK:
Code:
# lsmod
tun 14813 0 - Live 0xbf091000
bcmdhd 483764 0 - Live 0xbf005000
kineto_gan 4230 0 - Live 0xbf000000
In logcat, there are various errors from wpa_supplicant and other, which all basically just indicate that it can't find wlan0. Here's a small sample:
Code:
E/wpa_supplicant( 5847): Could not read interface wlan0 flags: No such device
E/wpa_supplicant( 5847): nl80211: Could not set interface 'wlan0' UP
E/wpa_supplicant( 5847): wlan0: Failed to initialize driver interface
This is confirmed from shell:
Code:
# ip link ls wlan0
ip: can't find device 'wlan0'
The problem started on stock, I think stock GB. I do not know of any trigger for it happening.
Around that time I was playing around with rooting for the first time, and I tried Revolution S-OFF which I recall changed my HBOOT from 1.19 to 1.17 or something. But that's as far as I got at the time, I just ran Revolution S-Off, I remember it changed my HBOOT version on phone startup, and then I never tried anything more with flashing/rooting.
I do not know if the Wifi problem started at the same time I tried that hboot change. I cannot remember exactly when the WiFi broke, I don't know if anything triggered it.
All I am pretty sure of is that the problem started on stock GB, and then it was not resolved when I OTA updated to stock ICS (the stock ICS upgrade then changed my hboot to 1.29).
So I know the problem existed on Stock ICS. I think it happened also on stock GB. Then this is what I have also tried recently, in the last week, since I first started flashing/rooting/customising my phone:
Full phone wipe - used 4Ext to do complete wipe of all partitions, before installing new ROMs
Tried with a) no SD card at all, b) two different SD cards, c) did a complete format of one SD card
Tried without sim-card, also tried WiFix to set country code - doubt this has anything to do with it though as there's not even a wlan0 device.
Stock 3.33 FW, and then XDA-Dev 3.32 FW and XDA-Dev 3.33 FW
Stock HTC ICS release as per OTA update
Android Revolution HD 7.1 ROM 4.0.3 ICS
Elegancia ROM 3.70 ROM 4.0.4 ICS
Stock, Faux, Sebastian and Bricked kernels
Originally HTCDev locked, and now unlocked
Originally S-On, and now S-Off (Hboot 1.27)
Flashing boot.img separately with fastboot flash boot boot.img
Flashing ROM with 4Ext SmartFlash (even though I had S-OFF) - and then turning it off again and re-flashing.
Deleting wpa_supplicant.conf (not that this should work as issue is before supplicant. I've put the conf back now.)
So right now my phone is:
HTCDev unlock
S-Off, HBoot 1.27 (I used Juopunutbear-off with the 'wire trick')
4Ext Flash Recovery
Elegancia Rom 3.70 with Bricked kernel
I have searched so much and tried so many things, so I would be super grateful for any help at all. Maybe it's just a HW fault, but I have seen other people with the same symptoms of dmesg reporting it can't find the device, and some of those people did have the issues caused by SW problems, so I am hoping there is still some chance it's resolvable.
Thanks in advance!
No thoughts from anyone?
Would be great to get any thoughts or feedback - even if it's just to say that the HW is broken.
I've been looking all over for a solution for this problem myself. WiFi 'died' with an OTA a while back, none of the suggestions found all over work.
WiFix (basically changing the region) doesn't apply, wlan0 doesn't even start properly.
You mentioned BT is working, but I can see devices, not connect to them, so for me BT is partially working.
What I tried so far:
Different FWs/RUUs, even going back to Gingerbread!
Different RIL - FW/Radio combos
Different ROMs on Universal 3.33 FW as well as FWs from RUUs
I even put a Z710e RUU on it to see if that might work.
Device:
Sensation XE Z715e, currently on: HBoot 1.27.1100, FW 3.33.401.153 Radio11.76C.3504.00U_11.29A.3504.18_M
Stock Rom lsmod:
Code:
bcm4329 225933 0 - Live 0xbf03c000
kineto_gan 4190 0 - Live 0xbf000000
CM10.1 lsmod:
Code:
bcmdhd 444356 0 - Live 0x00000000
I see the same errors as OP in my logcat and dmesg.
I'm starting to suspect the chip is fritzed and needs to be replaced (I can't heat it as suggested here: http://forum.xda-developers.com/showpost.php?p=38165494&postcount=66 )
My other Z715e is unaffected.
My htc was off for one month because i went to a trip and did not take it with me. when i came back i turned it on and boom! bootloop! came from nowhere.
I had the vipers rom on it so i tried to update to the newest vipers rom but still bootloop. i tried to install different rom but nothing help,
At the end i installed RUU and still i'm in bootloop! please help me
amitshkuri said:
My htc was off for one month because i went to a trip and did not take it with me. when i came back i turned it on and boom! bootloop! came from nowhere.
I had the vipers rom on it so i tried to update to the newest vipers rom but still bootloop. i tried to install different rom but nothing help,
At the end i installed RUU and still i'm in bootloop! please help me
Click to expand...
Click to collapse
can you boot into bootloader?
if yes post all the on screen details
rzr86 said:
can you boot into bootloader?
if yes post all the on screen details
Click to expand...
Click to collapse
yes i can get into bootloader but in recovery i get error.
***LOCKED***
PYRAMID PVT SHIP S-OFF RL
HBOOT-1.27.0000
RADIO-11.24A.3504.31_M
OpenADSP-v05.6.0.2226.00.0418
eMMC-boot
JAN 13 2012, 17:33:34
HBOOT
FASTBOOT
RECOVERY
FACTORY RESET
SIMLOCK
IMAGE CRC
amitshkuri said:
yes i can get into bootloader but in recovery i get error.
***LOCKED***
PYRAMID PVT SHIP S-OFF RL
HBOOT-1.27.0000
RADIO-11.24A.3504.31_M
OpenADSP-v05.6.0.2226.00.0418
eMMC-boot
JAN 13 2012, 17:33:34
HBOOT
FASTBOOT
RECOVERY
FACTORY RESET
SIMLOCK
IMAGE CRC
Click to expand...
Click to collapse
from this guide it has 3 options to flash 4ext recovery(see step 1)
http://forum.xda-developers.com/showthread.php?t=1472298
after that go into recovery
format all partitions except sdcard
flash the rom
see if it boots
rzr86 said:
from this guide it has 3 options to flash 4ext recovery(see step 1)
http://forum.xda-developers.com/showthread.php?t=1472298
after that go into recovery
format all partitions except sdcard
flash the rom
see if it boots
Click to expand...
Click to collapse
i flashed 4ext recovery and flashed 3.33 firmware and flashed ARHD 7.2 (i did full wipe for all patitions)
still in bootloop but now it pass the HTC logo and the quitly brilliant logo and start the beats animation then it restart.
HI
GREETINGS
according to your bootloader you have stock htc hboot and
stock htc hboot does not go well with soff
flash the hboot in my attachment
to flash the hboot:-
1 put the file in root of sd card
2 reboot into bootloader
3 the bootloader will scan the file, follow on screen instruction
4 reboot back in to bootloader and make a clean installation of the rom as suggested by "RZR86"
shrex said:
HI
GREETINGS
according to your bootloader you have stock htc hboot and
stock htc hboot does not go well with soff
flash the hboot in my attachment
to flash the hboot:-
1 put the file in root of sd card
2 reboot into bootloader
3 the bootloader will scan the file, follow on screen instruction
4 reboot back in to bootloader and make a clean installation of the rom as suggested by "RZR86"
Click to expand...
Click to collapse
I flashed the new hboot and flashed the recovery again and made a clean installation including format for all partitions and still i stuck in this bootloop! what can i do more?
amitshkuri said:
what can i do more?
Click to expand...
Click to collapse
Absolutely loads of stuff. First thing is to get the logs.
Flash a rom with adb set in the default.prop in the boot image ramdisk ( CM for example )
while the device is bootlooping run
Code:
adb shell dmesg
which gives the kernel messages then you can run
Code:
adb logcat -b system -b radio -b events -b main
this will run forever, you'll notice it repeating the same messages over and over, look out for lines that start with "E/"
they're errors being reported and will lead you to the cause of you're bootloop
If either of these two fail then reboot into recovery and run
Code:
adb shell cat /dev/last_kmsg
This is a saved copy of dmsg from the last session.
Once you've got the logs you can easily pinpoint the cause of the problem all you got is read them
PROTIP: Look for the word error or fail or something similar
ok so that's all the errors i found while booting:
E/QC-NETMGR-LIB( 165): couldn't open file /sys/module/f_rmnet/parameters/rmnet_ctl_ch
E/QC-NETMGR-LIB( 165): couldn't open /sys/module/rmnet/parameters/rmnet_ctl_ch
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/DxDrmNexPlayerIntegrator( 169): ** Discretix Server loaded config file - result=0 **
E/DxDrmNexPlayerIntegrator( 169): ** Discretix SignalsListener Thread is starting **
E/DxSecureClock( 169): ** Discretix Clock Monitor is starting **
E/msm8660.gralloc( 153): DEBUG_CALC_FPS: 0
E/msm8660.gralloc( 153): period: 10
E/msm8660.gralloc( 153): ignorethresh_us: 500000
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 0
E/SurfaceFlinger( 153): composer device failed to initialize (Invalid argument)
E/rmt_storage( 120): Unable to open /boot/modem_fsg
E/rmt_storage( 120): Invalid rmt_storage client
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 1
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 2
E/HtcBootAnimation( 225): Could not find width.
E/HtcBootAnimation( 225): Could not find height.
E/HtcBootAnimation( 225): Could not find framerate.
E/HtcBootAnimation( 225): Could not find part1.
E/HtcBootAnimation( 225): Could not find part2.
E/HtcBootAnimation( 225): Could not find part3.
E/HtcBootAnimation( 225): sqlite3_open error, sqlite result: 14, errno: 2, No such file or directory
E/QC-DIAG_LSM( 156):
E/QC-DIAG_LSM( 156): Diag_LSM: Diag_LSM_Init: Failed to open handle to diag driver, error = 13
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 3
E/ExtendedExtractor( 156): Failed to open MM_PARSER_LIB, dlerror = Cannot load library: reloc_library[1290]: 156
E/AudioPolicyManagerBase( 156): Could not open support_receiver()
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 4
And this came at the second of crash:
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 5
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 6
E/QC-NETMGR-LIB( 165): ifioctl: close port failed: (9)Bad file number
E/QC-NETMGR-LIB( 165): ifioctl: open port failed: (19)No such device
E/QC-NETMGR-LIB( 165): netmgr_kif_ifioctl_open_port() failed for rmnet0 on attempt 7
am i in trouble?
amitshkuri said:
am i in trouble?
Click to expand...
Click to collapse
It's difficult to say with ONLY the errors LOL. You've just removed all the context of what was going on around leading upto it. Can you post the rest of them, not here though, pastebin or somewhere like that.
Also dmesg output would be pretty useful to see if all the drivers are install correctly.
At first glance, You seem to be missing some vital libraries. files, to say anything more at this point would just be guessing? but yeah, dmesg and a full logcat.
Actually to save a back and forth you can run the following commands
Code:
adb root
adb shell stop
adb shell dumpstate > state.txt
adb shell dumpsys > sys.txt
Don't know what you know so I'll explain what this does.
adb root , restarts adb as the root user
adb shell stop, this stops the servicemanager and it's child services , basically stop loading android. If you have a boot animation you should see it stop, this also stops device from rebooting as the next commands take some time to run.
dumpstate and dumpsys will dump your entire device contents to state.txt and sys.txt on your desktop machine. you won't see any output and they do take some time to run so please be patient. As you've fully formatted it I wouldn't expect any personal data to be present in those files but may contain device specific info please have a look before posting. searching the for things like your email address, name, IMEI, serial no's etc should help.
Then zip the files and attach them to this thread. Like I mentioned these files contain everything about the Device and the current state and will give us everything we need to figure out whats wrong.
If you're not comfortable "doing the dump!" ( sounds like a song ) then option 1 of logcat and dmesg should do I'll probably end up asking for more but meh!
ok i tried but
Code:
adb root
adb shell stop
didn't help and the boot restart again and again so i cannot write the rest of codes you gave me.
i attached a rar file with the context of logcat and dmesg.
amitshkuri said:
ok i tried but
Code:
adb root
adb shell stop
didn't help and the boot restart again and again so i cannot write the rest of codes you gave me.
i attached a rar file with the context of logcat and dmesg.
Click to expand...
Click to collapse
That's fine dmesg tells all in this case, It's a bit weird. you system partition seem to be at fault. these messages
Code:
<6>[ 2.457794] EXT4-fs (mmcblk0p22): INFO: recovery required on readonly filesystem
<6>[ 2.457977] EXT4-fs (mmcblk0p22): write access will be enabled during recovery
<6>[ 2.466827] EXT4-fs (mmcblk0p22): barriers disabled
<6>[ 2.468963] EXT4-fs (mmcblk0p22): recovery complete
<6>[ 2.476013] EXT4-fs (mmcblk0p22): mounted filesystem with writeback data mode. Opts: barrier=0
which is just information but a couple of lines down is this
Code:
<6>[ 3.588012] EXT4-fs (mmcblk0p22): re-mounted. Opts: noauto_da_alloc,barrier=0
Logcat also has this related message
Code:
I//system/xbin/busybox( 107): tune2fs 1.41.12 (17-May-2010)
I//system/xbin/busybox( 107): tune2fs 1.41.12 (17-May-2010)
I//system/xbin/busybox( 107): The needs_recovery flag is set. Please run e2fsck before clearing
what it looks like is happening is the kernel has remounted your /system partition to try to set it up for recovery while the device is booting make system files unavailable in the process, which ties up to the messages about missing libraries from earlier on. it may well be easily solved simply by following the instruction and running e2fsck on /dev/block/mmcblk0p22, it worth a shot I'd say.
reboot into recovery and run
Code:
adb shell e2fsck /dev/block/mmcblk0p22
you may also have to remove the need_recovery flag from the partition... I don't know how to do that off the top of my head and I have to go out for a bit.... Google may be your friend
More Soon!
own diBeco
trevd said:
That's fine dmesg tells all in this case, It's a bit weird. you system partition seem to be at fault. these messages
Code:
<6>[ 2.457794] EXT4-fs (mmcblk0p22): INFO: recovery required on readonly filesystem
<6>[ 2.457977] EXT4-fs (mmcblk0p22): write access will be enabled during recovery
<6>[ 2.466827] EXT4-fs (mmcblk0p22): barriers disabled
<6>[ 2.468963] EXT4-fs (mmcblk0p22): recovery complete
<6>[ 2.476013] EXT4-fs (mmcblk0p22): mounted filesystem with writeback data mode. Opts: barrier=0
which is just information but a couple of lines down is this
Code:
<6>[ 3.588012] EXT4-fs (mmcblk0p22): re-mounted. Opts: noauto_da_alloc,barrier=0
Logcat also has this related message
Code:
I//system/xbin/busybox( 107): tune2fs 1.41.12 (17-May-2010)
I//system/xbin/busybox( 107): tune2fs 1.41.12 (17-May-2010)
I//system/xbin/busybox( 107): The needs_recovery flag is set. Please run e2fsck before clearing
what it looks like is happening is the kernel has remounted your /system partition to try to set it up for recovery while the device is booting make system files unavailable in the process, which ties up to the messages about missing libraries from earlier on. it may well be easily solved simply by following the instruction and running e2fsck on /dev/block/mmcblk0p22, it worth a shot I'd say.
reboot into recovery and run
Code:
adb shell e2fsck /dev/block/mmcblk0p22
you may also have to remove the need_recovery flag from the partition... I don't know how to do that off the top of my head and I have to go out for a bit.... Google may be your friend
More Soon!
Click to expand...
Click to collapse
The shell e2fsck did not help, still in bootloop.
i searched in google about the need_recovery flag and i found one post that explain how to do this but in ubuntu linux
the command " debugfs " mentioned there, i dont really understand what to do.
amitshkuri said:
The shell e2fsck did not help, still in bootloop.
i searched in google about the need_recovery flag and i found one post that explain how to do this but in ubuntu linux
the command " debugfs " mentioned there, i dont really understand what to do.
Click to expand...
Click to collapse
hi again.
After reading some more e2fsck need some extra options. apologises for that
Also as is usually the case with these things you're not the first person to have this problem. A quick xda search for "The needs_recovery flag is set" brings up this post
I've just tested it because my cache partition has the needs_recovery flag set so I ran the commands in that post in recovery and it did clear the needs_recovery flag. so in your case you need to boot into recovery make sure /system is NOT mount which should be the default state and run the following commands
Code:
adb shell
tune2fs -l /dev/block/mmcblk0p22 | grep features
this command get the list of filesystem features it should look something like this ( order may be different )
Code:
Filesystem features: has_journal resize_inode filetype needs_recovery extent sparse_super large_file
Next we'll run e2fsck with the right command this time LOL
Code:
e2fsck -f /dev/block/mmcblk0p22
After that we can remove the old journal with tune2fs
Code:
tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p22
This should remove both the has_journal and needs_recovery flags from the feature list. Seeing as has_journal was set we'll turn it back on
Code:
tune2fs -O has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p22
Note the caret symbol ( ^ ) which is the difference between the above to commands. This controls whether a feature should be added or removed
Finally check the feature list again
Code:
tune2fs -l /dev/block/mmcblk0p22 | grep features
It should now look like this or something similar, If it still has needs_recovery in the list then something is wrong
Code:
Filesystem features: has_journal resize_inode filetype extent sparse_super large_file
All we need to do now is pray to the ghost of steve jobs and say the magic words
Code:
reboot
And hopefully we might have a win for you! :good:
when i write this line: e2fsck -f /dev/block/mmcblk0p22
i get this: Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix<y>?
if i press "y" i get this: Inode 13765 is in use, but has dtime set. Fix<y>?
and more and more and more questions and cant continue with the next lines you gave me.
what to do?
amitshkuri said:
when i write this line: e2fsck -f /dev/block/mmcblk0p22
i get this: Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix<y>?
if i press "y" i get this: Inode 13765 is in use, but has dtime set. Fix<y>?
and more and more and more questions and cant continue with the next lines you gave me.
what to do?
Click to expand...
Click to collapse
e2fsck -f -y /dev/block/mmcblk0p22
That will answer yes to all questions!
i did all exactly and still in a bootloop..
i got Filesystem features: has_journal resize_inode filetype extent sparse_super large_file
without the needs recovery, all went well.
is there hope?
amitshkuri said:
i did all exactly and still in a bootloop..
i got Filesystem features: has_journal resize_inode filetype extent sparse_super large_file
without the needs recovery, all went well.
is there hope?
Click to expand...
Click to collapse
Time to rinse and repeat, Grab the dmesg and the logcat and lets see what it's saying now? Also Have you tried reflashing the rom, it's possible the tune2fs has deleted some files but we can only find out by looking at the logs!
i tried now to reflashed and still bootloop :/
i attached the new demsg and logcat.
thank you for all the help!
amitshkuri said:
i tried now to reflashed and still bootloop :/
i attached the new demsg and logcat.
thank you for all the help!
Click to expand...
Click to collapse
Not a problem on the help. At least you bought an interesting problem to solve It's not your normal bootloop cause.
hmmm , It seems to have gone back to needs recovery.... Ok. Can you run the command from earlier but this time do not re-add the journal feature, so these commands
Code:
tune2fs -l /dev/block/mmcblk0p22 | grep features
e2fsck -f -y -v /dev/block/mmcblk0p22
tune2fs -O ^has_journal -c 1 -i 1d -m 0 /dev/block/mmcblk0p22
tune2fs -l /dev/block/mmcblk0p22 | grep features
#EDIT Mount as read only to mark it ready for mounting
mount -ro -text4 /dev/block/mmcblk0p22 /system
reboot
can you copy the output of these commands and post them up, I'm just curious to see what its runnning.
Do you know how to make your boot image insecure and how to mount /system with rw by default?
If not can you send me the boot image you're using an i'll fix it up.
The plan is to attempt the fs repair and remove journaling which from what I understand can be responsible for triggering the needs_recovery. should that not work, the kernel will try running recovery on the fs at boot time but this time it won't need to remount the /system partition because it will be already mounted as rw ... that's the theory at least.
If it fails send the logs and we'll have a look a some other options depending on the log out. But I wouldn't be worried there's still a couple of more things we can leverage to fixup the system partition.
Hey everyone,
It is possible to use an external Wi-Fi adapter with an android phone to run aircrack-ng, however I've had a lot of difficulties doing so. Here is a tutorial to make it easier for you.
The theory
Running the aircrack-ng suite itself is not much of a problem, as android is pretty much like ubuntu. The most difficult part of running aircrack is that the wifi chipsets of most phones do not support "monitor mode". This mode is required to capture any information from the air, not just the ones for your computer, and is therefore necessary for aircrack (airmon-ng). First of all, you should Google if your phone's wifi chipset supports this mode. If it does, find out how. If it doesn't, you can follow this guide and use a usb wifi stick.
Android is linux, and uses a linux kernel. The easiest way to get the driver for our WiFi adapter to work is to rebuild the android kernel with the driver built-in. We can then flash the new kernel to the phone, and copy the firmware binary. This tutorial uses CyanogenMod, because it is a well documented, open-source ROM. With some adjustments you can use the same method on other ROMs. If you do not have experience building a linux kernel, it is best to stick to this guide and use CyanogenMod.
What you'll need:
- Android phone
- Computer with Ubuntu (or other linux distribution)
- USB OTG Adapter (micro usb to usb female)
- Wireless USB Adapter
- Time and patience
I am using my Samsung Galaxy S4 GT-i9505 and an Eminent EM4454 Wireless USB adapter using the rt73 driver, but I am sure this will work with other devices.
A. Install your ROM and aircrack-ng, on your phone...
1) ...install Cyanogenmod. Don't delete the .zip download after installation.
2) ...install "Complete Linux Installer" from Google Play and download and unpack Ubuntu in /sdcard/ubuntu/ubuntu.img as stated in the app.
3) ...install the aircrack-ng suite in the chrooted ubuntu. On ubuntu 12.04, this cannot be done using apt-get:
sudo apt-get install build-essential libssl-dev nano
wget http://download.aircrack-ng.org/aircrack-ng-1.1.tar.gz
tar -xzvf aircrack-ng-1.1.tar.gz
cd aircrack-ng-1.1
nano common.mak
Then find CFLAGS ?= -g -W -Wall -Werror -O3 and remove -Werror.
make
sudo make install
B. Rebuild the kernel, in a terminal on linux on your computer...
1) ...install adb and fastboot
sudo apt-get install adb fastboot
2) Enable USB-debugging on your phone, connect to your computer and test the connection on linux on your computer:
adb get-state
3) Find the GitHub page for the cyanogenmod kernel for your device. You can find this page on cyanogenmod.org. Now download the kernel source and extract it into a folder.
4) Change working directory into the kernel
cd pathtothekernel
5) See if there is a .config file. In a CyanogenMod kernel, there probably isn't. Type:
nano .config
If you see an empty screen, we need to get your devices current configuration:
adb pull /proc/config.gz config.gz
zcat config.gz > .config
rm config.gz
4) Make the necessary changes in the configuration file to have your USB wireless driver built in. To do so:
make menuconfig
Use the enter key to expand an item in the menu, and the space bar to mark a module. Make sure you mark the necessary modules with a *, not an 'M', so they will be built-in. Most wireless drivers have the mac80211 driver as a dependency. Make sure you select that one with an asterix (*), too.
For example, for my rt73 based adapter, I did:
Networking Support > Wireless > [*] ... (mac80211)
Device Drivers > Network > Wireless LAB > [*] Ralink Drivers > [*] rt73usb
5) Make some changes to fight errors:
Still in menuconfig, make the following changes:
Kernel Hacking > (1024) Block? size > 1032
Now to tell gcc to build ignoring warnings edit the Makefile
nano Makefile
Now go down a few pages and add the line:
KCONFIG_CFLAGS += -w
6) The normal gcc C compiler cannot be used as it will build for your computers processor. We need to build for ARM-processors, called cross-compiling. To make the cross-compiling work you need the arm-eabi- toolchain.
cd ~/Downloads
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
The will download the ~120Mb toolchain.
7) Tell the Makefile where the toolchain is
cd pathtothekernel
export PATH=$PATH:~/Downloads/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
export ARCH=arm
8) Then build the kernel. It you get errors, don't be scared and Google them. One cause of weird errors is not having enough memory; add a swapfile and try again. The building of the kernel will take quite some time:
make
C. Flash the new kernel to the phone
1) When the build is finished, it has saved "zImage". This image is our kernel. For the sake of simplicity, let's copy it to the desktop but rename it so that later commands won't override it:
cp arch/arm/boot/zImage ~/Desktop/new-zImage
2) For flashing, we need to pack this zImage into a boot.img. Get the boot.img out of the ROM you now run on your phone. For example, the CyangonMod.zip you had to flash to your phone to install it, contains a boot.img. Most flashable .zip files have a boot.img in them. Copy this boot.img to your desktop, too.
3) Extract the boot.img
sudo apt-get install abootimg
abootimg -x boot.img
this will place 3 new files on your desktop.
4) Delete the extracted zImage and boot.img, as we want our self-compiled kernel.
rm zImage
rm boot.img
5) Edit the configuration file and remove the line with kernel-size, as our new kernel's size will be slightly larger.
nano bootimg.cfg
Remove the line beginning with bootsize:, which is probably the first line
5) Use abootimg to repack new-zImage and the 2 extracted files.
abootimg --create boot.img -f bootimg.cfg -k new-zImage -r initrd.img
6) Backup your phone in case anything goes wrong, and flash the boot.img. For many phones, this can be done using fastboot on linux. On my Galaxy, I had to use Mobile Odin: http://forum.xda-developers.com/showthread.php?t=1347899
D. Copy the firmware and run, on your phone...
1) ... start the chrooted ubuntu
2) ... insert your USB OTG and in that the Wireless USB Adapter
3) ... run airmon-ng and make sure your device is listed.
airmon-ng
If not, check that your kernel is flashed (under Settings > About Device > kernel it should say [email protected]) and that the correct drivers were selected with an asterix * (built-in, y) in make menuconfig. If it is listed, continue.
4) We now have the correct driver, but the firmware is likely missing. Download the .bin firmware that belongs to your driver. In my case, I had to download the rt73 driver from aircrack-ng website, and copy the .bin firmware file. Install ES File Manager or another root explorer, choose Root Explorer and then mount /system as Read/Write so that you can edit the contents. Now copy the firmware file to /system/etc/firmware/.
5) Run airmon-ng and check which interface your Wireless USB Adapter is.
airmon-ng
6) Start the monitor mode
airmon-ng start wlan1
Replace wlan1 with the interface name of the Wireless USB Adapter
7) If everything went right, it should say that monitor mode is enabled. You can now use
airodump-ng mon0
replacing mon0 with the monitor interface. If you get the error SIOCFLAGS: No such file or directory, the firmware file (e.g. *.bin) is not placed in the right directory (/system/etc/firmware and maybe a path extension, check the firmware README) or has the wrong name.
Congratulations, you have now got a phone running aircrack-ng!
I got this to work on my stock Samsung TouchWiz ROM by making a few adjustments:
- Get the kernel from Samsung: http://opensource.samsung.com/
- Change the lines in the .config file of the kernel below ## Samsung Rooting ... from =y to =n using nano
- To get boot.img, download the ...tar.md5 firmware matching your current firmware from http://www.sammobile.com/firmware/, rename .tar.md5 to .tar, and extract the boot.img. You cannot use mkbootimg here, only abootimg, as this boot.img has a special ramdisk address!
Thank you helped heaps. had been compiling as modules and couldnt insmod.
s4 i9505 stock rom - aircrack - tp-link tl-wn722n
Jesus, that was awesome. Couldn't find a better tutorial on the net!
Thanks again.
Btw, could you please upload the Galaxy S4 Cyanogen rom with the kernel?
I would appreciate alot.
Hey i have Htc desire C! I did the instal "bcmon.apk" but when I run the program turns out this message "cant run as root,'su' failed... why ??? please help me !
argentux said:
Hey everyone,
It is possible to use an external Wi-Fi adapter with an android phone to run aircrack-ng, however I've had a lot of difficulties doing so. Here is a tutorial to make it easier for you.
The theory
Running the aircrack-ng suite itself is not much of a problem, as android is pretty much like ubuntu. The most difficult part of running aircrack is that the wifi chipsets of most phones do not support "monitor mode". This mode is required to capture any information from the air, not just the ones for your computer, and is therefore necessary for aircrack (airmon-ng). First of all, you should Google if your phone's wifi chipset supports this mode. If it does, find out how. If it doesn't, you can follow this guide and use a usb wifi stick.
Android is linux, and uses a linux kernel. The easiest way to get the driver for our WiFi adapter to work is to rebuild the android kernel with the driver built-in. We can then flash the new kernel to the phone, and copy the firmware binary. This tutorial uses CyanogenMod, because it is a well documented, open-source ROM. With some adjustments you can use the same method on other ROMs. If you do not have experience building a linux kernel, it is best to stick to this guide and use CyanogenMod.
What you'll need:
- Android phone
- Computer with Ubuntu (or other linux distribution)
- USB OTG Adapter (micro usb to usb female)
- Wireless USB Adapter
- Time and patience
I am using my Samsung Galaxy S4 GT-i9505 and an Eminent EM4454 Wireless USB adapter using the rt73 driver, but I am sure this will work with other devices.
A. Install your ROM and aircrack-ng, on your phone...
1) ...install Cyanogenmod. Don't delete the .zip download after installation.
2) ...install "Complete Linux Installer" from Google Play and download and unpack Ubuntu in /sdcard/ubuntu/ubuntu.img as stated in the app.
3) ...install the aircrack-ng suite in the chrooted ubuntu. On ubuntu 12.04, this cannot be done using apt-get:
sudo apt-get install build-essential libssl-dev nano
wget http://download.aircrack-ng.org/aircrack-ng-1.1.tar.gz
tar -xzvf aircrack-ng-1.1.tar.gz
cd aircrack-ng-1.1
nano common.mak
Then find CFLAGS ?= -g -W -Wall -Werror -O3 and remove -Werror.
make
sudo make install
B. Rebuild the kernel, in a terminal on linux on your computer...
1) ...install adb and fastboot
sudo apt-get install adb fastboot
2) Enable USB-debugging on your phone, connect to your computer and test the connection on linux on your computer:
adb get-state
3) Find the GitHub page for the cyanogenmod kernel for your device. You can find this page on cyanogenmod.org. Now download the kernel source and extract it into a folder.
4) Change working directory into the kernel
cd pathtothekernel
5) See if there is a .config file. In a CyanogenMod kernel, there probably isn't. Type:
nano .config
If you see an empty screen, we need to get your devices current configuration:
adb pull /proc/config.gz config.gz
zcat config.gz > .config
rm config.gz
4) Make the necessary changes in the configuration file to have your USB wireless driver built in. To do so:
make menuconfig
Use the enter key to expand an item in the menu, and the space bar to mark a module. Make sure you mark the necessary modules with a *, not an 'M', so they will be built-in. Most wireless drivers have the mac80211 driver as a dependency. Make sure you select that one with an asterix (*), too.
For example, for my rt73 based adapter, I did:
Networking Support > Wireless > [*] ... (mac80211)
Device Drivers > Network > Wireless LAB > [*] Ralink Drivers > [*] rt73usb
5) Make some changes to fight errors:
Still in menuconfig, make the following changes:
Kernel Hacking > (1024) Block? size > 1032
Now to tell gcc to build ignoring warnings edit the Makefile
nano Makefile
Now go down a few pages and add the line:
KCONFIG_CFLAGS += -w
6) The normal gcc C compiler cannot be used as it will build for your computers processor. We need to build for ARM-processors, called cross-compiling. To make the cross-compiling work you need the arm-eabi- toolchain.
cd ~/Downloads
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
The will download the ~120Mb toolchain.
7) Tell the Makefile where the toolchain is
cd pathtothekernel
export PATH=$PATH:~/Downloads/arm-eabi-4.6/bin
export CROSS_COMPILE=arm-eabi-
export ARCH=arm
8) Then build the kernel. It you get errors, don't be scared and Google them. One cause of weird errors is not having enough memory; add a swapfile and try again. The building of the kernel will take quite some time:
make
C. Flash the new kernel to the phone
1) When the build is finished, it has saved "zImage". This image is our kernel. For the sake of simplicity, let's copy it to the desktop but rename it so that later commands won't override it:
cp arch/arm/boot/zImage ~/Desktop/new-zImage
2) For flashing, we need to pack this zImage into a boot.img. Get the boot.img out of the ROM you now run on your phone. For example, the CyangonMod.zip you had to flash to your phone to install it, contains a boot.img. Most flashable .zip files have a boot.img in them. Copy this boot.img to your desktop, too.
3) Extract the boot.img
sudo apt-get install abootimg
abootimg -x boot.img
this will place 3 new files on your desktop.
4) Delete the extracted zImage and boot.img, as we want our self-compiled kernel.
rm zImage
rm boot.img
5) Edit the configuration file and remove the line with kernel-size, as our new kernel's size will be slightly larger.
nano bootimg.cfg
Remove the line beginning with bootsize:, which is probably the first line
5) Use abootimg to repack new-zImage and the 2 extracted files.
abootimg --create boot.img -f bootimg.cfg -k new-zImage -r initrd.img
6) Backup your phone in case anything goes wrong, and flash the boot.img. For many phones, this can be done using fastboot on linux. On my Galaxy, I had to use Mobile Odin: http://forum.xda-developers.com/showthread.php?t=1347899
D. Copy the firmware and run, on your phone...
1) ... start the chrooted ubuntu
2) ... insert your USB OTG and in that the Wireless USB Adapter
3) ... run airmon-ng and make sure your device is listed.
airmon-ng
If not, check that your kernel is flashed (under Settings > About Device > kernel it should say [email protected]) and that the correct drivers were selected with an asterix * (built-in, y) in make menuconfig. If it is listed, continue.
4) We now have the correct driver, but the firmware is likely missing. Download the .bin firmware that belongs to your driver. In my case, I had to download the rt73 driver from aircrack-ng website, and copy the .bin firmware file. Install ES File Manager or another root explorer, choose Root Explorer and then mount /system as Read/Write so that you can edit the contents. Now copy the firmware file to /system/etc/firmware/.
5) Run airmon-ng and check which interface your Wireless USB Adapter is.
airmon-ng
6) Start the monitor mode
airmon-ng start wlan1
Replace wlan1 with the interface name of the Wireless USB Adapter
7) If everything went right, it should say that monitor mode is enabled. You can now use
airodump-ng mon0
replacing mon0 with the monitor interface. If you get the error SIOCFLAGS: No such file or directory, the firmware file (e.g. *.bin) is not placed in the right directory (/system/etc/firmware and maybe a path extension, check the firmware README) or has the wrong name.
Congratulations, you have now got a phone running aircrack-ng!
I got this to work on my stock Samsung TouchWiz ROM by making a few adjustments:
- Get the kernel from Samsung: http://opensource.samsung.com/
- Change the lines in the .config file of the kernel below ## Samsung Rooting ... from =y to =n using nano
- To get boot.img, download the ...tar.md5 firmware matching your current firmware from http://www.sammobile.com/firmware/, rename .tar.md5 to .tar, and extract the boot.img. You cannot use mkbootimg here, only abootimg, as this boot.img has a special ramdisk address!
Click to expand...
Click to collapse
Thats insane that it can actually run aircrack, especially considering i had a hard time just running linux on it.
yoshihat said:
Thats insane that it can actually run aircrack, especially considering i had a hard time just running linux on it.
Click to expand...
Click to collapse
How is that so? For me it wasn't complicated at all.
I did everything and got everything ready, up to
Code:
make menuconfig
And it gives me error 2. And then it says something about there not being a variable.
:/
Please help?
I am actually having a time trying to make it work. I did everything right, then I sucessfully build the boot.img, but when I flash it through Mobile Odin as "Kernel" and the Cyanogenmod loads, the screen is all screwed up, like the SystemUI has crashed + interference signal effect, its unusable. Then I restore it through TWRP back to normal.
Do you know what may be the problem? Im using the 10.1.3 JFLTEXX CyanogenMod Build. (For the i9505.)
Edit: Nevermind, was compiling the M build against the Stable one. Obvious error. It works 100% now, thanks!
GruberEXN said:
I am actually having a time trying to make it work. I did everything right, then I sucessfully build the boot.img, but when I flash it through Mobile Odin as "Kernel" and the Cyanogenmod loads, the screen is all screwed up, like the SystemUI has crashed + interference signal effect, its unusable. Then I restore it through TWRP back to normal.
Do you know what may be the problem? Im using the 10.1.3 JFLTEXX CyanogenMod Build. (For the i9505.)
Edit: Nevermind, was compiling the M build against the Stable one. Obvious error. It works 100% now, thanks!
Click to expand...
Click to collapse
Could you please send the edited working kernel with the modules/drivers built in that you installed? (Please, like a link or something?)
androidiphonehacker said:
Could you please send the edited working kernel with the modules/drivers built in that you installed? (Please, like a link or something?)
Click to expand...
Click to collapse
Ok! I built the RTL8187/8187b driver, do you have that one? (Alfa wireless chipsets often use those ones.)
Edited for unknown reasons!
I have a TP-Link TL-wn722n USB wireless adapter. I'm kind of a noob at kernel building, and I'm not sure what driver/module it uses. Soooo... Could you build it for me please please pleaaaase? xD
I have (that USB adapter), and the newest CyanogenMod ROM for model SGS-i9505.
Tell you what: I'll pay you if you build it.
Sent from my GT-I9505 using Tapatalk
androidiphonehacker said:
I have a TP-Link TL-wn722n USB wireless adapter. I'm kind of a noob at kernel building, and I'm not sure what driver/module it uses. Soooo... Could you build it for me please please pleaaaase? xD
I have (that USB adapter), and the newest CyanogenMod ROM for model SGS-i9505.
Tell you what: I'll pay you if you build it.
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
Add'd your skype.
Building a kernel requires some troubleshooting, so prepare your device with TWRP or any recovery menu. (A nandroid backup would be nice too.)
And I don't mind a donation, although I don't want a payment. Maybe a cheap game would do the work after one day of troubleshooting your new kernel
Hello everyone....
i have a few little update form my side...
But first, my englisch is not the best, i'm sorry for it ^^
1. The is Important for every one how work at the end with aircrack... Then you need to get to patch the mac80211 data (channel-negative-one-maxim.patch and mac80211.compat08082009.wl_frag+ack_v1.patch from aircrack), otherwise you get at the end a fixed channel -1 problem in aircrack.... of which more later
Here now My litte Upgrade to build a another Kernel because CM10... For this session I use the Kernel form Yank555.lu on JB 4.1.2!
First you need to get the Kernel von GitHub. "github /yank555-lu/SGS3-JB/archive/Update11.zip"
After you extracte the kernel into your Kernel-Folder go in it.
cd ../path/to/kernel
########## 1. You need to edit the Makefile to beware for compile errors. ##########
nano Makefile
Search at the line 571:
-- KBUILD_CFLAGS += -fdiagnostics-show-option -Werror \
++ KBUILD_CFLAGS += -fdiagnostics-show-option \
Search at line 373:
-- -mcpu=cortex-a9 -mfpu=neon -mtune=cortex-a9 -fno-pic \
-- -munaligned-access
++ -mtune=cortex-a9
Now go to line 693:
++ #
++ # Edit by Mastaaa
++ #
++ KCONFIG_CFLAGS += -w
Save the file and Close it....
################ 2. Download and Patch the Wireless Patches. ################
For the negative-channel fix you need to get the Patches.
wget patches.aircrack-ng.org/mac80211.compat08082009.wl_frag+ack_v1.patch &&
wget patches.aircrack-ng.org/channel-negative-one-maxim.patch
Now patch it...
patch ./net/mac80211/tx.c mac80211.compat08082009.wl_frag+ack_v1.patch &&
patch ./net/wireless/chan.c channel-negative-one-maxim.patch
################### 3. make .config and edit menuconfig. ####################
Ceate a Basic .config File with:
make Yank555.lu_v3.x_series_defconfig
Now Edit the Menuconfig:
make menuconfig
Here the Basic edit's (i think) you get to need:
1. Edit the Kernel Info (to what you want...):
General setup --->
(...) Local version - append to kernel release (Hit Enter to edit this...)#
2. Turn On the mac80211 driver:
[*] Networking support ---->
-*- Wireless ---->
< > Generic IEEE 802.11 Networking Stack (Mark to <*>)
[ ] Enable mac80211 mesh networking (pre-802.11s) support (Mark to [ * ]
3, Mark the additional usb drivers:
Device Drivers ---->
.....[*] Network device support ---->
..........[*] Wireless LAN ---->
...............(Mark <m> or <*> waht you need.... Here a few examples
...............<*> Atmel at76c503/at76c505/at76c505a USB cards
...............<*> Realtek 8187 and 8187B USB support
...............<*> Atheros Wireless Cards ----->
...............<*> Ralink driver support ----->
....................<*> Ralink rt2500 (USB) support
....................<*> Ralink rt2501/rt73 (USB) support
....................<*> Ralink rt27xx/rt28xx/rt30xx (USB) support
....................[ * ] rt2800usb - Include support for rt33xx devices
....................[ * ] rt2800usb - Include support for rt35xx devices (EXPERIMENTAL)
....................[ * ] rt2800usb - Include support for rt53xx devices (EXPERIMENTAL)
....................[ * ] rt2800usb - Include support for unknown (USB) devices
4. Mark the OTG support on !:
Device Drivers ---->
.....[*] USB support ---->
..........[ ] OTG support ............................................................(Mark it to [*])
..........< > Enable Wireless USB extensions (EXPERIMENTAL) ..(Makr it to <*>)
5. Make Kernel hacking:
Kernel hacking ---->
.....(1024) Warn for stack frames larger than (needs gcc 4.4) (Edit this to 1032)
######################### 4. compile the Kernel. ###########################
make ARCH=arm CROSS_COMPILE=$CCOMPILER -j6
(with make -i ... you can ignor errors, but i think thats not good ^^)
########################## 5. make ramdisk.gz. ###########################
mkdir ramdisk-new
cp -ax ramdisk ./ramdisk-new
#clear git repositories in ramfs
find ramdisk-new -name .git -exec rm -rf {} \;
#remove empty directory placeholders
find ramdisk-new -name EMPTY_DIRECTORY -exec rm -rf {} \;
rm -rf ramdisk-new/tmp/*
#remove mercurial repository
rm -rf ramdisk-new/.hg
#copy modules into ramfs
mkdir -p ramdisk-new/lib/modules
find -name '*.ko' -exec cp -av {} ramdisk-new/lib/modules/
#make ramdisk.gz
mkbootfs ./ramdisk-new | gzip > ramdisk.gz
########################### 6. make boot.img. ############################
./mkbootimg --kernel arch/arm/boot/zImage --ramdisk ramdisk.gz --board smdk4x12 --base 0x10000000 --pagesize 2048 --ramdiskaddr 0x11000000 -o boot.img
################ 7. make modules.tgz for your chroot Linux. ###################
tar -czf modules.tgz `find . | grep ko$`
(... This modules.tgz you have to copy to sdcard0,
then go into chrootet (after you have flashed the new Kernel!) Linux and make: )
cd /lib/modules
mkdir `uname -r`
cd *
tar -zxf /sdcard0/modules.tgz
depmod -a
now turn the usb-wlan on S3 and make:
modprobe <your-driver>
example:
modprobe rt73usb
Now your Wifi-USB must be Online...
Soooo that was it from my self...
(For any Questions, you have. I'm on my Position...
Bye bye,
Master X
Please help me I have got HTC one mini on stock . Is it possible...?
Yes i think so...
In the theory at android 2.3 its possible to compile it with rt73usb extentials...
I'll do the kernel for i9500, but I'm afraid to damage the phone the wrong make.
If one makes the kernel for i9500 you Could you share?
yes, I did. and running rlt8187 alfa wifi on ubuntu.but wps not work. Everything other than these problems well
Probably, to add to another something and there are ( in kernel)
GT-I9500 cihazımdan Tapatalk kullanılarak gönderildi
LG G2 802 International Version
Can someone create a Kernel for This Device? Please?
With RTL 8187 Support
Would pay for it.
I added usb adapter device support to kernel successfully but then my wifi stopped working here is the dmesg of turning wifi on
Code:
<4>[ 2273.866333] wlan: disagrees about version of symbol cfg80211_ready_on_channel
<4>[ 2273.866455] wlan: Unknown symbol cfg80211_ready_on_channel (err -22)
<4>[ 2273.866729] wlan: disagrees about version of symbol __ieee80211_get_channel
<4>[ 2273.866821] wlan: Unknown symbol __ieee80211_get_channel (err -22)
<4>[ 2273.867065] wlan: disagrees about version of symbol cfg80211_cqm_rssi_notify
<4>[ 2273.867187] wlan: Unknown symbol cfg80211_cqm_rssi_notify (err -22)
<4>[ 2273.867370] wlan: disagrees about version of symbol cfg80211_roamed
<4>[ 2273.867523] wlan: Unknown symbol cfg80211_roamed (err -22)
<4>[ 2273.867614] wlan: disagrees about version of symbol cfg80211_pmksa_candidate_notify
<4>[ 2273.867736] wlan: Unknown symbol cfg80211_pmksa_candidate_notify (err -22)
<4>[ 2273.867858] wlan: disagrees about version of symbol wiphy_register
<4>[ 2273.868011] wlan: Unknown symbol wiphy_register (err -22)
<4>[ 2273.868133] wlan: disagrees about version of symbol cfg80211_disconnected
<4>[ 2273.868286] wlan: Unknown symbol cfg80211_disconnected (err -22)
<4>[ 2273.868499] wlan: disagrees about version of symbol cfg80211_new_sta
<4>[ 2273.868591] wlan: Unknown symbol cfg80211_new_sta (err -22)
<4>[ 2273.868774] wlan: disagrees about version of symbol cfg80211_tdls_oper_request
<4>[ 2273.868865] wlan: Unknown symbol cfg80211_tdls_oper_request (err -22)
<4>[ 2273.869018] wlan: disagrees about version of symbol cfg80211_connect_result
<4>[ 2273.869171] wlan: Unknown symbol cfg80211_connect_result (err -22)
<4>[ 2273.869262] wlan: disagrees about version of symbol cfg80211_inform_bss_frame
<4>[ 2273.869415] wlan: Unknown symbol cfg80211_inform_bss_frame (err -22)
<4>[ 2273.869506] wlan: disagrees about version of symbol wiphy_new
<4>[ 2273.869659] wlan: Unknown symbol wiphy_new (err -22)
<4>[ 2273.869781] wlan: disagrees about version of symbol cfg80211_rx_mgmt
<4>[ 2273.869903] wlan: Unknown symbol cfg80211_rx_mgmt (err -22)
<4>[ 2273.870117] wlan: disagrees about version of symbol cfg80211_send_unprot_deauth
<4>[ 2273.870239] wlan: Unknown symbol cfg80211_send_unprot_deauth (err -22)
<4>[ 2273.870361] wlan: disagrees about version of symbol cfg80211_mgmt_tx_status
<4>[ 2273.870513] wlan: Unknown symbol cfg80211_mgmt_tx_status (err -22)
<4>[ 2273.870727] wlan: disagrees about version of symbol cfg80211_inform_bss
<4>[ 2273.870819] wlan: Unknown symbol cfg80211_inform_bss (err -22)
<4>[ 2273.871002] wlan: disagrees about version of symbol wireless_send_event
<4>[ 2273.871093] wlan: Unknown symbol wireless_send_event (err -22)
<4>[ 2273.871246] wlan: disagrees about version of symbol wiphy_free
<4>[ 2273.871337] wlan: Unknown symbol wiphy_free (err -22)
<4>[ 2273.871520] wlan: disagrees about version of symbol cfg80211_scan_done
<4>[ 2273.871612] wlan: Unknown symbol cfg80211_scan_done (err -22)
<4>[ 2273.871795] wlan: disagrees about version of symbol regulatory_hint
<4>[ 2273.871856] wlan: Unknown symbol regulatory_hint (err -22)
<4>[ 2273.872039] wlan: disagrees about version of symbol cfg80211_get_bss
<4>[ 2273.872100] wlan: Unknown symbol cfg80211_get_bss (err -22)
<4>[ 2273.872283] wlan: disagrees about version of symbol cfg80211_michael_mic_failure
<4>[ 2273.872436] wlan: Unknown symbol cfg80211_michael_mic_failure (err -22)
<4>[ 2273.872528] wlan: disagrees about version of symbol cfg80211_ibss_joined
<4>[ 2273.872680] wlan: Unknown symbol cfg80211_ibss_joined (err -22)
<4>[ 2273.872833] wlan: disagrees about version of symbol cfg80211_del_sta
<4>[ 2273.872985] wlan: Unknown symbol cfg80211_del_sta (err -22)
<4>[ 2273.880584] wlan: disagrees about version of symbol cfg80211_remain_on_channel_expired
<4>[ 2273.880737] wlan: Unknown symbol cfg80211_remain_on_channel_expired (err -22)
<4>[ 2273.880889] wlan: disagrees about version of symbol wiphy_unregister
<4>[ 2273.880950] wlan: Unknown symbol wiphy_unregister (err -22)
<6>[ 2277.103332] SLIM_CL: skip reconfig sequence
<6>[ 2336.262878] SLIM_CL: skip reconfig sequence
<6>[ 2341.206115] SLIM_CL: skip reconfig sequence
<3>[ 2372.867187] init: untracked pid 7791 exited
<6>[ 2375.211242] SLIM_CL: skip reconfig sequence
<6>[ 2378.713043] SLIM_CL: skip reconfig sequence
<6>[ 2385.924896] check_recover_vbus_collapse: VBUS input current still limiting to 700 mA. Retry set
<6>[ 2397.413330] SLIM_CL: skip reconfig sequence
<4>[ 2464.730682] set_usb_max_current: setting current max to 1500
<4>[ 2544.752166] set_usb_max_current: setting current max to 1500
<4>[ 2604.769744] set_usb_max_current: setting current max to 1500
<4>[ 2674.810363] set_usb_max_current: setting current max to 1500
<6>[ 2686.035491] SLIM_CL: skip reconfig sequence
<3>[ 2690.290008] qup_i2c qup_i2c.0: QUP: I2C status flags :0x1300c8, irq:226
<3>[ 2690.290191] qup_i2c qup_i2c.0: I2C slave addr:0x28 not connected
<3>[ 2690.300445] pn544 0-0028: pn544_dev_write: i2c write err -107, but retry 1
<3>[ 2691.778778] qup_i2c qup_i2c.0: QUP: I2C status flags :0x1343c8, irq:226
<3>[ 2691.778961] qup_i2c qup_i2c.0: I2C slave addr:0x28 not connected
<3>[ 2691.789093] pn544 0-0028: pn544_dev_write: i2c write err -107, but retry 1
<6>[ 2694.949035] SLIM_CL: skip reconfig sequence
<4>[ 2714.834625] set_usb_max_current: setting current max to 1500
<6>[ 2715.883575] SLIM_CL: skip reconfig sequence
<6>[ 2843.803405] SLIM_CL: skip reconfig sequence
<6>[ 2854.273345] SLIM_CL: skip reconfig sequence
<6>[ 2955.025512] msm_otg msm_otg: USB exited from low power mode
<6>[ 2955.026306] msm_otg msm_otg: b_idle work, inputs=0x00000001
<6>[ 2955.026580] msm_otg msm_otg: Avail curr from USB = 0
<6>[ 2955.026885] msm_otg msm_otg: phy_reset: success
<6>[ 2955.136352] msm_otg msm_otg: USB in low power mode
<6>[ 2969.677581] msm_otg msm_otg: USB exited from low power mode
<6>[ 2969.678131] msm_otg msm_otg: b_idle work, inputs=0x00000003
<6>[ 2969.853424] msm_otg msm_otg: chg_type = USB_SDP_CHARGER
<6>[ 2969.853576] msm_otg msm_otg: b_idle work, inputs=0x00000003
<6>[ 2969.859283] msm_hsusb msm_hsusb: vbus online
<6>[ 2969.859436] msm_hsusb msm_hsusb: CI13XXX_CONTROLLER_RESET_EVENT received
<6>[ 2969.859558] msm_otg msm_otg: changed to b_peripheral, from b_idle
<6>[ 2970.140228] msm_hsusb msm_hsusb: reset
<6>[ 2970.140686] android_work: android_work: did not send uevent (0 0 (null))
<6>[ 2970.178863] android_work: android_work: sent uevent USB_STATE=CONNECTED
<6>[ 2970.182403] msm_hsusb msm_hsusb: reset
<6>[ 2970.182891] android_work: android_work: sent uevent USB_STATE=DISCONNECTED
<6>[ 2970.261993] android_work: android_work: sent uevent USB_STATE=CONNECTED
<6>[ 2971.677764] android_usb gadget: high-speed config #1: android_usb
<6>[ 2971.677917] msm_otg msm_otg: Avail curr from USB = 500
<6>[ 2971.733306] android_work: android_work: sent uevent USB_STATE=CONFIGURED
<6>[ 2971.880920] mtp_open
<6>[ 2974.863128] msm_ta_detect_work: USB exit ta detection - frindex
<3>[ 3000.568115] init: untracked pid 8878 exited
<3>[ 3003.624877] init: untracked pid 8948 exited
<6>[ 3005.894012] SLIM_CL: skip reconfig sequence
I think problem occurs when I enable "cfg80211 wireless extensions compatibility" but unless enabling it i cannot see the wifi adapter in airmon-ng
if CONFIG_CFG80211_WEXT=y = inner WLAN wont work
if CONFIG_CFG80211_WEXT=n = usb wifi adapter wont work with aircrack, reaver
getprop
[wifi.interface]: [wlan0]
[wlan.driver.ath]: [0]
[wlan.driver.config]: [/data/misc/wifi/WCNSS_qcom_cfg.ini]
[wlan.driver.status]: [unloaded]
logcat:
I/WifiManager(16050): Process ndroid.settings enabled Wifi
D/WifiService( 779): setWifiEnabled: true pid=16050, uid=1000
E/WifiStateMachine( 779): Failed to load driver!
E/WifiStateMachine( 779): DriverFailedState
here are documentations about it but they are too complex for me :
https://community.freescale.com/docs/DOC-93603
http://blog.linuxconsulting.ro/2010/04/porting-wifi-drivers-to-android.html
as fas as I understand from what I read I should recompile wlan.ko after building new kernel but i dont know how
can't find any help
I just successfully built a kernel with my phone over nfs (wifi). I used gcc-armhf or rather to be specific, when it complained I set 'CROSS_COMPILER=/usr/bin/', cleaned, and retried. Everything seems to have went fine, and as expected I have the zImage in arch/arm/boot and the modules are scattered around, but theres a list on stdout I can use to copy them somewhere.
1.) Which kernel object files do I need?
2.) I will look at the device/samsung/d2spr/extract-files.sh file to see where I should put them, but where should I put the ones that may have been created from the config changes and are not listed?
My first couple of trys failed due to the kernel being too large, so I changed some things to modules that I think can wait to load or set up an init script. I also didn't use mkbootimg, I used abootimg, that may have been why, not too sure. I used unmkbootimg and saved the stdout to a file this time and built the kernel on my phone, still, those are some questions I still have.
Edit: Another way to ask this question...
3.) Do I need to replace the 'blobs' that I got from the official CM ROM with the ones I just built?
4.) Do the modules I built contain the proprietary code to run the hardware, or where some (wifi driver for instance) 'filled' in with 'dummy code'?
Note: The zImage built was 3699216 bytes or about 3.6 MB. The zImage I need to replace is "Kernel size 3907440" or roughly 3.9MB, things are looking good, for once! :highfive:
Just use a script to find and copy all of them
Code:
find . -iname '*.ko' -exec cp {} MODULES_OUTPUT_FOLDER_HERE \;
Run from the root folder of your kernel source
Kernel modules go in the system/lib/modules folder
They contain code to assist the kernel, it's not so much proprietary blobs like pulling libs from stock to get AOSP working but they are device and kernel specific. The entire source for each module is there...so it's not proprietary or else someone would get sued
And no, they don't get filled in with dummy code, they get built with drivers that have been adapted for the specific board and then for the specific phone model and kernel code. Modules add in what the kernel leaves out...the kernel might say "initialize wifi chip, load driver and then connect", but the main code with all the specifics of how to do that is actually stored in the wifi module (dhd.ko)
CNexus said:
Just use a script to find and copy all of them
Code:
find . -iname '*.ko' -exec cp {} MODULES_OUTPUT_FOLDER_HERE \;
Run from the root folder of your kernel source
Kernel modules go in the system/lib/modules folder
They contain code to assist the kernel, it's not so much proprietary blobs like pulling libs from stock to get AOSP working but they are device and kernel specific. The entire source for each module is there...so it's not proprietary or else someone would get sued
And no, they don't get filled in with dummy code, they get built with drivers that have been adapted for the specific board and then for the specific phone model and kernel code. Modules add in what the kernel leaves out...the kernel might say "initialize wifi chip, load driver and then connect", but the main code with all the specifics of how to do that is actually stored in the wifi module (dhd.ko)
Click to expand...
Click to collapse
Well, I hope all is not lost.
I took my last working zip I built and used an archive manager to crack it open, I replaced the zImage with the one I built on my phone. Then I replaced all .ko files that where built in system/lib/modules and closed the archive. I flashed it to my phone and installed it, now I am stuck in aboot loop and can't get to recovery.
What should I do? Can I fix it with Oden or something? That is what I used to originally root it.
Scratch that, I pulled the battery and pushed the buttons more cautiously (nervous shakes), in recovery.
What do ya think it coulda been?
I disabled paranoid networking, removed CIFS, and changed NFS to Modules instead of built-ins.
Edit: I'll try cross compiling on my lap-top, maybe had to do with the toolchain and arm abei(sp?), maybe wifi nfs is unreliable in witing to the disk?
Maybe if I use the original .ko files that I pulled from the device as per the CM extract-files.sh script, and just add the new kernel and new modules that didn't already exit?
I'll have to brute this out and hope I don't brick my phone in the process.
Kernels won't brick your phone unless it overclocks to the point where it's melting, otherwise you're good
What it sounds like is something went wrong and you had a kernel panic...or maybe the kernel didn't load at all
Check /proc/last_kmsg to see if it loaded at all
CNexus said:
Kernels won't brick your phone unless it overclocks to the point where it's melting, otherwise you're good
What it sounds like is something went wrong and you had a kernel panic...or maybe the kernel didn't load at all
Check /proc/last_kmsg to see if it loaded at all
Click to expand...
Click to collapse
My bad, as soon as I got into recovery I flashed a known working zip.
I am going to keep trying to build a custom kernel but I would like to figure out how to configure it within my source tree and let it get compiled with a rom.
but here is a cat of /proc/last_kmsg just incase it survived.
Code:
[ 0.000000] Truncating memory at 0xc0000000 to fit in 32-bit physical address space
[ 0.000000] smem_find(137, 80): wrong size 72
[ 0.023561] AXI: msm_bus_fabric_init_driver(): msm_bus_fabric_init_driver
[ 0.056035] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056035] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056065] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056065] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056065] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056096] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056096] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.056096] msm_rpm_get_status(): Status id 433 not defined for target
[ 0.076056] msm_gpiomux_install: write failure: -14
[ 0.076056] msm_gpiomux_install: write failure: -14
[ 0.076056] msm_gpiomux_install: write failure: -14
[ 0.076087] msm_gpiomux_install: write failure: -14
[ 0.125194] [msm8960_init_cam:1572]setting done!!
[ 0.177262] i2c i2c-14: Invalid 7-bit I2C address 0x00
[ 0.177384] i2c i2c-14: Can't create device at 0x00
[ 0.177872] i2c i2c-19: Failed to register i2c client cmc624 at 0x38 (-16)
[ 0.177964] i2c i2c-19: Can't create device at 0x38
[ 0.178483] Error-Bad Function Input
[ 0.179185] max8952 19-0060: DVS modes disabled because VID0 and VID1 do not have proper controls.
[ 0.407630] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: scm_pas
[ 0.418953] smd_channel_probe_worker: allocation table not initialized
[ 0.429757] msm_ipc_router_init: Unable to create IPC logging for IPC RTR
[ 0.430581] msm_ipc_router_ipc_log_init: Unable to create IPC logging for Req/Resp
[ 0.430856] msm_ipc_router_ipc_log_init: Unable to create IPC logging for Indications
[ 0.437082] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: acpuclk-8960
[ 0.473950] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: dtv
[ 0.477857] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: mdp
[ 0.491316] pm_runtime: fail to wake up
[ 0.991881] hdmi_msm hdmi_msm.1: external_common_state_create: sysfs group eeb42a08
[ 0.993804] Inside writeback_driver_init
[ 0.994353] Inside writeback_probe
[ 1.534289] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: rotator
[ 1.548023] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: grp3d
[ 1.558583] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: grp2d0
[ 1.568686] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: grp2d1
[ 1.602289] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: qsee
[ 1.789500] cm36651_setup_reg: initial proximity value = 0
[ 1.910697] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: usb
[ 1.930016] mms_ts 3-0048: [TSP] ISC Ver [0xbd] [0x22] [0x22]
[ 1.934777] mms_ts 3-0048: [TSP] fw is latest. Do not update.
[ 1.947077] [__s5c73m3_probe:3868] S5C73M3 probe
[ 1.950862] [s5c73m3_sensor_probe_cb:3843] Entered
[ 1.955562] [s5c73m3_i2c_probe:3725] Entered
[ 1.959896] [s5c73m3_init_client:3424] Entered
[ 1.965359] [s5c73m3_i2c_probe:3745] Exit
[ 1.968655] [s5c73m3_sensor_probe:3776] Entered
[ 1.973081] [s5c73m3_spi_init:226] Entered
[ 1.977170] [s5c73m3_spi_probe:191] Entered
[ 1.981321] [s5c73m3_spi_probe:201] s5c73m3_spi successfully probed
[ 1.987669] [s5c73m3_sensor_probe : 3799] Probe_done!!
[ 2.042698] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: msm_sdcc
[ 2.049076] couldn't get usb power supply
[ 2.057530] mmc0: No card detect facilities available
[ 2.064153] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: msm_sdcc
[ 2.081245] AXI: msm_bus_scale_register_client(): msm_bus_scale_register_client: name: msm_sdcc
[ 2.093575] aat1290a_led_probe : Probe
[ 2.378849] bam_dmux_init : unable to create IPC Logging Context
[ 2.419594] cypress_touchkey 16-0020: Touchkey FW Version: 0x06
[ 2.534594] init: invalid uid 'fm_radio'
[ 2.950068] enable_store: android_usb: already disabled
[ 2.954768] init: Unable to open persistent property directory /data/property errno: 2
[ 87.924614] SysRq : Emergency Remount R/O
[ 88.153181] Restarting system.
No errors detected
Maybe disabling Android's Paranoid Networking breaks other things?
If this wont work, maybe I will try writing a post installation script for apt-get and try to get Android to recognize the new packages nd define some permission for that .xml file I know is hiding somewhere. I might have to create a database of permissions required for all the packages in the repos (that would suck). But really, if I could just get basic Linux filesystem permissions I wouldn't need to do all of that. That whole, "only allow certain groups to create sockets" option is pulling the chair out from under me. I'll have to study the source for the filesystem a little deeper, maybe I can disable it (or at least allow root) from the source without taking it out of the kernel config.
For instance, postgresql needs to open a socket and bind to a port, it tries ipv4 an ipv6 AF_INET and AF_INET6, and this paranoid feature will check the processes gid as well as other permissions I think to see if it can. So I tried setting the gid bit to run /etc/init.d/postrgresql as gid AID_INET but it still fails, probably because the file is not listed in that .xml file I mentioned earlier. I think a post installation script might work best if I can't turn the feature off or fix it to be more permissive.
I think the packing have some issue.. Go into my github check moto_tool their u can see unpack repack txt file open it. Change the value as per you phone and you are done