Hey guyz, you should look at this, f*** u se ¬¬
best reply from page 2 of the thread linked above:
kernelzilla said:
It's entirely far fetched, as OP is trying to correlate something that isn't the cause.
The only thing he's proven is someone typed make oldconfig or make menuconfig, there is usually no indication of source code changes in the .config, outside of new kernel config options that may be in the running kernel vs provided defconfig (did you even check? no). The fact that you didn't even mention looking at the actual kernel build timestamp in /proc/version tells me you don't really know what you're doing, it's not in the .config...
Are there any modules that exist on stock but aren't available for compilation from source? Are there any kernel modules that are exporting tainted symbols? (i.e. is /proc/sys/kernel/tainted 0?) That would rule out any use of proprietary or missing modules. Do any of the stock modules export newer versions or kmsg info that isn't in the source? I highly doubt you looked through the source this extensively.
Most production kernel development cycles I've been a part of involve a period of code freeze before the final release. Usually during this period only absolutely show-stopping bugs are fixed and things like debugging and factory/test hardware modules are removed. It is likely that this is what happens at SE.
Do you really think they put relatively untested code in the kernel during that 5 day period from source finalization and production build? Any changes, especially the security measure you speculate were put in, would require extensive testing. Judging by the contributions that SE has provided in AOSP, they test their software and hardware for compliance more than the average vendor. It's illogical to me to assume they've snuck some code in when they spend countless man-hours doing testing and QA.
This type of speculative witch-hunt makes the community look bad, not SE. You need to provide factual evidence of a license violation, not .config file changes.
Click to expand...
Click to collapse
Related
Not sure if we've had this response so far but I wanted to share it.
______
Dear Dave,
Thank you for your continuous interest on our product.
In particular, we''d like to recommend to use toolchain 2009q3 version. Our development team recommend this version.
(arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2)
Please send full details of your build error log.
Thank you.
Sincerely yours,
Oh, where to begin..
I believe that's the toolchain they recommend in their "instructions".. Regardless, we figured that out rather quickly.
The problem here is that what they released to us was not their production source code. It was some early development version of it, with a number of issues, the most prominent being it didn't even compile as provided.
The fact that we had to patch sound/soc/codecs/wm8994.c so that the phone wouldn't drop audio 5-10 seconds into every phone call is pretty much concrete proof that what we were given was development code, not production code.
I'm going to pass on the exact same message back, we'll see what happens.
Probably nothing.
at this point it's fairly pointless. we have been hastling them for almost a month now, and they've done nothing. despite all the issues with the code, our dev team has gotten their provided kernel source to boot and run with no issues, hence the overclocking kernels available. even if they did release the actual source now it's basically worthless. unless it's for a higher kernel version we can use for a froyo rom.
sonofskywalker3 said:
at this point it's fairly pointless. we have been hastling them for almost a month now, and they've done nothing. despite all the issues with the code, our dev team has gotten their provided kernel source to boot and run with no issues, hence the overclocking kernels available. even if they did release the actual source now it's basically worthless. unless it's for a higher kernel version we can use for a froyo rom.
Click to expand...
Click to collapse
Its not whether I its pointless or not, they need to be held accountable for uploading bad source which I believe is against the gpl. Funny how their build sh is configured for 2010 and they recommend 2009q3...
Sent from my SCH-I500 using XDA App
I agree, but is sending them a million emails that they mostly ignore really "holding them accountable"? I think not.
So ignoring them is the answer?
I think not.
Feedback is the most civil thing at this point. If its ignored, I'm sure more stern action can be taken, if the community as a whole decides to.
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
I wish somebody participated in this with you. I need it also /
funkydaemon said:
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
Click to expand...
Click to collapse
Good idea. Although most probably it'll all be native C code compiled into binary form, not amenable to decompiling.
So you'd probably need a very good debugger and a system call tracing facility in strace.
I guess hell might also break loose because SIM encryption(?), voice encoders(?), network locking(?) and god knows how many of those proprietary tidbits may be sitting in there.
SIM encryption broken leading to duplication of SIMs and leading to smartcard encryption and open source tools to reprogram your credit cards with more money.
That's not hell. That's hell in a hand basket with us enjoying the ride
Keep us posted. It's guys like you who think outside the radio that gave us the TV
For Qualcomm based devices you need to decompile Hexagon code.
For other Intel XMM6260 etc based devices suffice IDA (ARM).
In both cases the raw binary blobs may be encrypted, but extractable from running machine.
I'm working on it, in a fashion, and am writing up a document compiling everything that has been done on cellphone radio hacking. I've not found much on baseband firmware; there's a lot of info out there but it's been tough to find amongst all the other hacking that has similar keywords. Currently most quality info around this subject involve an extra (and depending on desired features; expensive) bit of hardware and two open source software packages with their decencies. As the hardware is currently outside my budget ($300 for the best bang for buck) I'll be working on getting the software to recognize the hardware built in my Android devices. Provided that all goes well I should be able to read and write on the frequencies that the in-built hardware supports and hopefully, as I always get an identical device when getting one, read and write with my backup android device. Be warned if you decide to follow me down this path; there are laws restricting what non-licensed persons/companys can do on certain RF frequencies and this depends on where you live, I'm no expert only a person capable of reading lots of dry informative documents, provided I do achieve direct contact between devices this hack could (and likely will) fry one of my antennas so be warned you'll likely do the same :banghead: so do this on an old device that you don't care about before ever trying on something you use daily. With the warning out of the way lets get down to the quick version.
~~~~~~~~~~~~
Currently all the developing I've found educational has involved the before mentioned "expensive hardware" known as software defined radio, shortened to SDR, go a head and pop open a new tab and Google search either. You'll eventually find that cellphone manufacturers have likely already put these into many devices. You'll also hopefully find the two kickstarters, HackRF ~$300 and bladeRF ~$400, these are likely what I'll be saving up for; HackRF for sure as the next release will likely be able to send and receive at the same time instead of switching quickly between modes. If you dig deep enough you'll find a blog post from a hacker that plugged an Android into a much more expensive SDR and was able to place calls and send/receive text; the blog poster stated something to the effect that this was not a useful hack but I believe that it's a great proof of concept and totally worth another look. However, this hacker has also almost been sewed for some of the demonstrations with this kind of technology involving the capture and description of calls and texts so tread carefully.
The software I mentioned before boil down to GNU Radio and Open BTS; there's dependencies for each but all seem to be installable on Linux running on top of Android. Furthermore I see that someone (I'll edit your name in in a sec Edit: idcrisis ) previous mentioned wanting c or c++ support, GNU Radio uses these languages perhaps I can ask for some help when I get a little further in porting this to run without Linux in the middle so much? I think if we use the GPS to set the time then the signal shouldn't drift to much.
I'm using an app called Debian Kit to give me a flavor of Linux called Squeeze for testing the software. If you choose to try what I'm doing then make use of the readme that the developer wrote or the guide I wrote for general Linux on Android installation and interaction fund in my sig to get started. If you want access to the document I'm compiling then you'll want to PM me at this moment as the chances of hardware frying is high and I'll share a link to Google docs; I'll be releasing a full guide when I've figured out how to avoid damage.
Eventually I hope to port many of the functions in GNU Radio into an app that makes use of internal hardware. Currently I've found a few that make use of hardware plugged into Android through USB "on the go" or "host mode" just search "RTL SDR" in the app store and you'll see'em, but, currently nothing making use of internal hardware. If any are interested in joining forces and helping figure out how to do all this I'd be glad to offer any support I can.
Other things related to cellular antenna hacking other than the above mentioned software and hardware that I'm compiling into the same document. Well this is where we get into the parts I'm hitting the wall on. It looks like I'll have to get into Kernel modification as this is one of the things used to communicate between software and hardware. There's also the flashable files known as radios and I'll be digging further in how these files are modified.
Basically this is a very tough question to answer and has taken many months of reading, searching, and more reading to get this close bit if we all work together I know that we'll be able to modify how the antennas in our devices work.
Edit 01142014- Found a guide on reverse engineering embedded device firmware, the guide is on a router but as the chips in our phones are embedded perhaps the steps are similar
http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/
Sent from either my SPH-D700 or myTouch3gs or M470BSA
Guide for running Linux on Android that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
^^ NO! The embedded chips in the Linksys routers are MIPS based and not ARM like all our Androids. Very different, although technique is the same.
But thanks, for taking time to check up on all this.
Any updates ?
Hey Guys,
I'm looking into this, I've successfully extracted files from the OnePlus One's baseband, its running RtOS called REX, QC calls it AMSS.
Have a look at the thread here: http://forum.xda-developers.com/oneplus-one/general/discussion-hlos-reverse-engineering-t3292829
Waiting for the OsmocomBB update it projects
QCOM modem leaked sources.
Type in google/bing: "AU_LINUX_ANDROID_JB_MR1_RB1.04.02.02.050.116_msm8974_JB_MR1_RB1_CL3904528_release_AU"
I'm sure I'm not the first developer to ask this question, so at the risk of possible embarrassment I pose this question to the development community as a way for myself and others to learn:
When we build AOSP projects we often do based on the repos from that project. But in Samsung's OSRC releases you often get 2 packages: kernel source and a "platform" package. In there is what Samsung "says" is needed to build AOSP for that given device. For example, I often see bluetooth and audio source in there.
So here's the question....
Given the issues we're seeing in i9505 variants for Bluetooth and headphone call audio, why do we not try using this source for testing purposes? Sure, it may not be the newest but if it works where we are currently having issues; couldn't the differences be merged and hopefully resolve the issue?
Obviously Samsung's solution of just "dropping" the source on top of stuff already being used doesn't make sense. But I can't believe I'm the first to ask and there has to be a reason why. Hopefully some maintainers can shed some light and by doing so, help newer devs (like me) understand the background behind it.
Thanks!
garwynn said:
I'm sure I'm not the first developer to ask this question, so at the risk of possible embarrassment I pose this question to the development community as a way for myself and others to learn:
When we build AOSP projects we often do based on the repos from that project. But in Samsung's OSRC releases you often get 2 packages: kernel source and a "platform" package. In there is what Samsung "says" is needed to build AOSP for that given device. For example, I often see bluetooth and audio source in there.
So here's the question....
Given the issues we're seeing in i9505 variants for Bluetooth and headphone call audio, why do we not try using this source for testing purposes? Sure, it may not be the newest but if it works where we are currently having issues; couldn't the differences be merged and hopefully resolve the issue?
Obviously Samsung's solution of just "dropping" the source on top of stuff already being used doesn't make sense. But I can't believe I'm the first to ask and there has to be a reason why. Hopefully some maintainers can shed some light and by doing so, help newer devs (like me) understand the background behind it.
Thanks!
Click to expand...
Click to collapse
The stuff in platform isn't what is needed for AOSP - it is (with rare exceptions) only GPL-licensed stuff Samsung is legally obligated to release.
Occasionally little bits and pieces of it are useful (like a single GS2 or GS3 release that included libsecril-client source code), but usually not.
For example, the BT stack in all GS1 platform releases was useless for AOSP, because it was Broadcom's hacked-up version that had dependencies on a proprietary binary (I forget its name - they got around GPL by making it a separate program that communicated using sockets with the rest of the BT stack.)
All of the BT/headphone problems with Snapdragon-based GS4s are, as I understand it, issues with libcsd-client (same library that was troublesome for Note2 and CM until someone ran libcsd-client through Hex-Rays Decompile to see what Samsung mangled...)
It seems like OEMs have a bad habit of hacking up libcsd-client in undocumented ways - LOTS of Qcom devices have had miscellaneous weirdness stemming from libcsd-client lately.
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
Cheers,
I found this new app here (https://forum.xda-developers.com/g4/themes-apps/app-kppd-control-t3639878) relating to colour calibration and it uses KPPD, an interconnect to Qualcomm's display driver named mdss. This looks to be a nice tool but I got curious as to the status of KPPD support on the Redmi Note 4 (with an SD obviously). This requires the mdp subcomponent of mdss.
Checking the kernel sources I got quite curious as to whether there is any kind of support and I do see at least that kernel driver's source code included but I am kind of uncertain whether it's included or not. I see little evidence of a usable defconfig so I cannot easily check whether it's even in the kernel included (thanks a lot for just throwing the sources out but not the most helpful build instructions at least at a glance; I will revoke that statement if I was merely blind).
I know that kcal is another alternative but that needs a kernel driver included (kinda meh but better something than nothing ) and that limits the kernel choices and ROM choices a lot. If anyone who is a dev knows of a "usable" defconfig that builds the official kernel source then I could look it up myself, but obviously I am lazy and may err with my deductions and rather get a straight forward answer in that case.
From checking the CIT I have the feeling that mdss_mdp is not supported as the LCD section lists mdss_dsi, another subcomponent of mdss.
EDIT: Pardon for the bad title Just after proofreading my post I published it without actually adjusting the thread title D: If a mod reads this, please adjust it accordingly to what you feel it should be