Hello,
My goal is to compile rowboat ( froyo) for the NC.
To start, I'm trying to compile u-boot for NC with the sources provided by B&N with no luck
I tried with omap3621_boxer_config with no luck. I had some errors at compilation.
Once fixed ( with few hacks) I've got a small u-boot.bin (about) 160Kb whereas stock u-boot is 280 kb.
What' wrong ? I think the sources don't match the NC binaries.
Occip
Try omap3621_evt2_config.
pokey9000 said:
Try omap3621_evt2_config.
Click to expand...
Click to collapse
I don't find this config in u-boot .
There are only
omap3621_boxer
omap3621_edp1
omap3621zoom3
Did you successfully compile u-boot with the sources ?
Occip
Look at the makefile, not the headers.
Rowboat Wiki http://code.google.com/p/rowboat/ misses completely OMAP36xx chips out of its builds for some reason (Motorola took them?).
In other words, building for OMAP35xx may cause some problems/performance issues.
Sure I can be completely wrong, just disregard this.
----------------
fineoils.blogspot.com
"NooKColor: Next Step"
Any reason you're going rowboat rather than http://omappedia.org/wiki/Android_source_code_versions?
As I posted elsewhere, my brain was faulty earlier, the correct target is omap3621_evt1a_defconfig for the kernel, omap3621_evt1a_config for u-boot and x-loader.
For fun, in the kernel I tried faking out the 3621 detection so it believes it's a 3630. Someone earlier (I can't remember) noticed that Nooter was showing bogomips in like with 1GHz, and since I built it for a 3630 target I was hoping the same would apply here. It looks like the top 2 power states are ignored with the 3621, while the 3630 gets all 5.
I get 7.598 MFLOPS in Linpack with this change vs 6.133 with the old; and 1094 in Quadrant vs. 981 with the old. The downsides are that the core gets cranked up to 1.35V vs. 1.26V at 800MHz, and my touchscreen got a lot less responsive. The former is probably not a big deal since most of the time the CPU is not running full out.
The patch:
Code:
diff -Naur arch/arm/mach-omap2/board-3621_evt1a.c ../dev/kernel/arch/arm/mach-omap2/board-3621_evt1a.c
--- arch/arm/mach-omap2/board-3621_evt1a.c 2010-11-25 14:49:49.000000000 -0600
+++ ../dev/kernel/arch/arm/mach-omap2/board-3621_evt1a.c 2010-12-05 20:45:28.537597020 -0600
@@ -624,20 +622,20 @@
{
#if defined(CONFIG_MACH_OMAP3621_EVT1A) && defined (CONFIG_MACH_SDRAM_HYNIX_H8MBX00U0MER0EM_OR_SAMSUNG_K4X4G303PB)
omap2_init_common_hw( h8mbx00u0mer0em_K4X4G303PB_sdrc_params ,
- omap3621_mpu_rate_table,
- omap3621_dsp_rate_table,
- omap3621_l3_rate_table);
+ omap3630_mpu_rate_table,
+ omap3630_dsp_rate_table,
+ omap3630_l3_rate_table);
#elif defined(CONFIG_MACH_OMAP3621_EVT1A) && defined(CONFIG_MACH_SDRAM_HYNIX_H8MBX00U0MER0EM)
omap2_init_common_hw( h8mbx00u0mer0em_sdrc_params ,
- omap3621_mpu_rate_table,
- omap3621_dsp_rate_table,
- omap3621_l3_rate_table);
+ omap3630_mpu_rate_table,
+ omap3630_dsp_rate_table,
+ omap3630_l3_rate_table);
#elif defined(CONFIG_MACH_OMAP3621_EVT1A) && defined (CONFIG_MACH_SDRAM_SAMSUNG_K4X4G303PB)
omap2_init_common_hw( samsung_k4x4g303pb_sdrc_params,
- omap3621_mpu_rate_table,
- omap3621_dsp_rate_table,
- omap3621_l3_rate_table);
+ omap3630_mpu_rate_table,
+ omap3630_dsp_rate_table,
+ omap3630_l3_rate_table);
#endif
omap_init_irq();
omap_gpio_init();
diff -Naur arch/arm/plat-omap/include/mach/cpu.h ../dev/kernel/arch/arm/plat-omap/include/mach/cpu.h
--- arch/arm/plat-omap/include/mach/cpu.h 2010-11-25 14:49:49.000000000 -0600
+++ ../dev/kernel/arch/arm/plat-omap/include/mach/cpu.h 2010-12-05 21:10:15.878587990 -0600
@@ -221,7 +221,8 @@
# endif
#endif
-#if defined(CONFIG_MACH_OMAP3621_BOXER) || defined (CONFIG_MACH_OMAP3621_EVT1A) || defined(CONFIG_MACH_OMAP_3621_EDP)
+//#if defined(CONFIG_MACH_OMAP3621_BOXER) || defined (CONFIG_MACH_OMAP3621_EVT1A) || defined(CONFIG_MACH_OMAP_3621_EDP)
+#if defined(CONFIG_MACH_OMAP3621_BOXER) || defined(CONFIG_MACH_OMAP_3621_EDP)
# undef cpu_is_omap3621
# define cpu_is_omap3621() 1
#endif
Thanks !
Thanks to pokey9000!
It's ok for the evt1 config.
For fun, in the kernel I tried faking out the 3621 detection so it believes it's a 3630. Someone earlier (I can't remember) noticed that Nooter was showing bogomips in like with 1GHz,
Click to expand...
Click to collapse
It was me
I remember that with my igep020 (omap3430) a simple mw command within u-boot could set the frequency of the MPU (and not overrided by the kernel).
After some digs in the kernel, it seems the BT could be enabled easily.
Cheers Occip
occip said:
I remember that with my igep020 (omap3430) a simple mw command within u-boot could set the frequency of the MPU (and not overrided by the kernel).
Click to expand...
Click to collapse
I couldn't make heads or tails of the clock tree code in u-boot and decided to go for broke turning off the 3621 specific code. I still don't know about the touchscreen thing, but I realized that I was comparing the stock kernel against this one. I've rebuilt the kernel from BN's code as provided and will see if the touchscreen is still wonky when I get home.
occip said:
After some digs in the kernel, it seems the BT could be enabled easily.
Click to expand...
Click to collapse
I tried uncommenting the code surrounded by CONFIG_WL127X_RFKILL, and fixing up the GPIO to the one defined right above it, and I get a driver segfault on boot. I guess for starters it makes more sense just to force it on in u-boot.
This page may be helpful.
ft
Overclocking and undervolting
Hi,
I manage to tweak few parameters with the help of pokey9000 code. Now 5 levels are enabled (OPP1 --> OPP5 , 300,600,800,1000,1100 Mhz). it runs pretty fast (same score as droid X in quadrant benchmark). I also tweaked the voltage at every level. At 600Mhz , the MPU has a voltage of 0.850 v (1.1v instead, 30 % decrease), I will check for increased autonomy.
So my omap 3621 seems to be a good production batch item.
Now direction to kernel 2.6.32 with droidX kernel sources (mapphone_defconfig)...
Cheers
Occip
Very good news...
Thanks Occip
occip said:
I manage to tweak few parameters with the help of pokey9000 code. Now 5 levels are enabled (OPP1 --> OPP5 , 300,600,800,1000,1100 Mhz). it runs pretty fast (same score as droid X in quadrant benchmark). I also tweaked the voltage at every level. At 600Mhz , the MPU has a voltage of 0.850 v (1.1v instead, 30 % decrease), I will check for increased autonomy
Click to expand...
Click to collapse
Nice! Did you work around the check for the OPP5 fuse? It's not fused on my NC's OMAP, and when I ignore it to get 1.2G it falls over. I didn't make any changes to the OPP freq/voltage settings though.
pokey9000 said:
Nice! Did you work around the check for the OPP5 fuse? It's not fused on my NC's OMAP, and when I ignore it to get 1.2G it falls over. I didn't make any changes to the OPP freq/voltage settings though.
Click to expand...
Click to collapse
I made an ugly hack the function omap_pm_get_max_vdd1_opp() returns always VDD1_OPP5
I didn't make any tests with frequency higher than 1.1Ghz so ... maybe 1.2Ghz is possible
Amazing work, Pokey and Occip. Are either of you still having screen issues at higher clock speeds?
Sent from my ADR6300 using XDA App
FrasierCrane said:
Amazing work, Pokey and Occip. Are either of you still having screen issues at higher clock speeds?
Click to expand...
Click to collapse
I think the artifacting I saw was a combination of my imagination and a hacked up .apk of Angry Birds. There is still a small issue where the touch screen loses some responsiveness right after the kernel is booted, but clears up after you put the NC to sleep and wake it up again.
Hot damn this is exciting. As the kernel work progresses, will this be something we can add to the NC without recovery, or will we have to wait on this?
Hey,
You can come join us at irc.freenode.net #nookie we have 2.2.1 booting with wifi. Working on the battery.
pokey9000 said:
I think the artifacting I saw was a combination of my imagination and a hacked up .apk of Angry Birds. There is still a small issue where the touch screen loses some responsiveness right after the kernel is booted, but clears up after you put the NC to sleep and wake it up again.
Click to expand...
Click to collapse
Good to hear. The default screen calibration seems a bit conservative for a full-function tablet anyway, so I can definitely see where you're coming from.
Sent from my ADR6300 using XDA App
rhcp0112345 said:
Hey,
You can come join us at irc.freenode.net #nookie we have 2.2.1 booting with wifi. Working on the battery.
Click to expand...
Click to collapse
i would love to be a fly on the wall, but being at work prohibits that. But saying you have 2.2.1 booting.. you mean you have a quasi working cutom froyo build going? double exciting!
Related
So I was just looking around the Qualcomm open source (CodeAurora) repositories and noticed that lots of interesting things are going on over there for the qsd8x50 that aren't yet in our N1 kernels.
One of the most potentially useful things to us, is adaptive undervolting, that always chooses the optimal voltage level based on the current temperature and silicon process variations.
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=621d0e14e6fcf454974634cf822f06fba1bd6816
If someone could get this into an N1 kernel, we wouldn't need any more experimentation with undervolting and could always run at the maximum possible stable voltage.
Other interesting changes include USB host support (although it's unlikely the N1 hardware is physically wired to allow for this):
https www codeaurora.org/gitweb/quic/chrome/?p=kernel.git;a=commit;h=109894cac8d01c6273cfa0466f7823a04e919bea
Unfortunately, the Chromium kernel for MSM/QSD seems to be structured quite differently and being worked on by a different team to the Android kernel. Still, it'd be nice to see someone attempt to port at least the AVS patch to a CM kernel.
p.s. can a moderator please approve my account to directly include links? This manual link-munging is getting annoying
This sounds interesting
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Also of interest is their framebuffer driver. We need it in the N1 kernel to use their X11 driver.
Has anyone had any luck getting a CAF kernel booting on the N1?
Markdental said:
I know a lot of the devs here check out Qualcomm's latests postings, so hopefully they are aware of this...
Click to expand...
Click to collapse
Yeah I know, but this is their Chromium/ChromeOS kernel, not their Android kernel. Might have gone unnoticed (I for one, had not thought to look there -- I'd have thought the only Chrome-specific kernel changes would've been the X11 driver -- why should platform-power-management changes not be shared across both kernels?)
I ported AVS code to the N1 kernel.
You can download the experimental version here:
http://forum.xda-developers.com/showthread.php?t=654416
AVS kernel is very experimental, and I expect it not to be fully stable.
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Ivan Dimkovic said:
Also, it looks 1.275v is not really enough for 1.1 GHz - at least AVS complains that it cannot find stable voltage.
Click to expand...
Click to collapse
Funny that: a processor rated for 1 GHz (in a world where if they could get away with selling it as a 1.1 GHz processor they certainly would have) isn't actually capable of 1.1 GHz without compromising stability and/or lifetime. Who'd have thought
Cheers for porting it to your kernel though, I'll be interested to see if it makes much difference to battery life.
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Ivan Dimkovic said:
I got no problems with AVS so far - I will release new kernel update tonight with AVS with no overclocking, as AVS and overclocking do not mix well for some people. Also, I provided the patch-code on my github, so other kernel developers can use AVS too, if they wish. There is still an ugly hack inside (one liner, though) which I will fix tonight, too.
Regarding "getting away" with faster CPU (Qualcomm) - I am not really sure if they would do it. There are market pressures, and CPUs are not always binned according to test validation - rather, other factors are at play, such as market demand.
So, it does happen - if someone is lucky, that is - to receive a CPU which could be binned higher, but it was still released at lower frequency because of market demands.
Intel is a very good example of such practice, and I am sure Qualcomm is no different as this is a huge market.
Click to expand...
Click to collapse
No doubt about it. Look at the Desire for example. It will be equipped with the 1ghz Snapdragon but will be underclocked to 768mhz to preserve battery life. So while it is certified for higher speeds HTC feels the market would prefer longer battery life over a little bump up in cpu speed
intersectRaven said:
I'll study this for integration in my .32 kernel...I'll have plenty of time once Holy Week vacation starts here.
Click to expand...
Click to collapse
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
jlevy73 said:
Out of curiosity, what advantages if any do you see with the .32 kernel over .33?
Click to expand...
Click to collapse
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
intersectRaven said:
Well, I've been using it for longer than .33 since I found it to be more responsive and a lot more stable with my 3d live wallpapers. Its also smaller when compiled so I can enable the compiler optimizations with ease.
Click to expand...
Click to collapse
Also, the upstream (AOSP) MSM kernel tree is still at .32... I would guess they may be stabilizing for a release as they've merged the -stable patchseries too (2.6.32.9 etc).
Over at PROJ: Overclocking the Adreno GPU on Snapdragon Devices they were trying to achieve to overclock the GPU to improve performance.
I've decided to open this thread for dedication for software porting/improving for adreno GPU on all Snapdragon chips.
1st thing we require/need to start work is:
Any source for the adreno/gpu drivers that are currently being run on our devices.
Its been mentioned that Acer liquid has same gpu running on lower cpu clock and achieving greater results.
Open source 3D driver for Snapdragon @ CodeAurora | Site Source
Acer liquid GPU drivers and source
Require Acer Liquid dump of adreno libegl files
Acer Liquid Kernel Source | Source site
AdamG working on this repo
http://github.com/xdabravoteam/cm-kernel
(May or may not be helpful)
glbenchmark: Acer liquid | Nexus One = Desire | EVO4G | Incredible
From there we should be able to improve our drivers from other devices but i think its a good start to look at the Acer Liquid since the source is available iirc.
That should be what we need for a start.
If i'm missing anything please let me know and i'll add it.
For reference to the other threads i posted.
Desire Porting thread | EVO4G porting thread | Incredible porting Thread
Hopefully we can get this project going and improve our GPU performance.
reserved for changelog
reserved for downloads/links
Alright, I'm going to write out everything I know so far in the best of my knowledge to help with others who are looking at this project. Conjecture will be separated off as thoroughly as possible. Let me know if any of this is wrong or needs updating, it's to be informative as possible.
Acer Liquid E:
There is a kernel framework that activates the GPU and provides clock and power control. Changing these states seems to be interrupt driven, upon the right signal the clock will be shuffled through a few states depending on load. The clock is always set through the minimum clock rate and the maximum clock rate is inflexible.
Outside of this, there is a non kernel-level driver binary that controls all other GPU operations. We do not yet know where it is or how it operates in the boot process.
Known points of interest:
Liquid E roms, to find the GPU binary driver portion.
Kernel source/drivers/char/msm_kgsl for the kernel portion of the driver.*
kernel source/arch/arm/msm/
Nexus One:
There too is also a kernel framework. It does not appear to initialize the driver at any point. In fact, I cannot find any external calls to the kgsl code whatsoever. They are most likely called from the binary portion of the driver, whose whereabouts are also a mystery.
Known points of interest:
kernel source/drivers/video/msm/ and msm/kgsl
kernel source/arch/arm/msm/
Conjecture:
My personal belief is that the radio plays a role in the Nexus One's GPU control system. It is the only part I know of initialized early enough to get us a framebuffer that isn't the kernel. The GPU may still be initialized in some part of the kernel I have not charted, but I have yet to see anything. Those whom I've contacted on this issue have not responded.
On a related note, there could also be a security system in the radio (or even the GPU firmware itself) that prevents kernel access to specific functions and further prevents user access to specific functions. If it exists and if it's a problem, we may have to find a way to maneuver around it.
The Acer E's binary driver really should be in the main part of any packaged rom. Upgrading it would be too useful to lock off somewhere.
Questions to answer so far:
How does the GPU get initialized in both devices?
Where in the process does this happen?
What is done during this time? (control handed off, some lockdown event, clocks set, etc...)
Is there a security mechanism that is set differently on the Liquid E?
If so, can it be defeated?
Where is the binary part of the driver for both devices?
Expected gains
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. If we can get their driver implemented on our devices, we should get similar gains in OpenGL ES 2.0. OGL 1.1 (and 2D if implemented differently) performance gains may differ.
Anyways, I'll try as best as I can to help out anyone who is trying this undertaking while at the same time trying to avoid riling up everyone as bad on the radio subject as I did in the other thread. Also, I'm running this all from memory, so everything may not be spot on.
* If needed, I can chart out the functions to create a pleasant flow chart for people new to this area to follow.
EDIT: Oi, there's something really wacky about my formatting, only certain parts actually look really bolded. It's like my fonts shrink slightly after the Acer Liquid E list. Hope no one has bad OCD like I do.
EDIT 2: Updated with Jack_R1's correction below.
nothing to add here but my support
best of luck gentlemen, I believe this is definitely needed.
About time such a thread got started!I was tracking the thread about overclocking closely,but things got a little too intense there...
So,because I was in the UK for vacation this past week(call me an idiot,I'll accept it) and just got back in Greece I have some questions.First,wasn't intersectraven working on a kernel with the E's driver built in?How is that going?And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
storm99999 said:
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. The CPU on the E is clocked at 75% or so of the N1. There is a known relationship between the CPU and GPU clocks, so assuming it's perfectly linear, it is possible that the new GPU code would be 75% faster in OpenGL ES 2.0 code. Gains may be different in other OGL versions.
Click to expand...
Click to collapse
Have to correct this. The relationship of GPU clock to CPU isn't a given number, relationship to other places is. The GPU frequency is the same in Liquid E and in Nexus, so the gain will be 50%. Still, a lot to gain, if possible.
It's only semantics, but in case the porting succeeds - it's good to know the ballpark for the expected gains.
Best of luck with this effort, I hope it'll succeed.
tolis626 said:
And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
Click to expand...
Click to collapse
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...
You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.
Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.
It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.
Anyways, my big post updated to reflect Jack_R1's correction.
storm99999 said:
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...
You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.
Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.
It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.
Anyways, my big post updated to reflect Jack_R1's correction.
Click to expand...
Click to collapse
This idea seems plausible, i'll pm iR if hes able to do that
If anyone reading this is also able to do this please let us know. I'm sure theres many people who are willing to test this.
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
madman_cro said:
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
Click to expand...
Click to collapse
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.
This brings back memories...
I'll keep an eye on this. Good job babijoee.
NeoS2007 said:
This brings back memories...
I'll keep an eye on this. Good job babijoee.
Click to expand...
Click to collapse
good memmories from wm))
tolis626 said:
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.
Click to expand...
Click to collapse
Will do lets all work together
NeoS2007 said:
This brings back memories...
I'll keep an eye on this. Good job babijoee.
Click to expand...
Click to collapse
like you i want to improve graphics on our beloved devices.
Edit:
I've setup a duplicate thread in Desire,Incredible and Evo threads all linking back to this main one. Alot of people are thinking the way to improve GPU is only to OC it and NeoS2007 and myself know better. We both were involved in winmo msm7k gpu software/driver improvement and achieved great results with the help of other xda members/developers.
Not for one second did i believe that our devices were running optimised graphic drivers and other devices such as Acer liquid E for example proves that.
Posted in the Evo section as well. Told some idiots to stay back
I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.
Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.
Just my $.02
<Postedit> I hope you guys don't mind me detailing out all of what I've done with hopes that someone will find it helpful, it's very... verbose. Plus, if I have to share the source, I can remember exactly what files were tweaked to send a smaller than 700Mb file.
Alright, here's my current plan once I get my build environment stable again (oh hey, Ubuntu 10.10? Do it!):
The N1 code has two layers, a wrapper layer and the interface layer. The Liquid E code has only an interface layer which appears compatible to (but different than) the wrapper layer on the N1. I'm going to replace the N1's interface layer to see if it still runs. If it does, we now will have a current kernel build that would allow both drivers to operate, barring complications.
The current driver would have all the wrapper layer code it needs, but the new driver will have the correct interface layer code it needs.
Then, I'll bust open a Liquid E rom (Aren't the Liquid and Liquid E roms interchangeable? That worries me.), hunt down the driver, find out how it starts up in the system, add it to a current rom, test it for differences, and then break the interface layer by putting no-op asm.
This is all simplified (and possibly horribly wrong) of course, but anyone looking at this project may be interested in trying something similar.
Edit: Alright, I found out that both of them have an on-boot frame buffer, but the new Qualcomm one is much larger and more capable. I'll start my porting project there, as that quite literally could be the difference.
Edit2: Oh god the Kconfig errors! They've overtaken the ramparts!
Edit3: It looks like I'm missing a large series of .h files, but other than that, there have been no compilation errors. Also, if you end up where I am, you want MDP31 instead of MDP40, kinda caught me off guard.
Edit4: I like keeping things written down for everyone. Anyways, here's the list of file movements I've done so far for anyone interested, as I need to make sure that if I get a result, it must be duplicatable.
Acer Kernel linux/include/msm_mdp.h must be moved to the same place in a Cyan kernel.
All of Acer Kernel's drivers/video/msm/ must be copied over but the kgsl folder must stay intact.
A blank Kconfig must be made in the same folder.
The Acer Kernel's drivers/video/Kconfig must be copied over. The options you want:
We have a MDP31 chip
Not sure yet, but autodetecting the panel is what I've chosen
MDDP 2.0 doesn't seem to matter, so best left disabled.
After all of this, there seems to be missing a single .h file, which has the function dma_cache_pre_ops() and related in it.
Edit5: I really hope that putting this much detail out doesn't bother anyone... Anyways, the next step fixed most of this, I modified msm_fb.c to have this in the definitions:
Code:
#define pgprot_noncached(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
#define pgprot_writecombine(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE)
#define pgprot_device(prot) \
__pgprot_modify(prot, L_PTE_MT_MASK|L_PTE_EXEC, L_PTE_MT_DEV_NONSHARED)
#define pgprot_writethroughcache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITETHROUGH)
#define pgprot_writebackcache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEBACK)
#define pgprot_writebackwacache(prot) \
__pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEALLOC)
This does throw some errors cause this isn't supposed to be there, but this is just a temporary hack.
The dma problem disappeared after that (don't know why...) and now I just have to find out why "info" is undefined at line 840 now.
Edit6: It looks like disabling the boot logo (as dumb as that is) gets rid of that error, but it throws a warning that the system needs the logo to be enabled. It's just a temporary measure, plus, I'd love to see a logo-less boot screen.
Edit7: Added a NULL to line 104 in drivers/video/msm/msm_fb_bl.c before
Geniusdog254 said:
Posted in the Evo section as well. Told some idiots to stay back
I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.
Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.
Just my $.02
Click to expand...
Click to collapse
I have been using http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/staging/msm/mdp.c as a base reference for my work and for bugfixes, as the staging area has the driver implemented as a .35. I'm going to try something, maybe downloading the whole source from this one repo and using the config I got, maybe it will spare me the issue. It's so clean, so error free, I'm liking it.
Edit9: Alright, downloaded 2.6.35 kernel, copy-pasted staging driver, got rid of all the errors prior.
Wow great start storm it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know
babijoee said:
Wow great start storm it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know
Click to expand...
Click to collapse
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.
Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.
I'll keep this post updated once I get the iR source downloaded.
Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...
Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.
Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"
Edit5: Commented out line 71 and 72 in mddi.c
Edit6: replaced dma_coherent_pre_ops and post_ops with dmb, as the functions prior don't exist and a commit says dmb replaces them. Really not sure about this. Compiling is smooth sailing from hereon out, except a duplicated function. Let's see if it kills my phone.
I have read through this and can say I honestly have no idea what half of the mumbo jumbo means but ill give it a bump and good luck to all you devs.
Sent from my Nexus One using XDA App
storm99999 said:
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.
Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.
I'll keep this post updated once I get the iR source downloaded.
Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...
Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.
Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"
Edit5: Commented out line 71 and 72 in mddi.c
Click to expand...
Click to collapse
Ah k thanks for the update.
Title says a helluva lot ;-)
READ THIS WHOLE POST AND THE WHOLE POST AFTER IT!
Features:
All steps undervolted about 25%. Should be stable still
The table is currently 300, 600, 950mhz until I can make it scale more than 3 steps.
The voltage for 950Mhz is less than at stock for 800Mhz, so you should see better battery life even though we're overclocked.
Display flicker fixed (or at least toned down, it can't be completely eliminated with the LED backlighting)
Scheduler tweaks backported from later kernel versions
Some governor tweaks of my own for responsiveness
To install this, just flash the zip in ClockworkMod. This shouldn't harm your device, but I make no promises. I trust it enough to run it on my device, if that means anything to y'all. I also attached a zip to flash back to the stock kernel (..but why would you break my heart by doing so..? ;P).
Next Up:
I REALLY want to get 1Ghz+ working, and my code is sound (I'm sure of that) but it won't boot on my device. I think I just need to find the right voltage, or I could have a bad die for OC'ing. This is the first thing I will work on.
Maybe the interactive CPU governor
Look into the 2-point touch limitation
Source:
Source is available on my GitHub at https://github.com/geniusdog254/Quickie
I will not flat out ask for donations, however I do appreciate them. So if you're feeling generous or appreciate my work then it would help me out a lot if you could donate. I have my game Reflex-A-Tron on the Market for $1 if you'd like to donate like that, or there is a link under my name on the left side to donate, and one in my signature. The one on the left and in my signature is to donate via PayPal. Any amount is appreciated, but please don't feel obligated.
You can contact me here via PM, on Twitter @geniusdog254, or email me at [email protected]. Email or Twitter is the preferred method, because I really despise the XDA PM system.
Disclaimer:
If this breaks your Nook, kills your family/pets, or starts global thermonuclear war, do not blame me. You have been warned. If you break your device and blame me, I will point at you and laugh.
Changelog:
1-11-11 - Screamer:
Overclock to 950Mhz. Still chokes at 1Ghz, which tells me it's probably my device. 950 is stable.
Temp sensor drivers. Thanks to the Nookie FroYo guys!
Updated to 2.6.29.6.
Scheduling tweaks from 2.6.31.
Code idle time from 2.6.34.
Scaling fixed. Now scales properly between all 3 CPU levels. Adding more than 3 makes it choke for some reason. I'll look into it.
Test version set at 1Ghz added. Just because it doesn't work for me doesn't mean it won't work for you. Don't get your hopes up though, I've tried making it work every way from Sunday
Notes:
Screen WILL be unresponsive immediately after a boot. Just lock the device for several seconds, unlock it, and all will be fine until another reboot. I blame B&N, it happens with all custom kernels.
Yes, I know there are more versions of this kernel than there are Windows Vista. The middle one is the recommended one. If your Nook can't run at 950Mhz (crashing often, or just won't boot) try the one with the 900mhz tag. If you wanna try and push it higher, try the 1Ghz one. Be warned: very little success is reported with the 1Ghz kernel. The top level of these chips seems to be right around ~925-975Mhz. Very few devices will be able to hit 1Ghz.
You should probably wipe your cache partition after flashing this. You won't lose anything, and many people are reporting that it makes things more stable at the higher freqs for them.
MD5 Sums:
stock-1.0.1-kernel.zip — 78ccf8ab0cd35b988cc9a81bd8bbc310
quickie-1ghz-test.zip — 7076a88cae2229910478e698c0e19435
quickie-screamer.zip — 22e8c2cc21e42cca1d18377a92b49540
quickie-900mhz.zip — 40362515da86cb4baea37b0bc6358feb
Wow thanks so much for this. Gotta try it out!
wow very nice! going to have to give this a shot!
Awesome! But is it compatible with nookie froyo (2.2) or the stock BN (2.1)?
Update: It boots Nookie Froyo but powers off immediately after booting. I am looking forward to the release of the 2.6.32 version of your work. Keep up the good work!
Sent from Nook Color (Nookie Froyo microSd optional)
runhopskipjump said:
Awesome! But is it compatible with nookie froyo (2.2) or the stock BN (2.1)?
Sent from Nook Color (Nookie Froyo on emmc)
Click to expand...
Click to collapse
Just stock 2.1.
With the Nookie FroYo, it wouldn't flash the kernel to the SD for boot, plus (at least on th Epic) a 2.6.29 kernel won't boot on FroYo, it needs 2.6.32 or higher
Glad to have you part of the nook color family. You did awesome work on the Epic4G.
Looking forward to more great stuff from you.
Thanks
Sent from my LogicPD Zoom2 using Tapatalk
Loss of touch sensitivity
I loaded up the new kernel via Clockwork and all went smoothly with the install. I noticed immediately that my touch sensitivity has decreased. I now have to press and hold just about as long as you would press and hold to bring up a context menu or something. If I don't do that, my touch is ignored and not registered.
Interestingly enough, when I type an email on the keyboard, it recognizes my typing very quickly. No apparent loss of sensitivity when I'm using the keyboard. I wonder why and how that is???
I guess I need to recalibrate the screen again to regain sensitivity.
I did notice that Castle Crashers frame-rate has improved a good bit with the overclock. It's a noticeable and welcome difference.
Angry birds was a bit annoying to play with the loss of screen sensitivity.
Edit: I alleviated the loss of touch sensitivity by installing the LCDDensity app from the Android Marketplace and selecting a density of 200.
Tried to install via clockwork and I keep getting errors unable to install. an I missing something?
sent from my nookcolor using the xda app
Got it working with clockwork update... thanks!
Flashed. Am loving it, seems much snappier, and the keyboard response at 900mhzz is much improved. Keep up the good work!
NC overcklock
Hi,
Last month I made some tests with overcloking /undervolting. I was able to push the NC at 1.15GHz, with a little voltage tweaking. 1Ghz was achieved without voltage tuning. The smartreflex technology adjusts automaticaly the OPP voltages to minimize the power consumption. Maybe the L3 speed can be increased to 200 Mhz by setting DPLL at 400MHz (in u-boot).
Occip (working for 2.6.32 NC kernel)
deitiphobia said:
I loaded up the new kernel via Clockwork and all went smoothly with the install. I noticed immediately that my touch sensitivity has decreased. I now have to press and hold just about as long as you would press and hold to bring up a context menu or something. If I don't do that, my touch is ignored and not registered.
Interestingly enough, when I type an email on the keyboard, it recognizes my typing very quickly. No apparent loss of sensitivity when I'm using the keyboard. I wonder why and how that is???
I guess I need to recalibrate the screen again to regain sensitivity.
I did notice that Castle Crashers frame-rate has improved a good bit with the overclock. It's a noticeable and welcome difference.
Angry birds was a bit annoying to play with the loss of screen sensitivity.
Edit: I alleviated the loss of touch sensitivity by installing the LCDDensity app from the Android Marketplace and selecting a density of 200.
Click to expand...
Click to collapse
me too, seems touch for a while(XXms) take effect, less then that screen acts like nothing touch it. this drived me mad when using Gellery, switch pictures give terrible feeling.
i think this relay to the clock scaling, i will check this out using SetCPU.
thanks for your work!
Amazing work with the kernal. I flashed and changed density to 200 in Root Explorer /system/build.prop and it works great.
Also in Spare parts I change both animations to Fast instead of defaults.
occip said:
Hi,
Last month I made some tests with overcloking /undervolting. I was able to push the NC at 1.15GHz, with a little voltage tweaking. 1Ghz was achieved without voltage tuning. The smartreflex technology adjusts automaticaly the OPP voltages to minimize the power consumption. Maybe the L3 speed can be increased to 200 Mhz by setting DPLL at 400MHz (in u-boot).
Occip (working for 2.6.32 NC kernel)
Click to expand...
Click to collapse
Can you add me in GTalk? [email protected]
I have some stuff I'd like to ask about. How did you do the OC? Did you change the actual clock in u-boot so everything scales up? Or did you add more VDD_OPP* steps. I used some of the code I saw before for the Droid's 3430 chipset, using the OPP steps. The stock kernel has steps built in for up to 1.2Ghz, but if I enable them I can't make it boot, at least on my device.
I can't figure out the voltages either, probably because I fail at hex. If I understood that, it would help me a lot.
sugwacee said:
me too, seems touch for a while(XXms) take effect, less then that screen acts like nothing touch it. this drived me mad when using Gellery, switch pictures give terrible feeling.
i think this relay to the clock scaling, i will check this out using SetCPU.
thanks for your work!
Click to expand...
Click to collapse
Hrrm. It sounds like the CPU scaling is staying low, because I see absolutely no change in the touch sensitivity, and I didn't touch any of the code related to it. Try setting the CPU Governor to OnDemand or Performance in SetCPU if it isn't set there already.
Geniusdog254 said:
Can you add me in GTalk? [email protected]
I have some stuff I'd like to ask about. How did you do the OC? Did you change the actual clock in u-boot so everything scales up? Or did you add more VDD_OPP* steps. I used some of the code I saw before for the Droid's 3430 chipset, using the OPP steps. The stock kernel has steps built in for up to 1.2Ghz, but if I enable them I can't make it boot, at least on my device.
I can't figure out the voltages either, probably because I fail at hex. If I understood that, it would help me a lot.
Click to expand...
Click to collapse
diff is available http://nookdevs.com/NookColor:_Nookie_Froyo_Tips#Overclock_.5B100.25_untested_on_this_system.5D
occip said:
diff is available http://nookdevs.com/NookColor:_Nookie_Froyo_Tips#Overclock_.5B100.25_untested_on_this_system.5D
Click to expand...
Click to collapse
Odd. That's exactly what I've done (with a couple diff voltages) but it won't boot on my Nook. I guess I just got a bad die. Can you explain the voltage values? I know how to increase/decrease the hex number, but how does it correlate to the actual voltage? Like how is 0x38 = 1.35V in a stock kernel?
Definitely going to try this out. Thanks for the work. I'll report back with comments/questions/concerns.
nrune said:
Tried to install via clockwork and I keep getting errors unable to install. an I missing something?
sent from my nookcolor using the xda app
Click to expand...
Click to collapse
+1 I am getting the same. It installs half way then stops with a big exclamation mark, asks me to shut down and restart. I would love to try this. Any ideas?
EDIT: OK got it. CWM updated to 3005 and now it can go into recovery was on 3002 which did not.
This is very much appreciated.
Be expecting some monies so you can buy some candy in the near future.
keep up the good work.
Thanks!
DAFUQ!!!!
This will be a sparse post for now... I'll fill in the documentation later, I'm kinda fried after fighting this stability bug.
Source: https://github.com/Entropy512/kernel_galaxys2_ics/tree/entropy_kernel_main
Initramfs: https://github.com/Entropy512/initramfs_galaxys2_ics/
Features:
CWM 5.5.0.4
Hopefully fixed SetCPU stability issues
fuel_alerted wakelock fix
Voltage control (use SetCPU)
Mali 3-step clock/voltage control (READ THE CHANGELOG - IT IS DIFFERENT FROM SIYAH)
Legacy Gingerbread hotplug code (including all tuning features from the final GB DD release)
Not much else for now, thank Samsung for their broken frequency control code that took a team effort of multiple kernel developers (gokhanmoral, simone201, franciscofranco, and others) to track down the problems in and fix.
Tested base: I9100 XWLP7
Should work: Any I9100 official release
Guaranteed not to work: Any I9100 leak (XXLPJ or older)
Not supported: AT&T leaks. UCLC2 won't boot for the same reason as XXLPJ and older - giving you a sign of how old the codebase is. Any leaks that do boot will have the microphones reversed in calls.
Planned features - short term:
Overclock
CIFS
Planned features - mid-term:
Try to reduce power usage during suspend/resume
Apply the "target down threshold" concept used for GPU clocks to the Conservative governor - a single down_threshold doesn't work well when 200 MHz is less than half of 500 MHz, but 1000 MHz is more than 80% of 1200 MHz.
Known issues:
"Internal" SD card in recovery is actually the external one
04/23/2012:
Some more stability fixes (hopefully)
Legacy Gingerbread hotplug code - More stable, and includes all of the Daily Driver tunables from Gingerbread
Mali 3-step GPU clock/voltage control - NOTE: Down thresholds are different from Siyah. Instead of being percentage of current load, they are desired load at the next frequency step down. So "normal" thresholds will be much higher. For example, if your second frequency is 100 MHz and the third is 200 MHz, a down_threshold of 80 for 200 MHz on this kernel is the same as setting down_threshold to 40 on Siyah. (e.g. siyah_threshold=down_freq*down_threshold/cur_freq)
04/10/2012: - SUCK!!!!!!
Revert a patch that turned out to be useless (see github)
Swap internal/external SD cards in recovery to be consistent with CM9 - this creates a known issue (see known issues)
04/04/2012: - ZOMBIE ASS!!!!!!!
Voltage control
sio and v(r) ioscheds
Hopefully last of the stability issues fixed (a glitch deep in the bowels of cpuidle)
04/02/2012:
Fixed CPU hotplugging
04/01/2012:
Initial release, pulled due to issues.
FAQ
FAQ will go here when I have time.
Reserved for future use.
Nice!!!!!!!!!!!!!!!!!! glad you finally released!!!
Dangerous stuff here?
Posting in a closed thread.
Ill update stuff here too.
Seems to still be issues in exynos4_enter_idle()...
Edit: If you have any issues, disable all SetCPU or similar clock control profiles and run the standard min/max of 200/1200.
hurr hurr I dun broke (and fixed in 4/2) teh hotplug
ZOMBIE ASS!!!!!
New release, last one until after the Easter holiday. Too much cleaning to do and family visiting.
I'll clean up the thread and open it up after the holiday.
Oh, and ERDs shouldn't have their thread titles auto-lowercased if too many caps!
New release - minor changes compared to Zombie Ass, leaving the thread open this time around.
Still a lot to do... But at this point stability issues seem to be gone.
Entropy512 said:
New release - minor changes compared to Zombie Ass, leaving the thread open this time around.
Still a lot to do... But at this point stability issues seem to be gone.
Click to expand...
Click to collapse
Nice thanks for your hard work
Sent from my SGH-I777 using XDA
Awesome, thanks Entropy. Donating some beer money now...
Download size is 554 bytes. That is using a computer. Something may be wrong with that size
xpakage said:
Download size is 554 bytes. That is using a computer. Something may be wrong with that size
Click to expand...
Click to collapse
Same here, PC or Phone. Saw this in ShoStock Rom thread as well, Shoman had to re-upload his files.
****it... XDA uploading seems wonky. Reuploading...
Gave entropy the 5,000 thanks...I win the internet.
Entropy512 said:
****it... XDA uploading seems wonky. Reuploading...
Click to expand...
Click to collapse
Nooooo, SUCK it
Should be fixed.
Thanks entropy
Sent from my SGH-I777 using Tapatalk 2
Presenting EM Kernel or EMk for short for the Galaxy Note 8.0 (N5100), other variants will face development once this kernel is reported working. Features are pretty basic for now, haven't made any extensive changes, but expect them soon . All of my developments for the Note 8.0 will be faster and better (considering that I won't have to request for testers and files), if I have the device in hand, so if you think of me as worthy, consider making a donation, every single one is highly appreciated
My Github: github.com/emwno
You will my custom recovery i.e CWM to flash this kernel.
Features:
I will only be listing major or noticeable changes. Read commits @ github for details
Overclock Support
Intelligent write-back
Network speed tweaks (crypto)
I/O Schedulers: Sio, Row, Zen
Governers: InteractiveX, Savagedzen, Zzmoove, PegasusQ, Lulzactive, SmartassV3 (only listing which I've added)
ARM specific optimizations
Triangle Away support
Boeffla Sound support
Google Snappy drivers
Sudden Death addressed*
Releases:
EMk-03: N5100 | N5110
Changelog:
03
OC fix
Attempted Wifi fix for N5110
Governers added: Lulzactive, SmartassV3
Some more IO's (dont remember names)
Roll back to stock voltages
Boeflla Sound support
Triangle Away support
Lz4 compression (faster boot)
02
Support for N5110
Various build fixes
Zzmoove governer
Row / Zen IO Schedulers
Fixed up write-back
PegasusQ governer alterations (github)
AIO temp remove
01
Initial release
I am a giant knucklehead - I read "note 8" and didn't pay attention to the model #.
The test was done on a 5110 - I somehow missed the actual model # it was written for.
It does sound like the data reminded emwno about a detail, though.
That said, the restore technique does work (and I didn't softbrick my device.)
Thanks for taking a run at this!
The new boot.img took a really long time to get from initial Galaxy model # screen to the blue and white Samsung logo on first boot.
Wifi not working with the new kernel on first or second boot.
Did in fact boot, though. Antutu thinks cpu metrics are a hair slower than stock, and the UI feels a little slower also.,
A recovery zipfile would be super cool.
I mounted the external sd, then used
dd if=/dev/block/mmcblk0p5 of=/external_sd/bootrecover.img bs=1M
to backup and
dd if=/external_sd/bootrecover.img of=/dev/block/mmcblk0p5 bs=1M
to restore and now have wifi again.
roustabout said:
Thanks for taking a run at this!
The new boot.img took a really long time to get from initial Galaxy model # screen to the blue and white Samsung logo on first boot.
Wifi not working with the new kernel on first or second boot.
Did in fact boot, though. Antutu thinks cpu metrics are a hair slower than stock, and the UI feels a little slower also.,
A recovery zipfile would be super cool.
I mounted the external sd, then used
dd if=/dev/block/mmcblk0p5 of=/external_sd/bootrecover.img bs=1M
to backup and
dd if=/external_sd/bootrecover.img of=/dev/block/mmcblk0p5 bs=1M
to restore and now have wifi again.
Click to expand...
Click to collapse
Man..... i forgot modules....
Anyways it will be slow until all the backports are complete. thanks for the report!
emwno said:
Presenting EM Kernel or EMk for short for the Galaxy Note 8.0 (N5100), other variants will face development once this kernel is reported working. Features are pretty basic for now, haven't made any extensive changes, but expect them soon . All of my developments for the Note 8.0 will be faster and better (considering that I won't have to request for testers and files), if I have the device in hand, so if you think of me as worthy, consider making a donation, every single one is highly appreciated
My Github: github.com/emwno
You will my custom recovery i.e CWM to flash this kernel.
Features:
Overclock Support (upto 1.8Ghz)
Intelligent write-back
Network speed tweaks (crypto)
I/O Schedulers: sio
Governers: InteractiveX, Savagedzen (only listing which I've added)
AIO backported (from linux 3.6 kernel)
ARM specific optimizations
ARM Topology enabled
Modified LMK
Releases:
EMk-01: http://d-h.st/mDP
Changelog:
01
Initial release
(read features)
Click to expand...
Click to collapse
Great Job! Now we need one for the N5110.
An observation on the Samsung kernel and OS: for a good bit of time after a reboot, the cores are all running flat out at 1.6 ghz.
The immediate cause is apparently that the device is scanning the internal memory and sdcard and this is a somewhat processor-intensive task.
What surprised me, though, was that after installing cpu usage monitor, only one of the cores was doing most of the work - but all 4 were running at 1.6 ghz for a lot of the time.
Hopefully I'll be restarting less this evening and can look to see if this is true in more casual usage. If others are noticing this, it seems like better multicore management by the kernel would go a LONG way to ameliorating the relatively poor battery life.
The device uses the pegasusq governor, which does support core hotplugging, but is either just not that good at doing so or isn't configured to release unused cores very quickly.
I haven't had a chance to compare the settings I have with the explanations in this excellent post on the governor and what it's doing:
http://forum.xda-developers.com/showpost.php?p=24233103&postcount=3
I have yet to modify governers for specificds such as battery life and speed. Its scanning because of the intelligent write back, which does the major work faster with all cores at while booting.
I spent some time looking at governor settings last night.
When I finished, I'd used the device for about 5 hours, did 6 reboots and a number of benchmark cycles and had gone from 90% charge to 45% charge.
So if that holds up, I'm getting about 3 hours more per cycle. One thing I noticed: if you run an Antutu benchmark, you may want to reboot your device - Antutu seems to lock all four cores at 1.6 ghz for a long time after it runs.
I landed on two modifications via set CPU:
first mod: set ignore_nice_load =1
"ignore_nice_load - Setting to 1 causes governor to ignore load resulted by nice processes while making scaling decisions. Nice processes are the one i/o scheduler refers to as low priority process.
UNIT: Boolean 1 or 0"
Basically, a process which is nice is one that will get out of the way if I'm doing something else, and I'm not interested in, even for 15-20 minutes, running all four cores at full speed to get it done. It looks to me as if media scanning is a process with the nice flag set.
Second mod: changed freq_step from 37 to 12.
"freq_step - Defines how much as a percentage of maximum frequency, governor should increase CPU frequency each time CPU load reaches up_threshold.
UNIT: Percentage"
As shipped the processors step in giant increments.
Setting that value to a 12% step rate gives me 200 mhz increments, and I see that my processor is spending much more time in the 400-600 mhz range than before,.
I'm probably going to do additional tests with a 6% step rate (100 mhz increments) at some point.
The nice setting emerged from looking to see what was running at boot time and coming across threads on the behavior such as this one:
http://forum.xda-developers.com/showthread.php?t=1994650
I'm happy with the performance I'm seeing in this setup, and happier still with the battery life I'm seeing. Your mileage may vary, of course, but waiting a few milliseconds more for the processor to cycle all the way to 1600 mhz hasn't made the device feel stuttery to me.
Still on my to-do list is getting the cores to up and downshift more independently. The governor tends to let only one core lag the others, so I almost always see three cores at once at the same frequency, even if only one appears to be doing anything.
EMk02 Live.
Just took a run at emk02-5110 - still no wifi.
Bluetooth was fine, boot was speedy.
My tools for looking at CPU reported that the clock speeds available were 50 mhz-1600 mhz.
It seems possible that the high end was truncated at 1600 mhz by chip reporting something inaccurately, and that as a result the low end was also pushed very low?
The kernel seemed just fine aside from no wifi, though!
roustabout said:
Just took a run at emk02-5110 - still no wifi.
Bluetooth was fine, boot was speedy.
My tools for looking at CPU reported that the clock speeds available were 50 mhz-1600 mhz.
It seems possible that the high end was truncated at 1600 mhz by chip reporting something inaccurately, and that as a result the low end was also pushed very low?
The kernel seemed just fine aside from no wifi, though!
Click to expand...
Click to collapse
Only till 1600? I remember adding upto 1800... About the no wifi, flash the attachment and let me know of the result.
Still no wifi.
Clock still tops at 1600 reported.
The attached wifi fix file has scsi_wait_scan.ko in it -- I'd thought that was a filesystem module?
Did it replace anything? I hope not, as it doesn't seem to make a backup of the original?
roustabout said:
Still no wifi.
Clock still tops at 1600 reported.
The attached wifi fix file has scsi_wait_scan.ko in it -- I'd thought that was a filesystem module?
Did it replace anything? I hope not, as it doesn't seem to make a backup of the original?
Click to expand...
Click to collapse
That is the only module that was generated. thats the stock one. taking a look at source again..
EDIT: try flashing this. built kernel again. (all generated modules added)
Hmmmm
OK, I poked around a bit first on my device and then I extracted /system from the firmware blob, used simg2img and mounted the output in a linux system to get a look at what Samsung delivers.
I did not see a scsi_wait_scan in their flashable system. I found a folder called dhd which apparently relates to networking.
The installed system doesn't use these files, though - is that because Samsung integrates them all into the kernel?
At any rate, I know I won't overwrite anything when I get time to flash now, at least
OK, tried flashing in the boot.img and the files in 2.zip. Still no wifi.
Also, the files in 2.zip are *.ko, the other files are *.so, and in the extract of system, there no .ko files -- is that part of what's what?
To make testing simpler down the road, I also made a flashable boot.img restore file, which folks can get a copy of here
http://www.mediafire.com/download.php?w89vgdn4kdds781
emwno said:
That is the only module that was generated. thats the stock one. taking a look at source again..
EDIT: try flashing this. built kernel again. (all generated modules added)
Click to expand...
Click to collapse
fixed 2.zip,still no wifi
Why... did i do something so dumb... the libs are placed elsewhere.... making a new zip.
let us know when you got the wifi working I am really looking forward to flashingthis
Does anyone want sound mods supported? Such as Boeffla Sound snd Wolfson Sound. All kernel based.
emwno said:
Does anyone want sound mods supported? Such as Boeffla Sound snd Wolfson Sound. All kernel based.
Click to expand...
Click to collapse
Yes please!
New change log for kernel. Ignore the one on OP. If you have any requests, present them to me.
03
OC fix
Wifi fix for N5110
Governers added: Lulzactive, SmartassV3
Some more IO's (dont remember names)
Roll back to stock voltages
Faster USB charging
Boeflla Sound support
Triangle Away support
CPU voltage control
Lz4 compression (faster boot)
Some back ports from linux 3.4 mainline (will post which after confirmed working myself) - no more
emwno said:
New change log for kernel. Ignore the one on OP. If you have any requests, present them to me.
03
OC fix
Wifi fix for N5110
Governers added: Lulzactive, SmartassV3
Some more IO's (dont remember names)
Roll back to stock voltages
Faster USB charging
Boeflla Sound support
Triangle Away support
CPU voltage control
Lz4 compression (faster boot)
Some back ports from linux 3.4 mainline (will post which after confirmed working myself)
Click to expand...
Click to collapse
Do we have a download yet?