Related
Title says it all.
The ODROID-T is a 10" tablet development platform using a Samsung S5PC110 (sound familiar?) SoC, sold by HardKernel Co. Ltd. (link, tech specs, dev area)
On their kernel build HOWTO page (link), they provide a cross toolchain download link.
Some saucy details:
Dir in tar: 4.3.1-eabi-armv6
Target: arm-samsung-linux-gnueabi
edit: the dir in the toolchain provided by Samsung in latest I9000 source drop is arm-eabi-4.2.1, so I presume the ODROID-T one uses newer gcc. Fewer bugs?
Since the hardware is so similar, has anyone tried building SGS kernels with this? I presume it to be configured and patched up ready for all the possible quirks and gotchas of this chip, so I'm quite curious as to the pro's / cons of using this versus the various CodeSourcery and CT-NG setups out there.
Any comments / experiences with this?
As far as I can tell there is nothing particularly special about the ODROID-T toolchain that sets it aside from any other ARM toolchain. You could almost definitely use that toolchain but there are several alternatives, here are some examples:
http://www.codesourcery.com/sgpp/lite/arm/portal/[email protected]=lite
http://www.gnuarm.com/
http://www.yagarto.de/
or you can build your own:
http://www.hermann-uwe.de/blog/buil...-with-binutils-gcc-newlib-and-gdb-from-source
Thanks for the links! I'll definitely check them out when I have time.
The reason I'm interested in people's experiences using different toolchains is because many of them probably use any number of patches for bugs which surfaced during tests on real hardware.
What really tipped me off about this was the wakeup lag story: one toolchain will produce laggy kernels, the other wont. That seems to indicate that somehow an obscure bug got fixed somewhere. Hard to pinpoint exactly except by lots of experimenting and compiling user reports.
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…
In due for our major rollout event, ARM. Project will be coming to your mako. We are an non-profit organisation alike cyanogenmod, but only focusing on creating a global aftermarket kernel for the Android OS, specifically to remove the major setbacks of linux.
What's so awesome about the kernel apart from stock manufactured vanilla kernels?
- this includes custom codes which are open-sourced, which aims to tweak the linux kernel to the peak for Android. This gives you a feeling like having Android and, at the same time, feel like you have the smoothness like ChromeOS.
What's in the codes you add?
- they are just codes ported over from other lightweight open-source OS, but, will also include our own various inspirations.
Currently, we are in closed development for mako. We are in need of 2 Maintainers for source building and basic bugfixes and 2 testers for alpha testing. Please PM me to discuss on.
We hope to help shape your phone's future!
nicholaschw said:
In due for our major rollout event, ARM. Project will be coming to your mako. We are an non-profit organisation alike cyanogenmod, but only focusing on creating a global aftermarket kernel for the Android OS, specifically to remove the major setbacks of linux.
What's so awesome about the kernel apart from stock manufactured vanilla kernels?
- this includes custom codes which are open-sourced, which aims to tweak the linux kernel to the peak for Android. This gives you a feeling like having Android and, at the same time, feel like you have the smoothness like ChromeOS.
What's in the codes you add?
- they are just codes ported over from other lightweight open-source OS, but, will also include our own various inspirations.
Currently, we are in closed development for mako. We are in need of 2 Maintainers for source building and basic bugfixes and 2 testers for alpha testing. Please PM me to discuss on.
We hope to help shape your phone's future!
Click to expand...
Click to collapse
Can't wait to see how this turns out
Let's just say the release is near!
First few versions will not include features as it will be more of a build clean fix.
Features will come in time by time.
DO NOT report bugs in the development thread. Report it here with the following info:
- Logcat
- dmesg
- A brief description of what happened.
Is there a kind of LTS (long term support) ROM that regularly backports kernel and OS security patches? Kind of like a 6.0.1 with January 2017 patch level? I know I can install most ROMs without GApps (Slimroms is probably my favorite) but most of these ROMs base either off AOSP or CM/LOS which also base off AOSP, so when Google stops patching AOSP, these downstream ROMs stop getting security patches.
I don't really care for Android N as I'm perfectly happy with M but would like to squeeze another year or two out of it.
Just curious if such a thing exists; I'm sure it's no small feat to backport security patches, but it's something I'm very interested in to get the most life out of what's still an excellent device. This likely applies to many other devices as well (N4, N5, OPO, others who have been retired for reason other than money).
Edit: I should add that I'm aware of new tags, such as https://android.googlesource.com/platform/build/+/android-6.0.1_r78 but these seem to stop roughly two years out and don't really seem to have a guarantee of when they'll stop being updated. I'm looking to extend that two year mark to three or four years.
Android doesn't do LTS like Ubuntu. If you want to have the most current security updates, you'll have to update to Android 7.1.1. Security updates will continue for another 12 months.
It would be cool if there was a custom ROM that implemented something like this; not necessarily android per se, but sometimes, especially in an enterprise environment this would be a great idea.
mituzora said:
It would be cool if there was a custom ROM that implemented something like this; not necessarily android per se, but sometimes, especially in an enterprise environment this would be a great idea.
Click to expand...
Click to collapse
This was more what I was thinking of. I know Android officially doesn't go beyond ~2 years but that's what I'd like to see changed. Desktop OSes and software sometimes have these long-life versions (as pointed out, Firefox and Ubuntu to name just two) so it would make sense to start doing this for mobile OSes, certainly in an enterprise environment but a "would be nice" is also for older units or people who really don't care about bleeding edge but don't want to be left behind.
I imagine a model similar to Redhat and it's Enterprise Linux distribution which is open source (and then released by the CentOS folks), though in that case Redhat themselves are doing the backporting and patching. Since Google doesn't do that (pretty much the opposite if you look at their rolling releases for Chrome/Chromium) it would have to be a third party responsibility.
It would be a pretty big undertaking and wouldn't solve any issues that would lie in binary blobs typically used for most the hardware, but it could be a base for others to use if they had something a little more open (or as open as a smart phone can realistically be). In case any security research students are looking for a capstone...
Edit: regarding the "not necessarily android" note; I was thinking about this while I was working on an Ubuntu Touch port. I like how polished Android is and that I can even use it sans-Google apps but being strong-armed into the latest version of the OS is pretty silly. I really don't care about anything N brings from M. The step from L to M was huge and M has been rock solid for me, so I would like to see M used as an LTS base. N is just too weird and buggy, even half a year into it. For me at least.
But why would you stay on 6.0.1 which is noticeably slower than 7.1.1 on N6?
I've not had that experience myself; performance has been either the same or slightly worse but that's very subjective. It's not terribly important if 6.0.1 were used as a base or 7.x, I just picked 6.0.1 as an example because of its maturity and my perceived stability over 7.x.
Nope! Google has stopped pushing security updates to Marshmallow so the latest security patch level you will have is December 2016 on any Marshmallow ROM. Gotta switch to Nougat to continue to get security updates.
The only two ROMs I'm aware of that still push M builds are Mokee and AOKP. But again, just because they have compile dates in January of this year, they are still going to have either the November or December security patch. Backporting is too much work and would be stupid for any dev to waste time on.
Nothing is a waste of time if you're learning.
retro486 said:
Nothing is a waste of time if you're learning.
Click to expand...
Click to collapse
Yes, but as a developer you learn more from the latest version, so it makes more sense to focus on it.
Android is not conceived as a LTS OS, it is made for devices which are meant to be used for two years, so it doesn't makes sense to provide security patches for older versions.
If you're really up to the challenge, you should start a LTS ROM project yourself, because based on your response, I think you like to learn, and I think you'll learn a lot by doing it yourself.
Fair enough. And considering my original question about an LTS edition was answered (several times) I'll leave it at that. Thanks!
Well, while not officially that, but I am on MOB31S, which is a 6.0.1 January security patch official ROM. It is currently the official T Mobile ROM. I'm not sure how you would get it if not on T-mobile.
Sony Mobile is committed to supporting the open developer community, and one way to show this is by publishing parts of our code as well as selected tools developed by our internal developers.
For some of the Xperia™ devices, we provide Android™ Open Source Project (AOSP) device configurations on GitHub. This means that the software will be open for you as a developer to use and contribute to. This is a way for us to support the open Android community, and it is also a tool for us to facilitate and verify contributions to AOSP.
If you want to build AOSP for your unlocked Xperia device, you find all the resources you need in the sections below.
https://developer.sony.com/develop/open-devices/
Unified 4.4 kernel sources
https://github.com/sonyxperiadev/kernel
Project git
https://github.com/sonyxperiadev/
Bug tracker
https://github.com/sonyxperiadev/bug_tracker/issues
Now you can build the latest Android with the latest 4.4 kernel
Vendor v11 is out
https://developer.sony.com/develop/open-devices/latest-updates
For user security dm-verity and File Based Encryption are enabled by default
Please disable them only if you are developing new features
Regards
J
Why do you deny us full functionality on AOSP?
You claim to support the development of AOSP and Androids ecosystems, but deny us full functionality of our hardware if we switch from Sony stock rooms ?, photos get crazy, lowlight even worse, the volume of sound is completely erased and all post-processing disabled got my XZ as a replacement phone when my newly purchased 9 died, and I have never seen such an openly "supported" project, which has been so denied by developers. There is no person who thinks "it'll will be really fun to develop on this phone, they will take away 90% of their PR sales points just if i unlock it, god what challenge this will be" ... Never happened .. Stop locking features behind DRM and / or make it irrelevant to AOSP ... Snälla... Låt oss välja själva, voiding warranty for UB'ing is enough. Don't remove points that made the phone sell if you really want us to be intrigued to develop, it's too late for XZ now, but for your future flagship, this is IMO a must
And gpu performance on AOSP is a letdown, even with latest v11 vendor files
All build guides are updated with the Security updates
https://developer.sony.com/develop/open-devices/guides/aosp-build-instructions/
Here is the list of all known bugs. If you find bugs you can always open a ticket in the bug tracker and we will check it ASAP.
https://github.com/sonyxperiadev/bug_tracker/issues