[KERNEL] [3.1.10] Olympus (Atrix 4G) Kernel Project

Search This thread

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
@krystianp @Zn7mkUKzN1r8aCIV I think I've found why the wlan is not taking the cpu out of deep sleep. At least for the bcmdhd scenario (I didn't look to see how bcm4329 was hooked).

On bcmdhd there are two modes of operation. With so-called Out-of-Band Interrupts and without. With it, there's a dedicated pin for irq. This pin could be set to wake the cpu as usual. The thing is that in current setup, we're using the driver without OOB interrupts, i.e. notifications in form of interrupts comes from SDIO events. The bcm chip is programmed to drive it's pin as a interrupt selectively, so it probably just sets idle when OOB mode is not in use, therefore we couldn't simply cheat and enable_irq_wake() (or something) on the pin, as it would either do nothing or permanently inhibit deep sleep.

I enabled the OOB interrupts and although the system boots up to the lock screen, it reboots in the sequence, probably from a crash - and I lack the machinery (jtag?) to capture the kernel dump at that point.

With the bcmdhd, the steps would be to fix whatever is causing this, and then see if there's need for enable_irq_wake() or something.
 

attrixnor

Senior Member
Oct 23, 2012
133
53
Hello Dev Team
could you precise the actual source kernel link to use for this kernel. (because Krystianp kernel seems to be not updated since one month, PolesApart kernel seems ok )
why don't you use the same github for futur update ?
although , thank for all :)
 
  • Like
Reactions: notasin

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
Hello Dev Team
could you precise the actual source kernel link to use for this kernel. (because Krystianp kernel seems to be not updated since one month, PolesApart kernel seems ok )
why don't you use the same github for futur update ?
although , thank for all :)

The official kernel, currently maintained by @krystianp for both cm9, cm10 and Z's kitkat is at https://github.com/CyanogenMod-Atrix/android_kernel_motorola_olympus/ .

The branch I maintain is forked from it, it's *way* experimental and for Z's kitkat only. Also I'm not part of the dev team or actually any team, <sarcasm>I'm just a trouble maker trying to burn it's own phone</sarcasm>.

I'm merging fixes/updates from different sources and if and only if they prove useful and minimally stable, I'll ask krystianp to merge. Of course he may cherry pick anything in there. The ext4 fixes (hmmm perhaps I didn't push these yet, but if not, will soon) all comes from upstream, the mm changes comes from faux123 and other sources. IIRC There's also a few memory leaks that comes from upstream (either linux itself or google android branch).

I currently cannot recommend people to try my branch as some changes may set your house on fire, kill your neighbor, or, more likely, bring some damage to your phone or data loss. If and only if I see some improvement such as make the phone reboots less, then I'll post an experimental zip update to kitkat's thread, as I don't want to unnecessarily bother krystianp as I'll be the one to blame for whatever.
 
Last edited:

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
Bluetooth wake

I've tracked down the following messages to bcm4329_rfkill.c
It seems the desired effect of enabling/disabling wakepads for the bluetooth pins are not exactly working.

Code:
<3>[  122.179910] Failed gpio lp0 enable for irq=353, error=-22
<3>[  122.193628] Failed gpio lp0 enable for irq=353, error=-22 
<4>[  123.193661] ------------[ cut here ]------------
<4>[  123.193704] WARNING: at kernel/irq/manage.c:510 irq_set_irq_wake+0xbc/0xec()
<4>[  123.193714] Unbalanced IRQ 353 wake disable
<4>[  123.193720] Modules linked in: bcmdhd
<4>[  123.193757] [<c0014418>] (unwind_backtrace+0x0/0xec) from [<c004d1f4>] (warn_slowpath_common+0x54/0x64)
<4>[  123.193774] [<c004d1f4>] (warn_slowpath_common+0x54/0x64) from [<c004d234>] (warn_slowpath_fmt+0x30/0x40)
<4>[  123.193790] [<c004d234>] (warn_slowpath_fmt+0x30/0x40) from [<c009009c>] (irq_set_irq_wake+0xbc/0xec)
<4>[  123.193820] [<c009009c>] (irq_set_irq_wake+0xbc/0xec) from [<c03018d8>] (enter_lpm+0x54/0x84)
<4>[  123.193848] [<c03018d8>] (enter_lpm+0x54/0x84) from [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4)
<4>[  123.193866] [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4) from [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c)
<4>[  123.193882] [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c) from [<c00131ac>] (ipi_timer+0x38/0x40)
<4>[  123.193897] [<c00131ac>] (ipi_timer+0x38/0x40) from [<c0008338>] (do_local_timer+0x60/0x74)
<4>[  123.193918] [<c0008338>] (do_local_timer+0x60/0x74) from [<c000de14>] (__irq_usr+0x34/0xc0)
 

Zn7mkUKzN1r8aCIV

Senior Member
Mar 20, 2013
250
1,470
I've tracked down the following messages to bcm4329_rfkill.c
It seems the desired effect of enabling/disabling wakepads for the bluetooth pins are not exactly working.

Code:
<3>[  122.179910] Failed gpio lp0 enable for irq=353, error=-22
<3>[  122.193628] Failed gpio lp0 enable for irq=353, error=-22 
<4>[  123.193661] ------------[ cut here ]------------
<4>[  123.193704] WARNING: at kernel/irq/manage.c:510 irq_set_irq_wake+0xbc/0xec()
<4>[  123.193714] Unbalanced IRQ 353 wake disable
<4>[  123.193720] Modules linked in: bcmdhd
<4>[  123.193757] [<c0014418>] (unwind_backtrace+0x0/0xec) from [<c004d1f4>] (warn_slowpath_common+0x54/0x64)
<4>[  123.193774] [<c004d1f4>] (warn_slowpath_common+0x54/0x64) from [<c004d234>] (warn_slowpath_fmt+0x30/0x40)
<4>[  123.193790] [<c004d234>] (warn_slowpath_fmt+0x30/0x40) from [<c009009c>] (irq_set_irq_wake+0xbc/0xec)
<4>[  123.193820] [<c009009c>] (irq_set_irq_wake+0xbc/0xec) from [<c03018d8>] (enter_lpm+0x54/0x84)
<4>[  123.193848] [<c03018d8>] (enter_lpm+0x54/0x84) from [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4)
<4>[  123.193866] [<c006b1f0>] (__run_hrtimer.isra.33+0x44/0xd4) from [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c)
<4>[  123.193882] [<c006bb0c>] (hrtimer_interrupt+0x104/0x27c) from [<c00131ac>] (ipi_timer+0x38/0x40)
<4>[  123.193897] [<c00131ac>] (ipi_timer+0x38/0x40) from [<c0008338>] (do_local_timer+0x60/0x74)
<4>[  123.193918] [<c0008338>] (do_local_timer+0x60/0x74) from [<c000de14>] (__irq_usr+0x34/0xc0)

Do you have any clues to fix it? me thinks only K / M know how to do these irq stuffs with tegra2 soc... Thx a lot for being still around :)
 

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
Do you have any clues to fix it? me thinks only K / M know how to do these irq stuffs with tegra2 soc... Thx a lot for being still around :)

