Search This thread

NetBender

Member
Feb 20, 2012
46
7
Last edited:
  • Like
Reactions: tylerdurden83

movelbit

Senior Member
Nov 9, 2008
576
141
Valongo
I'd like to wish you all a Merry Christmas, lots of food, kisses, hugs, and quality time.

Whoa its already end of 2013 and we've been here since 2011, its crazy... Together we did amazing stuff, and I'll let you finish, but the greatest is yet to come thanks to osm0sis that been keeping me on the loop and giving me some help. After Christmas I'll push official releases supporting CM, both 4.3 and 4.4 and also some crazy work merged from all other Nexuses work :) thanks for sticking with FK!

Sent from my Nexus 5 using XDA Premium 4 mobile app

There are some paid users here waiting for the promissed update

Enviado do meu Galaxy Nexus através de Tapatalk
 

osm0sis

Senior Recognized Developer / Recognized Contribut
  • Mar 14, 2012
    14,534
    32,724
    Halifax
    GT-i9250
    Nexus 7 (2013)
    I'm having even more problems with mounting rw with this version... Not sure why, but I can not edit/save any scripts in /etc/init.d. I tried a couple different utilities, and even though the folder shows as mounted rw, nothing will save.

    Update: I'm fairly certain this issue is kernel or ramdisk specific. Using the same utilities, same busybox install, and either stock (Shiny rom) kernel or mpokang kernel that doesn't have a ramdisk does not exhibit the rw mounting issues.

    Hope this helps narrow it down for you, osm0sis.

    I can't seem to reproduce the issue anymore with SuperSU v1.91 - what about you? Maybe it was more of a root bug all along..

    really odd question, but does someone have all the franco.Kernel's that there has been?

    Specifically the final R196 and the Final Jellybean 4.1.2 kernel :D

    Between the link in the OP and http://minooch.com/franciscofranco/ that should be all of them.

    Edit: Hmm, actually I take that back. Looks like Francisco cleaned up the server and everything before 4.2 support is gone.. I wonder if anyone mirrored them?

    ---------- Post added at 01:38 AM ---------- Previous post was at 01:01 AM ----------

    Ah ****, I take that back, I can repro the rw issue again. It's so random though..
     
    Last edited:
    • Like
    Reactions: Edward Stanbury

    Vekhez

    Senior Member
    Sep 7, 2013
    549
    263
    Who Cares?
    I can't seem to reproduce the issue anymore with SuperSU v1.91 - what about you? Maybe it was more of a root bug all along..



    Between the link in the OP and http://minooch.com/franciscofranco/ that should be all of them.

    Edit: Hmm, actually I take that back. Looks like Francisco cleaned up the server and everything before 4.2 support is gone.. I wonder if anyone mirrored them?

    ---------- Post added at 01:38 AM ---------- Previous post was at 01:01 AM ----------

    Ah ****, I take that back, I can repro the rw issue again. It's so random though..

    Yeah, they are all cleaned up, I did like 2 hours of searching, there are no mirrors.. So I guess Franco's the only one with em.
     

    AutomaticFailure27

    Senior Member
    Sep 24, 2010
    679
    365
    I'm having even more problems with mounting rw with this version... Not sure why, but I can not edit/save any scripts in /etc/init.d. I tried a couple different utilities, and even though the folder shows as mounted rw, nothing will save.

    Update: I'm fairly certain this issue is kernel or ramdisk specific. Using the same utilities, same busybox install, and either stock (Shiny rom) kernel or mpokang kernel that doesn't have a ramdisk does not exhibit the rw mounting issues.

    Hope this helps narrow it down for you, osm0sis.

    I had the same type of issue using Root Explorer. What I found (which not 100% sure if it is what fixed it but it worked after that) was I was able to mount everything to r/w but still not able to change it. I then backed all the way to root "/" and noticed that was still at r/o. After switching that, I was able to do pretty much everything again.
     

    pkgnex

    Senior Member
    Aug 13, 2012
    955
    1,135
    Michigan
    I can't seem to reproduce the issue anymore with SuperSU v1.91 - what about you? Maybe it was more of a root bug all along..



    Between the link in the OP and http://minooch.com/franciscofranco/ that should be all of them.

    Edit: Hmm, actually I take that back. Looks like Francisco cleaned up the server and everything before 4.2 support is gone.. I wonder if anyone mirrored them?

    ---------- Post added at 01:38 AM ---------- Previous post was at 01:01 AM ----------

    Ah ****, I take that back, I can repro the rw issue again. It's so random though..

    Os,

    Yeah, the r/w issue seems to be gone on my device at the moment - and the only thing I did was update SU to 1.91.

    One odd thing, though... when rebooting out of recovery, I still get the "Root access possibly lost. Fix?" prompt in cwm. The affirmative response (which I never choose) points to "Yes - Fix root (/system/xbin/su)".

    This has been happening for a while on your (recent) Franco kernels, but not on stock or other ram-disk free kernels, so I wonder if there is any relation, or if this helps you pin down any other issue.

    BTW - Answering "NO" to the CWM prompt I listed above does not cause me to loose root.

    Also, mounting the top level root directory r/w did not fix the issue for me when it was occurring, unlike what another user said. Root explorer would copy/save files in non-root directories, but not in anything normally mounted r/o.
     
    Last edited:
    • Like
    Reactions: osm0sis

    pkgnex

    Senior Member
    Aug 13, 2012
    955
    1,135
    Michigan
    Franco kernel for Galaxy Nexus is discontinued? Not so much updates since November 2013.

    Not discontinued, just development has slowed. You'll see the same in every other G-Nex kernel forum because:

    1. The Developer community has wrung just about everything possible out of the G-Nex kernel.
    2. The 3.0 kernel hit end-of-life a month or two back (3.0.101)
    3. The device is over 2 years old, and the Dev's have been putting more effort toward two generations of newer hardware that still have more room for improvement kernel-wise.

    Franco has promised at least one more version, and I am confident it will come in the not-too-distant future. At this point, the various kernels out there are all quite similar and very good / mature. We should all relax and just be happy that we have the current crop of kernels to use rather than the 2-year old stock kernel the G-Nex shipped with!
     

    namelesske

    Senior Member
    Dec 25, 2010
    96
    14
    www.dirtywindows.hu
    Not discontinued, just development has slowed. You'll see the same in every other G-Nex kernel forum because:

    1. The Developer community has wrung just about everything possible out of the G-Nex kernel.
    2. The 3.0 kernel hit end-of-life a month or two back (3.0.101)
    3. The device is over 2 years old, and the Dev's have been putting more effort toward two generations of newer hardware that still have more room for improvement kernel-wise.

    Franco has promised at least one more version, and I am confident it will come in the not-too-distant future. At this point, the various kernels out there are all quite similar and very good / mature. We should all relax and just be happy that we have the current crop of kernels to use rather than the 2-year old stock kernel the G-Nex shipped with!

    Hmm maybe "ignorance is bliss" the best way to handle when a device is end of its life :) That was sad moment when 3.x kernel EOL-ed and later Google Denied KitKat :(
     

    pkgnex

    Senior Member
    Aug 13, 2012
    955
    1,135
    Michigan
    Hmm maybe "ignorance is bliss" the best way to handle when a device is end of its life :) That was sad moment when 3.x kernel EOL-ed and later Google Denied KitKat :(

    Agreed - especially the Google KK denial for a device that still wasn't quite 2 years old. It sounds like 18 months is all the longer they plan to support devices now.

    My plan from here out is to buy only "close-to-stock-android" devices with high sales volumes... in order to take advantage of wide-spread developer support and hope that I am able to keep the device still feeling usable for 6 - 12 months after the official OEM/Google support dies off at 18 months.

    I have too many other things I want to spend my money on to justify buying a new phone / tablet for everyone in the family every 18-20 months!
     

    Top Liked Posts

    • There are no posts matching your filters.
    • 1562
      I hate big OPs.

      Works on all roms. r390 and newer versions are ONLY for 4.3 or newer.

      F.A.Q:
      1. My device rebooted or crashed, how can I help?
      A: Get me /proc/last_kmsg on pastie.org.
      2. Battery sucks, my device is not entering deep sleep. FIX PLOX!
      A: Fix it yourself, it's an app waking your device up not the kernel's problem
      3. Signal is dropping since I flashed the kernel, amg u sucks!
      A: The kernel has nothing to do with gsm/cmda signal. Make sure you have the latest radios
      4. Do I need to wipe anything when flashing this kernel?
      A: No.
      5. Does this kernel has X or Y mod?
      A: Learn to read, everything you need to know is in the features list, changelog or public repo.

      Downloads:
      4.3: http://192.241.177.15/GalaxyNexus/4.3/
      4.4: http://192.241.177.15/GalaxyNexus/4.4/

      Kernel changelog:
      http://192.241.177.15/GalaxyNexus/4.3/appfiles/changelog.xml

      Source:
      https://github.com/franciscofranco/Tuna_JB_pre1/tree/nightlies-4.3

      franco.Kernel updater Free apk: http://forum.xda-developers.com/showthread.php?t=1867127

      203
      [KERNEL][GPL][5 JUN - #Milestone 4][r200-ICS r210-JB] franco.Kernel | 4.0.3/4 |

      Terminal commands for all the options in this kernel:

      Color Multipliers:

      echo r g b > /sys/class/misc/colorcontrol/multiplier

      Replace r g and b for 2000000000 for stock color. If you want to change the colors just replace the first 3 numbers of each r/g/b with 0-400 of your choice.

      Gamma Control:

      echo r g b > /sys/class/misc/colorcontrol/v1_offset

      Replace r/g/b by -255/200 of your choice.

      Fsync:

      echo 1 > /sys/module/sync/parameters/fsync_enabled - to enable

      echo 0 > /sys/module/sync/parameters/fsync_enabled - to disable

      Sound Control:

      echo i > /sys/devices/virtual/misc/soundcontrol/volume_boost

      Replace i with 0-3 of your choice.

      Sound High Performance:

      echo 1 > /sys/devices/virtual/misc/soundcontrol/highperf_enabled - to enable

      echo 0 > /sys/devices/virtual/misc/soundcontrol/highperf_enabled - to disable

      USB Fast Charge:

      echo 1 > /sys/kernel/fast_charge/force_fast_charge - to enable

      echo 0 > /sys/kernel/fast_charge/force_fast_charge - to disable

      wifi_pm:

      echo 1 > /sys/module/bcmdhd/parameters/wifi_pm - to enable

      echo 0 > /sys/module/bcmdhd/parameters/wifi_pm - to disable

      Trinity's Contrast:

      echo i > /sys/module/panel_s6e8aa0/parameters/contrast

      Replace i with -25/16 of your choice.

      BLX:

      echo i > /sys/class/misc/batterylifeextender/charging_limit

      Replace i with 0-100 of your choice.

      OMAP Gamma interface:

      echo i > /sys/devices/platform/omapdss/manager0/gamma

      Replace i with 5-10 of your choice.

      Thermal Throttle:

      echo 1 > /sys/module/omap_temp_sensor/parameters/throttle_enabled - to enable

      echo 0 > /sys/module/omap_temp_sensor/parameters/throttle_enabled - to disable

      TCP Congestion Algorithm interface

      To check all the available options:

      sysctl net.ipv4.tcp_available_congestion_control

      To change to other option:

      sysctl -w net.ipv4.tcp_congestion_control=NAME_OF_THE_ALGORITHM

      Detailed test of all the algorithms:
      Latency - Download - Upload

      cubic:
      1st run: 15ms - 10,75Mbps - 7,82Mbps
      2nd run: 14ms - 10,84Mbps - 8,06Mbps

      reno:
      1st run: 13ms - 15,51Mbps - 6,73Mbps
      2nd run: 13ms - 14,73Mbps - 8,51Mbps

      bic:
      1st run: 12ms - 10,38Mbps - 8,61Mbps
      2nd run: 13ms - 10,78Mbps - 8,62Mbps

      westwood:
      1st run: 11ms - 17,65Mbps - 8,30Mbps
      2nd run: 13ms - 13,28Mbps - 8,29Mbps

      highspeed:
      1st run: 13ms - 10,76Mbps - 7,94Mbps
      2nd run: 16ms - 14,42Mbps - 8,52Mbps

      hybla:
      1st run: 14ms - 11,19Mbps - 7,44Mbps
      2nd run: 14ms - 13,47Mbps - 7,56Mbps

      htcp:
      1st run: 14ms - 13,24Mbps - 7,03Mbps
      2nd run: 15ms - 10,85Mbps - 8,00Mbps

      vegas:
      1st run: 14ms - 8,49Mbps - 6,62Mbps
      2nd run: 14ms - 12,00Mbps - 7,07Mbps

      veno:
      1st run: 13ms - 9,58Mbps - 8,13Mbps
      2nd run: 13ms - 8,50Mbps - 7,64Mbps

      scalable:
      1st run: 18ms - 12,01Mbps - 8,73Mbps
      2nd run: 14ms - 13,96Mbps - 8,23Mbps

      lp:
      1st run: 14ms - 14,90Mbps - 8,68Mbps
      2nd run: 14ms - 13,44Mbps - 8,72Mbps

      yeah:
      1st run: 14ms - 13,37Mbps - 8,28Mbps
      2nd run: 17ms - 13,89Mbps - 8,14Mbps

      illinois:
      1st run: 13ms - 12,93Mbps - 8,24Mbps
      2nd run: 16ms - 13,97Mbps - 6,46Mbps
      167
      Just woken up and feel like my head is going to explode already this last 5 pages is crazy

      haha. It's been a crazy two days. :) But it's been a blast.

      Now, sleep is over, time to get back to work!

      I got these from that thread:

      so it makes much sense, to make the min_sample_time as low as possible (?), but how low? what's the most appropriate sample time for battery and performance?

      for the timer_rate, franco suggested 30k to consider the CPUs latency. What has it to do with the cpu's latency?

      he also said min_sample_time doesn't have to be in multiple of timer_rate.
      in my case, all my timers are in 20k, which works fine as of now. But i must be missing some things, because I just saw somebody post these values, and no detailed explanation for having them.

      Yes and no. Here's what we're thinkin' so far.

      THIS POST WILL BE A RECAP OF THE LAST FEW PAGES OF RESEARCH! :)

      This was my original settings that I've been using for weeks:
      above_hispeed_delay: 20000
      go_hispeed_load: 50
      min_sample_time: 40000
      timer_rate: 20000
      So to make the short hand easier, we kept it in that order and just said: 20000/50/40000/20000 became 20k/50/40k/20k became 2/5/4/2. Make sense?

      Here is a breakdown of what they each mean:
      -above_hispeed_delay: Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load.
      -go_hispeed_load: The CPU load at which to ramp to the intermediate "hi speed".
      -min_sample_time: The minimum amount of time to spend at a frequency before we can ramp down.
      -timer_rate: Sample rate for reevaluating cpu load when the system is not idle.

      This is a good explanation that I wrote back on page 3038:
      -above_hispeed_delay: higher = better battery, lower = better performance. (100k is default)
      -go_hispeed_load:.......higher = better battery, lower = better performance. (50 is default)
      -min_sample_time:......lower = better battery, higher = better performance. (60k is default)
      -timer_rate:.................higher = better battery, lower = better performance. (20k is default)
      So Google's default is 10/5/6/2. Lower numbers are all better for performance except min_sample_time (there higher is faster). So our goal is to find a sweet spot.

      The default 10 is for "Once speed is set to hispeed_freq, wait for this long before bumping speed higher in response to continued high load." So we think 10 is too high, but if you go too low, then you'll be using the higher freqs a lot more than you need and it will hurt the battery. So we are leaning towards 6 (60000) for above_hispeed_delay.

      The default 5 is for "when the CPU hits X% amount of load, then jump to the hispeed_freq." Again if this one is too low then it will cause the higher freqs to be used more often then they need, so we actually turn go_hispeed_load up a little bit to 7 (70).

      The default 6 is for "how long do I wait before lowering the clock speed from what it's currently at." So the lower we put this, the better battery will be. We're still trying to decide between 3 (30000) and 5 (50000). Osm0sis is getting more lag at lower levels, and finds the best performance mark at 5. So we turn min_sample_time down a little from stock to help with the battery.

      The default 2 is for "wait this long before changing the clockspeeds from what it's at now." While technically 2 sounds better because it's changing more often, Franco believes that by setting the timer_rate to be the same thing as the CPU sample_rate (which is preset at 30000), then that will make the CPU more efficient at switching. So we increased it from 2 (20000) to 3 (30000).

      So TO RECAP: Using the stuff from above, Google's defaults for these settings are 10/5/6/2 and we are changing them to 6/7/3/3 or 6/7/5/3 (again, still testing that third number for the min_sample_time).

      Does that make sense for everyone interested in following along? Any questions? Feel free to try out these settings yourself (the easiest way is with Franco's app or something like Trickster). We want as much feedback as possible on this.
      The next kernel release will have the totally tweaked settings for everyone to test without having to change their own stuff.

      :):D:laugh::good:
      111
      Kernel Emergency Settings Reset Zip

      Alright so here's something that's been requested for awhile.

      I wrote it up recently with Franco's stamp of approval, so I'm posting it here now. Please direct people back to this post from other threads.

      This can/should be everyone's go-to when experiencing problems after updating to a new kernel build, you get stuck in a bootloop, or you think there's a conflict between ROM and kernel (or kernel tweaking app) you can't track down, since likely some leftover settings (voltages, etc.) are at fault. It's also useful if you just want to make sure you're running clean defaults. This should work on any device franco.Kernel and f.Ku support, as well as a variety of other devices, kernels and control apps: eXperience (Free/Pro), GLaDOS Control, TricksterMod, Trinity Kernel Toolbox, ROM Toolbox (Lite/Pro), SetCPU, Faux123 Kernel Enhancement Project, Performance Control and Synapse.

      Flashing this via custom recovery of your choice will delete the kernel app settings file(s), disable init.d and userinit.d scripts by moving them to a subfolder (/system/etc/init.d/off/ and /data/local/userinit.d/off/ respectively) and wipe cache and dalvik-cache for good measure.

      Hopefully it helps!


      Note: If your ROM has a Performance/Tweaking App built-in you should also manually disable any Set On Boot options it has. For example, I couldn't include clearing CM's Advanced Settings since they're built into the main com.android.settings/Settings.apk along with a lot of other Android OS settings (APNs, Developer Options, etc.), so to run clean and without conflicts on CM you need to unset them yourself.

      You should also avoid having more than one control app installed at a time. Conflicts have been reported even with everything "unset" in two apps.

      I also chose not to disable anything your ROM may have in /data/cron or /system/addon.d since some rely on it heavily, so you can choose to review those directories' contents and whether you want to leave them enabled on your own. I also left out disabling sysctl.conf since that's done by f.K and the Franco's Dev Team scripts, and also seemed a bit heavy-handed for this zip script.



      Download counts for the previous versions: 790; 2678.
      105
      Sure. Happy to post my franco.Kernel settings here for anyone who wants to try them. I'll keep these up-to-date if I change them. :)

      These are my f.K settings, my DirtyV settings can be found here.
      Device: Galaxy Nexus
      Max Frequency: 1305 MHz
      Min Frequency: 384 MHz
      Governor: interactive
      Governor Tunables: a_h_d 15000 / g_h_l 95 / h_f 729600 Hz / m_s_t 45000 / t_r 15000 / i_b_f 1036800 Hz / t_l 85 / t_s 80000 / b_d 1000000
      IO Scheduler: row
      IO Scheduler Tunables: h_r_q 100 / r_r_q 75 / h_s_q 5 / r_s_q 4 / r_w_q 4 / l_r_q 3 / l_s_q 2 / r_i 15 / r_i_f 25
      Read Ahead Buffer: 512; NR Requests: 512
      TCP Congestion Avoidance Algorithm: westwood
      Screen Off Max Frequency: 537 MHz

      Color Multipliers: 230 235 340
      RGB Gamma: -4 0 5
      Trinity Contrast: -22; OMAP4 Gamma: 4; CAB: Disabled

      Sent from franco.Kernel updater app:
      https://play.google.com/store/apps/details?id=com.franco.kernel

      The following voltages are just as a reference. DO NOT enter them; your device may not be able to handle them this low, causing freezes and reboots. They are here so that people can compare their stable voltages after following the UV guides linked below, to see how our devices compare. Every device is different, so again, DO NOT enter them.
      mpu_voltages:
      1804mhz: 1425 mV
      1728mhz: 1375 mV
      1612mhz: 1325 mV
      1536mhz: 1275 mV
      1420mhz: 1225 mV
      1305mhz: 1175 mV
      1228mhz: 1125 mV
      1036mhz: 1075 mV
      729mhz: 925 mV
      537mhz: 825 mV
      384mhz: 775 mV
      192mhz: 725 mV

      iva_voltages:
      430mhz: 1125 mV
      332mhz: 1025 mV
      266mhz: 925 mV
      133mhz: 825 mV

      core_voltages:
      512mhz: 1050 mV
      384mhz: 975 mV
      153mhz: 800 mV
      There are some battery savings from UVing but they aren't extreme. If you do not know how UVing works and/or you can't/won't read to properly build your own voltage profile, then just stick with the defaults Franco has already UVed. If you do still want to learn to UV then, once again, everyone should build their own voltage profile for their own device. Read this, this, this, and this for starters on UV methods. You don't know how your device will do until you learn and try.

      As a sidenote, if anyone else wants to share their voltages for comparison the easiest way is to copy the contents of the 3 voltage files (mpu/iva/core) in /sys/class/misc/customvoltage/ - they look (almost) exactly as the sections above.
      Fsync on just in case anything ever happens I want my data protected. That said I do disable it temporarily if I ever want a bit more performance in an app or game. SR is hardcoded disabled in the latest builds.

      The other thing worth noting is I set my color settings on boot with an init.d script. Doing it that way you can end up with a completely different result from the same values. The contrast, blacks and colors are much more natural. Also it's seamless which is nice; they take effect during the Google logo. Attached is my init.d script for that. Alter it to your own color settings, remove the .txt extension, push to /system/etc/init.d/ and set the correct perms; rwxr-xr-x (chmod -R 755 /system/etc/init.d in Terminal Emulator).

      900colorsettings can be found with my other init.d scripts (from Franco Dev Team), here: https://s.basketbuild.com/filedl/devs?dev=osm0sis&dl=osm0sis/scripts/900colorsettings

      Note: On my new replacement screen, setting the color multiplier too early in the boot (any time before the boot animation) made everything look dark, oversaturated, uncontrasted and dusky; basically the opposite of the way it used to work on my old panel. Adding sleep 2; before that line in the init.d script fixed this, so experiment if your panel is more like my new one, and the init.d as-is after you put in your settings makes it look worse.

      [ New init.d script with my new colors. I need the sleep 4 because of my problem in my "Note" above, so comment it out if you don't need it, it will make it look worse. Previous download counts were 1880, 646, and 307. Thanks everyone! ]
    Our Apps
    Get our official app!
    The best way to access XDA on your phone
    Nav Gestures
    Add swipe gestures to any Android
    One Handed Mode
    Eases uses one hand with your phone