Hi !
My note is running CleaNoteV6 (LRQ) with XXLRK model and kernel.
I recently wanted to use my GPS and after activating the GPS in the drop-down menu, I started a GPS app like Gmaps or Waze or even GPS Test, the GPS icon is not showing in the status bar and I obviously can't get a single satellite signal nor a fix.
I tried GPS after flashing the rom and it was working at this time.
I have tried to reflash modem, different kernels and a dalvik cache wipe. Nothing worked!
Any suggtestions ?
Thanks!
For me, I will reinstall the rom and take only 20 min with clean install
simplelife said:
For me, I will reinstall the rom and take only 20 min with clean install
Click to expand...
Click to collapse
I think it wouyld take more than this with all the apps I have
I keep this option as a final solution, but I actually was waiting for JB to perform a full wipe / clean install.
Thank U for answering !
sibere said:
I think it wouyld take more than this with all the apps I have
I keep this option as a final solution, but I actually was waiting for JB to perform a full wipe / clean install.
Thank U for answering !
Click to expand...
Click to collapse
Since you know what to do and ready try everything ( changed modem, kennel...etc) that why I come up with final solution ( clean install rom)...hihi
Flashing kernels and cache/dalvik wipes sometimes doesn't fix the problem. What fixes most problems is to flash stock GB. Do a full wipe. See if that gps works. Then start over.
This seems time consuming considering the number of apps you have but it may be quicker than finding an "easy" fix. You can go on with this problem for days. On the other hand you can be done in a day if you do the "final" solution.
ginopunsalan said:
Flashing kernels and cache/dalvik wipes sometimes doesn't fix the problem. What fixes most problems is to flash stock GB. Do a full wipe. See if that gps works. Then start over.
This seems time consuming considering the number of apps you have but it may be quicker than finding an "easy" fix. You can go on with this problem for days. On the other hand you can be done in a day if you do the "final" solution.
Click to expand...
Click to collapse
Yep seems a good idea. I'll try to flash rom again with a wipe and if it's still dead I'll flash GB and then ICS again. What a pain in the *ss !
Found the solution!
I finally found the solution to this issue!
After rebooting, I decided to have a look at the logcat before flashing/wiping.
I found issues with two pipes used by GPSD in /data/gps
These are the WRONG files (pipes) that gpsd couldn't open:
Code:
[email protected]:/data/gps # ls -la
ls -la
drwxrwx--x 2 system system 4096 Oct 23 13:24 .
drwxrwx--x 28 system system 4096 Oct 23 14:13 ..
prw-rw---- 1 gps system 0 Oct 18 01:27 .gps.interface.pipe.to_gpsd
-rwxrwx--x 2 app_139 app_139 6786 Oct 18 16:28 .gps.interface.pipe.to_jni
I deleted those files, rebooted the phone one more time, and voilà ! I've got my little GPS icon flashing again in the notification bar!
So if this appends to you, turn off GPS, go to /data/gps , delete any .gps* file you can find there, reboot and you'll get your GPS back to life. gpds is creating the files when you turn on any GPS app.
These have the right system rights.
Code:
[email protected]:/data/gps # ls -la
ls -la
drwxrwx--x 2 system system 4096 Oct 23 14:24 .
drwxrwx--x 28 system system 4096 Oct 23 14:23 ..
prw-rw---- 1 gps system 0 Oct 23 14:25 .gps.interface.pipe.to_gpsd
prw-rw---- 1 gps system 0 Oct 23 14:25 .gps.interface.pipe.to_jni
XDA AND I WE DO NOT MAKE RESPONSABLE OF ANY DAMAGE SUFFER
Hi i need help form others for making a good cm12.1 rom and future cm13 rom here i put the TODO and the progress, will be post all source code as things progress...
TODO:
Add recovery usb sticks support
Add support to f2fs
Kernel optimizate make compatible with GGC 5.1( lets see if we can)
Fix all bugs
Compile without any error
Make ZIP pakage I never fixed it need help
Test build and look for errors
Progress:
LZMA compression in kernel
LANG=C brunch ouya best command for building it
Add f2fs to rom not to kernel
Fix bluetooth erros building rom
Used arm-eabi 4.7 for compiling kernel if not you will get errors
Fix kernel error with this commit https://github.com/Dazzozo/huawei-kernel-3.4/commit/158c9bf883a203530b2f558be1b3cd168fc3d202
Fit New Recovery in /recovery partition
DOWNLOAD:
ALPHA: http://www.mediafire.com/download/o9yqmdvuygoip3g/cm-12-20151024-UNOFFICIAL-ouya.zip (untested)
Source code:
Kernel: https://github.com/werty100/android_kernel_boxer8_ouya
Tree: https://github.com/werty100/android_device_boxer8_ouya
Vendor: https://github.com/werty100/android_vendor_boxer8_ouya
I for one am thankful for your hardwork if you get this working. I still use my Ouya daily strictly for xbmc and cm12/13 would bring much needed new life to it.
I have fixed recovery, it works but it doesnt have the option usbdisk for mounting USBs so need more work on it
Here i give to you recovery for people to test it i need tester i am busy...
So do I just follow the old CM tutorials and install this instead at the recovery step?
bb_chazz said:
So do I just follow the old CM tutorials and install this instead at the recovery step?
Click to expand...
Click to collapse
It is a experimental recovery and need to be config for mounting usbs so now not use it unless you want to test it and report back experience and bugs,
Also the build posted it doesnt boot at all , i am keep working when i have time for it. I think a new build will come this weekend
I was going to just test but if you want to work on it a little more first just let me know and I will test when ready.
Starting new build with a few changes i want this build to boot up in a few hours i will post resoults and upload source code
Looking forward for this!
Wow, I just fired up my Ouya for the first time in a while today and figured I would see if anyone has done anything recently. Glad to see this little box isn't completely dead!
Any chance of some compile instructions?
Bussy
werty100 said:
Starting new build with a few changes i want this build to boot up in a few hours i will post resoults and upload source code
Click to expand...
Click to collapse
I am with exams and busy and i have to soft-briked my ouya now that i sof-briked my ouya I have obtein what i was looking for the mount points for looking if it si the ral error of builds not finishing compiling:
[email protected]:/ $ ls -al /dev/block/platform/sdhci-tegra.3/by-name
lrwxrwxrwx root root 2000-01-01 01:00 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2000-01-01 01:00 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2000-01-01 01:00 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2000-01-01 01:00 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2000-01-01 01:00 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2000-01-01 01:00 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2000-01-01 01:00 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2000-01-01 01:00 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2000-01-01 01:00 USP -> /dev/block/mmcblk0p7
LNX is boot that was the one i was searching for but we cant use this boot partition beocuse if we bricked it will be very difficult to recover it
In cm11 updater-script boot.img is extract to system: package_extract_file("boot.img", "/system/boot.img");
So i need more of research to make a new build i will try this friday or weekend if someones nows how to fix this issue tell us
gumbi2400 said:
Wow, I just fired up my Ouya for the first time in a while today and figured I would see if anyone has done anything recently. Glad to see this little box isn't completely dead!
Any chance of some compile instructions?
Click to expand...
Click to collapse
With cm12.1 is simple downlad cm12.1 source and download ouya parts and when building use this specific command LANG=C brunch ouya and just it , with the old source may have some problems but i am testing new soruce to see if it works if it compile 100% i will upload the new source changes
Good stuff. I always struggle setting up my repo manifests properly. Next goal is to compile Android TV properly with the new sources.
gumbi2400 said:
Good stuff. I always struggle setting up my repo manifests properly. Next goal is to compile Android TV properly with the new sources.
Click to expand...
Click to collapse
Thanks for working for the ouya, i am compiling cm12.1 right now with las cm12.1 soruce and fixes for ouya wait like 3 hours or less i will post new source code
Erros making zip
I am having a lot of erros making zip with no releasetools Magic Error with cm11 releasetools a lot of errors i cant finnished build :crying::crying:
Someone know how to fix it
werty100 said:
I am having a lot of erros making zip with no releasetools Magic Error with cm11 releasetools a lot of errors i cant finnished build :crying::crying:
Someone know how to fix it
Click to expand...
Click to collapse
https://github.com/TeamRegular/android_device_ouya_ouya1_1/tree/cm-12.0/releasetools
werty100 said:
I have fixed recovery, it works but it doesnt have the option usbdisk for mounting USBs so need more work on it
Here i give to you recovery for people to test it i need tester i am busy...
Click to expand...
Click to collapse
thanks for your time and work on this device,& ill be glad, to be a tester!!
THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.
Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary
garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary
spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance
@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)
Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?
Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9
garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.
Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.
[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #
dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!
I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.
I DID NOT MAKE THIS ROM!!!!!! - A developer by the name of TheKit made this rom, so do not give me any credit for this rom, give it all to them.
I am simply linking it because I love this phone, I love Sailfish OS on it, and I think a lot of people would enjoy Sailfish OS on it as well and just don't know it is available.
Q: "What is Sailfish OS and why should I use it?"
A: Sailfish OS is a great OS for many reasons. Having used multiple android roms I can attest to the fact that:
1. It has MUCH better battery life (however it has a weird battery read bug, see issues below)
2. It is MUCH faster and generally more stable when it comes to the things that work (your calls won't drop, your system won't lock up due to lack of ram, etc.)
3. It has a great gesture driven UI that is a joy to use and very gorgeous to look at. No more of this all white bull**** Google has been forcing down our throats since 2014
Q: "How good is the battery life?
A: After a day of playing cave story at work and reading discord and listening to music, I am at about 30-40% end of day (I start at 8:30AM, stop at 4:00PM)
Okay now that the Q/A segment is over, lets get to the real meat
ISSUES
1. Battery Read is wonky, it only goes in 10% increments until it reaches 20%, then it starts going in 5% increments
2. If you use the 2.1.3.7 build keyboard backlight is broken, but it works fine on the 2.1.0.11 build
3. Bluetooth is wonky, I was able to play audio through speakers in the 2.1.3.7 build...
4. FM Radio is broken too
5. As the maemo-talk thread says, CDMA is untested, and like on Photon Q, most likely does not work. GSM works great though! :good:
6. The old 2.1.0.11 build has a slew of issues compared to the new 2.1.3.7 build. These include data not working out of box, wifi requiring a reboot to work, and auto rotation not working in a majority of apps by default. Consult this thread and the maemo talk thread for more help, and if you want rotation anywhere, install patchmanager 2.0 and auto rotate anywhere from warehouse for sailfish os.
Alien Dalvik install tutorial
I did not make this and do not know who did. the developer claims someone threw a brick at them with an sd card attached. The sdcard contained links to these files in the form of a text file names "monkeyAIDS.txt"
https://drive.google.com/file/d/1mS6di1jYfVeDoFBjcANS6SmfkhGyEKoa/view - AD Jolla C (different from the Turing phone rpm, this is built for 3.1.x kernels)
http://sfos.scanf.su/maserati/alien-patched.tar.gz
So extract both files to your ~/ (home) directory and type in the following:
devel-su
[insert root password you set in settings]
zypper in [alien dalvik rpm]
rsync -a /home/nemo/alien/ /opt/alien/
ln -s /vendor /opt/alien/system/vendor
reboot
OPTIONAL: fix for the default 320PPI value
devel-su
[insert root password]
vim /opt/alien/system/build.prop
change ro.sf.lcd.density to the value of your choosing (Droid 4 is 256)
Keyboard Backlight Fix, works on 2.1.0.11, don't know about 2.1.3.7 -- Thank you @moodroid for this legendary patch!
On <2.1.3.7, I got the keyboard backlight to work by creating an /etc/mce/20backlight.ini with:
[KeyPad]
BrightnessDirectory=/sys/class/leds/keyboard-backlight
Then do 'pkcon install mce' and 'systemctl restart mce'.
Download Links
Here is the thread with the Download Link to the 2.1.0.11 build
https://talk.maemo.org/showthread.php?t=99031&page=9
If you don't mind a lack of keyboard backlight and want a more up to date build, grab the new and fabulous leaked 2.1.3.7 Build:
https://drive.google.com/file/d/1k3MOCrMvbFb114Omf0MzSvnQ7wBkTiWH/view?usp=sharing
Basically if you are fed up with how ****ty the latest Lineage OS builds are and just want to try something new, give this a try. Why not? What have you got to lose. All in all great work by TheKit and I am very happy with the port as it is and I think you will be too.
Hi,
On <2.1.3.7, I got the keyboard backlight to work by creating an /etc/mce/20backlight.ini with:
[KeyPad]
BrightnessDirectory=/sys/class/leds/keyboard-backlight
Then doing 'pkcon install mce' and 'systemctl restart mce'.
Hope you get the OK to share your AD success!
Thanks
moodroid said:
Hi,
On 2.1.3.7, I got the keyboard backlight to work by creating an /etc/mce/20backlight.ini with:
[KeyPad]
BrightnessDirectory=/sys/class/leds/keyboard-backlight
Then doing 'pkcon install mce' and 'systemctl restart mce'.
Hope you get the OK to share your AD success!
Thanks
Click to expand...
Click to collapse
dude you are a legend!
I would add that to the OP but you are first comment so anyone viewing the op will see this. I will definitely tell TheKit about this (then again, he gave you the 2.1.3.7 build so you can just tell them yourself)
Greetings,
I've been playing around with SailfishOS on my Droid 4 in the past few days, and I have a few questions about the whole thing. TheKit publicly shared a 2.1.3.7 build for the Droid 4 on his thread at Maemo, is that the one you are talking about or is it a different build? As someone mentioned this specific build seems to have issues with wifi, and I have the same problem. I can't post links, but the download link to the build I mentioned is on page 12.
The 2.1.0.11 build seems to work fairly well, however I wasn't able to install Alien Dalvik. After the installation the "Android Support" button does show up in the settings app, however nothing happens when I click the start button. I also attempted installing an apk both via the GUI (by clicking on it in the downloads) and via the command line by using "apkd-install", but it doesn't seem to work. Full log of the installation process attached.
I talked with TheKit, and the 2.1.3.7 build I mentioned (the one at page 12) is indeed outdated. He just updated the OP at Maemo and added the latest 2.1.3.7 build, which I just flashed and it's working great. Also installed Alien Dalvik following the instructions in the OP and it seems to be working fine as well! However I wasn't successful with the backlight fix method yet.
For anyone wondering how I flashed the latest build I went CM11 --> SailfishOS 2.1.0.11 --> SailfishOS 2.1.3.7 (rel2).
NIKKOS said:
I talked with TheKit, and the 2.1.3.7 build I mentioned (the one at page 12) is indeed outdated. He just updated the OP at Maemo and added the latest 2.1.3.7 build, which I just flashed and it's working great. Also installed Alien Dalvik following the instructions in the OP and it seems to be working fine as well! However I wasn't successful with the backlight fix method yet.
For anyone wondering how I flashed the latest build I went CM11 --> SailfishOS 2.1.0.11 --> SailfishOS 2.1.3.7 (rel2).
Click to expand...
Click to collapse
Hi Nikkos,
Sorry - that was me that posted the backlight fix, and I agree that it doesn't work on 2.1.3.7-rel2. It'd worked on every other version I tried, and I've now edited my post above. Glad everything is working.
Sorry again
moodroid said:
Hi Nikkos,
Sorry - that was me that posted the backlight fix, and I agree that it doesn't work on 2.1.3.7-rel2. It'd worked on every other version I tried, and I've now edited my post above. Glad everything is working.
Sorry again
Click to expand...
Click to collapse
No worries.
If anyone is wondering how to change the SailfishOS UI scale (I find the default one to be way too big) here's how I did it via the terminal:
Code:
devel-su
rm /etc/dconf/db/vendor.d/locks/silica-configs.txt
dconf write /desktop/sailfish/silica/theme_pixel_ratio value
I believe the default value should be around 1.1; you can also reset the value to stock with:
Code:
dconf reset /desktop/sailfish/silica/theme_pixel_ratio
or read the value with:
Code:
dconf read /desktop/sailfish/silica/theme_pixel_ratio
Not exactly droid 4 related, but thought I'd share.
Okay, I got the backlight to turn on!
Type the following in the terminal:
Code:
devel-su
echo 255 >/sys/class/leds/keyboard-backlight/brightness
It seems to properly react to some triggers like standby after being turned on but not to others like sliding the keyboard in and out (which means it will always stay on if the screen is on, regardless if it's been slided in or out). My assumption is that the keyboard sliding trigger got broken in some way, as I believe that's the way the backlight is being turned on. The events which trigger the backlight seem to be stored in the file /sys/class/leds/keyboard-backlight/trigger, so I assume that would be a good starting point to attempt fixing this.
The keyboard backlight intensity can also be changed, just change the 255 to a different value (it goes from 0 to 255).
Note: this change is not permanent, it will need to be applied again at reboot. Writing a script which executes the above commands at boot should be trivial though, and I will include instructions when I get it done myself.
EDIT:
Here's how to make the change permanent. Following these instructions you will create a Systemd service which will turn the backlight on when active and off when inactive; it will automatically run at boot and it can also be controlled like any other Systemd service (i.e. using systemctl via the terminal)
Type the following commands through the terminal:
Code:
devel-su
cd /etc/systemd/system
touch keyboard-backlight.service
chmod 744 keyboard-backlight.service
You will now need to edit the keyboard-backlight.service file with a text editor (either vim or nano will do, vim comes preinstalled, nano does not). Depending on your preferred text editor, type the following:
Code:
vim keyboard-backlight.service
or
Code:
nano keyboard-backlight.service
Now write the following to the file and save it:
Code:
[Unit]
Description=XT894 keyboard backlight service
[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo 255 >/sys/class/leds/keyboard-backlight/brightness"
ExecStop=/bin/sh -c "echo 0 >/sys/class/leds/keyboard-backlight/brightness"
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
Now type the following to enable the service:
Code:
systemctl enable keyboard-backlight.service
That's it. You can now control the service by using the following:
Code:
systemctl start keyboard-backlight //This will turn the backlight on
systemctl stop keyboard-backlight //This will turn the backlight off
systemctl status keyboard-backlight //This will display the service status
Can anyone share the google drive file from the first post? Is there an alternative link available? Or could you PM me a google drive link? Thanks!
Can anyone suggest the best/correct ROM-slot size for TWRP?
Is it still like for CM/LOS:
800MB for system
10MB for cache
and rest for data as one likes?