I'm looking a bit deeper. It seems that the approach for the bluetooth module to wake the cpu isn't formally right, altough it might be working anyway (or not, but I don't think we would notice).

On another subject, I've enabled the ram console (which saves the last syslog entries on /proc/last_kmsg in case of a crash) and I'm using it to debug the wifi w/ the dedicated irq handler (as per one of my previous messages). There's a NULL pointer dereference in the driver, although fixing it won't make the driver work, it'll only prevents a reboot. But I was bored and decided to debug the reboots triggered by leaving the phone idle when powered on battery and both mobile data and wifi on, and then checking /proc/last_kmsg.
I don't like what I don't see in there: I expected a kernel crash, that would be (relatively) easy to fix. What I see instead (repeatedly) is the phone leaving deep sleep, the wifi reconnecting to AP, and crashing afterwards. No indication of a driver problem, so it can either means the crash is very bad deep inside an irq handler or some other deep low-level thing (that could crash before the system had a chance to log it), or it's not triggered by the tegra cpu at all.

I have a few theories but no data to support them. One is that there's a bad interaction between the CPCAP (the power controller, it's actually a Texas Instruments TPS65950 / TWL5030 which Motorola rebrands), the modem and the CPU. The CPCAP is responsible for powering all devices and it have a builtin firmware with some monitors and both software and hardware watchdogs. If something is not done in the right sequence or time, the CPCAP may assert a hard reset on everything (that would mean a reboot). For instance, suppose for some reason on our side (i.e. kernel) we leave some CPCAP notification masked out, i.e. the cpu don't wake up from deep sleep to service this notification. CPCAP could assume the cpu crashed and assert a reboot. If the modem crashes and is not serviced by the cpu while in deep sleep, the CPCAP could detect that (I don't have evidence that it does) and reboot too.

I'll keep digging on spare time :p
 

Zn7mkUKzN1r8aCIV

Senior Member
Mar 20, 2013
250
1,470
I'm looking a bit deeper. It seems that the approach for the bluetooth module to wake the cpu isn't formally right, altough it might be working anyway (or not, but I don't think we would notice).

On another subject, I've enabled the ram console (which saves the last syslog entries on /proc/last_kmsg in case of a crash) and I'm using it to debug the wifi w/ the dedicated irq handler (as per one of my previous messages). There's a NULL pointer dereference in the driver, although fixing it won't make the driver work, it'll only prevents a reboot. But I was bored and decided to debug the reboots triggered by leaving the phone idle when powered on battery and both mobile data and wifi on, and then checking /proc/last_kmsg.
I don't like what I don't see in there: I expected a kernel crash, that would be (relatively) easy to fix. What I see instead (repeatedly) is the phone leaving deep sleep, the wifi reconnecting to AP, and crashing afterwards. No indication of a driver problem, so it can either means the crash is very bad deep inside an irq handler or some other deep low-level thing (that could crash before the system had a chance to log it), or it's not triggered by the tegra cpu at all.

I have a few theories but no data to support them. One is that there's a bad interaction between the CPCAP (the power controller, it's actually a Texas Instruments TPS65950 / TWL5030 which Motorola rebrands), the modem and the CPU. The CPCAP is responsible for powering all devices and it have a builtin firmware with some monitors and both software and hardware watchdogs. If something is not done in the right sequence or time, the CPCAP may assert a hard reset on everything (that would mean a reboot). For instance, suppose for some reason on our side (i.e. kernel) we leave some CPCAP notification masked out, i.e. the cpu don't wake up from deep sleep to service this notification. CPCAP could assume the cpu crashed and assert a reboot. If the modem crashes and is not serviced by the cpu while in deep sleep, the CPCAP could detect that (I don't have evidence that it does) and reboot too.

