So, I have a barebones version of MeeGo (barely) running on the Nexus S. I can't really do much with it on my own, but I'm posting the info here so you can build it and try it for yourself.
What works:
• ADB root shell
• X11 & UI apps
• Super-AMOLED brightness control (fixed! still off-colour tho…)
What doesn't work currently:
• Touchscreen
• WiFi
• Anything else
If you've never built a MeeGo rootfs before, it's relatively straightforward, and all the binaries are precompiled for you (but it's definitely for developers only).
I have my boot.img (kernel + ramdisk) and a MeeGo kickstart file at http://blog.steventroughtonsmith.com/2011/01/nexus-s-meego.html ; you can use fastboot to boot the image, or flash it to the recovery partition to dual boot. The actual MeeGo rootfs is run from a rootfs.ext2 file you can drop onto the Nexus S using Mass Storage mode - no need for messy flashing or the like, you can thank me later).
There's not much else I can do on my own right now, so if you want to see anything become of this do get involved!
My kernel is stock git://android.git.kernel.org/kernel/samsung.git ; make herring_defconfig; the only change was modifying the .config to turn on CONFIG_VT (needed for X11).
Go nuts!
Well done on the port so far. This is way beyond my area of expertise, but I do hope that some people can help build off of what you've done so far. Always nice to see what kind of fun stuff we can run on these devices...
Looking forward to more development on this!
Great stuff!
I have been waiting for someone to start something like this, I work as an embedded developer during the day so not much time at night but I will chip in were and if I can, I am pulling the source and looking at the build system / process.
Looks like you have done the heavy lifting of bootstraping the device now its just about porting drivers.
Cheers and great start!
What driver are you using for the X11 and is it accelerated?
ilfccd said:
What driver are you using for the X11 and is it accelerated?
Click to expand...
Click to collapse
It's using unaccelerated graphics; although, with luck, SGX 540 graphics drivers are available for other devices (like the OMAP4) so in theory you may be able to patch those to run.
Update - backlight working; color is still fscked, might be gamma:
According to PowerVR rep on CES there should be an open source driver later this year (info from Phoronix, but they are lately not really reliable source of info).
Here is another question though. Have you tried using the omap tree of linaro for the kernel build?
I don't have Nexus S around currently and I'm doing all my work on TI OMAP (A8) based IGEP v2 board and TI OMAP 44xx Panda (A9) board. As they both have PowerVR 530/540 graphics I'll check tonight or tomorrow if the closed driver is compatible with linaro's kernel as I'm currently running that on the IGEP. As Samsung is part of linaro, there could be some patchests for the hummingbird in there. The current uname -r for the linaro is: 2.6.35-1008-linaro-omap so it could be compatible w/ MeeGo's kernel, there could be even newer version in the git tree.
Keep up the great work, I'm really interested in what you are doing with MeeGo. Thanks!
ilfccd said:
According to PowerVR rep on CES there should be an open source driver later this year (info from Phoronix, but they are lately not really reliable source of info).
Here is another question though. Have you tried using the omap tree of linaro for the kernel build?
I don't have Nexus S around currently and I'm doing all my work on TI OMAP (A8) based IGEP v2 board and TI OMAP 44xx Panda (A9) board. As they both have PowerVR 530/540 graphics I'll check tonight or tomorrow if the closed driver is compatible with linaro's kernel as I'm currently running that on the IGEP. As Samsung is part of linaro, there could be some patchests for the hummingbird in there. The current uname -r for the linaro is: 2.6.35-1008-linaro-omap so it could be compatible w/ MeeGo's kernel, there could be even newer version in the git tree.
Keep up the great work, I'm really interested in what you are doing with MeeGo. Thanks!
Click to expand...
Click to collapse
I'm not sure how compatible the kernels will be, the Hummingbird is not an OMAP device (and it would be more akin to the OMAP3 than OMAP4); but if the kernel works, then it should work with MeeGo too. MeeGo is relatively versatile.
Graphics drivers would be nice!
I actually use the linaro distro (ubuntu essential, which i hate) to build meego inside it, because of the work the linaro guys did on the gcc compiler (should be better versed for arm chips). according to the wiki here https://wiki.linaro.org/Platform/UserPlatforms/2010-09-13
the drivers for omap3 should be freely accessible (the 530 core). there is a mention of the 540 core in there also, but I haven't really used them as I don't run X on the boards. You could try the PVR 540 driver for the OMAP4, you might be lucky with the build, could be compatible with the one in the hummingbird. If it is, this could potentially be far better than the Nexus and HD2 MeeGo 'ports' .
ilfccd said:
I actually use the linaro distro (ubuntu essential, which i hate) to build meego inside it, because of the work the linaro guys did on the gcc compiler (should be better versed for arm chips). according to the wiki here https://wiki.linaro.org/Platform/UserPlatforms/2010-09-13
the drivers for omap3 should be freely accessible (the 530 core). there is a mention of the 540 core in there also, but I haven't really used them as I don't run X on the boards. You could try the PVR 540 driver for the OMAP4, you might be lucky with the build, could be compatible with the one in the hummingbird. If it is, this could potentially be far better than the Nexus and HD2 MeeGo 'ports' .
Click to expand...
Click to collapse
I'd try the OMAP4 driver if it was easy to get! I can only find instructions for the PandaBoard, and no repo or download links.
I will try too, if I can't locate them myself will ask someone there. First of all I have some urgent IPoIB business to attend to, though. Probably later tonight or sometime tomorrow.
Edit:
I forgot to ask, did you build MeeGo from scratch or only the kernel and used the daily userland from the arm tree?
ilfccd said:
I will try too, if I can't locate them myself will ask someone there. First of all I have some urgent IPoIB business to attend to, though. Probably later tonight or sometime tomorrow.
Edit:
I forgot to ask, did you build MeeGo from scratch or only the kernel and used the daily userland from the arm tree?
Click to expand...
Click to collapse
Prebuilt userland, no compiling required. I always use the daily RPMs (when the repo is working…)
google just released new graphics driver dunno if that will help your screen problems https://groups.google.com/group/android-building/browse_thread/thread/90d5498622a6ea4
As far as I've seen this was the most promising thread about porting meego here..
So I would suggest to just contact the ones who dived deeper into the matter and even made some progress.
Thread: http://forum.xda-developers.com/showthread.php?t=764255
tomqman said:
google just released new graphics driver dunno if that will help your screen problems https://groups.google.com/group/android-building/browse_thread/thread/90d5498622a6ea4
Click to expand...
Click to collapse
Unfortunately the graphics driver they released is specific to Android, and Android's version of libc. I don't believe there's a way to get that running on GNU/Linux or MeeGo :-(
Being the noob I am what is meego?
tominater12 said:
Being the noob I am what is meego?
Click to expand...
Click to collapse
Nokia (and Intel)'s future smartphone/tablet platform. A real Linux distribution designed for mobile devices, entirely new touch based UI, GPU acceleration, multitouch, etc.
Whoever gets this done gets a beer from me I am really excited about meego but I wont be able to buy the n9 because im on contract untill march next year. If you can get this to run on the nexus s than it should run on the sgs too, that way I can use meego wothout buying a new phone Keep it up
tomislavp4 said:
Whoever gets this done gets a beer from me I am really excited about meego but I wont be able to buy the n9 because im on contract untill march next year. If you can get this to run on the nexus s than it should run on the sgs too, that way I can use meego wothout buying a new phone Keep it up
Click to expand...
Click to collapse
Am hoping to have it up and running on the HD2 first, and then hopefully some of the work we do for that will port over to the Nexus S. Can't wait for the N9…
Well the title pretty much said it all folks. I'm quite curious if there are still dev's around that are considering such a port ? As we all know 3.4 marked the merging of a lot of Android code to the mainstream Linux Kernel. 3.4 wouldn't actually be the best choice as 3.5 and now 3.6 has seen more code going upstream not only from Android but also ARM support.
Would be a real improve to have any of 3.x kernel for our devices. I've been trying to learn all the kernel parts that are needed to build, but it seems that there are a lot of changes since stock 2.6.35 or 2.6.38... IMO a real C code kernel developer is needed to have it working and a lot of free time to spent on it. I'm not that guy right now, but I know that in Desire forum there are a few people working on it, and if they could it would be easier to make it work on mahimahi.
BTW, I could buy a new N4 (the stock was sold in Spain in 9 minutes) and probably my N1 would be retired.
Are you the only kernel dev that is still active in the community ? Would be a sad thing to see the first Nexus phone go like this.
This guide tries to explain very briefly the different types of CyanogenMod builds, particularly for the Sony Xperia devices, and what usage each type may be suitable for. The guide is oriented towards newcomers, who often find themselves wondering what are the differences between these various builds (don't worry, I used to be perplexed myself) and which one would serve them better. Anyone seeking further information is well advised to check the CyanogenMod wiki or search around the forums here.
The nightlies are regular automatic builds* of the CM source. Because changes get constantly pushed to the CM source from various developers, these builds reflect a more or less random state of the code, and because there's no human intervention in deciding whether to build or not, the nightlies can contain random bugs. Actually, the larger and most severe bugs are typically filtered out by the preliminary testing and review process before they even get committed, but it's impossible to catch everything that way. Indeed, the nightlies' primary purpose is just to make sure that the code still builds correctly. Nevertheless, they are also a rather useful tool for large-scale testing -- and that's how these not-so-huge bugs get caught as well.
The more substantial changes or the ones that could possibly break a lot of things (or few things really bad) get tested separately, with the experimental builds, before they are committed to the CM source.
The stable builds are based on a snapshot of the source code that is deemed suitable enough for everyday use. They are expected to be free of any serious bugs. By the way, a "snapshot" is just what it sounds like: a momentary picture of the code at some specific point of time, as decided by of the developer(s) who oversee the project development. In technical terms, the snapshot is a Git tag.
When a stable release is planned, the commits are gradually restricted to only the ones that fix things; the ones that "merely" introduce new functionality (which potentially means new bugs) are postponed until after the release (in developer terms, the code is "frozen"). In this process, the code gets several preliminary snapshots, namely, the release candidates (or RC), which reflect the advancements in the code stabilization and bug fixing. In other words, each new RC should have more and more of the identified issues ironed out, until all of them eventually get fixed, at which point the stable version is finally released (hence why an RC is just a "candidate").
The FXP builds are manual builds of the CM code with patches by the FreeXperia project. FreeXperia is the core group of developers who, with the help from other skilled developers from XDA and CM, maintain the Sony Xperia line of devices for CyanogenMod. This means that (an often asked question) most of these patches get promptly committed to the general CM source. The only exception might be changes that turned out to behave badly. In other words, any fixes or new features in the FXP builds very soon get included in the CM nightlies as well. Unlike the CM nightlies, however, the FXP builds are manual, so they are expected to be more stable: whether because the current code has been confirmed as stable enough, or because particularly problematic one has been patched. Thus, they might be considered the equivalent of the CM milestone (or M) releases.
IMPORTANT: Whichever type of build you choose, always keep current enough backups, preferably of different types (e.g. a nandroid/CWM/TWRP and a Titanium/etc. one) and in different physical locations (in particular, keeping your backups only on your SD card is asking for trouble). Keeping several chronological versions is a wise practice as well (you might, for instance, find your last and only backup to be corrupt). Remember that you can never have too many backups!
Which version should I use if I...
TBA
This guide started as a post in another thread, and I'd like to thank @tilal6991 for confirming what had been only assumptions then. All your recommendations, whether to fix mistakes or to enhance the guide, or even just comments, will of course be very welcome.
----
*) The current list of the automatically built targets, together with the frequency of the builds, is here.
Changelog
----------------
12 Sep 2013 - Initial version.
Note to the mods: I'm afraid I couldn't think of better forum for this short guide. It is relevant to more than just the Xperia T, yet perhaps not that helpful beyond the Sony devices, as the major source of confusion seems to be the FXP builds (and these, of course, are Sony specific). If you do have a better idea, please don't hesitate to move the thread -- and thanks a lot in advance.
Note about "Which version should I use if I...": I'll try to fill that one in as soon as possible, but I got some serious problems at home, so it may actually take a while. Sorry about that.
Guide moved to general...
Nice guide Btw
Sent from mALL GLORY TO THE HYPNOTOAD!!
There's been a lot about EAS on XDA recently. Is there any sign of a kernel with it for Honor 5c or anything that can be ported?
Thanks
EAS is a Kernel enhancement currently being proposed to Linux Foundation. There's a series of patches to the Linux LPM Manager.
For it to come to this device, it'd take for a developer to port &/or apply the said patches to the mainline kernel for this device. Given that the design is so bleeding edge, it is considered not ready for user deployment. Hence the lack of one here.
More Reading - https://developer.arm.com/open-source/energy-aware-scheduling
In particular, I want to port Omnirom 4.4 to a device which has sources for that particular device available from it's manufacturer's website. Note: the documentation available from the github repo is very sparse and underwritten, particularly in the area of porting and building that port.
4.4 dates back to when I was still active (FYI I have not been active in the development community for 3+ years, kind if just popped in to check things out)
In general, a branch THAT old will not have any support and you likely won't find anyone bothering to code review any submissions. I'm not sure what the current state of the instructions for building for supported devices is.
No project has EVER had significant documentation on porting, because every device is different and the barriers you run into are different every time... It's something that is incredibly time consuming and you learn by doing. It requires general analysis and diagnostics/troubleshooting/problem solving skills. If there were a way to write a step-by-step porting guide - you would see far more devices supported at far higher levels of quality than what you actually see.
What device is this? I'm really surprised that you've found complete AOSP sources from the manufacturer. That's basically unheard of for anything other than Google devices and Sony's AOSP project. If you've merely found a kernel source code drop - congratulations, you've got around 1% of what you need.