Related
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
scholbert said:
Hi kernel hackers,
it is getting very silent recently about possible security hacks on the Milestone platform.
Today i stumbled over some kernel code located in /drivers/misc/sec.
Maybe this had been discussed already.... anyway
There're some interesting functions in the source code and i wonder which application is using this module to enter the secure world of OMAP.
Some of the functions are accessing registers, that are also involved in low level routines of the bootcode (e.g. mbmloader).
Some questions:
Which application in android userspace is using this module?
Could we tweak this module to get access to some of the protected OMAP registers?
Is it a signed module?
Would be nice to use a modified module and activate some of the blocked features (e.g. DAP controller for debugging).
Any comments welcome!!!
Regards,
scholbert
Click to expand...
Click to collapse
Well, I'm not a kernel hacker, but I have an educated guess...
I believe that the radio system uses those functions to check whether the kernel is valid or not, so, we have the radio not working with a replacement kernel that is loaded using kexec...
Perhaps, if it is possible to "change" this function using a module, we could get a function always telling the kernel is valid and have kexec working on Milestone. Again, I'm not a kernel hacker, but that is my guess.
Hi, I'm sorry that I wont be much help but these guys might;
https://www.droid-developers.org/
irc://irc.freenode.net/#milestone-modding
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
scholbert said:
Hi,
thanks for your comments so far.
To be more precisely i think this kernel driver is calling the secure monitor in some way. See here:
https://www.droid-developers.org/wiki/Secure_Monitor
There's also a structure defined in that driver. I think i'll have to compare some of the ioctl entries.
https://www.droid-developers.org/wiki/Secure_Services
I'll do some investigation on this issue and search the web for some userland source code using this driver.
Again, if someone knows more about it, your welcome
Cheers,
scholbert
Click to expand...
Click to collapse
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
SophT said:
you don't have to search for the source, it's on SourceForge:
http://sourceforge.net/projects/milestone.motorola/files/
Click to expand...
Click to collapse
Yeah sure, i knew this
Anyway, thanks for the hyperlink!
In the meantime i grepped all binaries from the latest distribution.
I found out, that two applications are using /dev/sec.
1. dbvc_atvc_property_set
2. tcmd
If someone knows which package of source code they belong to... would save some time searching.
EDIT:
O.K. Google did it for me...
Seems that both binaries are proprietary code. Some early conclusions:
1. dbvc_atvc_property_set
This one is started as a service in init.mapphone_umts.rc and seems to use /dev/sec for granting rights to access OMAP secure world (e.g. read eFuse values for unique device id, IMEI etc.).
This binary contains a certificate which is not Milestone specific (XT720 uses the same).
So right now i don't know, if this certificate is needed to access /dev/sec or the application itself identifies itself as trusted application (signed app).
Would make sense, if the BP uses signed applications to access certain low level functions, e.g. read/write the eFuse bank.
2. tcmd
This one is also started as a service in init.mapphone_umts.rc to access a variety of devices. Seems to be related to data streaming or stuff.
As stated it has an entry for /dev/sec and it got no certifcate.
Would be interesting to get some more info about that.
Further comments....
P.S.: This bloody security stuff is making me sick
Regards,
scholbert
Hi again,
i just compared some of the defines in the kernel driver headers (/drivers/misc/sec/sec_core.h) with the ones xvilka reversed inside mbmloader.
Code:
...
#define API_HAL_KM_SOFTWAREREVISION_READ 33 // 0x21
...
#define API_HAL_NB_MAX_SVC 39 // 0x27
#define API_HAL_MOT_EFUSE (API_HAL_NB_MAX_SVC + 10) // 0x31
#define API_HAL_MOT_EFUSE_READ (API_HAL_NB_MAX_SVC + 15) // 0x36
...
For comparison see the table here:
https://www.droid-developers.org/wiki/Secure_Services
It is obvious that /dev/sec allows to access OMAP secure world and uses the above mentioned API calls to push information to userspace apps.
The question would be, if ioctl must be certified through the API using some key ...
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
See ya,
scholbert
scholbert said:
O.K. i see this is deep down code creeping, but maybe someone understands what i try to work out
Click to expand...
Click to collapse
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
mystichobo said:
I think I know what you are trying to work out, but I can't think of any way to help
You're pretty much comparing the results of your findings with that of the mbmloader dump right?
Click to expand...
Click to collapse
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
puffo81 said:
I would like so much to fully understand what you are doing, but I can understand just a little..
btw I hope that you'll be glad to know that you have all my psychological support!
Click to expand...
Click to collapse
Thanks a lot for pointing out
Best regards,
scholbert
scholbert said:
Yeah, kind of... we know for sure there's an API to access security functions on OMAP. I just digged out some parallels in kernel code and mbmloader.
If we could make use of security functions from within kernel space (by using a tweaked module) this would be a nice playground.
Perhaps, there's any bug or backdoor we could shamelessly exploit to:
a. boot custom kernel with second boot
b. tweak the security system and enable some hidden functions inside OMAP
Click to expand...
Click to collapse
That's what I thought
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Cheers,
hobo
mystichobo said:
Surprised noone has looked into it earlier really
Anyway good luck with it, adding my moral support too.
Click to expand...
Click to collapse
I got into contact with xvilka.
Obviously there'd been some investigations concerning this issue.
To be honest, i don't know if it's worth to digg a little deeper or if it will ever led to something useful in the end. Could be fun though
Perhaps it would be nice idea to tweak the driver and put some debug message in the code.
Another interesting thing to do would be a logging function.
This way it would be possible to get some insights of the API to secure monitor.
Anyway, i think it's never useless to discuss about some hacking here. At least were at xda-developers
If you like to tweak some kernel code, join in!!!
Have fun!
scholbert
Hello,
Just bough myself the amazing Galaxy Note 10, and it has "Peel Smart Remote" built-in app.
This app works fine with a lot of TV brands, but I believe it could be even better.
Are there any other apps that can control that IR emitter as well?
I want to be able to control my cable TV decoder, as well as other devices in my house, that are NOT available on peel.
As I'm trying to learn android dev (very beginning yet), I would love to know how to write my own app, so I could try to write something useful.
However, there are NO DOCS AT ALL about it! Not on Android SDK, not on Samsung SDK. No API related, absolutely nothing.
Looking at Samsung developer forums, their oficial position about the subject is that "there is no information about it, that's all we known".
Well, if "Peel Smart Remote" app is able to control that infrared chip, it MUST have a way for us (developers) to do the same!
Can anyone tell me/us how to start?
I don't know, maybe a little reverse engineering in peel's source code to find out how peel works, and reproduce it!
I believe I'm not the only one that is looking for some different uses for the IR Led Emitter on the Galaxy Note 10, so let's try to figure out something!
Thanks!
http://forum.xda-developers.com/showthread.php?t=1934442&page=3
afaik touchsquid programmers got the api from Samsung
Haldi4803 said:
http://forum.xda-developers.com/showthread.php?t=1934442&page=3
afaik touchsquid programmers got the api from Samsung
Click to expand...
Click to collapse
Hummmm now that was weird...
I just downloaded that touchsquid demo, and they have A LOT of limitation on the demo version: "you cannot try the samsung TV in this demo version". Also, you can't download it from market/play, you download the INSTALLER from play, and have to allow "allow other source" to install it.
I mean, if peel is obscure, touchsquid is even more!
What are they afraid of?
nope!
Demo mode has limited function because of license...send me a pm arr arr!
You install the .apk from market, And then You install the help And settings apk. These two are separat. No Idea why.
The developers of touchsquid are extremely responsive, I paid the £11 for the Samsung tablet version, it nicely controls my UK sky+, Samsung tv and hdmi switcher "straight out of the box" and after a couple of email exchanges my Phillips DVD system, they responded to emails the same day and in both cases updated their device database with correct ir codes within 1 to 2 days. Bearing in mind how poor Peel its for non American users, this it's the only alternative at present, it's a bit of a niche due to the general lack of devices with an ir emitter so any attempts of the developer community to make one would be keenly anticipated
Sent from my GT-I9100 using xda app-developers app
I wish Logitech would get in on this. I LOVE my harmony one remote, and would happily pay for an app that would let me do the same with my tab, even if it is a spendy app.
twiggums said:
I wish Logitech would get in on this. I LOVE my harmony one remote, and would happily pay for an app that would let me do the same with my tab, even if it is a spendy app.
Click to expand...
Click to collapse
Ask, and you shall receive...
http://www.logitech.com/en-us/tablet-accessories/other-accessories/harmony-link
Edited to Add: Oops! Sorry, doesn't work with ICS. WTH? Also requires an add on device...
Nakel said:
Ask, and you shall receive...
http://www.logitech.com/en-us/tablet-accessories/other-accessories/harmony-link
Edited to Add: Oops! Sorry, doesn't work with ICS. WTH? Also requires an add on device...
Click to expand...
Click to collapse
That's strange - stupid Logitech! I found that the best IR software for Android is the one that comes with the Sony Tablets. It has a great database of existing devices, but it also allows the IR blaster to learn commands from existing controls (ie I have an infra-red controlled light switch which it works with).
I imagine if there is an API for the IR Blaster someone could program such features in.....it's frustrating that Peel doesn't work with Sky though. I might try the suggestion above myself.
jonboyuk said:
I found that the best IR software for Android is the one that comes with the Sony Tablets. It has a great database of existing devices, but it also allows the IR blaster to learn commands from existing controls (ie I have an infra-red controlled light switch which it works with).
Click to expand...
Click to collapse
Any chance you could post links to the Sony apk and to that IR switch that allows the Note to learn commands? That would be great!
Haldi4803 said:
Demo mode has limited function because of license...send me a pm arr arr!
Click to expand...
Click to collapse
Just sent. License from who? Samsung? I mean.. Do we need to have a licensed remote control to work with Samsung (or other) devices?
Or is the license about using their trademark?
I mean, (if we got that API), can't we develop apps to control Samsung (and other) devices?
Can't we share them for free on Google Play? I can't think a way that this would cause financial losses for them!
Nakel said:
Any chance you could post links to the Sony apk and to that IR switch that allows the Note to learn commands? That would be great!
Click to expand...
Click to collapse
Actually, Galaxy Tab/Note only have IR Emitter.
It doesn't have a receiver, that's why we can't have a "IR Code Learning" with our Galaxy Tab and Galaxy Note.
Are there any developers here who can help me disassembly existing APKs, and try to find out how to control that IR chip?
I never worked with Java before, only learned to disassembly compiled C/C++ applications...
Nakel said:
Any chance you could post links to the Sony apk and to that IR switch that allows the Note to learn commands? That would be great!
Click to expand...
Click to collapse
As said before it's merely a blaster - not a receiver. Touchsquid is great but sadly the ui is seriously lacking polish!!
Yeah, yeah, I get that the Note 10.1 does not have a IR receiver. If you read the quote I list, a poster claims to have a switch that allows the sony app to learn. Hence, I asked for a link to the app and the switch.
Nakel said:
Yeah, yeah, I get that the Note 10.1 does not have a IR receiver. If you read the quote I list, a poster claims to have a switch that allows the sony app to learn. Hence, I asked for a link to the app and the switch.
Click to expand...
Click to collapse
No he doesn't - because that was me who said that. In fact, what I said was there is on the Sony S Tablet, the program is capable of learning commands BECAUSE the Sony has an IR receiver built in. Which doesn't help us because the Note 10.1 doesn't (which I have found out since making that post). I never said it would work on the 10.1!
jonboyuk said:
No he doesn't - because that was me who said that. In fact, what I said was there is on the Sony S Tablet, the program is capable of learning commands BECAUSE the Sony has an IR receiver built in. Which doesn't help us because the Note 10.1 doesn't (which I have found out since making that post). I never said it would work on the 10.1!
Click to expand...
Click to collapse
My mistake for misunderstanding your post.
jonboyuk said:
No he doesn't - because that was me who said that. In fact, what I said was there is on the Sony S Tablet, the program is capable of learning commands BECAUSE the Sony has an IR receiver built in. Which doesn't help us because the Note 10.1 doesn't (which I have found out since making that post). I never said it would work on the 10.1!
Click to expand...
Click to collapse
Well the Note hasnt a dedicated IR receiver, but maybe the camera could just do the same job. You can see the IR diode of any remote flashing if you point at the camera whilst using the cam app. Anyway there are already tons of IR codes available on the web, all we need is an app which is way more customable than the Peel app.
blue_one said:
Well the Note hasnt a dedicated IR receiver, but maybe the camera could just do the same job. You can see the IR diode of any remote flashing if you point at the camera whilst using the cam app. Anyway there are already tons of IR codes available on the web, all we need is an app which is way more customable than the Peel app.
Click to expand...
Click to collapse
What is really a "IR Code"?
Is that about the frequency of IR Led Blinking?
For example, on PEEL you have to choose your device, than you can customize key codes.
Example: My LG TV: Vol-up=326, Vol-down=327.
Peel doesn't support it, but let's say it DOES, and I choose "Samsung TV", but customize the Vol-Down code to "326".
Will it work on my LG TV? Or are there any other variables that intereferes on it?
I mean, if the only variable is that "code", than we could make a "Brute force" trying codes from 1 to 6556, and pause it when something happens to our TV or any other device, is that right?
About the camera working as a IR Receptor, that really would makes sense IF camera could take enough fps to decode the frequency.
That's something to investigate.
Are the programmers in "Android Development" aware of this thread? Someone with a little more technical information could add more to this thread (I can't post there, unfortunally).
Here's a good explaination of codes: ww w. hifi-remote.c om/infrared/IR-PWM.shtm l.
Some raw LG codes are here: files.remotecentral.c om/library/3-1/lg/2008_television/index.ht ml.
For the moment i have no idea how the 'code' number in the Peel remote is linked to the raw code. Illhave a look there tomorrow
Does anyboda have new informations regarding a infrared remote APP?
It would be great if I could remote control my LED Stripes with the Galaxy Note 10.1. There are some similar apps like IRDroid but all are using an external device.
Would it be possible to use the integrated infrared interface in android APP?
I copied the following response from Samsung's developer forum. Samsung will not release the API for the IR blaster on Galaxy Tab 2 series.
developer.samsung.com/forum/board/thread/view.do?boardName=GeneralB&messageId=169974
[email protected], Sep, 06, 2012 06:15 Post #1
Hello,
I have bad news for you.
Unfortunately I can't help you, since we don't provide IR Api to the public.
Regards,
Adam Panasiuk
Samsung Developers
Originally posted by : [email protected]
Hello,
I'll try to get the information you require and get back to you soon.
Regards,
Adam Panasiuk
Samsung Developers
Originally posted by : [email protected]
Hello!
We would like to find out if we can utilize the IR (Infrared) port on the Galaxy to comunicate to a another device. We do not see that the Standard Android SDK has any support for IR. Does Samsun have an SDK or API to utilize?
Thanks,
jeremy
Click to expand...
Click to collapse
Here is another forum post, I noticed that the username of the last response is "TouchSquid". They must have either talked to someone higher up at Samsung or figured it out on their own since they now offer an app.
developer.samsung.com/forum/board/thread/view.do?boardName=GeneralB&messageId=140654
This lack of an SDK is both bizarre and confusing. Both of the available apps - Peel and Touchsquid - are useless for different reasons. If you could combine them both then they might add up to a useful app but separately they're useless. I've tried and uninstalled both.
The thing that's really needed is someting I've been after for a long time and I'm surprised no-one has yet thought of it - a combined IP Remote. All the Hifi and electronics manaufacturers have their own apps and SDKs to control their equipment over wifi and each one needs to be installed separately. Imagine a single interface that could talk to all of the various IP controls. You wouldn't need an IR port then, just a set of IP controllable equipment.
It could be extended to incorporate things like Mediaportal or XBMC, WDTV live, AppleTV? - basically anything with a web based interface and an SDK. Build it so that each remote is added as a plugin and it can be expanded as each new device comes along. It would be the ultimate Home Cinema remote!
Someone get on it!
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
it's a great idea，but it seems so difficult for us to complete such a huge program.
one-piggy said:
it's a great idea，but it seems so difficult for us to complete such a huge program.
Click to expand...
Click to collapse
It is not as big as you make it out to be. The drivers already exist, they just need to be ported. The differences between 2.6.32 and 3.0.X (the first target) are not that big, so the changes needed should be limited. The number of drivers which need to be ported is also rather limited, especially given the potential number of volunteers. The difficulty level for porting these drivers is generally not that high, there are plenty of examples to be found for similar hardware which has already been ported.
The list contains 17 items. Several of them need to be checked for compatibility only (USE_OF, MACH_OMAP_MAPPHONE, VIDEO_OMAP2_VOUT, SND_OMAP_SOC, USB_MOT_ANDROID). This leaves 12 items. The CPCAP-related drivers might already be available (need to check later Motorola code). The procfs-related stuff should be easy to implement (PROC_DEVICETREE, OMAP3_EXPORT_DIE_ID) and might already be available under different names.
For OMAP-specific stuff (CONFIG_MPU_BRIDGE etc) there is linux-omap, more specifically several mailing lists frequented by people who have experience with porting to the linux-omap tree.
Porting the sensor drivers (SENSORS_AKM8973_AKMD, SENSORS_KXTF9) should be straightforward. The camera/video-related drivers might be more complicated as they'll need to be adapted to use ION. Then again, maybe they have already been ported? If not, there should be plenty of examples for similar hardware to base a port on.
I'm not saying porting these drivers/features will be effortless. Nor does it have to be. Porting ICS and later JB to Defy(+) wasn't effortless either yet still someone did it. By dividing the tasks needed to port these drivers/features the amount of effort needed will be limited. As said, I assume that there are several people frequenting this (part of this) site who should be capable of partaking in this effort.
YetAnotherForumUser said:
The differences between 2.6.32 and 3.0.X (the first target) are not that big
Click to expand...
Click to collapse
I second that. There's a huge misconception that 3.0.x a major change. But it wasn't. They just bumped up the version number.
Sent from my MB526 using xda premium
simmilar drivers in this repository
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
junesoung said:
https://github.com/redyk/omap3630-3.0.8
Lg Optimus Black(sniper) 3.0.8 sources..
I found smmilar drivers but i don't know these drivers same them
Click to expand...
Click to collapse
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
don't see a problem if someone wants to make a separate attempt. i think community effort has better chance in getting latest kernel up and running.
YetAnotherForumUser said:
LG Optimus Black 'sniper' kernel, 3.0.57:
https://github.com/TheMeier/lge-kernel-sniper-linux-stable
Has source for the following drivers, probably more - I just cloned the repository.
AKM8973 Magnetometer
KXTF9 Accelerometer
WL127X_RFKILL
Click to expand...
Click to collapse
Sounds good
GalaxySL use same cpu(omap3630)
It has 3.0 kernel too
You can find more drivers
Sent from my MB525 using xda app-developers app
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
May be this would help http://forum.xda-developers.com/showthread.php?p=33801839
http://forum.xda-developers.com/showthread.php?p=33710566
Sent from my MB526 using xda app-developers app
Comparison between Defy and LG Optimus Black kernel configuration
m11kkaa said:
quarx is already very far with the kernel. The actual problem is that he has no idea how to get display working.
If anyone can help with this that would be great.
Click to expand...
Click to collapse
The display subsystem in the LG Optimus Black seems to resemble that in the Defy(+), so for that purpose those sources can be useful.
For comparison purposes I attached a side-by-side diff of the default Defy(+) kernel .config and that for the LG Optimus Black.
domokos said:
Which is the base you intend to use as a starting point, test / compile against?
https://github.com/Quarx2k/jordan-kernel/tree/3.0.8-defy_display
This one?
Click to expand...
Click to collapse
That is the base I used to find missing drivers/features. For porting purposes it does not matter that much which base is used, as long as it is as close to baseline as possible. The linux-omap tree would be a good starting point as that is a) synchronized with baseline and b) where work on OMAP-related stuff takes place. As the purpose of the port is to get Android to run, the most recent Android-specific branch would be a good target. Of course there is much to say for taking the path of least resistance so if one of those other trees around here (Quarx 3.0.8-defy_display, LG, Samsung, a mashup of all three, etc) can get us where we want to be in less time that would be an option as well.
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
YetAnotherForumUser said:
Even though JB is more or less feature-complete on Defy(+) there are still a few nits which will be hard to squash without having access to features which are only available in later kernels (eg. the ION memory allocator). Given that this board is frequented by people who (theoretically at least) should be able to give a hand in porting the required drivers/features to get a 3.X kernel up and running on Defy(+) I started making an overview of those missing bits. It should only take a relatively small group of willing volunteers, each responsible for a driver or feature, to get those bits ported.
From a quick glance at the configuration options used with the currently used 2nd-boot kernel I come to the following list of drivers/features which will need to be ported to 3.X. Some of these might already be available under different names in the kernel. Others might have been ported but are simply not part of the kernel tree I used to make this comparison (Quarx2k/jordan-kernel; branch 3.0.8-defy_display). Yet others might not be needed in the newer kernel because their functions are taken over by other drivers/features.
This is not a complete list of features needed to get a kernel running on the Defy(+) (see mapphone_defconfig in branch 2.6.32 for what is needed).
In the following list I marked potential replacements in bold type, usually followed by a question mark (?) to indicate I'm not sure they are fully compatible replacements for the 2.6.X drivers/features. The drivers/features are listed in 2.6.X menuconfig order using Kconfig names and symbols.
Drivers needed for Jordan w/kernel 3.x
Top level
Support for open firmware device tree (ARM port)
ARM_OF -> USE_OF ?
Support for device tree in /proc
PROC_DEVICETREE
DSP Bridge driver
MPU_BRIDGE
System Type
Motorola Android Platform Phone
MACH_MAPPHONE -> MACH_OMAP_MAPPHONE ? complete?
Motorola Android Platform phone 2nd-boot kernel modifications
MAPPHONE_2NDBOOT
Export DIE ID code under /proc/socinfo
OMAP3_EXPORT_DIE_ID
Device Drivers/Misc devices
AKM8973 Magnetometer
SENSORS_AKM8973_AKMD
KXTF9 Accelerometer
SENSORS_KXTF9
Bluetooth power control driver for TI wl127x
WL127X_RFKILL
Motorola OMAP Device Type Driver
OMAP_DEV_TYPE_DRV
Motorola Modem PM Driver
MODEM_PM_DRIVER
Motorola netmux driver
NETMUX_DRIVER
Motorola netmux link driver
NETMUX_LINKDRIVER
Motorola Camera Driver
CAMERA_MISC
Device Drivers/Multimedia support/Video capture adapters
HP OMAP3 Imaging/3A driver
VIDEO_OMAP3_HP3A
Video out driver
VIDEO_OMAP_VIDEOOUT -> VIDEO_OMAP2_VOUT ?
Device Drivers/Sound card support/Open Sound System (DEPRECATED)
Audio driver for OMAP3430 with CPCAP
SOUND_CPCAP_OMAP -> SND_OMAP_SOC ( = ALSA)
Device Drivers/USB support
CPCAP USB Transceiver Driver
CPCAP_USB
Device Drivers/USB support/USB Gadget Support
USB Gadget Drivers (MOTO Android Gadget)
USB_MOT_ANDROID
Device Drivers/Real Time Clock
CPCAP RTC
RTC_DRV_CPCAP
So... anyone here who is willing and able to take on one of these drivers/features? Within a reasonable time frame (weeks, not months)? Anyone who knows of existing ports for these missing bits?
Why wait for Quarx or any of the other already overworked developers to do all the work? Just join hands, sing Kumbayah and get porting - but post here which driver/feature you want to work on to avoid needless duplication of effort.
I'll wait a few days for others to take the fun projects, then I'll start on those which are left.
Click to expand...
Click to collapse
Maybe this link can be useful: http://blackscratches.blogspot.ro/2012/04/how-to-build-android-kernel-308-for-ti.html it seems very explicit about porting kernel 3.0.8 on omap 3630 including drivers
Fight4Music said:
http://forum.xda-developers.com/showthread.php?t=1546102
maybe this will be helpfull?!
Click to expand...
Click to collapse
It might. For more stuff like that have a look at the Linux OMAP Kernel Project where you'll find more about the various OMAP-related development efforts. The above link points to one of the many branches of this tree:
http://git.omapzoom.org/?p=kernel/omap.git;a=summary
In the p-android-omap-3.4 branch there is a camera driver for the "Aptina MT9P031 Camera". The Defy+ (and Defy/Bayer) contain a camera based on the MT9P012. It stands to reason that there is a family relationship between all these mt9xyyy sensor drivers.
Working 3.0 kernel for Samsung Galaxy SL
The Samsung Galaxy SL shares quite a bit of hardware with the Defy(+). There now is a working (if not feature-complete) 3.0 kernel for this device.
https://github.com/dhiru1602/android_kernel_samsung_latona
Attached to this message is a side-by-side diff between the Defy default config and that for the latona (S G SL) as well as a side-by-side diff between the Optimus Black default config and that for the latona.
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
junesoung said:
http://forum.xda-developers.com/showthread.php?t=1546102
Sent from my MB525 using xda app-developers app
Click to expand...
Click to collapse
See #14...
YetAnotherForumUser said:
See #14...
Click to expand...
Click to collapse
Oh, sorry;
Sent from my MB525 using xda app-developers app
Listen to live FM broadcasts on devices that don't have a built-in FM radio!
Description
SDR Touch turns your mobile phone or tablet into a cheap and portable software defined radio scanner. Allows you to listen to live on air FM radio stations, weather reports, police, fire department and emergency stations, taxi traffic, airplane communications, audio of analogue TV broadcasts, audio amateurs, digital broadcasts and many more! Depending on the hardware used, its radio frequency coverage could span between 50 MHz and 2.2 GHz. It currently demodulates WFM, AM, NFM, USB, LSB, DSB, CWU and CLW signals.
You can get a compatible USB receiver for under $20 online from eBay. Just plug in your rtl-sdr compatible USB DVB-T tuner into your Android device using a USB OTG Cable and turn on SDR Touch. For list of supported Realtek RTL2832U based dongles, please see the end of the description.
Compatible USB DVB-T tuners
- Generic RTL2832U (e.g. hama nano)
- ezcap USB 2.0 DVB-T/DAB/FM dongle
- Terratec Cinergy T Stick Black (rev 1)
- Terratec NOXON DAB/DAB+ USB dongle (rev 1)
- Terratec Cinergy T Stick RC (Rev.3)
- Terratec T Stick PLUS
- Terratec NOXON DAB/DAB+ USB dongle (rev 2)
- PixelView PV-DT235U(RN)
- Compro Videomate U620F
- Compro Videomate U650F
- Compro Videomate U680F
- Sweex DVB-T USB
- GTek T803
- Lifeview LV5TDeluxe
- MyGica TD312
- PROlectrix DV107669
- Zaapa ZT-MINDVBZP
- Twintech UT-40
- Dexatek DK DVB-T Dongle (Logilink VG0002A)
- Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)
- Dexatek Technology Ltd. DK 5217 DVB-T Dongle
- MSI DigiVox Micro HD
- Genius TVGo DVB-T03 USB dongle (Ver. B)
- GIGABYTE GT-U7300
- DIKOM USB-DVBT HD
- Peak 102569AGPK
- SVEON STV20 DVB-T USB & FM
Interaction with battery savers
It turns out some manufacturers such as Huawei and Samsung have very aggressive power saving policies and force close background apps without notice. If the system decides to kill the RTL-SDR (or SdrPlay) driver while SDR Touch is running, the app will stop playing and become unresponsive eventually showing a "Disconnected unexpectedly" error message.
If you are experiencing this issue, the only solution that currently exists is to manually whitelist *both* the SDR driver app and SDR Touch in your phone's power saving settings to prevent the operating system from unexpectedly stopping the apps. More information and instructions on how to do this based on your particular phone make and model can be found on this website: dontkillmyapp.com
Feedback
An article about SDR Touch - Android Meets the RTL2832U from HamRadioScience
A user submitted video showing off advanced features of SDR Touch running on a mobile phone:
Any additional feature suggestions, comments or feedback will be much appreciated!
looking good sir looking good
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
daniel_reetz said:
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
Click to expand...
Click to collapse
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Although this seems to be a great app, I couldn't make it to work with Xperia Ray... ("no tuner found" error)
Anyone here had success with making it work on a Xperia phone?
martintzvetomirov said:
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Click to expand...
Click to collapse
Fanastic, thank you. I can't wait for squelch!
I'll supply whatever data/info you need to implement P25. I/Q samples are no problem. I understand completely that your time is limited and there is a larger audience to serve, but if you need resources, please let me know what you need and I'll see how I can help.
My account here is new, so I can't post links, but "DSD" and "radioreference wiki" will get you to the DSD source.
Amazing work! Well worth the $9.99USD pricetag. Gave you a nice review on the Google Market/Play Store as well.
FYI: Works wonderfully on an Acer A500 w/ Android 4.2.1.
SDR Touch has been removed by Google from Google Play! I will investigate the issue and will report back as soon as I have more information!!!
If somebody needs the latest version of SDR Touch, please download it from the attachment. Keep in mind that as soon as SDR Touch goes back to Android market you might need to reinstall it in order to get the latest updates!
Ok, just to make it clear for everybody that is concerned.
SDR Touch DOES NOT violate the GPL license!
SDR Touch is merely a client for - https://github.com/martinmarinov/rtl_tcp_andro-. rtl_tcp_andro is released under GPL2+. SDR Touch and rtl_tcp_andro are separate works in the sense of GPL. They are neither statically or dynamically linked and they are two separate executables that communicate over a TCP connection. rtl_tcp_andro is bundled with SDR Touch merely to help the user and with accordance to point 2. of GPL Terms and Conditions. You can think of SDR Tocuh as an "installer" of rtl_tcp_andro. It just launches rtl_tcp_andro with Runtime.exec("");. Furthermore SDR Touch could happily work without the bundled rtl_tcp_andro in network mode by connecting to a remote computer running either rtl_tcp_andro or the original rtl_tcp.
Therefore GPL is not violated. Saying that GPL is violated would be like saying that you can't listen to online radio with your proprietary music player because the radio is being streamed with a GPL based software.
A quote from GPL-3.0:
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Click to expand...
Click to collapse
Did you read that quote ?
... and which are NOT combined with it such as to form a larger program, in or on a volume of a storage or distribution medium ...
Click to expand...
Click to collapse
A single .APK _is_ a single distribution medium ... and they definitely _ARE_ combined to form a larger program. The "SDR Touch" .APK is the larger program, containing both your own code and the rtl_tcp_andro binary. That clause is meant for when you ship a CDRom with different stuff on it for example where they have no special relation ship. Here the relation ship and dependency is clear (even says so in the damn description of the app)
The problem is not with SDR Touch or the way it's a client for a rtl_tcp version, that's the right way to do it.
The problem is that both are distributed bundled.
SDR Touch and rtl_tcp_andro need to be two separate packages to be installed independently by the user.
There is also the requirement to make a written offer and include the full license terms when distributing rtl_tcp_andro, usual way is to include both the license in the .APK and also accessible to the user in the UI (menu often).
Cheers,
Sylvain
smunaut said:
Did you read that quote ?
Click to expand...
Click to collapse
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
The license is linked in the Help section of SDR Touch. The thing that I haven't done is to put the license physically on the apk as well.
But that's a good point,
Thanks,
Martin
martintzvetomirov said:
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
Click to expand...
Click to collapse
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
smunaut said:
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
Click to expand...
Click to collapse
Ok, I see your point and this looks like an option. I still can argue that they are separate but in order to prove that, as you say, I might split them into two packages.
Will see how things go, will keep you posted!
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
MS3FGX said:
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
Click to expand...
Click to collapse
Ok, this makes sense.
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
stejc said:
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
Click to expand...
Click to collapse
I already have sever requests about this. I will keep this idea in the record. I will first need to make sure SDR Touch is working properly and implement the list of features in the first post.
Also, I was able to rapidly prototype so far but now I'm back in University and I am forced to slow down the development speed. So it may take some time.
Any chance to make the whole app Open Source? This would be a nice recognition of the hard work done by the rtl-sdr folks, and solve your packaging problem.
I have licensed APRSdroid (which btw. can modulate and demodulate Packet Radio using audio in/out) under the GPL, and I can not complain about people not getting the paid version from Google Play.
To the contrary, 80% of my users actually bought the app, and all without evil nag screens!
martintzvetomirov said:
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
Click to expand...
Click to collapse
Absolutely. That is the idea behind the GPL in the first place, that other developers can benefit from improvements made to the code. Having a separate download for rtl_tcp_andro would definitely be a positive for the community, I could personally think of a couple interesting projects with it.
martintzvetomirov said:
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Click to expand...
Click to collapse
Of course, it's your right to keep your own software closed source. I don't personally believe in keeping this kind of software closed, but it's your decision.
Though I would like to point out that this type of software is going to get paid downloads either way. The type of users you will attract with this kind of software are the same kinds of users who have no problem donating to open source projects. We aren't talking about some casual game here that just anyone will be downloading, this is an application developed for more technical users who have a pretty good idea of the amount of effort that goes into a project like this.
In any event, I'm glad to see you taking the proper steps to make sure your software is GPL compliant.
FUNcube Pro & FUNcube Pro Plus Support
Any chance FUNcube Pro & FUNcube Pro Plus Dongles Support can be added in the future.
So wanted to connect my XZ Premium to my 4K PC monitor, but got response from Sony that they disabled this feature...
Snapdragon 835 has Displayport functionality through the Type-C, anyone know how to enable it?
Don't expext Sony to unlock this feature anytime soon even though it would only take them a minute or two.
They have a history of bottlenecking their smartphones by removing special features with every new device.
Don't believe me? Then check out this list. And that's only the tip of the ice berg.
https://forum.xda-developers.com/xz...xz-premium-t3660441/post73724764#post73724764
You'd have to get in touch with the folks at Qualcomm and ask them directly.
Please let us know their response here in this thread.
Good luck.
In theory, it is also considered that not all mobile devices and OTG are supported, but in practice exists an option for the rooted phone to change in some system xml code files.
Something similar must be possible here as well.