Results 1 to 16 of 16
  1.    #1  
    GO AWAY. DO NOT READ THIS POST. IT DOES NOT EXIST. IF YOU FOLLOW THE INSTRUCTIONS IN THIS THREAD YOU MAY FIND YOURSELF THE OWNER OF AN IPHONE AND YOU WILL BE VERY SAD. YOU MIGHT FIND THAT YOUR PHONE WAKES UP DURING MEETINGS AND SINGS THE CRAZY FROG SONG. YOUR SELF PORTRAITS PICTURES FROM THE CAMERA MAY MAKE YOUR FRIENDS CALL YOU DORIAN GREY. THIS KERNEL WAS DEVELOPED WITH THE AID OF HALF A BOTTLE OF BENROMACH ORIGINS. LMGTFY.COM.

    New kernel with pre-empt and all the io schedulers enabled, *and* the camera works. The fix appears to be to set noop as the default scheduler, and somewhere in the boot process (other than swaphack) it gets pushed to cfq. The phone appears to have full functionality I am interested in as tested (make/receive calls, WiFi, novaterm, gcc, perl).

    Once booted, you can then flip the scheduler to anticipatory with:

    echo anticipatory > /sys/block/mmcblk0/queue/scheduler

    I would also recommend the cpufreq changes I have noted in posts passim. I use the following in an event.d script:

    # Set min frequency
    echo 125000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
    # Set max frequency
    echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

    # Set powersave bias to 5
    echo 5 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias

    # Set up_threshold to 50
    echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

    # Set up_threshold to 20000
    echo 20000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

    Phone breaks? You get to keep both pieces and go buy another on your own dime. Enjoy!

    Linkage thanks to the esteemed uNiXpSyChO:

    http://www.unixpsycho.com/uImage.sbup_iotest
    http://www.unixpsycho.com/config_sbup_iotest

    Cheers, Steve

    You read this far? Didn't I tell you not to read this post? Now look what you've gone and done to your phone. And it's all your fault, too.
    Last edited by sbromwich; 04/10/2010 at 12:26 AM. Reason: Not my fault if people read the post after I tell them not to.
  2. #2  
    Wait, so is this going to literally brick your phone, like in purposely?
  3. #3  
    Quote Originally Posted by Menace187 View Post
    Wait, so is this going to literally brick your phone, like in purposely?
    If that would be a problem, then don't try it.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  4. #4  
    I could not tell if he was being sarcastic or not, cause i dont know why anyone would purposely want to brick their pre, and if so then just throw it at a brick wall lol
  5.    #5  
    Quote Originally Posted by Menace187 View Post
    Wait, so is this going to literally brick your phone, like in purposely?
    If you have to ask... You shouldn't be trying this. I *did* say not to read the post.

    Cheers, Steve
  6. #6  
    Quote Originally Posted by sbromwich View Post
    If you have to ask... You shouldn't be trying this. I *did* say not to read the post.

    Cheers, Steve
    I never said that i was going to try this, Just a curious question. cause like i said i was not able to tell if you was being sarcastic
  7.    #7  
    Test cases as provided by Jack87:

    * Youtube plays without flickering.
    * MP3s play without jitter.
    * Pandora is untested, not available in Canada.

    Cheers, Steve
  8.    #8  
    Quote Originally Posted by Menace187 View Post
    I never said that i was going to try this, Just a curious question. cause like i said i was not able to tell if you was being sarcastic
    If you are willing to risk becoming the owner of an iphone, go ahead. I am sure caj2008 will be more than happy to give you a hand (and possibly a foot) with any issues you have trying to use it.

    Cheers, Steve
  9.    #9  
    As a battery performance test I again deliberately did not charge my phone last night. At 4:30am when I went to bed the Pre reported 96%, at 9:11am it is now reporting 90% charge, giving a drain (if the non-fake battery meter is accurate) of around 1% per hour when idle.

    I have also compiled schedtool and set the pulseaudio, lunasysmgr and CDMA telephony manager to realtime priority to see if that has any effect.

    Cheers, Steve
  10. #10  
    Wow! Now how is it that you could get more from the hardware that Palm engineers themselves?

    Or is this just a proof that they know than Pre hardware can do more, and they are waiting for future releases, just for marketing reasons??
  11. #11  
    I, for one, accept our new kernel building overlords.
    Bringing you the first video recorder (Precorder), the first SDL application/game (DOOM), the first "make my magicjack/corporate voicemail play on my webos phone thingy" (gsm codec package), and now, webos's first opensource media recorder (voice and stream!) -> zcorder
  12.    #12  
    Quote Originally Posted by Tokafondo View Post
    Wow! Now how is it that you could get more from the hardware that Palm engineers themselves?

    Or is this just a proof that they know than Pre hardware can do more, and they are waiting for future releases, just for marketing reasons??
    Pure dumb luck, I think. I've also worked on embedded stuff on the past so I have a level of familiarity that lets me understand what Palm are doing in places.

    The hardware can certainly do more, Palm are understandably being conservative considering the size of the user base; I have seen what can go wrong when hardware is configured too optimistically and sent out to the user base - those of you with Sportster modems back in the day might remember Spiral Death Syndrome as a prime example of this sort of thing. It all worked fine in the lab, the beta testers didn't catch it, but as soon as a few hundred thousand people bought them the defect showed up for a small but vocal percentage of users.

    Cheers, Steve
  13. #13  
    hello. First of all, my compliments for your work.

    second, i have not read the post. My text-to-speech did it for me... :P

    and third: are those kernels just for cdma pre or can someone try them on gsm/european pre aswell?
  14.    #14  
    Quote Originally Posted by Tokafondo View Post
    hello. First of all, my compliments for your work.

    second, i have not read the post. My text-to-speech did it for me... :P

    and third: are those kernels just for cdma pre or can someone try them on gsm/european pre aswell?
    Thanks :-)

    Theoretically the kernel itself should run fine. GSM is a more sophisticated protocol than CDMA, and it has been pointed out to me that the changes I make risk WAN instability (I ran a half hour conference call fine on the voice side though). I would be interested in a report as to how well the kernel works on GSM.

    Cheers, Steve
  15. #15  
    OK, so as far as I can understand, there are more improvements on this kernel apart from the 800 mhz speed.

    I'd like to test them, but not the 800 mhz speed.

    Is that possible?

    I had the experience of testing patches that doesn't work on international phones. All that patches of "remixing" the device menu simply do not work on my Movistar Pre.

    Does the kernel support international phones, or the kernel is on a level that has nothing to do with locale and international support?

    Thanks for being patient.
  16.    #16  
    Quote Originally Posted by Tokafondo View Post
    OK, so as far as I can understand, there are more improvements on this kernel apart from the 800 mhz speed.

    I'd like to test them, but not the 800 mhz speed.

    Is that possible?

    I had the experience of testing patches that doesn't work on international phones. All that patches of "remixing" the device menu simply do not work on my Movistar Pre.

    Does the kernel support international phones, or the kernel is on a level that has nothing to do with locale and international support?

    Thanks for being patient.
    Yes, it's perfectly possible to lock the speed to whatever range of frequencies - that's what the scaling_min_frequency and scaling_max_frequency do. If you want to lock it to a fixed speed just set them both to the same value - eg when I'm bench testing some stuff I set them both to 500000 to lock the speed to factory settings.

    The kernel itself is at a lower level; essentially the patches you are looking at are patching webos files, the kernel is the bit that handles the interface between lunasysmgr (which runs the patched files) and the hardware. It is compiled for, if memory serves, UTF-8 which should work fine. The kernel itself only really understands ASCII anyway.

    And yes, you are correct that there is more to this kernel than just overclocking. I would be interested if you get it going to know if you see any perceptible differences over the stock kernel.

    Cheers, Steve

Tags for this Thread

Posting Permissions