5 ms·

Windows Phone Internals Opens the Custom ROM World for Lumia Phones

79 points by ukz 11y ago

chiph 11y ago
If there's anyone who wants to get into this, I have a Lumia 920 (AT&T USA model RM-820) with Windows Phone 8.1 that I'm not using. Promise here (publicly) that you'll only use your skills for good, and it's yours.
- xlayn 11y ago
  Thanks for the goodie. Can I suggest to better wait a little bit and offer it in XDA for some well known developer once the thread sparks in fire?
- internet2000 11y ago
  Odd that no one's responding. If you want to get rid of your 920 and find no other takers, I promise I'll only use it for good.
  - chiph 11y ago
    PM me with your address (instructions are in my "about" field). I'm waiting on AT&T to unlock it (hopefully only 2-3 more days), and then I'll send it on. If they can't unlock it, I'll let you know (would be a bummer)
    - internet2000 11y ago
      Sent an email from f※※※@z※※※.org. Thanks!
- sp332 11y ago
  Absolutely! My Lumia 920 has been annoyingly broken for a while (works about half the time) and I miss it. Also my new Android phone has a locked bootloader so I'm missing playing with custom ROMs on that. I'd definitely be interested in driving tweaked, hacked, and radical firmwares on it!
hackuser 11y ago
It's great to have more open hardware. Even more, we need open OS's for mobile. There are no serious options beyond what the the market leader, Google, generously releases the code for: From what I can tell, almost all the 'custom ROMs' for Android phones are 99% AOSP [1] and do little to differentiate themselves from Android; by comparison, think of how different Linux is from Windows and MacOS. We need the BSDs, Linux distrbutions, GNUs, etc. for mobile. [1] Android Open Source Project, the free/open source version of Android that Google generously releases for devs to hack on. (Maybe it would be better for the open source world if they had to develop their own.) ----- EDIT: I might as well provide visibility to a few projects, though I know little about them; some might be defunct or dormant, for example. If someone can fill in details and gaps, it would help me (and others who are interested, I imagine) make sense of what's out there. Right now, I hardly know where to start. * OpenPhoenux (http://openphoenux.org/ http://openphoenux.org/): Several open hardware projects compatible with multiple OSes (imagine that - hardware on which you can install different OSes!), including the Neo900 discussed below and the GTA04. * OpenMoko (http://openmoko.org http://openmoko.org): "a project dedicated to delivering mobile phones with an open source software stack. Openmoko was formerly associated with Openmoko Inc, but is nowadays simply a gathering of people with the shared goal of "Free The Phone"." * Jolla and Sailfish OS (https://jolla.com https://jolla.com): An open system thhat looks commercially designed. Decended from Meego? * Meego and its many decendents: https://upload.wikimedia.org/wikipedia/commons/1/1b/Mer_and_mobile_operating_systems.svg https://upload.wikimedia.org/wikipedia/commons/1/1b/Mer_and_... * SHR (http://shr-project.org/ http://shr-project.org/): GNU/Linux based OS * QTMoko (http://qtmoko.sourceforge.net/ http://qtmoko.sourceforge.net/): "debian distribution for Openmoko Freerunner and Goldelico's GTA04 phone. Phone and user interface is based on QT Extendeded formerly known as Qtopia" defunct?
- gue5t 11y ago
  The folks at neo900.org and the leftover enthusiasts and hackers at maemo.org are working on building open-source replacements for the proprietary bits (pulseaudio codecs, a couple drivers, various middleware bits) from Maemo. They'd appreciate any help they can get from people who understand relevant topics or have time to learn. Eventually it should be possible to run fully open-source code (and an upstream kernel!) on an N900 or Neo900 and also make and receive telephone calls via oFono. I agree completely that AOSP is a joke of an "open source" project and that it engenders complacency while not providing the benefits a truly open OS would.
mschuster91 11y ago
The biggest problem for ANY alternative ROMs is the total and utter lack of transparency for chipset drivers and documentation. And even if the manufacturer publishes source trees for drivers, they're based on year-old kernel versions. Same goes for bootloaders. And that's a problem for the entire embedded Linux ecosystem, not just phones. I wonder what prevents the vendors from committing their drivers upstream? Can that be worked against, i.e. by the manufacturers or independent organisations financing people to integrate and maintain the drivers? It 'd be a huge benefit for the entire embedded ecosystem if people could find and fix bugs in out-of-mainline drivers, there are a shitload of bugs in them. edit: oh, and another thing, mainly concerning Android phones: the refusal of the Linux userland community to learn from Android and cut the craft accumulated in decades (x-server! the need for autotools which check for stuff that's been standardized for 10 years or longer without a way to cache certain tests systemwide! lack of really deep sleep, central to embedded systems! a shitload of "sound servers" resulting in 100+ms latencies!) to keep compatibility with even OLDER systems certainly does not help developers of alternative OSes.
- anonymfus 11y ago
  It is not a problem for Windows ROMs because SoC/board specific initialisation is done by UEFI on Windows phones and Windows NT kernel has a stable binary API for drivers.
- gue5t 11y ago
  You've hit the nail entirely on the head. Re: the reasons vendors never push code upstream, have you read http://lwn.net/Articles/662147/ http://lwn.net/Articles/662147/?
  - mschuster91 11y ago
    Yes. I seriously hope someone finds a local-root exploit for some out-of-tree driver used in a lot of devices, bonus points if it affects multiple vendors. Only when the pain/cost of going out-of-tree is too high, vendors will be forced to listen to the FOSS community instead of their bonehead lawyers telling that "drivers are our IP!!!!!!!!!!!". I'm shocked neither Heartbleed, Stagefright or that (iirc) Samsung kernel driver bug had enough of an effect. Or that Google does not require a (Github) published source tree for kernel+AOSP in order for certification.

