Hi there,
I'm a programmer and formerly worked for one of the major Android handset developers as a platform engineer. When we developed the devices, we had separate build configurations and tools for kernel and platform, and built them separately... I rarely had any issue in building a new kernel for a platform, or building a new platform and using it with an old kernel.
That being said, what is the present difficulty that is being run into with using what should be a fully-functional GB kernel (incl. graphics drivers) with the ICS or JB platform? I am genuinely curious on this mark - if you are using the original kernel and drivers, I would imagine you should have full functionality (as they expose at least OpenGL ES in a consistent manner).
If you reply, please don't water down your comments - I'm a kernel developer myself (though not for Linux), so I appreciate and look forward to technical jargon.
"GPU Acceleration" (Hardware Acceleration) I'd imagine would be handled via the OpenGL interface libraries that come with the driver... that's what I'm asking: why can't the Gingerbread ones be used? What specifically prevents it from working? What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
As I said, I used to do this professionally, and am a professional programmer, so I'm looking for specifics.
AmeiseMike said:
What's preventing you from modifying the ICS/GB platform to be compatible with "less-featureful" drivers?
Click to expand...
Click to collapse
Nothing. And that's exactly what the devs have been doing so far. The result is well known to everyone - an almost perfect system that's lacking true HW acceleration in certain areas. Modifying and adapting can only get you so far.
I'm no expert so I won't pretend to be one, but as far as I know it has something to do with the newer nvidia drivers (that support proper HWA) which are proprietary binary blobs and have only been released for kernels newer than what we have. So we have a working kernel with semi-working adapted drivers, or true proper drivers with no kernel to use them on. And that's exactly where all the current porting efforts are directed - making a working kernel for the Atrix that's recent enough to make video drivers useful. In fact, since you say you have quite some experience with kernel development, you might consider joining the team, I'm sure they can always use any help they can get.
You could theoretically use existing drivers from kernel space, but they are not compatible with ICS.
Another option would be to ask nVidia nicely for drivers then build a new kernel, not forgetting two dozen other neccessary drivers, too.
OR, you could use a newer kernel with drivers that are compatible with ICS and which includes better handling of resources.
Option one will be adequate for Honeycomb. Hardware acceleration was first introduced in API level 11 (Honeycomb) and the XOOM was horribly buggy and slow with the old kernel.
Option two will never happen for various (obvious) reasons. For hardware acceleration to work properly you need nVidia drivers which require a 3.0 kernel.
Option 3 is something that a few in the Atrix community are working on.
My question, though, is why are said drivers incompatible with ICS/JB? What has changed that has rendered the platform incompatible with the previous drivers? If 3d Hardware Acceleration worked in GB, why can it not be used within ICS/JB (which should only care about GL ES, which hasn't changed)? If a feature of some sort has been added in ICS/JB that has caused the incompatibility, why not disable it? Features that had worked shouldn't be rendered inoperable unless a binary-level incompatibility exists, and I can't fathom why one would when you have platform source (via AOSP).
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
integraletotale said:
That is a question i'm afraid no one other than nVidia can answer. Why do their HA drivers require a 3.0 kernel is the question to ask.
---------- Post added at 10:37 PM ---------- Previous post was at 10:34 PM ----------
What existing HA in GB are you referring to?
Click to expand...
Click to collapse
OpenGL ES 1 and 2 fully function on Gingerbread (and are accelerated, that is, not rasterized by something like Mesa). These are components of the GPU driver, more specifically the GLES interface libraries. I don't see why those are rendered incompatible.
That stretches beyond my knowledge of what is made available by the driver, so, I really don't know. I'd greatly appreciate you taking a minute to review progress being made on github. Links in the development section of this forum in the thread mentioned earlier.
To put it into a different context (approaching it a different way), have any other OSen such as Ubuntu been ported to the Atrix, using the kernel, and having 3d HWA?
Not sure if it's useful information or..... but from what I've read even the GB kernel used by Motorola for the Atrix was just a cobbled up rush job based on a Froyo kernel..
So the ROM developers here have a steeper hill to climb than you thought.... Making ICS/JB ROM's operational from basically a patched Froyo kernel
I once got Honeycomb working on a Froyo device (don't ask), including HWA... without any kernel changes.
My suspicion is that maybe people are unwilling to hack up the platform to work with the drivers as they are? So long as there are drivers that have supported HWA, there's no reason that they shouldn't be able to continue to do so, you have to alter the platform so that it can. ICS/JB internally will look a bit more like GB afterwards, but many of ICS/JB's improvements were in the realm of expanding what used HWA (which already existed) and improvements in their multithreading code, neither of which should require anything that's not already there.
EDIT: I'd point out that I'm speaking hypothetically. I don't know what the actual issue is, hence why I'm probing for specifics .
Are there any developers around who might be able to shed light upon this for me?
Hi,
What eaxctly do you need this information for? Are you working on porting Ubuntu Touch on the Atrix?
AmeiseMike said:
Are there any developers around who might be able to shed light upon this for me?
Click to expand...
Click to collapse
here's a link http://forum.xda-developers.com/showthread.php?t=2016837 , maybe you'll get your answer there
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
AmeiseMike said:
I'm not sure what that link has to do with my original question? I'm aware that attempts for porting other kernels are being undertaken, what I am wondering is why it's necessary (and not a vague 'because x and Y require a new kernel, but specifics).
Click to expand...
Click to collapse
You asked are there any developers around who might 'shed some light' on your question. There's only a handful of developers left and the link takes you to some of the most current ones. You can also check out the others in the Development section.
What exactly do you need this information for?
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
AmeiseMike said:
To see if there's an alternate route towards porting newer versions of the platform to the phone (as I said, I've ported platforms to older kernels before when I was employed by one of the manufacturers), and as a hobbyist forking Android and porting it to my phone (which is an Atrix).
I'm just very confused as to what the problem is that necessitates a new kernel; I didn't have any issues like this when porting platforms before - I merely altered the platform so that it would work with the older drivers (sometimes that required disabling newer functionality, but functionality that worked beforehand was still there).
Click to expand...
Click to collapse
Instead of asking, why not try and do it and see for yourself.:good:
Because I'm not interested in potentially bricking / rendering unusable my phone if there's a known good reason why it can't be done.
Related
Good news guys!
Jerpelea announced the eminent release of Cyanogen RC2 for the X10.
http://forum.xda-developers.com/showpost.php?p=7370940&postcount=91
So to keep the dev only thread clean, please post your questions, problems or comments here.
Update 2010-07-28:
jerpelea said:
with actual state of spl it boots then crashes
you can play a lil with the new kernel included into package
build 0005
http://hotfile.com/dl/57983756/408a452/0005.rar.html
Click to expand...
Click to collapse
Great news and great work by the devs!
I think that this release will be internal i.e. devs only. We never got RC1 so why should we expect RC2?
you got that wrong guys
Froyo is ready in RC2 for X10 this is not equal to : "the bootloader is finally hacked"
So stay calm please
Regards
Bin4ry
Man i got excited for a minute there. Looks like back to waiting.
Sent from my X10i using the XDA mobile application powered by Tapatalk
Damn it!
Still good news that it'll be ready for when it does get hacked.
no more wet dreams.
ill stick it once it gets useful fr all...
its nice to see progress at least, I thought they hit a brick wall a couple days ago as they stopped posting in the dev thread. It may be a while till we see a bootloader hack thats friendly for us but its hard to determine since we're not devs. As I understand it, the actual ROM is partly ready but it'll have a number of bugs etc still and only devs who can actually load it on through manual code will be able to test it out I think. It may be that its actually just a virtual rom to be loaded onto the SDK under the same conditions as the x10 to be tested by the developers. I THINK. As I said I'm not a developer so take my words with a huge grain of salt because I might be completely wrong.
PLS Can we get a little more detailed information.
instigator008 said:
I think that this release will be internal i.e. devs only. We never got RC1 so why should we expect RC2?
Click to expand...
Click to collapse
PLS Can we get a little more detailed information.
If the RC2 will be ready tomorrow then it means that RC1 was launched on the device?
irkkso said:
PLS Can we get a little more detailed information.
If the RC2 will be ready tomorrow then it means that RC1 was launched on the device?
Click to expand...
Click to collapse
what is the meaning of rc1 and rc2
RC = Release Candidate
irkkso said:
PLS Can we get a little more detailed information.
If the RC2 will be ready tomorrow then it means that RC1 was launched on the device?
Click to expand...
Click to collapse
No no no... you got it all wrong.
RC2 is the latest release of CyanogenMod and work has been carried out on this to "Port" it over to the x10. There wasnt any point in working on RC1 if CM RC2 was out.
rc = release candidate
a software enters rc usually after testing phase(alpha-beta-etc...)....
j4mm3r said:
Good news guys!
Jerpelea announced the eminent release of Cyanogen RC2 for the X10.
http://forum.xda-developers.com/showpost.php?p=7370940&postcount=91
Click to expand...
Click to collapse
So Jerpelea made a edit on the post... which is something pretty much expected as the bootloader is not cracked. So my guess is that this is going to use the spl loader module to boot into the CM kernel which has been ported for X10? Just a guess...
Can somebody explain to people like me who are new on android what does the cyanogen mod, is it just a firmware ?
What is called "kernel" in android and is it "modable" and if yes, why would it be ?
The answers...
Vilam said:
Can somebody explain to people like me who are new on android what does the cyanogen mod, is it just a firmware ?
What is called "kernel" in android and is it "modable" and if yes, why would it be ?
Click to expand...
Click to collapse
Hi Vilam, those are interesting questions, let me see if I can address those to your satisfaction.
The term "firmware" being distinct from "software", in my view is rapidly loosing its ability to be distinguishable from the latter. Essentially it refers to those parts of the executable code on a computing machine which remains unmodifiable or rather "burned in" to the circuitry. With the advent of modern flash memory storage, which is rather malleable compared to the earlier variants which existed, it is rather easy to change and update the machine code which is stored therein.
In other words, you might still refer to firmware to be part of the "software" which runs on a computing device which is not modifiable at run-time. In terms of a smart phone (which are rapidly becoming general purpose computing devices anyways), the firmware forms the basis of the software execution environment which affords the so called "apps" to run and provide either ever so innovative and useful functions.
Coming around to the point about Cyanogen mod... its a combination of firmware and software (if you still want to make that distinction that is). It in conjunction with helper pieces of code like the bootloader et. all. can completely replace the components that your phone was originally shipped with. Since these are Android phones that we are talking about, Cyanogen is derived from the same code base that Google officially uses for their various releases of Android. It is important to note that Android is a mobile application and phone platform rather than something which can easily be classified as "firmware" or "software"
Next question of yours about the "kernel". Not knowing what your level of familiarity of Linux or its derivatives is... let just say that Android is essentially like a distribution (or distro) of Linux designed specifically to run on mobile devices. As is the case with other Linux distros, they are formed around a core known as the "kernel". The "kernel" forms the core of the operating system which provides a homogeneous execution environment for the execution of various applications, which are in-turn pieces of software which are designed to provide the functionality which can be useful to the end-user. So all the so-called "apps" require the kernel to provide some services which are abstracted out enough so that the application programmer does not need to care about the really really low level stuff that actually has to go down if you actually want your device to do something. Hence the application programmer concentrates on the "high level" stuff, which is the functions that are actually going to be useful to the end-user!!
Like all modern computing platform, Android is a layered architecture and the "kernel" forms one of the most inner most parts of it (hence the name "kernel").
The linux kernel running Android for the X10 is already modifiable. People have been successful in compiling software modules called "kernel modules" which can be added to a running kernel and add functionality to it (this of course requires super user privileges or "root" access on the phone).
With the future pointing towards the capability of running mods like Cyanogen and the likes, the possibilities of modding and hacking are endless. Cyanogen, like the original releases of Android from Google are completely open source, so one can tweak almost all aspects of the phone functions. The possibilities are only limited by ones own imagination.
PS: I think I had too much beer and it makes me practice my English composition skills... hic!
Thank you very much for this clear explaination !
Please let me explain in newbie wordings. This is for ppl who can't understand what's going on at all.
1. A firmware likes an OS, if not exactly is. Windows, Linux, DOS, OS X are all OS. In android phone, there is merely one OS, which is Android.
2. Android is Linux.
3. Linux has a kernel, which is the main program. Without this, your machine can't run. On top of kernel, there is other software (movie player/web browser). Kernel + other software = distro (distribution).
4. Windows has different distro like Home, Professional, Ultimate... Linux has also different distro, so does android. One of them is CyanogenMod. The other could be Xperia X10 original.
5. Android is open source, so everyone can mod it. But that does also means someone can remove functions from it, one of them is Sony Ericsson, which locks your Xperia X10 for professional use.
6. While it is easy for us to upgrade Windows XP to Windows 7. It is difficult to install OS X from Windows XP. This is the same case for Android, it is easy to upgrade our Xperia X10, but it is not that easy to install CyanogenMod. There are honorable person working on this issue.
7. Why CyanogenMod? Because it is faster or it does not lock function like original Sony distro.
8. Just like installing OS X on regular PC, installing CyanogenMod may brick your machine. Much worse, Sony will definitely don't get your X10 repaired. So think if you need that extra function.
Hey guys,
Wondering if anyone can help me with this opengl thing. I am simply curious to where in a ROM is it? Also wondering what it is/does. Can anyone point me in the right direction please?
Thanks in advance.
I believe it's in the kernel information. There are discussions regarding it for the HC rom, but supposedly, the kernels we've been using are .32 or something, and the one that contains the video files we need are on a .36 version, that's a bit more difficult ot work with.
Basically, openGL, as I recall, is part of a video driver that handles 3D rendering, and/or acceleration. Our Gtablets are capable of it, and the froyo builds support it, since we have openGL for them. It's proven more difficult to be able to reverse engineer them for gingerbread or honeycomb roms. Nvidea hasn't provided the drivers for these operating systems (yet) so it's up to developers to attempt to build them from scratch, using existing drivers...
What is chainfire 3d? I read that it can run opengl apps?.. is that true?
So reverse engineering is out of the question. Snap! Lol. Ok thank you fam.
not completely out of hte question, just more difficult than expected, I think. the only thing to work from are devices running on the ventana hardware...so REing it to run on harmony board is a whole different story.
As soon as any of the harmony devices get it, then reverse engineering will, as far a sI know, be feasable.
TJEvans said:
not completely out of hte question, just more difficult than expected, I think. the only thing to work from are devices running on the ventana hardware...so REing it to run on harmony board is a whole different story.
As soon as any of the harmony devices get it, then reverse engineering will, as far a sI know, be feasable.
Click to expand...
Click to collapse
I wish I could help a bit more but I'm sucking right now! I finally broke down and want to give back to Andriod community but the whole Dev thing is kicking my ass lol. Thanks though TJ
Well I am no developer, but I just had a concept that maybe porting a rom from an identical device could be less painfull then cooking a complete rom from source. I was doing some search on similar hardware to our dell streak and found that htc hd2 has the same chipset and gpu. So maybe porting nand android roms of hd2 to dell streak may work. I may be wrong but I just thought if this is possible, this might help many rom devs build even more latest roms with less issues..
Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Moving to Q&A
nostard19 said:
Well I am no developer, but I just had a concept that maybe porting a rom from an identical device could be less painfull then cooking a complete rom from source.
Click to expand...
Click to collapse
Problem with that is, that the board with the same hardware differ at least at the
baseband (radio). Streak Mini for example uses a baseband from Qisda Inc, whereas - when I'm not mistaken - the HTC HD2 uses a baseband from htc. So the 3G -system needs to be adapted.
That goes on with wifi, camera, touchscreen, sensors, gps, lights, softkeys. Don't even
start to think about different linux kernels
With StreakSense someone once tried to port a rom from HTC Desire HD. It looked nice but
you couln't do anything you normaly do with a phone. Same will happen to all ported roms,
when they miss to port framework.jar, services.jar, wpa_client, ril, keychars and so on.
In the easy way, you may just reuse files from the streak original-roms, but in some cases
you need to decompile/disassemble the java and machine code to port the software. And that is when it gets really dirty and you need a lot of knowledge of the streak and the source-plattform to do that.
This is why it is so remarkable, that hPa came up with the MIUI and CM7 Versions for the streak. They had done lots of the dirty work in korea. Some is still missing (the docking) but the basic functions where successfully ported.
The majority of the rom is platform agnostic, as long as it reasonably resembles an arm based android style device.
The drivers are mostly isolated into their respective binary files, it's just that since they're modifying the android source itself their interfaces could deviate from the stock one.
Gluing together a generic rom from a similar setup with the matching drivers isnt particularly difficult, it's fixing the rough edges to get a reasonably useful rom that is.
Even most of the frameworks could be bit identical as they might be identical. Only when you start deeply integrating stuff like an OEM skin does it start to differ (froyo and GB era touchwiz comes to mind)
If I were to pull numbers out of my ass, i'd say:
Doing a basic copy and paste port of CM/MIUI/AOSP/etc: days of work
Porting a rom to work with binary-only drivers (and getting something worth using): weeks of work
Porting a rom from scratch: months of work depending on available drivers
Recreating basic drivers: months of work
Porting device specific drivers: months more on top of the basic ones
Creating a 3rd party bootloader: feat of strength
Porting an entirely new os: not very diffucult assuming drivers are documented well and a 3rd party bootloader
It depends on the devs available though, it's not the amount of devs available, it's the amount willing and able to create drivers for a device.
Hmm, lots of things I didn't knew about porting.. well its realy an awesme job all rom devs are doing...
Sent from my Dell Streak using XDA
Hi all,
I am noob at XDA. (About myself: I am a software engineer aged 30. I have been hacking computers since I was 10.)
I am here because I am planning to buy a new Android device soon. (And unless something really revolutionary happens, I don't plan to upgrade it in the next 2 years or so, so it's a long-term decision.)
My short-list is:
- HTC One S
- Sony Xperia S
or, if everything else fails:
- Samsung Galaxy Nexus
The hardware of the One S and the Xperia S is obviously more powerful than the Galaxy Nexus; my only concern is the software side of things.
The thing is, I really don't like the customization the hardware vendors do with the software, so I want to run raw vanilla AOSP, or something very close to it.
(CM definitely qualifies.)
Also, I am sick of waiting for ages for new android versions to be ported to my device.
Obviously, Galaxy Nexus is guaranteed to be get Android upgrades first, so that's a safe choice in this respect, but since I like the hardware of Xperia S (and One S) so much, I would like to gain a better understanding the software situation of them, so I can make an informed decision about my purchase.
I am aware of the fact that Sony is actively supporting the Free Xperia Team, which is bringing CM9 to Nozomi (among other devices), but I have no information about the details of the project, or it's limitations.
So, my questions are the following:
1. What is the exact nature of the support Sony is providing to the FXP team? (HW? HW docs? Binary drivers? Driver source? Consultation?) Has this changed in any way, now that Sony Ericsson has become Sony? Was this a one-time action, or have they made any commitment about the future?
2. What does one need to build a vanilla android ROM for the S, using the AOSP sources? (Let's forget Cyanogenmod for now.) What is the status of the required device drivers?
3. What are the current obstacles, hindering the release of CM9 (or any other derivative of AOSP) for this device? As far as I know, Nozomi was released in 2012.02, ~4 months ago. ICS was released in 2011.10, ~8 months ago. Official ICS (Sony's version, with Timescape) is rolling out about now; CM9 is not yet released. I wonder what is taking so long?
(Please understand that I really, literally wonder: I am not demanding anything, and I am not trying to offend or accuse anyone; I am totally aware that I don't understand the process; I would like to have more information to understand what needs to be done. And since I am software engineer, and I am not afraid of getting my hand dirty, so eventually, I might end up helping with it...)
4. Do we have any information about Sony's plan for this device beyond ICS? Jelly Bean is coming up soon. Regardless of Sony's decision, when JB is released, I would like to run it on my device, as soon as possible. What are our prospects for porting JB to Nozomi? Is Sony going to help with porting the device drivers to the new kernel, is something like that would come up?
* * *
Thank you for explaining this:
Csillag
1) No one knows for sure, but I'm pretty sure that it's not game changing, judging by the progress me and Doomlord made on AOKP without any help from Sony (obviously).
2) You can try building Gingerbread, but no one cares, right? For ICS, see the next answer.
3) The most important problem is that we don't have the drivers/kernel sources, and there's not much motivation for building it from scratch considering the soon(ish) ICS release. There are leaks with files for so called 'brown' or developer devices, but they also don't give much because of different low-level software. So the state of things is that almost everything but wireless is working, but wireless doesn't work at all. That means data, calls and WiFi.
4) JellyBean will likely be a minor upgrade (4.1 that is) and there's nothing stopping Sony from releasing anything on the 4.x branch. When 5.0 comes, it will depend on the hardware requirements but I'd guess we're getting it too.
K900 said:
1) No one knows for sure,
Click to expand...
Click to collapse
How is that possible?
The FXP guys (bin4ry, jerpelea, etc) are here on these forums...
... did they have to swear secrecy, even about the circumstances?
but I'm pretty sure that it's not game changing, judging by the progress me and Doomlord made on AOKP without any help from Sony (obviously).
2) You can try building Gingerbread, but no one cares, right? For ICS, see the next answer.
3) The most important problem is that we don't have the drivers/kernel sources,
Click to expand...
Click to collapse
You mean we don't have the kernel sources for ICS, right? Because for GB, we do have something, in this thread... I guess I should ask this in the relevant thread, but has anybody determined the exact differences between this source and the stock ( 2.6.35 ? ) kernel this is based on? How many non-standard drivers are there? Do they come from Sony directly, or do they come from 3rd parties? I will need to look into this...
and there's not much motivation for building it from scratch considering the soon(ish) ICS release.
Click to expand...
Click to collapse
And according to past experience, how long does it take Sony to release the kernel for ICS, after the imminent official ICS release?
There are leaks with files for so called 'brown' or developer devices, but they also don't give much because of different low-level software. So the state of things is that almost everything but wireless is working, but wireless doesn't work at all. That means data, calls and WiFi.
4) JellyBean will likely be a minor upgrade (4.1 that is) and there's nothing stopping Sony from releasing anything on the 4.x branch. When 5.0 comes, it will depend on the hardware requirements but I'd guess we're getting it too.
Click to expand...
Click to collapse
OK, that part sound good.
* * *
Thank you for explaining:
Csillag
csillag said:
How is that possible?
The FXP guys (bin4ry, jerpelea, etc) are here on these forums...
... did they have to swear secrecy, even about the circumstances?
Click to expand...
Click to collapse
I haven't seen them tell anyone, and I've never seen them do anything that's not available for everyone else (thankfully).
csillag said:
You mean we don't have the kernel sources for ICS, right? Because for GB, we do have something, in this thread... I guess I should ask this in the relevant thread, but has anybody determined the exact differences between this source and the stock ( 2.6.35 ? ) kernel this is based on? How many non-standard drivers are there? Do they come from Sony directly, or do they come from 3rd parties? I will need to look into this...
Click to expand...
Click to collapse
There are kernel sources for GB, the same ones from which the stock kernel was built. If you mean the upstream Linux kernel, it'll be a huge diff that's not so easy to port without datasheets (which we don't have) and actual understanding of how the hardware works. Speaking of drivers, I'm pretty sure you misunderstand the way Linux / Android 'drivers' work. Kernel-space drivers (modules) and userspace drivers (libraries and daemons) are two different things. They have to open source their kernels because Linus's tree ('official' Linux) is GPL, but the userspace parts are proprietary. ICS also brought many ABI changes, so just taking old libs and placing them in a new ROM often doesn't suffice.
csillag said:
And according to past experience, how long does it take Sony to release the kernel for ICS, after the imminent official ICS release?
Click to expand...
Click to collapse
It takes time, can't say how long really, but it shouldn't take too long because they know we want those sources.
K900 said:
I haven't seen them tell anyone, and I've never seen them do anything that's not available for everyone else (thankfully).
Click to expand...
Click to collapse
Have you seen them being explicitly asked about this?
(Because not saying anything because not being asked is completely different that refusing to reveal this info....)
There are kernel sources for GB, the same ones from which the stock kernel was built. If you mean the upstream Linux kernel,
Click to expand...
Click to collapse
Yes, that was what I have meant when I wrote "stock". Now I see that it was ambiguous wording...
it'll be a huge diff
Click to expand...
Click to collapse
That's sad.
I was hoping for finding only some added drivers, plus some small configuration changes elsewhere.
that's not so easy to port without datasheets
Click to expand...
Click to collapse
obviously
(which we don't have)
Click to expand...
Click to collapse
We don't have it, but the "official" FreeXperia team might, or they might be able to ask for it. This is exactly the kind of information I am trying to find about their collaboration with Sony...
and actual understanding of how the hardware works. Speaking of drivers, I'm pretty sure you misunderstand the way Linux / Android 'drivers' work.
Click to expand...
Click to collapse
No, actually I get that part. (I am exclusively using Linux for about 13 years now, and I have also done some kernel hacks earlier.) But maybe my wording was ambiguous again...
Kernel-space drivers (modules) and userspace drivers (libraries and daemons) are two different things. They have to open source their kernels because Linus's tree ('official' Linux) is GPL,
Click to expand...
Click to collapse
Well, that does not stop some vendors (like NVidia) to ship binary kernel modules, so I would not be too surprised to find even binary kernel modules bundled with the code. But if they are open source, that that's great.
but the userspace parts are proprietary.
Click to expand...
Click to collapse
I did not know the devices require userspace parts. I was assuming that the kernel modules implement standard linux device interfaces; for example cameras are simply accessible via v4l[2], the modem is a character device, etc...
...so you say this is not the situation, and besides the kernel modules, they require custom user-space parts for operation, right?
ICS also brought many ABI changes, so just taking old libs and placing them in a new ROM often doesn't suffice.
Click to expand...
Click to collapse
Yes, that part is clean.
It takes time, can't say how long really, but it shouldn't take too long because they know we want those sources.
Click to expand...
Click to collapse
So, you say that it's a totally possible situation that we need to wait for several further months until we can get access to the kernel sources, and build proper CM9, right?
Unfortunately, this is exactly what I would like to avoid.
Maybe I should just stick to Galaxy Nexus, in spite of the older hardware...
Thank you for explaining:
Csillag
csillag said:
Have you seen them being explicitly asked about this?
(Because not saying anything because not being asked is completely different that refusing to reveal this info....)
Click to expand...
Click to collapse
They tend to ignore such questions. PM me if you want my personal opinion, I'll try to stick to the facts here.
csillag said:
Yes, that was what I have meant when I wrote "stock". Now I see that it was ambiguous wording...
Click to expand...
Click to collapse
Nevermind.
csillag said:
That's sad.
I was hoping for finding only some added drivers, plus some small configuration changes elsewhere.
Click to expand...
Click to collapse
They add some stuff, but they also change stuff internally. Tweaks and patches and many different things to get the best performance on this specific board. CAF has a generic msm-3.0 kernel, but that's not as customized. And we're not really waiting for the kernelspace here.
csillag said:
We don't have it, but the "official" FreeXperia team might, or they might be able to ask for it. This is exactly the kind of information I am trying to find about their collaboration with Sony...
Click to expand...
Click to collapse
Such things are very, very strongly NDA protected. That's Qualcomm's secret sauce, and it wouldn't be secret any more if they gave datasheets to the community.
csillag said:
No, actually I get that part. (I am exclusively using Linux for about 13 years now, and I have also done some kernel hacks earlier.) But maybe my wording was ambiguous again...
Click to expand...
Click to collapse
Nevermind
csillag said:
Well, that does not stop some vendors (like NVidia) to ship binary kernel modules, so I would not be too surprised to find even binary kernel modules bundled with the code. But if they are open source, that that's great.
Click to expand...
Click to collapse
Actually what NVIDIA does is ship a GPL'ed kernel module whose only function is to set up an interface through which the userspace (libGL) can talk to the hardware. So their kernel module is open source, but all the magic happens in the proprietary userspace.
csillag said:
I did not know the devices require userspace parts. I was assuming that the kernel modules implement standard linux device interfaces; for example cameras are simply accessible via v4l[2], the modem is a character device, etc...
...so you say this is not the situation, and besides the kernel modules, they require custom user-space parts for operation, right?
Click to expand...
Click to collapse
Android has a HAL of its own, so mostly it's about HAL modules, libGL and libril (Radio Interface Layer) to talk to the modem. And here is where many hardware vendors pull an NVIDIA.
csillag said:
So, you say that it's a totally possible situation that we need to wait for several further months until we can get access to the kernel sources, and build proper CM9, right?
Click to expand...
Click to collapse
No, the kernel isn't that much of a problem. If we have to wait for too long, we'll just take CodeAurora msm-3.0 and port it which shouldn't be too hard cause it's as generic as possible.
csillag said:
Maybe I should just stick to Galaxy Nexus, in spite of the older hardware...
Click to expand...
Click to collapse
If you want AOSP now, you should go with the GNex. But the XPS is a nice phone, and the prospects with AOSP are good. Also would be nice to have someone more experienced with Linux (I'm just a student here) on the team/forums. If you get the XPS, PM me or Doomlord and I hope you'll help get AOKP running
Yes yes, you may think that I'm crazy for attempting to compile AOSP, but in fact im just obsessed with getting AOSP to work (on my previous device I spent a full year on it without success), thanks to the experience I know much more know about the environment.
I've done several pure aosp builds so far, and they result in a ~280mb system folder, which is kinda the size of aosp I guess (atleast for xxhdpi)
But they end with errors of course, anyways. I used the devices specs with updated overlays,and added dependencies (such as hardware) to the environment.
But since the aosp environment is very mean to new devices its once again a real struggle. as expected, but I like the challenge.
Anyways, Im currently trying out this hybrid-ish environment. which contains the items listed above but with several elements of the AOKP environment added (only the essential ones for compatibility).
Compiling goes so far so good. hope I will get a working build. (don't expect this to happen tho)
Oh and since samsung is releasing the S4 Google Edition (AOSP) soon it must be possible. (the google edition is the qualcomm varian afaik)
More info soon!
I'm going to drop this here for now until I have time to mess with it more.
https://groups.google.com/forum/?hl=en#!topic/android-building/_F67iLDcVzQ
Note: This leads me back to my previous question as to how we are supposed to build with this.
At face value it seems we're only getting fairly close to what we were with other OSRC releases.
Going to look at more later tonight.
Skilled devs can get pure aosp to work properly. It was done for sprints gs3 without using CM code.
Sent from my SPH-L720 using Tapatalk 2
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
drewX2 said:
You don't necessarily need proprietary binaries to be released to build AOSP, although it does make it much easier. Sometimes you have to resort to trial and error and debug tools.
Click to expand...
Click to collapse
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
broodplank1337 said:
(edit)...I'm crazy for attempting to compile AOSP...
Click to expand...
Click to collapse
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
oOo B0XeR oOo said:
I disagree completely. Without the prop' libraries and drivers that the OEM has built to manage the board you can most certainly expect the related hardware to fail or be only partially functional at best. Some other 3rd party generic driver would still be required if this example were true. In the good old AOSP days (maguro for example) had roughly a dozen proprietary files required for the device tree to build. With more and more OEMs making different hardware configs and spin-off APIs trying to lock down a lead in the game it has inflated that number greatly. In this instance, for example, S4 requires roughly 165 proprietary files in the vendor/ and device/ tree. Furthermore, with many of those stacks being required to pass for a successful boot complete (audio for example) there is little chance for even semi-functional usage without the required libraries and drivers.
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries and I have handled every step in porting; from display, audio, to calling, wifi, bt, etc. Released means the manufacturer provides a nice little package for you. I had to in many cases, figure out which libs from a stock rom were needed. Additionally, you can utilize libs from completely different devices as a temporary patch. I am very comfortable with kernel development and the android framework. If you were too, you would know what I am saying is true. Here is one tip, nearly every board is like another (within the same class; eg. MSM8960, APQ8064) with only slight variations (e.g. modem). Once you understand that, it becomes easier.
We're compiling pure AOSP already for this board. I'm not sure what your repo structure looks like but if you are based off a CM or AOKP base clone then you got some work cut out for you. The CM tree compiles completely different than AOSP. All EaglesBlood builds are compiled from our same main branch, which consists entirely of only pure AOSP + our own EB coding. There is no CM codeblock nor anything else polluting (no pun). Since CM and others have some custom hybrid APIs and such you may run into issues that are difficult to resolve or even identify. If you aren't the one committing those patches then it is difficult to know at a glance of what has been heavily CM-ified vs closer to native code; or unless you're very in-tune with CM, gerrit and GIT.
We'll be releasing AOSP 4.2.2 as soon as we get the kernel config where we want it to be. Stay tuned. http://www.eaglesblood.com
I agree with you on some points about CM code, however, you're group has been porting devices that were working or nearly working with base android code. Talk about an easy route. I can see you haven't had to do any hard work yet. Going from 4.1 -> 4.2 on a non google AOSP supported device or a device that has no CM build available for it is a whole different story. How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
Lastly, although I agree with you on some points about CM code, you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them), but you should give respect and credit to those who make what you do possible.
Click to expand...
Click to collapse
See Above.
drewX2 said:
I think you misunderstood what I said. First of all, I am speaking from *experience*. I have ported AOSP to devices without RELEASED proprietary binaries...
...How do I know? I've done it. I was the first to build CM for HTC DNA and both CM/AOSP for Oppo Find 5. Next time before you "completely disagree," make sure you know what you're talking about.
[/QUOTE
Great, hi-five to you, but before making bold assumptions...
http://www.xda-developers.com/android/aosp-jellybean-build-for-the-t-mobile-g2x/
drewX2 said:
...(CM) you should give them credit because your stuff is probably based on their stuff more then you lead others to believe; like nearly every other "dev group" out there. And by no means, am I some CM lover (I've had my quarrels with them),....
See Above.
[/QUOTE
I never suggested anything about CM, they are top-notch. I said we dont use their base code like "every other dev". Sorry you have had quarrels; and there is nothing "probably based off them" as I just told you our repo is straight AOSP & EB.
Likewise you should "know what you're talking about", prior to making assumptions and speculations.
^read above
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Im currently working on this as well...anyone have anymore success? Im currently fighting my way through compile errors...but I would love to be able to atleast get a bootable pure aosp from source...ill keep at it...but if anyone has gotten it yet please help speed up my process and enlighten me on what you did to compile a working aosp
Sent from my SAMSUNG-SGH-I337 using Tapatalk 2
I guess we all are I'm working on one too. Lots of research on correcting errors
Cm10.2 anyone??
Sent from my GT-I9505G using Tapatalk 2
deleted
Wrong post
I did it successfully with help of some external repos
forum.xda-developers.com/showthread.php?t=2397511