I'll keep digging on spare time :p

learnt a lot from your writings, Thx. finally flashes of light in this endless tunnel :)
 

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
What I could find out is that we have these GPIOs being passed to the irq_set_irq_wait() at some point or another:
TEGRA_GPIO_PU1
TEGRA_GPIO_PM0
TEGRA_GPIO_PM1
TEGRA_GPIO_PT0
TEGRA_GPIO_PU1

The problem is that none of them are allowed in deepest sleep level (LP0), so the API is complaining. It seems that the API has provisions for blocking LP0 entry and selecting LP1 instead (where the Interrupt controller should remain functional and any interrupt can wake the cpu again), but for some reason it's barking instead. I don't think it's successfully blocking LP0 entry, and it seems intentional.

If it would accept the IRQs and force LP1, any could wake the system, which I think could cost a lot in terms of battery (but perhaps I'm wrong: how often do these fire? These interrupts seems to be masked in/out as necessary, at least they could be). I suspect some tuning would be required to work that way. Anyway the support for LP1/LP0 arbitration seemed a bit too fragile, perhaps it was incomplete by the time the kernel was sourced.

On the other hand, and it's our scenario today, having these periferals behaving as they do now, they won't be serviced when the phone sleeps.

To make the long story short, I do believe that in the state the kernel it is today, it's better to leave this unchanged for now. The possible non-conformant scenario today is the wifi, as it can't wake the system. I plan to dig a little into it later (trying to fix the bcmdhd to work when CONFIG_BCMDHD_HW_OOB=y). The rest of the IRQs aren't really needed (AFAIK) as wake sources. The bluetooth module seems to - somehow - be able to take the phone out of the deep sleep, I don't know if the right pin is doing this or if it is through the serial port( tegra serial ports seems to be in the wakeup-capable list). Sometimes it takes quite a while, but my bluetooth headphone seems to be able to connect to the phone in 95% of the attempts. And in those 5% that it fail, I do believe it connects fine in the 2nd attempt, I never had to wake up the screen in order to do that (like I need to do with the wifi).

Sorry for flooding this, @krystianp is probably aware of all that, but I wish to share where I was pooking around and perhaps document it here so other people can contribute too.

On a side note, I'm looking at it because I was able to advance on the diagnostics (at least I think so, comparing to what I didn't know), but the main issues we would really have to tackle are the random reboots and the battery drain. I'm convinced that even if we had a perfect dynamic deep sleep setting today (we already have a static one, i.e. the phone really consumes little power when sleeping) from the kernel point of view, it would really contribute very little to the overall battery uptime ability: the main source of consumption seems to come from userspace wakelocks. The most hungry ones today accordingly to diagnostics programs seems to be the google cell location ones. But this is probably not caused directly by this: on the old android days, we had almost no wakelock straight in the kernel. And even on android userspace, there were modest usage and IIRC the api was a little different. In our case we had a nvidia middleware in both user and kernel space managing most of this stuff. Now android makes heavy use of it and kernel have internal usage too, so the semantics are different but google put a lot of testing efforts and cpu processing power evolves faster than battery, yet we have current generation phones with equal-or-higher idle-time. I suspect the RIL was fine-tuned, yet ours probably comes from the old days, without this tuning. Perhaps it caches google location requests/reports, have the modem configured to report them less often or just when changing, etc.

Sorry for the long thread, guys, I got carried away.
 

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
Progress

@Zn7mkUKzN1r8aCIV With a small patch and a change to .config wifi is now working fine in deep sleep. I'm not sure if this is enough to make notifications arrive in a decent time, but it's a must have.

This is the patch.
As you know I have made a lot of changes to my fork at github, so I can't be 100% sure this will work on the mainstream kernel, but I don't see why not.

Cheers!
P.S..: I'll test a little longer, and if we have demand I can push an update zip w/ a kernel image on kitkat thread for people to test.
 

Zn7mkUKzN1r8aCIV

Senior Member
Mar 20, 2013
250
1,470
@Zn7mkUKzN1r8aCIV With a small patch and a change to .config wifi is now working fine in deep sleep. I'm not sure if this is enough to make notifications arrive in a decent time, but it's a must have.

This is the patch.
As you know I have made a lot of changes to my fork at github, so I can't be 100% sure this will work on the mainstream kernel, but I don't see why not.

Cheers!
P.S..: I'll test a little longer, and if we have demand I can push an update zip w/ a kernel image on kitkat thread for people to test.