79 points by ukz 11y ago

chiph 11y ago

If there's anyone who wants to get into this, I have a Lumia 920 (AT&T USA model RM-820) with Windows Phone 8.1 that I'm not using. Promise here (publicly) that you'll only use your skills for good, and it's yours.

xlayn 11y ago
Thanks for the goodie. Can I suggest to better wait a little bit and offer it in XDA for some well known developer once the thread sparks in fire?
internet2000 11y ago
Odd that no one's responding. If you want to get rid of your 920 and find no other takers, I promise I'll only use it for good.
- chiph 11y ago
  PM me with your address (instructions are in my "about" field). I'm waiting on AT&T to unlock it (hopefully only 2-3 more days), and then I'll send it on. If they can't unlock it, I'll let you know (would be a bummer)
  - internet2000 11y ago
    Sent an email from f※※※@z※※※.org. Thanks!
sp332 11y ago
Absolutely! My Lumia 920 has been annoyingly broken for a while (works about half the time) and I miss it. Also my new Android phone has a locked bootloader so I'm missing playing with custom ROMs on that. I'd definitely be interested in driving tweaked, hacked, and radical firmwares on it!

hackuser 11y ago

It's great to have more open hardware. Even more, we need open OS's for mobile. There are no serious options beyond what the the market leader, Google, generously releases the code for: From what I can tell, almost all the 'custom ROMs' for Android phones are 99% AOSP [1] and do little to differentiate themselves from Android; by comparison, think of how different Linux is from Windows and MacOS. We need the BSDs, Linux distrbutions, GNUs, etc. for mobile. [1] Android Open Source Project, the free/open source version of Android that Google generously releases for devs to hack on. (Maybe it would be better for the open source world if they had to develop their own.) ----- EDIT: I might as well provide visibility to a few projects, though I know little about them; some might be defunct or dormant, for example. If someone can fill in details and gaps, it would help me (and others who are interested, I imagine) make sense of what's out there. Right now, I hardly know where to start. * OpenPhoenux (http://openphoenux.org/ http://openphoenux.org/): Several open hardware projects compatible with multiple OSes (imagine that - hardware on which you can install different OSes!), including the Neo900 discussed below and the GTA04. * OpenMoko (http://openmoko.org http://openmoko.org): "a project dedicated to delivering mobile phones with an open source software stack. Openmoko was formerly associated with Openmoko Inc, but is nowadays simply a gathering of people with the shared goal of "Free The Phone"." * Jolla and Sailfish OS (https://jolla.com https://jolla.com): An open system thhat looks commercially designed. Decended from Meego? * Meego and its many decendents: https://upload.wikimedia.org/wikipedia/commons/1/1b/Mer_and_mobile_operating_systems.svg https://upload.wikimedia.org/wikipedia/commons/1/1b/Mer_and_... * SHR (http://shr-project.org/ http://shr-project.org/): GNU/Linux based OS * QTMoko (http://qtmoko.sourceforge.net/ http://qtmoko.sourceforge.net/): "debian distribution for Openmoko Freerunner and Goldelico's GTA04 phone. Phone and user interface is based on QT Extendeded formerly known as Qtopia" defunct?

gue5t 11y ago
The folks at neo900.org and the leftover enthusiasts and hackers at maemo.org are working on building open-source replacements for the proprietary bits (pulseaudio codecs, a couple drivers, various middleware bits) from Maemo. They'd appreciate any help they can get from people who understand relevant topics or have time to learn. Eventually it should be possible to run fully open-source code (and an upstream kernel!) on an N900 or Neo900 and also make and receive telephone calls via oFono. I agree completely that AOSP is a joke of an "open source" project and that it engenders complacency while not providing the benefits a truly open OS would.

mschuster91 11y ago

The biggest problem for ANY alternative ROMs is the total and utter lack of transparency for chipset drivers and documentation. And even if the manufacturer publishes source trees for drivers, they're based on year-old kernel versions. Same goes for bootloaders. And that's a problem for the entire embedded Linux ecosystem, not just phones. I wonder what prevents the vendors from committing their drivers upstream? Can that be worked against, i.e. by the manufacturers or independent organisations financing people to integrate and maintain the drivers? It 'd be a huge benefit for the entire embedded ecosystem if people could find and fix bugs in out-of-mainline drivers, there are a shitload of bugs in them. edit: oh, and another thing, mainly concerning Android phones: the refusal of the Linux userland community to learn from Android and cut the craft accumulated in decades (x-server! the need for autotools which check for stuff that's been standardized for 10 years or longer without a way to cache certain tests systemwide! lack of really deep sleep, central to embedded systems! a shitload of "sound servers" resulting in 100+ms latencies!) to keep compatibility with even OLDER systems certainly does not help developers of alternative OSes.

anonymfus 11y ago
It is not a problem for Windows ROMs because SoC/board specific initialisation is done by UEFI on Windows phones and Windows NT kernel has a stable binary API for drivers.
gue5t 11y ago
You've hit the nail entirely on the head. Re: the reasons vendors never push code upstream, have you read http://lwn.net/Articles/662147/ http://lwn.net/Articles/662147/?
- mschuster91 11y ago
  Yes. I seriously hope someone finds a local-root exploit for some out-of-tree driver used in a lot of devices, bonus points if it affects multiple vendors. Only when the pain/cost of going out-of-tree is too high, vendors will be forced to listen to the FOSS community instead of their bonehead lawyers telling that "drivers are our IP!!!!!!!!!!!". I'm shocked neither Heartbleed, Stagefright or that (iirc) Samsung kernel driver bug had enough of an effect. Or that Google does not require a (Github) published source tree for kernel+AOSP in order for certification.