I pulled the latest kernel tarball, fixed and tweaked a few things, then compiled it on my Rhodium. Although it works well on my Rhodium, I cannot guarantee that it will work on yours. In addition, it is guaranteed NOT to work on any other since I disabled support for it in .config.
You can install this kernel just like the one you would off the autobuild. The kernel is named -fox-YYDDMM where the date is when I pulled the tarball. While suggestions and feature request are welcome, it takes me ~2.5hr to go through one compile, so don't expect a new build very often.
You need the patched haret.exe as well as an additional line in startup.txt to boot this kernel. Instructions for that can be found at http://forum.xda-developers.com/showpost.php?p=14519408&postcount=1.
Latest (8/20) at http://db.tt/OeRyLYu
Changelog:
8/20 http://db.tt/OeRyLYu
microp: Upstream version of LED patch from Detule. Please note the requirement of updated lights.msm7k.so still applies.
8/16 http://db.tt/3UWBs3y
microp: Updated microp LED patch from Detule, now with more blinkenlights goodness (and yes, it even blinks). In order to use this, however, you need an updated liblights from http://db.tt/ZUjymT9. The file should be bind-mounted on startup in your froyo.user.conf, ie: mount --bind /sdcard/lights.msm7k.so /system/lib/hw/lights.msm7k.so
8/15
microp: Proposed LED patch from Detule, mailing list has instruction on how to play with the blinkenlights.
.config:
Enabled IP_NF_TARGET_REDIRECT as a module because it's needed for certain app.
Started from clean source to get rid of any residuals.
8/11
Compcache: Included 0.5.4, patched kernel to support the swap notify
clock-wince: Added a debug output that shows freq requested, closest set, and the calc, without needing clock_wince.debug_mask=15.
.config notes:
LZOCOMPRESS/DECOMPRESS is built-in to the kernel. Therefore if you want compcache, you just need to insmod xvmalloc.ko and ramzswap.ko.
8/9
Upstream: htc_headset_microp fix
acpuclock: Changed turbo mode+20mhz only when acpuclock.force_turbo=2 is set. Also, overclock by 20mhz for any bus speed >100MHz.
modules: Use strip --strip-unneeded.
8/6
acpuclock: Change turbo mode t->axiclk_khz from 160000 to 180000. AXI clock control the bus freq, and upping it should make overall performance better.
clock-wince: Add supposed support for 48Mhz SD clock from .35. HOWEVER the kernel claims calc_freq is 61.44Mhz according to clock_wince.debug_mask=15. You also need to add msmsdcc_fmax=48000000 in order to use this clock anyway.
proc_comm_wince: Fix long-standing issue with msm_proc_comm_wince_pending_ints & DEX_INT_VBUS check which clobbered pending_int. You should no longer have a SoD during transition changes to/from suspending while inserting/removing the USB cable.
microp-k*: Got rid of the printk spam of backlight/keyled status changes.
.config changes:
1) Change default I/O scheduler to deadline. Our kernel does not do well with noop.
2) Change default AMSS firmware interface to 6125 which is what I have on my RHOD400. You can check yours (which is in the modem) by running dmesg | grep AMSS.
3) Change kernel default sleep_mode from CONFIG_MSM7X00A_SLEEP_MODE_POWER_COLLAPSE_SUSPEND to POWER_COLLAPSE. This is usually overridden but makes pm.sleep_mode=1 unnecessary.
4) Change CONFIG_MSM_CPU_FREQ_ONDEMAND_MIN from 128MHz to 112Mhz. This meant that the kernel never used the 112MHz clock because it was below the ondemand minimum. No-frills CPU can confirm this.
5) arm6k support enabled. Not sure if it makes a difference but the kernel hasn't complained.
6) Conservative and Powersave governor enabled.
7) CONFIG_INPUT_TABLET disabled, nothing was enabled in there anyway and ours uses TOUCHSCREEN.
8) CONFIG_USB_ANDROID_RNDIS_WCEIS enabled, supposedly makes Windows think it's dealing with a NDIS ICS device.
9) Enabled ext4 and disabled yaffs2. Ted T'so backported fixes for ext4 for .27 release. This contains all the patches available on his ext4 git for the 2.6.27 kernel, but still should be considered EXPERIMENTAL.
GPL availability notice:
kernel source as available from http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/commits/htc-msm-2.6.27
compcache module+patch from http://code.google.com/p/compcache/downloads/detail?name=compcache-0.5.4.tar.gz
.config used to compile available from within /proc/config.gz
Minor patches to the kernel source can be made against the git tree upon request. Please PM me if you are in need of that.
-- Starfox
Hmm haret freezes with your kernel on my rhod100_de.
(pm.sleep_mode=1 is deleted in startup.txt / no difference with pm.sleep_mode=1 not deleted)
Put sleep_mode back, and if it still doesn't boot, it's possible that the axi bus is too high. I'm looking to make it a kernel parameter in the next compile.
-- Starfox
So far so good.
Couple of things - first, it seems you didn't strip the modules...? There's no way they should be 7+mb .
Second, of all the things you've put in this kernel, one really stood out to me:
Starfox said:
proc_comm_wince: Fix long-standing issue with msm_proc_comm_wince_pending_ints & DEX_INT_VBUS check which clobbered pending_int. You should no longer have a SoD during transition changes to/from suspending while inserting/removing the USB cable.
Click to expand...
Click to collapse
If that's true ^^ (and works) why not submit a patch to mainline? Or is this your testbed for patch submission?
Good work, I'll see what I can make blow up. Only just booted... doesn't seem faster, but it's still settling methinks.
Please use the posted kernel/modules combo from the OP. I support 2 most recent revisions.
-- Starfox
i tried running this. it gets stuck at the HaRET: Booting Linux Dialogue in WinMo. am i suppossed to make any changes to startup.txt because i tried adding msmsdcc_fmax=48000000 to startup.txt and am getting the same response. is there anything I am suppossed to be doing?
anish88 said:
i tried running this. it gets stuck at the HaRET: Booting Linux Dialogue in WinMo. am i suppossed to make any changes to startup.txt because i tried adding msmsdcc_fmax=48000000 to startup.txt and am getting the same response. is there anything I am suppossed to be doing?
Click to expand...
Click to collapse
What device, build?
Rhod400, frx07
maybe a sample of the startup.txt would be appreciated too
also where am i suppossed to put msmsdcc_fmax=48000000 maybe im putting it in the wrong spot?
Running 8/6 here on rhod400. It seems just a tad bit faster/smoother.
anish88 said:
Rhod400, frx07
maybe a sample of the startup.txt would be appreciated too
also where am i suppossed to put msmsdcc_fmax=48000000 maybe im putting it in the wrong spot?
Click to expand...
Click to collapse
Did you just assume where the msmsdcc command goes? lol.
It goes in the "cmdline" between the quotes - where pm.sleep_mode is, etc. Make sure there's at least one space between each entry.
I'd imagine that's your issue, as I have the same phone/build and it works great for me.
arrrghhh said:
Did you just assume where the msmsdcc command goes? lol.
It goes in the "cmdline" between the quotes - where pm.sleep_mode is, etc. Make sure there's at least one space between each entry.
I'd imagine that's your issue, as I have the same phone/build and it works great for me.
Click to expand...
Click to collapse
odd, still no dice for me? what does your startup look like in general?
anish88 said:
odd, still no dice for me? what does your startup look like in general?
Click to expand...
Click to collapse
Did you rename the kernel? Have you updated the kernel before...?
My startup isn't anything special, just FRX07 with some additions for me (rel_path, OC, msmsdcc, no_partitions...)
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set initrd_offset 0x00a00000
set cmdline "msmsdcc_fmax=48000000 acpuclock.oc_freq_khz=714000 lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 rel_path=Androids/Stock07 no_partitions"
boot
i didnt have set initrd_offset 0x00a00000. i changed it, booting as we speak.
anish88 said:
i didnt have set initrd_offset 0x00a00000. i changed it, booting as we speak.
Click to expand...
Click to collapse
Shouldn't need it for .27... I forgot to mention that one tho, good catch. That is for .35/.39/3.0... .27 should work without it (and you'll need a new version of HaRET to use .35/.39/3.0 with that initrd_offset...)
anish88 said:
i tried running this. it gets stuck at the HaRET: Booting Linux Dialogue in WinMo. am i suppossed to make any changes to startup.txt because i tried adding msmsdcc_fmax=48000000 to startup.txt and am getting the same response. is there anything I am suppossed to be doing?
Click to expand...
Click to collapse
STOP.
If you are not getting past the boot scroll, then your phone cannot take the changes I made.
Again, let me make this clear. I do not guarantee that your phone will work with this kernel. I also can guarantee you that no mount of fiddling with startup.txt will change the fact that your phone will not boot.
You can try the updated zImage several post past the OP which should allow you to boot. Do not go blindly changing stuff in startup.txt. If you do not know what it does, ASK first.
-- Starfox
Starfox said:
STOP.
If you are not getting past the boot scroll, then your phone cannot take the changes I made.
Click to expand...
Click to collapse
Welcome to the joys of providing patches to the public...
The new zImage doesn't work for me either.
So my phone can't handle your kernel
Perhaps the AMSS firmware or the arm6k?
No Joy with Rhod500
Just tried this on my Rhod500 and I get a couple of Vibs from phone when Haret is launched, but the screen won't even re-paint... Just thought I would let everyone know...
Thanks...
If you need to know the AMSS version, it is shown during the HTC splash screen as [bunch of letters]-6125 or something very similar. From what I see the GSM users are having most of the issues, so it probaby is AMSS related.
-- Starfox
mgross029 said:
Just tried this on my Rhod500 and I get a couple of Vibs from phone when Haret is launched, but the screen won't even re-paint... Just thought I would let everyone know...
Thanks...
Click to expand...
Click to collapse
Ditto to this on a CDMA Rhod400 also. Vibrates on launching Haret, but does not go any further.
Related
Hi all,
I have Fat Free Froyo installed with the latest 14th Jan 2011 kernel voguimg-240x320-2.6.32-froyo-14-01-11_14.nbh edited to froyo & panel type 2 from t029000.massey.ac.nz but Google Goggles needs ipv6 support.
Is this a kernel problem or a problem with the build itself? I am experienced in linux, so can modprobe or insmod the ipv6.ko but I don't know where to get it from
Any help would be appreciated!
(message for kernel's developers) take this man! he can dev ipv6!
Jumping the gun there a bit
I triage bugs and work on stuff for Ubuntu. Have also ported a few linux bits to ppc64 (PlayStation 3).
I'm pinching the ipv6.ko from slayhers latest kernel build, hopefully that will work insmod-ding or modprobing it into the kernel thru the terminal on the Kaiser itself.
So, fingers crossed, this may be solved in 5 minutes!!
Didn't work, it must be compiled for a different platform...
Anyone have or know where to get a kernel for the Kaiser with ipv6 support, or failing that the correctly built ipv6.ko for the Kaiser so that it can be insmodded?
Getting it compiled in the kernel is the easy bit, although it does use up a lot of space which is limited in the kaiser's kernel so a little tweaking is needed. Getting it to work with the Kaiser's modem and the builds we currently use is a different matter unfortunately. It will take a bit of modding for it to work but it's more then achievable with a bit of free time. Wish i could buy that stuff!!If i get a chance i will get you the ipv6 module for the kaiser's kernel or a kernel with support for it so you can have a play.
I definitely look forward to it! If I knew how and what to modify I'd do it myself, but I thought arch-specific kernels had to be compiled on the arch itself? If that's the case, I can see how free time would be needed, it'd take hours or days to compile the linux kernel at 400MHz
I have compiled kernels before so if/when I learn how to do it myself, I could start to use my own git repo for more recent daily builds or something.
I'm also thinking about starting working on some *buntu stuff (I know Ubuntu is there for the Kaiser, but soem tweaks would help if I get a chance.)
Hmm, a little Googling goes a long way http://www.androidonhtc.com/wiki/Get_Involved << was hard to find that,so hopefully I can add ipv6 somewhere in the 'make menuconfig' options for the kernel.
Are the standard kernel options used by "make vogue_defconfig" ok to use, i.e. will it build a normal useable kernel so that everything works?
xteejx said:
Hmm, a little Googling goes a long way http://www.androidonhtc.com/wiki/Get_Involved << was hard to find that,so hopefully I can add ipv6 somewhere in the 'make menuconfig' options for the kernel.
Are the standard kernel options used by "make vogue_defconfig" ok to use, i.e. will it build a normal useable kernel so that everything works?
Click to expand...
Click to collapse
Yes, that is th correct make file to use. I have built the kernel with IPV6 support, haven't tested it but have attached the module to the post for you to try
Brilliant! I'll try it sometime within the next couple of days, although I might myself be working on a blazing fast kernel specifically for the HTC Kaiser, and it is SERIOUSLY!!!! fast, even at 400MHz I can notice a massive increase in speed with the exact same build, but I haven't economised too much.
I can see the the options for ipv6 in the ncurses menuconfig, so I guess it's just a case of enabling it and building the zImage right?
I seem to be having the old problem with the wifi though, and I know it's kernel related, but there are only patches for it, i.e. the wlan.ko, but can't see how to implement it myself so it's an all-in-one solution
When I get the hang of the Kaiser hardware properly, I might just push through a newer kernel from the armlinux site so watch this space
xteejx said:
I might myself be working on a blazing fast kernel specifically for the HTC Kaiser, and it is SERIOUSLY!!!! fast, even at 400MHz I can notice a massive increase in speed with the exact same build
Click to expand...
Click to collapse
How have you managed that??? What have you done?
I have no idea how it happened, perhaps the other devs add a load of useless options, but all I did was follow the instructions at that link above and compiled a zImage from the 2.6.32 arm branch, using the 2010 arm tools. Used NBHeditor to edit it for Kaiser, panel 2, froyo, flashed it and bang (not literally thank god).
I can't answer any better than that. I used the default options (for now at least) that the vogue build script uses for the kernel, but bluetooth, camera and gps work. No internet connection as yet either through the network or wifi, dumno what I've missed there, and no ipv6 (but can add that easily enough). Wifi doesn't work either, but I'm working on it, although that MAY be the reason why it's so fast...maybe it's missing a few options...still unsure at this point.
I notice that although this is an open community, and people attach NBHs, there are no changelogs or anything showing what the people have done with the kernel to implement some options, so it's kinda holding me back at the minute.
xteejx said:
I notice that although this is an open community, and people attach NBHs, there are no changelogs or anything showing what the people have done with the kernel to implement some options, so it's kinda holding me back at the minute.
Click to expand...
Click to collapse
That isn't true, all tested changes are pushed to git, you can see what has been changed and how from here: http://androidhtc.git.sourceforge.n....git;a=shortlog;h=refs/heads/htc-vogue-2.6.32
*facepalm!*
Didn't see that, will bookmark it and keep an eye on it, perhaps work with it. Thanks for the link
the androidhtc.com site is not related directly to the develop project because no developer is connected to it. Also the git repository it not hosted in linux to go but on sourceforge (so download the correct git). That site is very outdated.
wifi works if you use the correct branch (on sourceforge) and modules.
Am I right in thinking that http://androidhtc.git.sourceforge.n...7c0bf5edc4f5c6d64ce4df29254e8332ce26b;hb=HEAD is the prebuilt kernels and nbhs from the source at http://androidhtc.git.sourceforge.n...og;h=62f075ddd13f378fd252be94c77e4f93d12584fb ??
I think I'm looking at the right tree now.
Flashing the latest NBH: VOGUIMG-320-FROYO-01-16-11.NBH still gives me the wifi error. Do I need to manually add the wlan.ko to it or ??
I could've sworn that an NBH I flashed before had all that in the NBH and it worked fine.
Ok, got it back to how I had it:
Flashed latest.NBH from http://androidhtc.git.sourceforge.n...7c0bf5edc4f5c6d64ce4df29254e8332ce26b;hb=HEAD and dropped androidupdate.tgz to the /andboot folder of the SD card, installed update thru the boot menu and done.
So in reality there's nothing stopping me grabbing the same kernel source, building it and adding ipv6 support in the ncurses kernel config menu and making an NBH from it and flashing that over, and then doing the androidupdate.tgz, although I think with HTCFlasherGUI you can flash a zImage directly right??
Is there something wrong with the git at http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/kernel.git;a=summary I can't get access, it's showing old stuff. It looks closed since git clone rejects me
xteejx said:
Is there something wrong with the git at http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/kernel.git;a=summary I can't get access, it's showing old stuff. It looks closed since git clone rejects me
Click to expand...
Click to collapse
No, nothing wrong with it. Just do:
git clone git://androidhtc.git.sourceforge.net/androidhtc/kernel.git
You then need to set it to the correct branch using 'git checkout -b <branch you want> '
It's the 2.6.32 branch you are interested in, you can find out exactly what it's called using 'git branch -a' which will list the available branches.
Cool. Knew something went wrong somewhere, had to be me lol!
I added that ipv6.ko to the NAND via a androidupdate.tgz (only way I could do it), and it didn't work, something about incorrect module format (or something like that).
Are there any prebuilt kernels or NBHs for the Kaiser that include ipv6? Either as a module that I can insmod it in the terminal or built-in?
I hate being upstaged by people that can use Goggles without any problems.
I know slayher's kernels have ipv6, but I flashed the new stock one from http://forum.cyanogenmod.com/topic/4434-froyo-kernels-by-slayher/ and it didn't work. I mean the kernel did, but Goggles didn't - couldn't insmod it either - same invalid module format as the ipv6.ko scooter did for me
Also the git clone didn't work:
Initialized empty Git repository in /home/name/android-git/kernel/.git/
fatal: The remote end hung up unexpectedly
CPUFreq Successfully Installed and Running
Please visit my website for additional information
After receiving alot of positive results from my Kernel and several releases later. We have arrived at RLS 5.9, a prototype build incorporating CPUFreq for CPU Scaling and Idle control, and a modified version of Power Management. We are at a release stage of this Alpha build, and approaching Beta, where it is as follows:
Each build that is released that has an update to CPUFreq will have an update to the first subversion in the build version (eg. RLS5.9.1.0)
Each build that is released that has an update to Power Management will have an update to the second subversion in the build version (eg. RLS 5.9.0.1)
And of course each upgrade to a specific subsystem of the Kernel will up the version number of that specific subversion.
Current Release: RLS 5.9.2.2
RLS 5.9.2.2 will mark the beginning of the Beta stage out of Alpha stage. This release is showing far more promising results than my initial CPUFreq release.
I just want to personally thank all who have been supporting me and reporting any and all bugs that have been coming in, as I have been squashing them left and right in preparation to improve our Kernel for our phones to make them more feasible for everyday use.
Currently Being Tested:
Power Management - Reverted some old changes to the power management code, switched too Apps Sleep. Made some minor changes to the original pm.c source code and results are promising. Running VanijlEclair RLS11, and in rare cases the phone still crashes while sleeping, which I believe is related to the phone hiccuping when going to sleep, which in theory could completely blow up the timer that Apps Sleep uses for sleeping. I will investigate this part further, but so far, RLS 5.9.2.2 is much more stable than my previous release.
CPUFreq - No changes to the source code, still attempting to modify permissions so Android can modify the files that are required.
HAReT Users - Thanks in large part to V3rt!g(o) HAReT users can now boot the Kernel. I have made a slight modification to the default.txt file provided in the RLS 5.9 HAReT archive that uses Apps Sleep instead of Power Collapse. From what was reported, the Kernel takes about 2 minutes to initialize from WinMo, but after about 1min30sec to 2min, Android should begin loading.
Radio ROM - Currently Testing Radio 1.71.09.01, and so far it seems very stable and provides better battery usage.
Current Release (RLS5.9.2.2):
Kernel - HTC Polaris support re-introduced.
CPUFreq - Has been installed, and working inside the Kernel only. Android does not recognize CPUFreq correctly.
Processor - MSM-7201 processor increased from 384MHz to 528MHz
Stability - Has been improved further. Phone correctly sleeps and wakes properly. Still occasional crash occurs, but is random. Could go a full day without a crash, or could crash every 4hrs. Issue might be related to how much the CPU is being utilized at the time of wake up.
Power Management - Power Management restored to near WinMo states, still not as good as RLS5.7, but within range. Phone will last a full day of occasional use, and about 80% of the day on moderate use.
Initrd - New BootLogo has been made, and inserted into initrd. Unfortunately boot menu is not accessible. Made install scripts to compensate.
YAFFS2 - Exclusively does ECC checking on it's own without any help from the NAND driver. This should help with data corruption, but is not a permanent solution.
YAFFS2 - Disabled Forced erase chunk checking, slight increase in response time and decrease in read-time.
MTD - Disabled Verify NAND Page Writes
MTD - Disabled GPIO NAND Driver
EXT - EXT2 is currently disabled inside the Kernel. EXT4 has been fully enabled, aside from journaling, and is fully supported in the kernel and install scripts.
System - Switched from DG (High Resolution) Timer, to GP (Low Resolution) Timer.
System - Fully disabled High Resolution Timer -- Provided a decrease in kernel size without loss of performance.
sysfs - Enabled configfs. This will unavoidably increase RAM usage, but allow easier access to sysfs.
MSM - Performance Counter Driver enabled.
FrameBuffer Driver - Decreased fake-vsync delay from 10 to 5. Less times snow effect appears.
Known Issues:
Internal CPUFreq coding is unable to scale the processor, but the hacked msm_cpufreq_* functions are able to control the processor speeds. This will explain why CPUTuner and other Android software is reporting the CPU running at max speed. Will continue to investigate and work out problems with the coding.
JIT Compiler causes issues with framework.acore. Avoid using if possible.
CompCache not the cause of untracked PID errors -- Still investigating cause, though now understanding that it is related to data corruption.
Possibly depending on Radio, GPS takes quite awhile to acquire if not at all. -- Will investigate by flashing an older/newer radio.
Standby code not fully working due to being incompatible with clock code changes. Attempting to re-write power management code to be better compatible with the new clocks code.
CPUFreq Specifics:
Governors - Currently CPUFreq supports the following governors and can be changed while in Android using the Terminal: ondemand, conservative, powersave, performance. Userspace is currently disabled inside the Kernel.
Frequencies - Baseline frequencies the CPU will scale to but not limited too are: 81920 (82MHz), 122880 (123MHz), 245760 (246MHz), 384000 (384MHz). These are just placeholders to control where the CPU needs to scale too base on usage, it will go between lets say 82MHz and 123MHz or use one of the two.
Userspace - Until I can verify CPUFreq is fully operational without any issues, I will not enable Userspace Governor at this time.
Kernel Modules
File Attached to this Post, see below.
This Kernel has been tested with the AT&T Tilt variant of the Kaiser. Using it on any other Kaiser would in theory produce the same results, but due to minor changes in the hardware of each variant of the Kaiser, I'm still going to stress caution when using this Kernel with any other variant of the Kaiser
Things to note about EXT4: This file system will increase read/write cycles to your SD Card. Use with caution as it will decrease the life of your SD Card. Though since Journaling is disabled, read/write cycles will have decreased, but they are still higher than what they would be if EXT2 was used. If you do not feel comfortable having EXT4 on your SD Card, do not use this Kernel as there is no way to use EXT2. You have been warned.
Things to take note with this Kernel: Do not enable JIT compiler under Settings, as this has produced constant FCs with the acore framework. It is recommended that you enable CompCache and set it to the default 18%, as this provides a significant performance boost, and decreases Home screen closures while running other apps.
USE THIS KERNEL AT YOUR OWN RISK. I TAKE NO RESPONSIBILITY FOR ANY DAMAGES DONE TO YOUR PHONE WHILE USING THIS KERNEL.
Woohoo ! First Post!
Thank you Krazy-Killa! Will definitely try this now will post after testing!
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Hello Krazy-Killa,
Appreciate your effort !
I just installed it on my TYTN II and so far going well -edited .ngh to change the key mapping to normal.
3G works fine. yet to see BT,WiFi &GPS and overall otherwise.
I have tried Scoot's CM7 RLS1 build 2 days ago.is there any major changes you did - i feel some audio notification alerts changed w. r. t. Scoots.
how can i use those audio files if reqd-i mean can copy&dump to a specific folder and repack.
but its not really matter..
At the moment 'push' works fine and eager to see any 'server connection' problem will occur later with the email client.
i have radio 1.70.19.09
Thanks once again for the post.
Cheers !
cerebralgenius said:
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Click to expand...
Click to collapse
I will release the modules as a seperate androidupdate file this evening.
@chandra_100,
All my testing shows BT, WiFi, and GPS working. This Scoots CM7 build I released is just repackaged with my built modules for easy install.
Sent from my AT&T Tilt using XDA App
“Removed support for HTC Polaris”
That’s too bad,poor Polaris,555555555555555~
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
dark_prince said:
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
Click to expand...
Click to collapse
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Krazy-Killa said:
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Click to expand...
Click to collapse
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
for me kernel can't find data.img
Ive go some kind of problem. Im using fresh froyo and when I installed your modules update than I got hang in boot. Excatly at "adb_open" line. Without update everything is ok except wifi.
Sorry for my poor english
Neo2SHYAlien said:
for me kernel can't find data.img
Click to expand...
Click to collapse
I'll look into it. Though I may know the reason why, so I'll do some more testing, and will release once I have it fixed.
scooter1556 said:
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
Click to expand...
Click to collapse
I'll update my local bootenv, thanks.
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
MaRekRM said:
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
Click to expand...
Click to collapse
That was mentioned in the known issues, don't worry my next release will fix that (currently testing). Plus it'll add full EXT4 support like with clemsyn's kernel but you can format your SD card with the device now as I have updated initrd.
Sent from my AT&T Tilt using XDA App
Flashing
I'll try... flashing right now.
what about ipv6 support?
*EDIT* nevermind, i just saw that ipv6 is implemented.
Cannot restore databackup.img trough install menu...
I think this kernel canot handle the img fs. Mount is failing.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Backup FS
Krazy-Killa said:
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Click to expand...
Click to collapse
Probably the script that is generating databackup.img still using ext2.
tiagoclc said:
Probably the script that is generating databackup.img still using ext2.
Click to expand...
Click to collapse
Yep, it was exactly that. Just made the necessary changes, and compiled a new kernel. I'll go ahead and throw it out, but for now I'll point out that I haven't tested it so, please let me know the results.
Init itself is already setup to mount all loopback and SDcard partitions as EXT4 where applicable.
Just use atools to configure the kernel to use /system and/or /data on NAND or SDCard.
Why did you remove polaris support? I think that are plenty of polaris users that want to test your kernel
Thanks
This kernel is based upon the current git tree for 2.6.27 with minor tweaks included, such as ext4. This is suitable for all devices and should work as well as the autobuild. Please note this isn't an autobuild, so there might be a slight delay between a commit and an update to this thread. Also I do not intend to deviate much from the autobuild other than the changes mentioned below, so if you really need a feature, please include a compelling reason why it should be done.
You will need a new haret.exe as well as an additional line in startup.txt to boot this kernel. Instructions for that can be found at http://forum.xda-developers.com/showpost.php?p=14519408&postcount=1.
Commit 1348 (8/20): http://db.tt/UnLHCuR
Older version: Commit 1346 (8/16): http://db.tt/RhUlSDd
Changes:
Support for ext4 (You must use a rootfs dated 8/16 or later, and have the option ext4dev in your startup.txt cmdline)
Deadline I/O scheduler as default
Sleepmode 1 set by default (No longer needs pm.sleepmode=1 in your startup.txt cmdline)
Ondemand CPU governor minfreq lowered to 112MHz
Powersave and Conservative CPU governor added
Netfilter Redirect added as module
RNDIS set as default for tethering
Swap notifier patch for compcache included and enabled
Most of these changes are in .config, and can be verified by looking at /proc/config.gz in your running kernel. The swap notifier patch allows compcache to skip certain operations, which should improve performance if you do use ramzswap. Ext4 is still considered experimental in the .27 tree, but has been updated with Ted T'so's backport patches in his ext4 git.
Please again note the following on ext4 support:
1) You must use a rootfs dated 8/16 or later for the proper support
2) You must use my kernel, as it is the only one with the required support compiled.
3) You must have the cmdline option "ext4dev" inside your startup.txt. Otherwise it will still continue on using ext2 data.img.
4) Using ext4 will create a brand new file called data.ext4. This is intentional, as I did not want to have the same file (data.img) with different format to confuse the matter further. This also means that none of your existing app/setting will be preserved. Be sure to back up your data & app with something like Titanium Backup, and have at least 500MB free on your SD card so that the system can create a new store.
GPL availability notice:
kernel source as available from http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/commits/htc-msm-2.6.27
compcache module+patch from http://code.google.com/p/compcache/downloads/detail?name=compcache-0.5.4.tar.gz
ti wlan git clone'ed from git://android.git.kernel.org/platform/system/wlan/ti.git
.config used to compile available from within /proc/config.gz
-- Starfox
Just loaded this one up and found something very odd... my ts-calibration was all off... Booted back into WM and deleted and re-calibrated... Still seeing the same issue...
Not sure why a module would do that but just thought I would let you know...
I went back to your 8/15 and 8/16 test kernel and could not even use the slide lock... This one is really wierd... Going to delete my data.ext4 and see if I can resolve that way...
Thanks for all the hard work you've been putting in to come up with these kernels...
Edit: Just saw the update on this page... Thanks...
Sorry about having to pull the file, I've recompiled the whole thing using gcc-4.4 and the touchscreen seems normal again. For those who may have downloaded the first file, please download it again, even if you don't have issues. The correct filesize for the new version is 2460710 bytes.
For the technical-mined out there, the first attempt was compiled using arm-linux-gnueabi-gcc 4.5.2-8 under Ubuntu 11.04 amd64. Certain versions of compiler may introduce bugs where it might over-optimize certain things, and to complicate things, we are trying to make it run under a different architecture. That can introduce unforseen bugs due to endianess, data size differences, etc. that would otherwise not happen. Cross-compiling is a voodoo art at best, and the kernel source tree expands to ~900MB including all the intermediate files produced during the build process.
If you have a Ubuntu 11.04 machine and would like to help me determine if it was actually a cross-compile bug, send me a PM and I'll try to walk you through setting up the build environment and compiling the kernel. Since the bug popped up with the touchscreen, it will be relatively easy to confirm whether the compiler was responsible.
-- Starfox
Hmm - I must be missing something.
It says:
ext2fs_check_if_mount: No such file or directory while determining whether /dev/block/loop0 is mounted.
EXT3-fs (loop0): error: couldn't mount because of unsupported optional features (240)
EXT2-fs (loop0): error: couldn't mount because of unsupported optional features (240)
MILFS: Can't find milfs on dev loop0
mount: mounting /dev/block/loop0 on /dev failed: Invalid argument
Failed
Failed to mount /data (/sdcard/)
Anything I'm missing - I've triple checked all the instructions.
* RHOD100 UK
* Running on SD Card with new Haret and amended Startup.txt
What exactly is in your startup.txt cmdline, and which rootfs are you using?
-- Starfox
Right. So, I went back to the Commit 1346 (8/16) and that went away.
Now I'm getting "ignored duplicate definition of service" and the "request_suspend_state" loops... it might be due to the new Class 10 SD that I'm using for this testing - Going to find an old Class 2 and try again.
FYI - the startup.txt command line is
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 force_cdma=0 msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave pm.sleep_mode=1 hw3d.force=1 acpuclock.oc_freq_khz=716800 ext4dev physkeyboard=rhod100_uk-b4HOME"
rootfs is rootfs-20110816-7e04198.zip
StarFox,
Loading this kernel now to test it out... I've been running your 8/16 test kernel for over two days with only the wifi being a problem. The LEDs have working great!
I'll let you know how this kernel goes... Hopefully better than the Cross-Compiled on I grabbed... LOL
StarFox,
Ran with this kernel through yesterday and into this morning... It all seems stable... However, I did notice longer than normal GPS signal acquisition times. When I was running the 1340 kernel I noticed this too. When I went to your Test 8/16 kernel I was getting a lock much quicker. Going to go back to the 8/16 test kernel to verify this.
Thanks...
bughunt said:
Now I'm getting "ignored duplicate definition of service" and the "request_suspend_state" loops... it might be due to the new Class 10 SD that I'm using for this testing - Going to find an old Class 2 and try again.
FYI - the startup.txt command line is
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 force_cdma=0 msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave pm.sleep_mode=1 hw3d.force=1 acpuclock.oc_freq_khz=716800 ext4dev physkeyboard=rhod100_uk-b4HOME"
Click to expand...
Click to collapse
Okay, first, you're running a class 10 card with 1-bit and 14Mhz freq. Take these ones out: force_cdma=0 msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave hw3d.force=1
You can take this one out if running my kernel:
pm.sleep_mode=1
How old is this startup.txt? These are values that have not been used for a while.
-- Starfox
Update to build 1348, the new liblights will require you to have it bindmounted.
I'd appreciate if people would post different machines this has successfully worked on. I know it works on Rhodium, looking for Diamond/Raphael/users. Thanks.
-- Starfox
Starfox said:
Okay, first, you're running a class 10 card with 1-bit and 14Mhz freq. Take these ones out: force_cdma=0 msmsdcc_1bit msmsdcc_fmax=14000000 msmsdcc_nopwrsave hw3d.force=1
You can take this one out if running my kernel:
pm.sleep_mode=1
How old is this startup.txt? These are values that have not been used for a while.
-- Starfox
Click to expand...
Click to collapse
Right - that's fixed. It now boots up and seems a bit more snappy than before.
do you have to format a partition off of your sd card to ext4 before using this?
AkumaX said:
do you have to format a partition off of your sd card to ext4 before using this?
Click to expand...
Click to collapse
Nope, it will create a data.ext4 file that is the data.img, but in ext4 instead of 2.
My Rhodium is rebooting when I turn on Wifi. Radio is 3.44.25.27 running GBX0A (11.3.2011).
bughunt said:
My Rhodium is rebooting when I turn on Wifi. Radio is 3.44.25.27 running GBX0A (11.3.2011).
Click to expand...
Click to collapse
Rebooting to WinMo?
Have you tried on FRX07?
Which RHOD? I'd guess 100 from your carrier.
Edit - logs would be helpful, if you have any. On a reboot to WinMo, /data/system/dropbox logs are the only option (other than ramconsole)
arrrghhh said:
Nope, it will create a data.ext4 file that is the data.img, but in ext4 instead of 2.
Click to expand...
Click to collapse
cool, i'll try out this testing when i figure out where all my microsd cards went...
Move Panel to PLL2 and add 1056MHz Option. If you don´t know how? then ask me
EDIT: What about editing Neopeeks CWM recovery to change Data.ext4 to a real ext4 partition?
BlackRainX said:
Move Panel to PLL2 and add 1056MHz Option. If you don´t know how? then ask me
EDIT: What about editing Neopeeks CWM recovery to change Data.ext4 to a real ext4 partition?
Click to expand...
Click to collapse
You'll have to explain the panel one to me, but not sure what the 1056MHz option would do for this kernel.
Also, this is xdandroid kernel, not CWM. And data.ext4 is a real ext4 partition. It's only ext4dev because .27 was before ext4 was "official".
-- Starfox
BlackRainX said:
Move Panel to PLL2 and add 1056MHz Option. If you don´t know how? then ask me
EDIT: What about editing Neopeeks CWM recovery to change Data.ext4 to a real ext4 partition?
Click to expand...
Click to collapse
Blackra1n,to have a partition in cwm as ext4 you just need to change a few things in rootfs
Starfox said:
You'll have to explain the panel one to me, but not sure what the 1056MHz option would do for this kernel.
Also, this is xdandroid kernel, not CWM. And data.ext4 is a real ext4 partition. It's only ext4dev because .27 was before ext4 was "official".
-- Starfox
Click to expand...
Click to collapse
Panel if run from pll1 gets weird with gpu overclocked,so Blackra1n moved the panel to pll2,from what user reported the panel works well now and there's more speed,if you need more infos,pm me or blackra1n(I'm on #xdandroid in the afternoons)
More infos here
Please describe how panel gets "weird", because this is the first time I've heard of it. Rhodium by default runs at 960mhz pll from what I've seen. And there seems to be no way to conclusively test what freq a pll runs at - from a quick glance of the thread mentioned I saw some "tests" of factors other than a simple freq change - ie, I saw mention of JIT being enabled for the "overclocked" one, which does not help.
-- Starfox
Drop this file in your /system/etc folder, replacing the stock one. Cleaned up, and modified to work with a stock kernel or lean kernel.
Please open up the file, and read some of the notes I added, so you know what this does and how to change it if you so desire. It is very basic and straightforward.
Also, please remember one thing, if you want to go to the stock kernel, simply change any words in the scripts from "interactiveX" to "interactive".
Recommended lean kernel 3.16 with these scripts.
Designed to work with ALL Galaxy Note 3's running touch wiz 4.4.2 ROMs and running lean kernel or stock kernel. Other kernels are not guaranteed due to the voltages applied.
This will make a huge difference in performance and battery. Been using this (developed by me) for a long time now.
Summary:
*I/O optimization
*tuned interactive parameters
*fixed sysfs permissions for cpu's (root now has full control of sysfs tuneables)
*GPU sysfs identified for user to customize
*screen off frequency set to 1.2 GHz (can be changed by user)
*custom voltage set for bin 2 device. (Read instructions within file to adjust for others bins accordingly)
*custom mpdecision tuning and other relevant instruction regarding mpdecision binary
*general CPU tweaks for better performance, responsiveness and battery life (yes all 3 can be achieved, and are)
Again, open the file with a file explorer (or notepad+ in windows). Read it, understand it, adjust what you want, or leave it be. These settings are very much dialed in for the interactiveX governor of LK. It won't get much better. I'd say take a look at the voltage portion and mpdecision for now (found at the end).
Once more, drop file into the /system/etc directory... Replace the existing one, and reboot.
FILE DOWNLOAD
Updated today... many useful changes, and fixes (set up for stock kernel for now)
https://www.dropbox.com/s/tjlygujptls3lks/init.qcom.post_boot.sh?dl=0
Reserved for any common questions, or general information.
red_can_soda said:
Reserved for any common questions, or general information.
Click to expand...
Click to collapse
Nice bud, I'll have to see if it works on Lollipop TW
Using it in pvs bin 0 lol
So far so good. Make sure to set permissions to 755
i'll have to see if theres a difference between replacing the current file.... or firing it off in init.d
kevp75 said:
i'll have to see if theres a difference between replacing the current file.... or firing it off in init.d
Click to expand...
Click to collapse
Needs to be done post boot, otherwise the stock "post_boot" file does what it does post boot. Make sense?
Init.d executes earlier in the boot sequence. Therefore, some of the parameters will be overridden.
red_can_soda said:
Needs to be done post boot, otherwise the stock "post_boot" file does what it does post boot. Make sense?
Init.d executes earlier in the boot sequence. Therefore, some of the parameters will be overridden.
Click to expand...
Click to collapse
ehh but those if us who need a hack for init.d runparts inside this script (u have it in yours as well)
i have it in my init.d and it appears (notice the appears) to be working.
Im definately noticing a bit more responsiveness... as well I toned down the screen off max freq a bit and am getting pretty decent battery life.
kevp75 said:
ehh but those if us who need a hack for init.d runparts inside this script (u have it in yours as well)
i have it in my init.d and it appears (notice the appears) to be working.
Im definately noticing a bit more responsiveness... as well I toned down the screen off max freq a bit and am getting pretty decent battery life.
Click to expand...
Click to collapse
Forgot I had that there... Lol. Threw that in a while back so init.d would operate with a 100% stock boot.img
@kvp75, can I drop this into Phoenix Rom?
Chefedogg said:
@kvp75, can I drop this into Phoenix Rom?
Click to expand...
Click to collapse
It will work with any galaxy note 3 using Qualcomm hardware.
Chefedogg said:
@kvp75, can I drop this into Phoenix Rom?
Click to expand...
Click to collapse
shuld be able to... but dont really need to. phoenix has cpuntweaking built intobthe settings doesnt it?
sry been workin on DomPop
red_can_soda said:
Drop this file in your /system/etc folder, replacing the stock one.....
Click to expand...
Click to collapse
Lmao....Cob
kevp75 said:
shuld be able to... but dont really need to. phoenix has cpuntweaking built intobthe settings doesnt it?
sry been workin on DomPop
Click to expand...
Click to collapse
All good, I went ahead and did it anyway, it's def making a difference, battery life was not great but now it's better! Thanks for all the hard work guys, keep it up! I'll reflash DomPop again soon, it was unstable for me but Phoenix has been great
This activated all cores and set to performance... when i selected interactive the min value was 422... Am I doing something wrong? Everything stock and rooted 442
Edit. .. Ok I changed from interactivex to interactive and that fixed gov problem but all cores activated and min set to 422... Is that right?
Yes, minimum is 422 MHz because the l2 cache is bumped into action at that speed (as opposed to not being so at 300) and the voltage is the same.
In short, 300 is no5 used because 422 is faster, and without the extra hit on battery
Will this work with 4.4.4 w/o any issues? Been thinking on trying it on but I don't want it to mess anything and re-install stuff.
d-wad,
I cannot give you a definite answer there, as I have not yet looked at anything in 4.4.4.
If you can provide me a copy of the post_boot file for 4.4.4, I can take a look at it and see. I can't imagine why anything would have changed in this file, but you never know. All it takes is one line of code to cause something to go a little wonky for you.
Thanks, and just shoot me a PM.
Just giving you all a heads up.... I think there may have been a few errors in the stock init.qcom.post_boot file (they are human too, remember).
I am testing a few small changes to certain lines in the "factory" script to make sure. A brief explanation of it is that there are certain lines I removed from the one you all are using right now, and I did so because the file paths being called out did not exist!
However, I was going over this again tonight, getting ready for the official LP release and decided to review this odd discrepancy one more time. After doing some digging, I found that the file that some of those values were intended to be written to, were actually somewhere else!
Doh! - Sammy/QC. It is very possible that this location changed from a previous design or fs structure and somebody simply forgot to modify the script. Very interesting indeed.
Anyways, after I run this for a couple of days and do a little bit more investigating, I'll post the updated script for all of you.
Updated file and link... I recommend using this file or implementing these items into your current set up. Many of the changes are critical errors existing in the stock post_boot file, or simple optimization enhancements for our devices.
How to revert?
Sorry... TOTAL NOOB here...Do I just copy the orig file somewhere else, and drop this in place as you instruct? ( may have answered my own Q)
Seems a wise precaution.
I am running effortless rom rev 8 (lovin it too)
EDIT: I want to remind everyone DO NOT FILE AN UBUNTU BUG REPORT WITH THIS KERNEL INSTALLED, ALWAYS REVERT BACK TO THE STOCK KERNEL IF YOU HAVE AN ISSUE BEFORE FILING
This is my first actual Kernel project, so please be gentle.
This kernel is ONLY for the Nexus 7 (2013) flo. I do not know if it boots on the deb, theoretically it should as I don't have any flo specific options and there are config options for Deb in the Kernel configuration. It should work for those on stable, rc or rc-proposed and may possibly work on devel (not sure) as long as devel has not released a new kernel package (3.4.0-5-flo+)
I have cherry-picked some battery optimizations from bricked-flo, elementalx-flo (4.4 branch) and some additional commits elsewhere in an attempt to not only improve battery-life but also to bring some Android features (DoubleTap2Wake) to Ubuntu Touch.
Currently it has the following:
- ROW I/O scheduler
- Beginnings of OCing (pulled from ElementalX, I think I'm missing some commits to make this relevant though)
- ElementalX's kernel thermal control
- binfmt_misc support
- CD/DVD Filesystem Support for external optical drives (ISO9660/UDF)
- Some Slimbus enhancements
- Battery life optimizations (changing default MHz, etc.)
- Default CPU governor changed from Performance to Interactive (yes, they had it set to Performance, not sure why.)
- Direct Rendering Interface/Direct Rendering Manager (XFree86 + msm_kgsl_drm)
- and more!
You can check my github for the items cherrypicked into it and there is even a current release which has seen my battery drop 4% in the last 30 minutes with the screen fully on (no autolock), WiFi on and Bluetooth.
The name of the kernel is still up for change, TonoKrnl is not going to be it's final name unless everyone likes it.
Repository is at: http://github.com/ShadowEO/TonoKrnl
Releases can be found: https://github.com/ShadowEO/TonoKrnl/releases
Status of Github Repo: It builds. It boots and it runs. I am trying my hardest not to push changes that break building.
Reserved for future use. Currently the status of the kernel's updates can be found on the issue tracker: https://github.com/ShadowEO/TonoKrnl/issues/5
Be patient, if you don't see new releases right away, it's because I'm still in the process of generating them, check back later.
-- Release 1.0.3-UBports (11/19/2017): A lot was done to bring this kernel back into usable state, see below:
Added OTG Charging
Added initscripts for turning on features (Requires the rootfs to be mounted read/write for manual installation, see my latest post #16 I think...)
Created patches to be applied against a clean UBports kernel tree for certain features (right now, only DT2W and USB Charging)
(USB Host Charging was pulled from flar2's ElementalX source code, it is not turned on by default and can be turned on with
Code:
echo 1 > /sys/module/msm_otg/parameters/usbhost_charge_mode
Feature is tested and does work.
Developers:
1.0.3 brought the kernel tree back into a buildable state and also cleaned up some problems with the previous releases. I am in the process of generating a kernel patchset which will be able to be applied to a clean kernel to bring those features to the stock UBports kernel source. After I complete generating the kernel patchset, I will be rebasing the entire kernel project onto a clean tree (As I am absolutely certain that I have problems like unfinished cherry-picks [missing commits] etc.). Be patient regarding these patches, as I am re-adding the features I pulled in originally by hand rather than cherry-picking them as I appear to have fuxxed up somewhere cherry-picking previously.
If you have any random reboots, try:
Code:
echo 1 >/sys/module/msm_watchdog/parameters/runtime_disable
If you still receive random reboots afterwards or if you received them previously but the above command fixes them, please open an issue on my project tracker with a copy of /proc/last_kmsg attached.
Kernel TODO:
Generate kernel patchset and then rebase onto clean kernel tree
Finish Kernel Feature Documentation and publish (these docs will give information on tweaking the changes to the kernel, such as readahead buffer, turning on/off DT2W, turning on/off usbhost charging, etc.)
Move TonoKrnl initscripts into ramdisk, should make them more robust and reliable.
Create ZIP installer for TWRP recoveries (this is needed for automatic installation of kernel modules, since /lib/modules is a read-only, bound mountpoint for the Android LXC container. To fix this, we just have to move /lib/modules out of the Android container.
Allow me two questions:
Which kernel repository is this branched off? Apologies if that is dumb question, my git and kernel knowledge is cursory at best, but I can't seem to figure this out looking through your github repo.
ShadowEO said:
- Direct Rendering Interface/Direct Rendering Manager (XFree86 + msm_kgsl_drm)
Click to expand...
Click to collapse
What's the intention behind this? Does this have anything to do with enabling the freedreno driver for the GPU and would that pave a way to a setup without Mir, but with wayland or X?
doniks said:
Allow me two questions:
Which kernel repository is this branched off? Apologies if that is dumb question, my git and kernel knowledge is cursory at best, but I can't seem to figure this out looking through your github repo.
What's the intention behind this? Does this have anything to do with enabling the freedreno driver for the GPU and would that pave a way to a setup without Mir, but with wayland or X?
Click to expand...
Click to collapse
This started off with the debian source package for linux-image-flo in the Ubuntu archives which is the kernel for our device. The reason you are having trouble with figuring it out is because I started with the base (Ubuntu's 3.4.0-5-flo+), pulled it into an empty git repo and then started cherry-picking features. It was originally going to be for my own personal consumption as I didn't know how well a custom kernel would be received by the touch community (so far, in all the communities I've posted it, you were the only one to ask any questions ), but since I already had a git repo up, figured that I may as well share it. So here I am, an amateur working on the Linux kernel, and learning a lot.
My full intent was to improve the experience (even marginally) on Ubuntu Touch for the Nexus 7 2013, I wanted to bring the mobile kernel features previously found on the desktop that myself or others may find useful (hence binfmt support for qemu-user), there really is no reason for me to turn on DRI/DRM except to allow playing with Wayland and X, yes, that part is correct, and I have tested the freedreno driver with it (Freedreno does get the KGSL DRI device and does start X)
In addition I found some interesting choices in the kernel in terms of battery life, it would seem that the CPU governor used by the default Ubuntu Kernel is Performance, which would explain why the battery dies so fast, I tried to pull in some battery optimizations from a couple other kernels around the Android scene for the device. So far I'm pleased with the results, and recently found that both the original cherry-picking done for DT2W worked along with the code to add fast charging.
I've had to put the project on hold due to work issues, but once I'm able to work on it again, I'm reverting the last 100 changes pulled in that broke my tree and going from there since my original targets in terms of features actually worked. (I'm pretty sure it was some recent changes to the CPU hotplug driver that killed it, I can no longer compile the kernel without mpdecision on, so that's my likely suspect.)
Thanks for your explanations!
ShadowEO said:
This started off with the debian source package for linux-image-flo in the Ubuntu archives which is the kernel for our device.
Click to expand...
Click to collapse
So something like apt source linux-image-flo? And then to build you use the instructions in the package also?
there really is no reason for me to turn on DRI/DRM except to allow playing with Wayland and X, yes, that part is correct, and I have tested the freedreno driver with it (Freedreno does get the KGSL DRI device and does start X)
Click to expand...
Click to collapse
Exciting!
In addition I found some interesting choices in the kernel in terms of battery life, it would seem that the CPU governor used by the default Ubuntu Kernel is Performance, which would explain why the battery dies so fast
Click to expand...
Click to collapse
I'm really only speculating, but my conjecture to previous mentions of odd govenor choices in android kernels was that the actual android power management magic is happening behind the backs of the governors. But, I'm really just babbling. I don't know much of anything about this. You seem to be getting impressive improvements!
I'm reverting the last 100 changes pulled in that broke my tree and going from there since my original targets in terms of features actually worked.
Click to expand...
Click to collapse
So, that means: "If you want to try it now, don't use v1.0.2, but use v1.0.2-alpha for now." Is that about correct?
doniks said:
Thanks for your explanations!
So something like apt source linux-image-flo? And then to build you use the instructions in the package also?
there really is no reason for me to turn on DRI/DRM except to allow playing with Wayland and X, yes, that part is correct, and I have tested the freedreno driver with it (Freedreno does get the KGSL DRI device and does start X) Exciting!
In addition I found some interesting choices in the kernel in terms of battery life, it would seem that the CPU governor used by the default Ubuntu Kernel is Performance, which would explain why the battery dies so fast
I'm really only speculating, but my conjecture to previous mentions of odd govenor choices in android kernels was that the actual android power management magic is happening behind the backs of the governors. But, I'm really just babbling. I don't know much of anything about this. You seem to be getting impressive improvements!
I'm reverting the last 100 changes pulled in that broke my tree and going from there since my original targets in terms of features actually worked. So, that means: "If you want to try it now, don't use v1.0.2, but use v1.0.2-alpha for now." Is that about correct?
Click to expand...
Click to collapse
I removed the problem download, the only ones available are the source tree downloads and the last known good build I had, I have also tested to ensure that the last build up there works as well as it's the one I'm running on my device until I have time to go through the tree again.
As for building, essentially yes, but you have to build the image separately. Due to how Ubuntu currently has the filesystem set up and with Android's boot images, its not feasible to really package it in a traditional sense. Essentially what I did was create a chroot, apt-get source linux-image-flo and then to get a working defconfig I used the config.* files found in Debian.flo and Debian.master, from there was the tree that I used as my base.
Then run make with the following to customize:
Code:
ARCH=arm make menuconfig
ARCH=arm make -j <number of processors>
To build the image, you'll need to grab the boot image from your device and tear it apart using a abootimg them rebuild it with the Ubuntu ramdisk. If you are using MultiROM, you can just drop it in the folder for your ROM.
Edit: As for the weird choice of governors, I noticed during my investigations (via the cpufreq-info package) that while Android is managing the CPUs that are online (I found it's running it's own version of mpdecision behind the scenes inside the LXC container), it's not doing anything to the CPU governor. That's all managed in the kernel right now through CPUFreq it appears and in the stock kernel it's set to performance, as for the reason for it, I'm not sure myself.. The other governors ARE there though, just unused right now.
ShadowEO said:
This kernel is ONLY for the Nexus 7 (2013) flo. I do not know if it boots on the deb, theoretically it should as I don't have any flo specific options and there are config options for Deb in the Kernel configuration.
Click to expand...
Click to collapse
Jup, it does boot on my deb! I've downloaded the .img, put the tablet in bootloader mode and did
fastboot boot TonoKrnl-1.0.2-flo.img
It booted without problems, and so far it's running for about half an hour or so without any problems. Wifi, sound, video, usb mouse, all work fine.
doniks said:
Jup, it does boot on my deb! I've downloaded the .img, put the tablet in bootloader mode and did
fastboot boot TonoKrnl-1.0.2-flo.img
It booted without problems, and so far it's running for about half an hour or so without any problems. Wifi, sound, video, usb mouse, all work fine.
Click to expand...
Click to collapse
Wow, that's great to hear, I wasn't sure but I was definitely curious since I had seen options for both Deb and Flo in the makeconfig page.
If you can script it in (or edit sysfs.conf) to have it write a 1 to /sys/android_touch/doubletap2wake while it's booting, you can have working DT2W and there's quite some others to mess around with under /sys :3 CPU governors are somewhere there too, just don't have it offhand.
Since you are testing it out, have you noticed any changes in the device's normal battery life? The stock kernel seems to drain 1% every 1 1/2 minutes on my Flo, not doubting that the power optimizations ARE working (I know I'm getting much better life), I'm just wanting to ensure that it's not a placebo effect that I'm experiencing.
ShadowEO said:
If you can script it in (or edit sysfs.conf) to have it write a 1 to /sys/android_touch/doubletap2wake while it's booting, you can have working DT2W
Click to expand...
Click to collapse
After
Code:
echo 1 | sudo tee /sys/android_touch/doubletap2wake
I can indeed (sometimes) wake it with double tapping. I have since quite a while (with the standard kernel) the situation that its really hard to wake up. I have to press the powerbutton many many times. Feels like it is sleeping really deeply.
Since you are testing it out, have you noticed any changes in the device's normal battery life? The stock kernel seems to drain 1% every 1 1/2 minutes on my Flo, not doubting that the power optimizations ARE working (I know I'm getting much better life), I'm just wanting to ensure that it's not a placebo effect that I'm experiencing.
Click to expand...
Click to collapse
Well, I haven't noticed anything. I might just not be in the best position to judge. I rarely have it unplugged for more than a couple of hours at a time and I don't generally monitor the battery status closely. That being said though, I have very definitely never experienced anything remotely close to 1% per 1.5 min!
If you have a particular test/measurement you'd like to see - let me know.
doniks said:
After
Code:
echo 1 | sudo tee /sys/android_touch/doubletap2wake
I can indeed (sometimes) wake it with double tapping. I have since quite a while (with the standard kernel) the situation that its really hard to wake up. I have to press the powerbutton many many times. Feels like it is sleeping really deeply.
Well, I haven't noticed anything. I might just not be in the best position to judge. I rarely have it unplugged for more than a couple of hours at a time and I don't generally monitor the battery status closely. That being said though, I have very definitely never experienced anything remotely close to 1% per 1.5 min!
If you have a particular test/measurement you'd like to see - let me know.
Click to expand...
Click to collapse
I may be exaggerating slightly, but normally my tablet goes from 100% to 95% in about 5 minutes while I'm using it after taking it off the charger (in Ubuntu only, may be an rc-proposed thing too). I haven't seen that behavior since changing kernels. I'm gonna see if I can go ahead and start reverting commits today or possibly reset back to the last known good commit.
As for the screen problems, I think there is a bug in the current doubletap2wake driver, if you look at dmesg after using DT2W for a while, you'll see it being spammed with error messages from the touchscreen driver.
That could possibly be related. Additionally, I think the minimum processor speed defaulted to 384MHz (I didn't touch any processor clock speeds in here) which the Performance governor would never had let the processor hit. So it's likely that the minimum processor speed will need bumped up at least one step there, I get some stuttery behavior on the command line when the screen is off which I hadn't received on the stock kernel.
Edit (07/01/16): I'm not sure what else I can really bring to the table here, mpdecision running in the android LXC container defeats any meaningful changes to the clock speed. I also noticed mention that you shouldn't have two hotplugging daemons running at the same time, effectively that is what the new developments would've brought in. I think my best option to continue this would be to wait until the Xenial transition and see if they make any changes for me to update on.
I'm also quite a novice, so besides cherry picking commits, I'm not sure what else I can do.
ShadowEO, is bluetooth working on your device? With your kernel or with the one from Canonical?
I can't seem to get anything at all to show up on my deb.
I am so embarrassed that I didn't check this thread in so long. Ya, Bluetooth still works on my device with either kernel. Sometimes it doesn't seem to like to power on, so if you are having trouble, try this.
Open Terminal,
do sudo bluetoothctl and see if Nexus 7 (2013) shows up in there. If it does, type power on and hit enter. You should see the bluetooth indicator show up in the status bar. If it doesn't, exit bluetoothctl and do these from a root prompt:
start bluetooth-touch
start bluetooth-touch-flo
Sometimes the commands may take a little bit of time (no idea why honestly), but after those, you should see bluetooth start. At that point, if you still don't, fully power the device down and try again.
For whatever reason, the bluetooth scripts fail every so often, haven't been able to look into it much due to personal things IRL taking up all my time the last few months.
It's been a long while since I touched this project, but I have finally cleaned up the kernel source tree and ensured that it builds properly!
Two features that must remain disabled however are GOVERNOR_ELEMENTALX and MSM_SLEEPER as they are currently broken and do not function as of right now. The defconfig for flo also has sane defaults for the UBports Ubuntu Touch distribution (installable via the UBports installer application) and has DT2W enabled (but not turned on, that requires some extra work) by default.
You should also no longer need to disable the MSM watchdog using the instructions in the OP, running the kernel now and haven't experienced near as many random reboots I used to with the previous version! (I wonder if that was a UTouch problem, because I DO get random reboots sometimes using certain apps, but they're very rare... Then again, I'm not sure if UBports made any initramfs changes for the Flo when they added it to their system-image server, which they may have, since it's in the ubports-touch/15.04 distribution instead of their ubuntu-touch mirror for older, no-longer supported devices)
To turn on DT2W, you must follow the instructions on the github page for the 1.0.2 release.
NOTE: I highly recommend building the kernel from source rather than downloading a release! I have yet to add the current stable release to the github releases page! I also have a zip file with some helper scripts and configuration that can be installed into the UBports rootfs to turn DT2W and Kernel Samepage Merging on at startup. In case that's useful, I'm adding the zip to this post. To install, simply remount your root as read/write, extract the ZIP to / and then "chmod +x /sbin/tonokrnl-init" and reboot. Upon reaching the lightdm greeter, you should be able to shut the screen off, then double tap it to wake.
The files contained in the zip are:
/sbin/tonokrnl-init - Helper Script to start DT2W and KSM
/etc/sudoers/tonokrnl - Allows the user-session upstart config to run the helper script, which requires root.
/home/phablet/.config/upstart/tonokrnl.conf - Upstart configuration to run /sbin/tonokrnl-init using sudo (requires the sudoers file)
Off-topic slightly: The reason this project got set aside, was due to my IRL work, and because I had stopped using Ubuntu Touch and was testing out other ways of getting Linux onto the N7 'flo'. I messed with the Sailfish distribution found in the Nexus 7 2013 forum, then went to postmarketOS and messed with that (it's cool, but rather bare, not enough desktop packages to make it useful [no osk, etc]), then attempted to boot a debian distribution with the Linaro mainline kernel from John Stultz (couldn't even get X11 to start, the system did boot though! Perhaps mesa/libdrm needed recompiling with freedreno support...) and then finally came back to Ubuntu Touch via UBports!
Back on Topic, if you decide to use this kernel (either by building it yourself, or using the new UBports-1.0.3 release that will go up soon!) and install the attached helper scripts (or even find your own solution to on-boot DT2W, KSM, and the Interactive governor) please let me know your experiences! I noticed after turning KSM on that the web browser didn't crash as much, but I'm not sure if it's a placebo effect or not.
(I wonder if @flar2 has a 3.4.0 patchset I can apply rather than attempting to cherry-pick ElementalX into the kernel... That would be amazing to have ElementalX's additions to the kernel under Ubuntu Touch. [Please don't be angry I used a mention flar, I just wanted to ask if you had a patchset for the flo's kernel [version 3.4.0])