So you fixed wifi wakelock!!! I will try to setup the phone to test your patch :) Thx. a lot!!!
 

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
So you fixed wifi wakelock!!! I will try to setup the phone to test your patch :) Thx. a lot!!!
This change requires the CONFIG_BCMDHD_HW_OOB=y in kernel config in order to do anything, but I'm having decent results. Posted a compiled test kernel on your thread today. Sometimes I see erratic behavior i.e. Typing on SSH takes a few secs to come back from deep sleep. But I think the fact that I'm far from my Wi-Fi AP have something to do with it.

On a side-note (but kernel related), I remember you were trying to setup Kitkat to support full-device encryption. It seems we would need to port/merge dm-verify into kernel in order to support that. I don't know what else we would require (I've bookmarked this: http://nelenkov.blogspot.com.br/2014/05/using-kitkat-verified-boot.html - but haven't read it yet).

It seems this will become a standard (mandatory?) feature as of Android L.
 

Zn7mkUKzN1r8aCIV

Senior Member
Mar 20, 2013
250
1,470
This change requires the CONFIG_BCMDHD_HW_OOB=y in kernel config in order to do anything, but I'm having decent results. Posted a compiled test kernel on your thread today. Sometimes I see erratic behavior i.e. Typing on SSH takes a few secs to come back from deep sleep. But I think the fact that I'm far from my Wi-Fi AP have something to do with it.

On a side-note (but kernel related), I remember you were trying to setup Kitkat to support full-device encryption. It seems we would need to port/merge dm-verify into kernel in order to support that. I don't know what else we would require (I've bookmarked this: http://nelenkov.blogspot.com.br/2014/05/using-kitkat-verified-boot.html - but haven't read it yet).

It seems this will become a standard (mandatory?) feature as of Android L.

For full-device (actually /data) encryption, the major problem from 10.1 -> 11.0 is that /data cannot be umounted to start the encryption process. I tried many many ways (safe boot (longpress reboot), manually disabled services and so on, /data simply does not umount to start with.

I was thinking of compiling a static vold to run in recovery (given /data is unmount in recovery mode) to start encryption, but seems Android L is going to have encryption as default, I am on the sideline at this moment...

Again thx. for fixing the wifi wakelock bug!!! :)
 
  • Like
Reactions: asmaron

ravilov

Senior Member
Jan 26, 2010
2,219
1,346
localhost
For full-device (actually /data) encryption, the major problem from 10.1 -> 11.0 is that /data cannot be umounted to start the encryption process. I tried many many ways (safe boot (longpress reboot), manually disabled services and so on, /data simply does not umount to start with.
That happens when there's a process running that has files open on a specific mountpoint. lsof usually helps to identify such processes. Most likely it is some system service, such as battd.
 

rhcohen

Senior Member
May 17, 2013
210
59
For full-device (actually /data) encryption, the major problem from 10.1 -> 11.0 is that /data cannot be umounted to start the encryption process. I tried many many ways (safe boot (longpress reboot), manually disabled services and so on, /data simply does not umount to start with.

I was thinking of compiling a static vold to run in recovery (given /data is unmount in recovery mode) to start encryption, but seems Android L is going to have encryption as default, I am on the sideline at this moment...

Again thx. for fixing the wifi wakelock bug!!! :)

This is a bit off the current sub-thread -- but with such amazing progress lately on the kernel, I thought I would ask -- I will likely have some time in the next month to help on kernel debug/development. An issue that I had concluded was kernel related was the random behavior of the microphone in Skype and some other apps -- sometimes the mic works, sometimes the other party just gets white noise. I previously posted a problem that I think is related, which is stereo recording apps (e.g. RecForge) sometimes recording one only one channel. I see these problems (skype and recording apps) with both CM10.1 and CM11, but not if I go back to CM10 (different kernel), so I think it is somewhere in the current kernel. Any thoughts about where to look?
 
  • Like
Reactions: cscmf99

PolesApart

Senior Member
Nov 20, 2012
303
724
Rio do Sul, SC
This is a bit off the current sub-thread -- but with such amazing progress lately on the kernel, I thought I would ask -- I will likely have some time in the next month to help on kernel debug/development. An issue that I had concluded was kernel related was the random behavior of the microphone in Skype and some other apps -- sometimes the mic works, sometimes the other party just gets white noise. I previously posted a problem that I think is related, which is stereo recording apps (e.g. RecForge) sometimes recording one only one channel. I see these problems (skype and recording apps) with both CM10.1 and CM11, but not if I go back to CM10 (different kernel), so I think it is somewhere in the current kernel. Any thoughts about where to look?

As @krystianp have been working on audio issues for quite a while now, I recommend you start by studying the github changes of his latest changes (I personally prefer latest-to-oldest reading) and trying to understand them. I myself know nothing about audio in both kernel and userspace (I think the last time I looked in ALSA code it was just merged in Linux kernel, by about linux 2.0. Boy, I'm getting old).

I myself would like to work in everything battery charging related, so that we would have fine charging and discharging statistics, including charging up to 100%, whatever that means. But I'm also clueless of where to start at this point, and a bit short on spare time.

Another areas I would like to look at are getting 5GHz Wifi to work (I suspect it's not kernel related, though, at least the sources from where I've merged bcmdhd updates are supposed to be ok on that regard) and HDMI. It seems HDMI is pretty much functional accordingly to Krystianp's video(s) on youtube, I think we just need to detect the plug event somehow and direct it to some form of "enable this output" command. I'll try to manually do this last part and if it works, we're in game.
 

rhcohen

Senior Member
May 17, 2013
210
59
As @krystianp have been working on audio issues for quite a while now, I recommend you start by studying the github changes of his latest changes (I personally prefer latest-to-oldest reading) and trying to understand them. I myself know nothing about audio in both kernel and userspace (I think the last time I looked in ALSA code it was just merged in Linux kernel, by about linux 2.0. Boy, I'm getting old).

I myself would like to work in everything battery charging related, so that we would have fine charging and discharging statistics, including charging up to 100%, whatever that means. But I'm also clueless of where to start at this point, and a bit short on spare time.

Another areas I would like to look at are getting 5GHz Wifi to work (I suspect it's not kernel related, though, at least the sources from where I've merged bcmdhd updates are supposed to be ok on that regard) and HDMI. It seems HDMI is pretty much functional accordingly to Krystianp's video(s) on youtube, I think we just need to detect the plug event somehow and direct it to some form of "enable this output" command. I'll try to manually do this last part and if it works, we're in game.

Thank you for the suggestions. RE audio I will have a look. Last time I had posted about this (months ago) github commits were way behind the kernel zips that @krystianp was posting at dropbox; seems like that has changed. RE 5GHz Wifi, it works on my phone. As does battery charging to 100%. (I am running CM11 v3 with your 1027 kernel). So hard to work on these problems when they are only problems on some variations of the same model phone. So getting back to audio, it would be nice to know if Skype works every time for anyone, and if so, what are the particulars of that phone (CM version, kernel, and hardware specifics).
 

Mustkeg

Senior Member
Jan 2, 2012
192
89
Google Pixel 6
Google Pixel 6a
As @krystianp have been working on audio issues for quite a while now, I recommend you start by studying the github changes of his latest changes (I personally prefer latest-to-oldest reading) and trying to understand them. I myself know nothing about audio in both kernel and userspace (I think the last time I looked in ALSA code it was just merged in Linux kernel, by about linux 2.0. Boy, I'm getting old).

I myself would like to work in everything battery charging related, so that we would have fine charging and discharging statistics, including charging up to 100%, whatever that means. But I'm also clueless of where to start at this point, and a bit short on spare time.

Another areas I would like to look at are getting 5GHz Wifi to work (I suspect it's not kernel related, though, at least the sources from where I've merged bcmdhd updates are supposed to be ok on that regard) and HDMI. It seems HDMI is pretty much functional accordingly to Krystianp's video(s) on youtube, I think we just need to detect the plug event somehow and direct it to some form of "enable this output" command. I'll try to manually do this last part and if it works, we're in game.

I pulled some logs while switching between AUTO, 5GHZ only and 2,4 GHz only.
AUTO is frequency band '0'. 5GHz is '1'. 2.4GHz is '2'.
The 'Failed to initiate AP scan' messages would appear "endless" if I didn't switch back to AUTO or 2.4GHz only.

Code:
I/WifiService(579):  WifiService trying to set frequency band to 0 with persist set to true
I/wpa_supplicant(6130):  wlan0: CTRL-EVENT-SCAN-STARTED 
I/WifiService(579):  WifiService trying to set frequency band to 1 with persist set to true
E/wpa_supplicant(6130):  wpa_driver_nl80211_driver_cmd: failed to issue private commands
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
W/wpa_supplicant(6130):  wlan0: Failed to initiate AP scan
I/WifiService(579):  WifiService trying to set frequency band to 2 with persist set to true
I/wpa_supplicant(6130):  wlan0: CTRL-EVENT-SCAN-STARTED

Hope that helps!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 764
    Olympus Kernel Project

    Team:
    Project manager: jjwatmyself
    Development: krystianp, lehjr, Epinter, and mmontuori.
    Testing: zeljko1234, Hai_Duong, upndwn4par, Cocolopes, firecode95, Matada02, IM_back!, sidVici0us, Grey.Mouser, and ovitz.


    Issue tracking: https://code.google.com/p/kernel-olympus/issues/list

    m1k3_ was nice enough to open an FAQ thread http://forum.xda-developers.com/showthread.php?p=40125786


    THREAD RULES:
    • Off-Topic posts are not allowed
    • Only posts related to this project are allowed
    This thread is under strict moderation with strict enforcement of the rules posted above.


    A lot of time is spent by the team developing and testing. Make sure to support us any any possible way.

    ROM Alpha Builds:
    CM9: http://forum.xda-developers.com/showthread.php?t=2286515
    CM10.1: http://forum.xda-developers.com/showthread.php?t=2060064


    The official project source code repository is here https://github.com/CyanogenMod-Atrix/android_kernel_motorola_olympus

    The kernel code is provided as-is and you assume all responsibilities in compiling/running the kernel code. Under no circumstance, the authors assume any responsibility on damaging devices resulting in running code posted on and related to this thread.

    The code posted is considered in development stage, and may or may not work. Only testers are authorized to post bugs.

    If you think you have a solution to a problem, send us a pull request. We will gladly look at it and merge it if necessary...

    This is a big project, so it's broken down into milestones:
    • Logs via JTAG [complete]
    • Boot Kernel on Olympus [complete]
    • USB Drivers [complete]
    • Boot Android GUI [complete]
    • Audio drivers [complete]
    • Headphone Jack [complete]
    • Accelerometer [complete]
    • Touchscreen [complete]
    • Buttons Backlight [complete]
    • Hardware/3d acceleration [complete]
    • Buttons volume up+down and power [complete]
    • Wi-Fi Driver [complete]
    • Bluetooth Driver [complete]
    • HDMI [post-poned]
    • Modem Driver [complete]
    • Fingerprint Kernel Driver [complete]
    • Fingerprint ROM Libs+Framework [work in progress]
    • Proximity Sensor Driver [complete]
    • Light Sensor Driver [complete]
    • Compass Driver [complete]
    • GPS [complete]
    • Sleep/Wake-up [complete]
    • A/C Charging [complete]
    • USB Charging [complete]
    • Camera/Video Camera [complete]
    • Front Camera/Front Video Camera [complete]
    • Flash [work in progress]
    • ROM Assembly [complete]
    • Mobile / Cellular voice calling [complete]

    Videos (chronological order last=latest):

    Donors: Manzing, Zeljko(x3), tmz83, chronicfathead, techlegend, Grey.Mouser, Franklee99, sirianni, donk, ebswift, jhonnyx, sendust7, fedegin, ScottyTheEngineer, buffalo06, r3xx3r, andrea_marcello, TheOnePom, ticiano_arraes, snaker23, wm_newbie, Fuzzypits, livadaki, vladeco, johnagelo, Mustkeg, sxg75, DannyBiker(x2), vitis586, Dazzel, scanuto, c2lover, r3xx3r, LFCxda, Vazay, jagiho, gcam1964, Doug_M, fastrite, Rockado, ddementiev, Night Walker!, cavava, t0mahawk, tsdedst, rabby80, jorgeavm, tonglebeak, ProudGrognard, terraformer, moderaterain, chonkit, Nicki760(x2), mchinand, ParfenR, John`, yuric, ~kyle(x2), trogdan, jisse44, Loki149, cncrd, mapeterson, J252, rumcajsz, grafithaka, kav64, sqkid89, clemare, saldirai, damn909, Infected24, leandrolnh, banjo76, chronicfathead, drekkschleuder, KrisM22, therox, praded2007, Clifton90210, renatotec, rustutzman, unicycler, blttalas, DJ_Squizzy, unekock, Babanenbieger, Taffy1881, fahadsadah, achaw, rspaulo, tsdedst, raitchison, chrismen83, kur41, blah4, Jazviper, 3dfxvoodoo, toomaiv, BaruchRamos, trogdan, smashen, futuremax2k, cheveoner, KCKitsune, chonkit, wm_newbie, Big-Bob, lamandrion, tchcaphr, thewarhawk, lionelbac, nikidorian, syngamer96, Starbomba, mchinand, baraev, demir76, ahmetcan44, leandrolnh, gnnash, J252, imarmand, galrock, tekmad, KrisM22, mrtynl, mrbitman, netinetinet, toomaiv, Sass86, Taren21, akrz, celli123, rigues, parquet, samiam21, 3dfxvoodoo, matteoclc, c2lover, gscastor, Darkcrush, TouchMeBell, zansatsu, rustutzman, Beenees, aaaviad, kisposi, torque, pgsmith68, sabtheleo, magiin, vitis586, farran, ScottyTheEngineer, vicfuze, chrismen83, Daws72, cmenekay, czarcorp, ddementiev, cmenekay, falcomer, babSky, sirkha, xyzwqt, runekock, nanohcv, jonbruce, kaiwid23, maddoka, Richy87, effractor, Level99. (for missed donors, please provide your xda username, donations did not contain it).

    NOTE: by donating, you authorize your alias to be displayed as donors.

    Donations are completely your choice, if you decide to donate, we welcome it. However, under no circumstances we are soliciting you to donate.
    You can choose to donate to the developer or tester of your choice, we will handle donations internally.

    _______________________________________________________________________________________________________
    Blog Status provided by jjwatmyself:

    Update 4/25/2013:
    Greetings planet Atrix 4G. It's been a long road and I am writing on behalf of the Olympus Kernel development team who have informed me that a public alpha release is imminent. This is an exciting milestone because you too will be able to play Temple Run, watch AnTuTu draw 50,000 triangles, experience performance that blurs the lines between ginger, bread, butter, ice, cream, jelly and donuts. The key to this lime pie will be your understanding the current status and that there are risks. Call them the ten commandments or ten steps to having a finger print that may not work when we are done... or may be it will.

    1) The kernel project waives any and all responsibility for damage to any and all devices, including your iPhone, your car keys, and your homework and your Dad's plasma. The builds provided are alpha, and represent danger. Permanent damage may result.

    2) The public Alpha release will be based on CM9 (ICS 4.0), CM10 (JB 4.1) and available without restrictions. The developers plan to merge trees into the current CyanogenMod-Atrix and the release will follow quickly this work.

    3) The FAQ thread (http://forum.xda-developers.com/showthread.php?p=40125786) is the place to post any and all bugs, installation questions or concerns. "Bluetooth..." "Wifi..." "I flashed and I can't..." "What about finger print..." "Webtop..." "What happened to my battery? (Crying)" "I flashed and it says..." "Can you lend me $5..." "How do you spell ACDC..." all belong on the FAQ thread.

    4) The official testers are the gatekeepers for bug entry at http://code.google.com/p/kernel-olympus/. You can see who's who under the People link on the main page.

    5) New bugs are subject to acceptance. If the bug does not meet the requested criteria on the Google form, it will be deleted. This means that our testers all have very sharp pencils. They are literally Ninja Warriors with one or more Atrix 4G to burn.

    6) Priorities related to bug fixes, enhancements, direction of the project are determined by the developer team.

    7) This thread is under strict moderation and serves to provide communication updates on the Kernel development. Hit thanks with confidence.

    Update 4/27/2013 12 noon US eastern:
    Greetings Planet Atrix 4G. It's been a whirlwind for the team over the past 48 hours with much positive progress. Everyone is pulling hard and the team effort is really paying off. Yesterday, there was some major work on building accuracy on status of issues, and their prioritization. The priorities at the present time are working on understanding battery usage and classifying bugs. It's imperative to understand that this is an alpha rom and that it is not a daily driver. Seriously, this is for testing on your spare Atrix. Our testers have been known to use an XDA issued hard hat and goggles (that's Goggles, not Googles for the non English speakers). Alas, a public alpha link has not been posted for these reasons, but it is so very close. Plus the XDA issued hard hats are only available in pink. To the Android software developers in our Atrix 4G community, that are patiently waiting for news on this release, we are excited that the public release is so, so close and hope that this renewal in the foundation can become the basis for additional ROM development work. To our larger community, your support continues to be epic and it is your continued interest in the work of the project developers and testers that fuels many late nights and long days. Hold onto your seats, it's going to get faster and more furious! Planet Atrix 4G will truly be amongst us soon.

    Update 5/6/2013 9:30 pm US eastern:
    Greetings Planet Atrix 4G. Just a quick update (picture a whale coming up for air). The development team continues to make progress, as shown on the bugs site. The focus is now related to battery drain during deep sleep. We want our beloved Atrix 4G to be it's battery sipping self that we know it is (ref MROM CM7). It's a multipronged effort with all developers working as a team on this important optimization phase of the kernel development. Also, there is life to tend to, so we have to recognize that the amount of time that is available on any given week will vary. Each developer's commitment to the project objective continues to be monumental. The community's interest in the project continues to fuel their motivation and the excellence in their work. Let the good code flow and cheers to all.

    Update 5/9/2013: <-- That's U.S. of A. date format, for all you non-Yanks.
    Greetings Planet Atrix 4G. It turns out that our developers are thanking their lucky stars for their XDA issued hard hats and they tell me they make the world of difference. Something to do with keeping brain waves in and RF from nearby cell towers out. I never thought they'd take to them like this, so I guess I finally got one thing right. Anyway, you may be aware that the development has shifted from public to private. This is part of a strategy to curb additional, premature public release. Simply stated, the public alpha release has not taken place yet. The team recognizes that learning how to compile code, makes for a seriously fun and gratifying project. I know when I compiled code for the first time I shouted down the hall "Mum, look what I made!" and she shouted back "Oh honey, that's really good!" (ref Google Search 'really good'). So, back to the subject at hand, the various guides out there are intended for use with finished code, or code you wrote yourself. There is plenty of it out there to play with, but as of this writing, this Kernel isn't one of them. For those of you that understand all the inner workings of writing, dissecting and compiling code, we are flattered and tip our hard hats, in respect and appreciation, for your enthusiasm and interest on the project. Stay tuned and we promise that information on progress and status will continue to be published here. The code will eventually be made public again and the good times will roll once again. We hope that this information and feedback is well received. We're all here for the same reason and remember, Planet Atrix 4G will soon be amongst us.

    Update 5/10/2013 6:30 PM US eastern:
    Greetings Planet Atrix 4G. I have some wonderful news. :) At 6:00 PM US eastern time today, an Alpha release candidate (Alpha-RC1) was made available to the official test team. Their test results will become the basis for the decision for the public release. I know, I know, you're jumping and cheering and doing kart-wheels and shaking hands with your neighbor across the street (unbelievable but true). The developers on this project are a solid team and they have worked so many wonders on our little Atrix 4G. Our test team has been particularly patient, waiting for this release. Their expertise in leaving no stone unturned is something that will help take this kernel to levels that developers alone simply cannot accomplish. Please remember that our developers and testers need all the oxygen they can get and there efforts are focused on the above directive. It's only a matter of time before the Atrix 4G takes over this little green and blue planet. It won't be called Earth forever!

    Update 5/18/2013 1:30 PM US eastern:
    Greetings Planet Atrix 4G! One week has passed… it’s been fast… it’s been furious… and much has happened!! To recap, a mere one week ago, our test team was presented with our newest Alpha build. Internally we called it Alpha-RC1. This was the most current work, with contributions from all of our talented developers. Well, let me tell you, our test team performed like no other. These guys put the T, E, S and T into testing. It is my privilege to witness the powerful dynamic at play within this team. So, back to the opening statement, much has happened! After last weekend, the test results were reviewed by the developers and testers. Their input steered the decision that the build would not be released. This was because we knew that the threads would become flooded with feedback on items we were well aware of. So as the week unfolded, an in-between kernel-update was released to the testers. It was called debug, despite having nothing to do with debug. Much was learned from this. Hot on the heels of debug, Alpha-RC2 was provided by the developers for testing. It is currently being taken for a spin and detailed analysis of performance, in many areas, is being conducted. This began a mere eighteen hours ago. Some of our testers have not even got any sleep! I have been told that the XDA issued hard hats apparently double as a pillow. Yes, it’s been a fast and furious week. If there is ever a time to be inspired by the work of others, this is certainly ranking near the top of my list. All who are reading this, please remember: this is ‘Not a daily driver’; it is ‘For testing only’; and ‘This is an alpha’. We know that ‘Love of Atrix 4G is strong in you, it is’. Please read the following sentence twice. We are working through logistics and preparing for of a public release. YES, you heard me (long pause) we are almost there… IT is almost here… WE hope you are ready. IT will soon be amongst us!

    Update 5/19/2013 5:00 pm US eastern:
    Greetings Planet Atrix 4G. It is my privilege to be able to announce to you the first public release of the Ice Cream Sandwich & Jelly Bean Kernel for Atrix 4G. This marks the combined efforts of our developers, krystianp, lehjr, Epinter, mmontuori, and testers, zeljko1234, Hai_Duong, upndwn4par, Cocolopes, firecode95, Matada02, IM_back!, sidVici0us, Grey.Mouser, ovitz, who have worked countless hours, regardless of hour of day. It is through our community’s continued and combined interest, support and enjoyment of this epic Tegra 2 device, that this release IS NOW AMONGST US. The public Alpha will be available soon as a CM9 and CM10.1 release, each having a dedicated thread. We will announce their going live here. We invite you to download and very carefully test. I would like to take this opportunity to congratulate the team and thank the community, as we celebrate together.

    Update 7/10/2013:
    Greetings Planet Atrix 4G. Much time has passed since the last update and we are all still here. Although there has been a slow down in activity, there has been continuous communication within the team. Just recently, Krystian produced two test kernels in order to understand some specific issues related to voltage changes under specific scenarios: with and without SD, wifi, Gps, while recording video, etc. These tests were designed to demonstrate hardware variations amongst the many manufacturing runs, where there were either component level differences, or components with differing tolerances. In addition, you may have seen the videos posted on YouTube, by Krystian, demonstrating improvements in device performance. The progress is consistent and with that said, we have an announcement.

    Effective immediately the source code, that was private has been migrated into the public realm. There are two branches:
    - CM 10.1 (4.2 JB) branch
    - ICS (4.0 ICS) branch

    The team is excited about this news, and we hope you are too. We believe that this provides a good foundation for many more advances in the future.



    XDA:DevDB Information
    [KERNEL] [3.1.10] Olympus (Atrix 4G) Kernel Project, a Kernel for the Motorola Atrix 4G

    Contributors
    mmontuori, krystianp
    Kernel Special Features:

    Version Information
    Status: Alpha

    Created 2013-10-06
    Last Updated 2013-10-07
    270
    Update 04/21/2013:

    There has been lots of activity on the development and testing front over the past few days and I have become acclimated with much progress made prior to my joining. I found myself drawing a comparison to a relay race. For example, just yesterday Epinter revealed the results of working some of his usual magic and the day before mmontuori was doing the same. The testers continue to jump on testing as each cm9 and cm10 alpha build gets refreshed. Something to note is that the initial boot logo (M) is improved and progress is being made in the wake issues.

    There is no eta on the public beta (I was paid extra to write that) but at this rate I won't be surprised if I am asked by the team to read from a different sheet of music soon. It's fast and furious in the kitchen readers, so stay tuned please.

    Please remember that this thread is under strict moderation. Use the thanks button, and express your reactions in the general area please.

    More to follow and thank you for your continued support. :)

    Sent from my MB860 using Tapatalk 2
    195
    Odp: Olympus ICS/JB Kernel Port

    Usb works :)

    Sent from my MB860 using xda app-developers app
    174
    Next Phase... Exciting!!!

    We just finished clearing out the process for the first release path, the only item left out for now, it's the fingerprint driver, mainly because it also requires ROM changes in order to work, so for now, we decided to post-pone that feature until the second development cycle.

    Soon, we are going to declare a code freeze, meaning no more changes unless there is a bug report associated with it. This is a normal step in code development methodologies to maintain bugs and features under control. With code freezes also code changes are much smaller and targeted only to address problems. Easier to troubleshoot.

    I am really excited about how fast things are moving lately...