Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
thebeastglasser said:
Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
Click to expand...
Click to collapse
Is not that easy! I'm an EVO user/rom porter and I hear this alot where users such as yourself think is an easy process BUT is not. Same processor, same screen size maybe the same BUT at times the kernel is not there. Either the kernel for the device doesn't support ROM A or ROM B and therefore it can't be ported to whatever device or the libs keep it from running half way decent.....i.e WiFi doesn't work, sound is **** up or whatever the case maybe...just not functional to say the least.
Take for example Sense 4.0 on the One V....it was ported to the EVO4g and the ROM barely works! Both the One V and the EVO4g have similar hardware but one runs Sense 4.0 like a dream and the other one struggles with simple things like WiFi and Sound.
Now I'm sure someone else with a bit more knowledge on this can get into the specifics and the why's and what's of WHY this can't happen BUT that's it in a nut shell.....the kernel and 9/10 times libs
See ya around dude!
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
thebeastglasser said:
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
Click to expand...
Click to collapse
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Theonew said:
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Click to expand...
Click to collapse
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
thebeastglasser said:
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
Click to expand...
Click to collapse
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
mf2112 said:
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
Click to expand...
Click to collapse
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Hmmm, I am not as familiar with the Nexus devices, but I suspect that Google has released the hardware spec details and the source code for the drivers for Nexus phones, so the source code can be modified and included for the ports. HTC unfortunately has not been as open with some of their phones.
If you were to put a phone together, you would need to use hardware in it that you had access to the specs and source code for. This is not a great analogy, but I think it will serve. The camera app tells the OS, "take a picture", then the OS tells the driver, "make the camera take a picture", and the camera device driver controls the hardware parts like the shutter, the focus, and zoom to cause the picture to be taken and handed back to the OS to be saved and then the OS notifies the app, "here is your picture, awaiting next command".
If you do not have access to the camera driver source code and camera hardware specs to create a driver, or an actual driver from the camera manufacturer, then you are missing the crucial third part and you cannot make the camera take a picture even if you get an OS loaded and an app installed there.
Check out The Tricorder Project for an excellent example. Create your own Star Trek "tricorder" with various sensors and a touchscreen that runs on Linux for around $200 and some work putting it together.
thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Its easy to develop for nexus devices since Google always releases their sources and those devices are easily unlockable (the bootloader). This is one reason why they are usually referred to as development/developer devices.
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
thebeastglasser said:
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
Click to expand...
Click to collapse
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Theonew said:
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Click to expand...
Click to collapse
Alright that makes a bit more sense. Thanks for your help guys!
Related
So, since HTC is now almost 3 months past due releasing the kernel sources, I've been trying to adapt the GSM kernel to compile and work with our devices, by disassembling the stock kernel and going through line-by-line of the source to see what needs changing.
I started by copying all the '*hero*' files to be '*heroc*', and renamed all the symbols to be heroc as well. Then pulled /proc/config.gz to use as a base config. Also had to fix up the Kconfig's and Makefile's, as needed, to be able to support HEROC-specific stuff. That more or less gets it to a point where you can compile the kernel successfully, although it's still just a GSM kernel with the name and mtype of heroc.
Then I imported the stock kernel (extracted from boot.img, then decompressed) into IDA as a ROM, setup the CONST segment of string data, imported the symbols from /proc/kallsyms using an ida .idc script, and analyzed the remaining areas of the ROM. At that point, I had a virtually fully analyzed binary ROM in ida, complete with symbols. Then went through and renamed the important symbols from the board-heroc* segments as needed to match what is in the source. I also set up some of the more complicated structures/arrays to make them easier to identify.
I found several differences between the stock heroc ROM, and the make-shift hero-turned-heroc source code, and fixed most of what I came across, or just left notes for things to investigate later. What I have now is a hybrid GSM/CDMA kernel that will likely not boot on either device But I figure since I've put as much time into as I have, and I'm sure there are people more familiar with IDA and ARM than I am, I'm putting my IDA file out there for people to start from. If you're not familiar with ARM assembly, this is absolutely useless to you, so you probably shouldn't bother.
I've spent 2 sleepless nights on it already, and still can't get anything to boot. I also tried to get htc_fb_console working so that I could at least see where and why it was dying, but that hasn't worked out well either.
So, by all means, have fun: http://madcoder.binti.ehpg.net/~madcoder/stock_kernel_heroc.i64
It was created using IDA 5.2, 64-bit, but I don't know how well other versions are with compatibility. Oh yeah, it's 35MB
And if you make some breakthroughs, please post about it here. When I get some time, I'll make a patch set to go from the released GSM kernel, to what I have now, and put that up here too.
Thank you, sad but true
I just wanted to say thank you for this work and express how sad it makes me to see the necessity of reverse-engineering in an OPEN SOURCE kernel. I never thought I would see the day.
I would be very curious to hear from you about the specific differences your disassembling unearthed. Can you say with certainty that the Linux kernel code has indeed been changed to work on the CDMA Hero? I mean it's not simply a matter of some missing driver code or other userspace stuff? If so, this would be pretty damning for HTC.
Thanks again, it's amazing to watch the XDA developers' progress in spite of the barriers put in front of their work.
The majority of differences I found were in things like heroc_fixup() where it doesn't check for engineerid/skuid/etc; different camera driver (s5k3e2fx, vs cy8c); fewer checks for multiple pieces of hardware (which is weird considering the stock phone's kernel supports 4 devices) based on system_rev; wrong vreg_get() strings; etc.
The source that HTC released *does* appear to have all the support we need. With modifications to Kconfig and Makefile, and ignoring the missing board files, you *can* compile the kernel directly, using the stock /proc/config.gz, which means all the necessary drivers are already in the GSM source. It's quite obvious that they had a working kernel tree that supported the GSM phone, plus our 4 CDMA phones, and they simply yanked out the CDMA board files and Kconfig changes, before releasing the source code.
What worries me is that I can't get a console, so it's incredibly difficult to find out where it's dying at. If I could get even a serial console to work, it would make this task so much easier. I think my next step is going to be to load up my hacked kernel into ida, and see how different the two are -- that might be easier than translating asm into C and comparing that way. If I can just compare the assembly for the two, it'd probably be easier.
maejrep said:
plus our 4 CDMA phones
Click to expand...
Click to collapse
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
markachee said:
Not to derail this too much, but which 4 phones do you mean? does it name them in some way?
Click to expand...
Click to collapse
MACH_HEROC (sprint hero)
MACH_DESIREC (vzw droid eris)
MACH_HEROCT (not entirely sure, maybe bell south hero?)
MACH_NEONC (neon is supposed to be the touch dual, which afaik has never been planned as an android phone, so I'm not sure what's up with this name either)
You can see those in the /proc/config.gz on the phone (ungzip or zcat it first ), and just search for "CONFIG_MACH_".
Also in the htc_wifi.c source, you can see references to espresso, and many others.
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Mr. Biggz said:
Would it be possible to port the moment kernel over and use that since its the same processor type and then fill in the things we need?
Click to expand...
Click to collapse
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Keep up the amazing work mad man.
travo1 said:
I was talking to zefie not too long ago and he was saying the hero kernel is so much more stable than the moments kernel... just my 2 cents.
Click to expand...
Click to collapse
Yeah, my fiance went through 2 moments, and they were so buggy she switched to the Hero. No problems since.
flipzmode said:
Keep up the amazing work mad man.
Click to expand...
Click to collapse
+1 for keeping up the good work!
:beer: (Does that emote work on this forum? I hope so...)
bumping this so it doesnt get buried 3 pages again
toastcfh said:
bumping this so it doesnt get buried 3 pages again
Click to expand...
Click to collapse
I thought you said you were going to bed
gu1dry said:
I thought you said you were going to bed
Click to expand...
Click to collapse
i was till i had to refresh again
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
maejrep said:
Yeah, I basically put this on hold, due to work priorities (happens a lot unfortunately :/)
But with the news that HTC may be releasing the source soon, this is probably not worth continuing anyway
Click to expand...
Click to collapse
Honestly, I would continue it. Nobody's sure that HTC will release the source code (HTC said they would release the source for the "Gero"...we're hoping that was a mistype).
I have a feeling they won't release it anytime soon and you'll probably solve the entire issue with the cameras and more before that source is released.
bump.... its on the second page
Yea def keep the good work up HTC said over the weekends tht came and went so now all we got is you my good man
man we gotta get this thread stickied!!!!
toastcfh said:
man we gotta get this thread stickied!!!!
Click to expand...
Click to collapse
agreed... lol
anyhow i think this will work out before the htc hope does. bumped to the top
So, with some inspiration from NetRipper, I started trying to find a way that I could see how far it gets in the kernel booting before it stops, since I still don't have a console. Unfortunately, his suggests were LED-related (particularly gpio-enabled), and we don't have any of those. Did find one reaction that is very hard to miss, and luckily very easy to trigger: reboot via gpio
So now I'm stepping through the code, trying to find at what point in execution it stops rebooting and just hangs. So far I'm in init level 4 (of 6). I'm really hoping this leads me to something that will at least tell me "well THERE'S your problem!", and I can reverse the stock kernel asm to figure out what is different.
I was asked this by a friend, but it seems I lack the underlying knowledge to give him an answer.
Would it be possible to use the htc sense ui on our phones?
More generally.. why don't rom builders take stock from other popular phones and build them for multiple devices. Is there a reason that the evo sensation running sense. 3.0 wouldn't work on the charge?
I always thought android was like windows in the way you can install windows on almost any pc with any hardware config.
I am looking for a dev like danalo or kejar or someone to explain in a little detail why this is or isn't the case.
Thanks!
Sent from my SCH-I510 using XDA App
This has been asked many times. It's basically impossible.
Sent from my SCH-I510 using XDA App
DirgeExtinction said:
This has been asked many times. It's basically impossible.
Sent from my SCH-I510 using XDA App
Click to expand...
Click to collapse
has it? my forum search skills need work then i figured it was "impossible" I was just wondering why. I am a hardware engineer and while i know enough programming to get me by, I have am lost when it comes to understanding android and why one build for one device wont work on other devices.
How is it different than windows? Microsoft builds windows, and you can take that copy and install it on any PC you want, amd, intel.. nvidia graphics, radeon graphics..
why is this not the case with android? In my attempts to learn android, i downloaded the sdk, eclipse.. java etc.. and i notice that in the SDK there is "android 2.2" for example.. it doesnt break it down by device. So im wondering why there is a fragmentation between devices, if the code starts out the same for all devices.
again, why does it not function like windows, essentially "hardware independent"
EDITED
or... why coudln't just the sense UI be ripped out of an HTC rom, and ported to a samsung rom. I know I am probably speaking out of my ass here.. but i really dont know why we cant do this, hence the question to understand why
(forgive my curiosity, I am a college student.. I ask a lot of questions)
I believe it has something to do with the Sense framework. Don't quote me on that,though.
Bow Chika Wah Wah Premium
The sdk that you downloaded is for making apps. It is a baseline so if you make an app it works on all android phones. The ROM itself is basecoded for each phone as the companies ask google to develop a specific database structure. As far as the UI. Sense was made to be non portable. The Sense infostructure and libraries were written for HTC hardware. Porting it over would mean finding every lib, driver, and couple other hiddens files, decompiling them (which i don't know anybody that has successfully) rewrite the code for samsung hardware and recompile.
While impossible is the word used. it's really not, but lets call it, improbable for somebody to actually take the time to do it.
its extremely difficult if not impossible... I remember nitsuj saying there was a small coalition of devs who tried it a while ago and got it operational but almost everything was broken and borked... Its simply not meant to be run on non HTC phones and cannot be ported, but being the AOSP fan that I am I still wouldn't mind running that revamped Sense from the T-mo Sensation
blazing through on my VZ Droid Charge
so. HTC could do it then, because sense is their code, and as such, they have the source and could modify it accordingly. But trying to take Sense from an HTC phone and just install it onto a samsung phone would bork it badly.
I imagine this would be similar to ghosting a windows based machine, and then using that ghost image with an entirely different set of hardware. The image would fail to function correctly, if at all on the new hardware , especially if it was vastly differnt.
thanks for the responses. its making much more sense. I wasnt aware that the sdk wasnt the same as the rom on the phones.
you got it my friend. Although using symatec ghost, you can change the drivers and it would work. Putting sense on new hardware is like putting OS X on a tablet. Just wasn't meant to work.
[NOTE]: Mods please move this thread to general Q&A if you find suitable, posting here because I think question comes more towards development side.
So now the question is:
Here are things which I know (mostly read somewhere / heard from friends etc.)
I'm seeing CM7 progress and time to time devs saying can't go ahead because Wimax driver / GPS driver is proprietary (what exactly does it mean?). While as I was discussing with friends I came to know Android only provide HAL so by logic all drivers should be proprietary or no?
I'm quite sure I've not understood something properly so I wanted to know
1. are drivers available only by manufacturer and Android only provide HAL?
2. If yes then what would it take to fetch those drivers and try writing HAL?
3. If no then how can one start writing own drivers?
I know its not an easy process at all, but I was curious so asking here.
I would appreciate all inputs, and if anyone want to share links I am up for some reading
Thanks
wis3m0nkey said:
So now the question is:
I'm seeing CM7 progress and time to time devs saying can't go ahead because Wimax driver / GPS driver is proprietary (what exactly does it mean?). While as I was discussing with friends I came to know Android only provide HAL so by logic all drivers should be proprietary or no?
I'm quite sure I've not understood something properly so I wanted to know
1. are drivers available only by manufacturer and Android only provide HAL?
2. If yes then what would it take to fetch those drivers and try writing HAL?
3. If no then how can one start writing own drivers?
Click to expand...
Click to collapse
Android does not provide a "HAL" as in the Windows (NT) sense. Android is an operating environment running on the Linux kernel, and the programs (apps) running in Dalvik (Java-based).
The issue with CM/other generic AOSP-based build is twofold. First the driver to interface with the underlying has to be compiled into the Linux kernel. Luckily for most of us, the majority of smartphones are based on a few common chipsets (Qualcomm MSM etc.), so chances are you can find the source for a similar phone, and try to fiddle with the source to make it work. This also means that esoteric hardware (ie. WiMax) has a lot harder time getting the driver working.
Second is what allows the Android apps to use the driver to communicate with the hardware. This is where the issues like GPSone rears its ugly head, as it seems each manufacturer likes to do it's own way, so unless you are basing things on the mfg's Android builds, it's almost impossible to get it to "talk" to the driver.
In the end, that's why builds based on official/leaked builds have a lot easier time gettin everthing working because both kernel and userland "bits" are there.
-- Starfox
Starfox said:
Android does not provide a "HAL" as in the Windows (NT) sense. Android is an operating environment running on the Linux kernel, and the programs (apps) running in Dalvik (Java-based).
The issue with CM/other generic AOSP-based build is twofold. First the driver to interface with the underlying has to be compiled into the Linux kernel. Luckily for most of us, the majority of smartphones are based on a few common chipsets (Qualcomm MSM etc.), so chances are you can find the source for a similar phone, and try to fiddle with the source to make it work. This also means that esoteric hardware (ie. WiMax) has a lot harder time getting the driver working.
Second is what allows the Android apps to use the driver to communicate with the hardware. This is where the issues like GPSone rears its ugly head, as it seems each manufacturer likes to do it's own way, so unless you are basing things on the mfg's Android builds, it's almost impossible to get it to "talk" to the driver.
In the end, that's why builds based on official/leaked builds have a lot easier time gettin everthing working because both kernel and userland "bits" are there.
-- Starfox
Click to expand...
Click to collapse
Ok so if I understood this properly :
Driver (which resides in kernel) services can be accessed by Dalvik.
And apps access services provided by Dalvik.
So in this case drivers for android would be developed in same fashion as for any other linux based system. Only requirement would be to check for manufacturer data sheet (if not source code) to tamper with.
Am I correct?
And is there a general development thread specifically for epic 4g?
Thanks
wis3m0nkey said:
Ok so if I understood this properly :
Driver (which resides in kernel) services can be accessed by Dalvik.
And apps access services provided by Dalvik.
So in this case drivers for android would be developed in same fashion as for any other linux based system. Only requirement would be to check for manufacturer data sheet (if not source code) to tamper with.
Am I correct?
And is there a general development thread specifically for epic 4g?
Thanks
Click to expand...
Click to collapse
The difficulty is that manufacturers don't seem to release data sheets for proprietary (customized by the manufacturer) hardware...
Sent from my SPH-D700 using XDA App
styles420 said:
The difficulty is that manufacturers don't seem to release data sheets for proprietary (customized by the manufacturer) hardware...
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Aww man isn't it bad? I mean its same as what Apple tried doing with architecture specific Macs even Windows is trying with secure boot :-/ (But this is with phones compared to computers)
Why can't they just let devs work? I understand them having proprietary drivers but they should provide all required data to write one as well..
Well anyways I figure it won't matter even complaining about it. Anyways thanks guys I'll see if I can find any more info on manufacturer specific code.
wis3m0nkey said:
Aww man isn't it bad? I mean its same as what Apple tried doing with architecture specific Macs even Windows is trying with secure boot :-/ (But this is with phones compared to computers)
Why can't they just let devs work? I understand them having proprietary drivers but they should provide all required data to write one as well..
Well anyways I figure it won't matter even complaining about it. Anyways thanks guys I'll see if I can find any more info on manufacturer specific code.
Click to expand...
Click to collapse
This isn't a Mac vs PC thing.
This is a chip thing. Providing full disclosure of the register set makes some manufacturers nervous. Primarily because with some components, enough information needs to be provided such that you could potentially copy the device. Or at least features of it.
Qualcomm and Broadcom are very bad at this. They don't release anything unless it's under at least 5 NDAs.
I think u misunderstood me. I didn't say about mac vs pc. I was trying to give example about secure boot and macs rejecting to support all hardware.
Yes I understand chips can be duplicated but if its manufactured by samsung only then they shouldn't have problem
wis3m0nkey said:
I think u misunderstood me. I didn't say about mac vs pc. I was trying to give example about secure boot and macs rejecting to support all hardware.
Yes I understand chips can be duplicated but if its manufactured by samsung only then they shouldn't have problem
Click to expand...
Click to collapse
If it gets duplicated, it is no longer manufactured by Samsung only, and therefore is a problem.
Sent from my SPH-D700 using XDA App
seeing as android is a linux based operating system i dont understand why it wouldnt be possible to actually simply build the drivers from scratch. Ive done things like this for Wificards for my debian laptop as well as video drivers for intel chips that dont have linux based drivers. if they work the same way as the linux kernel does wouldn't it be logical to be able to do something similar?
metalblaster said:
seeing as android is a linux based operating system i dont understand why it wouldnt be possible to actually simply build the drivers from scratch. Ive done things like this for Wificards for my debian laptop as well as video drivers for intel chips that dont have linux based drivers. if they work the same way as the linux kernel does wouldn't it be logical to be able to do something similar?
Click to expand...
Click to collapse
It's the chip that is proprietary - those wifi cards use relatively well-documented chip sets, our phones do not. Unless you're aware of another device that uses the -exact- same chipset, with driver source code? (The question is rhetorical)
Feel free to guess at the unique opcodes and such, but trial and error will take a really long time
Sent from my SPH-D700 using XDA App
I'm glad to see some answers on this topic as I was curious about it as well. Can anyone comment on how past drivers have been hacked? E.g. how the Evo got Wimax working in cyanogen? Did they just trial and error the hell out of it until everything worked or did someone get inside information?
Some info
I'm pretty sure devs already have looked at it however anyone else who is wondering:
http://www.chipworks.com/en/technic.../teardown-of-the-samsung-epic-4g-smart-phone/
Samsung CMC730S WiMax baseband processor with SDRAM
That is wimax chip for epic 4g. I couldn't find more info that the chip itself, will report again if I come close to anything
So apparently Samsung SWC-E100 XOHM ExpressCard also uses same Wimax chip.
I'm checking if there are linux drivers available for the card.
http://www.wireless-driver.com/samsung-swc-e100-wimax-windows-driver-utility/
styles420 said:
It's the chip that is proprietary - those wifi cards use relatively well-documented chip sets, our phones do not. Unless you're aware of another device that uses the -exact- same chipset, with driver source code? (The question is rhetorical)
Feel free to guess at the unique opcodes and such, but trial and error will take a really long time
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
But the thing is that the samsung Galaxy S line of phones use what i can only imagine to be similar pieces of hardware. Wouldnt it make sense to be able to modify the drivers for say the fascinate`s camera or wifi for example to fit the epic. I know the keyboard isnt included in those phones but for the most part lines of phones tend to use similar if not the same hardware if they are made by the same companies. All it would take is to have the drivers for one or two of the phones in the same line and you would be able to practically guess the opcodes etc for the hardware signatures and make drivers accordingly. I mean a good example of this was when the fascinate drivers were used to boost our GPS or the fact that our CM7 is based off of the nexus S`version of CM7. It simply means that we have very similar if not the same hardware in most places. Now obviously if the phone is a random standalone piece with completely unique hardware then of course the drivers would be impossible to build with out the right specs and opcodes etc.
Actually on a side note, Ive been thinking about why the companies dont make a database for the drivers for each android phone effectively makeing each phone a nexus phone. It would allow for a version of android to be molded onto the phone with ease using a cookie cutter design making the creation of a newer phone easier and the support of older ones more feasible.
metalblaster said:
But the thing is that the samsung Galaxy S line of phones use what i can only imagine to be similar pieces of hardware. Wouldnt it make sense to be able to modify the drivers for say the fascinate`s camera or wifi for example to fit the epic. I know the keyboard isnt included in those phones but for the most part lines of phones tend to use similar if not the same hardware if they are made by the same companies. All it would take is to have the drivers for one or two of the phones in the same line and you would be able to practically guess the opcodes etc for the hardware signatures and make drivers accordingly. I mean a good example of this was when the fascinate drivers were used to boost our GPS or the fact that our CM7 is based off of the nexus S`version of CM7. It simply means that we have very similar if not the same hardware in most places. Now obviously if the phone is a random standalone piece with completely unique hardware then of course the drivers would be impossible to build with out the right specs and opcodes etc.
Actually on a side note, Ive been thinking about why the companies dont make a database for the drivers for each android phone effectively makeing each phone a nexus phone. It would allow for a version of android to be molded onto the phone with ease using a cookie cutter design making the creation of a newer phone easier and the support of older ones more feasible.
Click to expand...
Click to collapse
Well I guess sprint is only carrier using Wimax and above mentioned Wimax chips are only used in Epic. So to say this phone looks quite unique in that perspective though I think Nexus S 4G uses same chip, I couldn't find evident link pointing to it will report back as I do
rocket321 said:
I'm glad to see some answers on this topic as I was curious about it as well. Can anyone comment on how past drivers have been hacked? E.g. how the Evo got Wimax working in cyanogen? Did they just trial and error the hell out of it until everything worked or did someone get inside information?
Click to expand...
Click to collapse
I can't speak for the Evo Wimax people, but usually manufacturers that want to obscure their register set package up all the real meat in a userspace library, and distribute an open-source middleman kernel driver that basically relays commands through the middleman to the hardware (getting past the GPL).
Nvidia sorta does this, but they just link against the middleman directly and say F*** the GPL, even though it's still argued to be a violation.
Anyhow, for reverse-engineering, you can generally hack the middleman and record the 1's and 0's. Then you can attempt to decipher the data format based on what data changes, and the size of the frames. The stuff that doesn't change you can play back.
Of course, having any information about the device whatsoever helps a lot. I wouldn't be surprised if a hardware manual leaked for the Evo WiMax chip.
This is how a lot of the reverse-engineering was done on the HTC Vogue, the old device I developed for.
My life prevents me from helping at the moment, I hope to contribute on CM7 when things settle down.
jnadke said:
I can't speak for the Evo Wimax people, but usually manufacturers that want to obscure their register set package up all the real meat in a userspace library, and distribute an open-source middleman kernel driver that basically relays commands through the middleman to the hardware (getting past the GPL).
Nvidia sorta does this, but they just link against the middleman directly and say F*** the GPL, even though it's still argued to be a violation.
Anyhow, for reverse-engineering, you can generally hack the middleman and record the 1's and 0's. Then you can attempt to decipher the data format based on what data changes, and the size of the frames. The stuff that doesn't change you can play back.
Of course, having any information about the device whatsoever helps a lot. I wouldn't be surprised if a hardware manual leaked for the Evo WiMax chip.
This is how a lot of the reverse-engineering was done on the HTC Vogue, the old device I developed for.
My life prevents me from helping at the moment, I hope to contribute on CM7 when things settle down.
Click to expand...
Click to collapse
Thanks
However I don't understand most of it.
I've done until now is micro controller programming (say 8051 and similar)
Compiling kernel/FS for running on FPGA and few small boards, it was just compiling so I can set up tool chain and stuff but never actually developed / reverse engineered.
I would like to learn if u can point me to a good source.
wis3m0nkey said:
Thanks
However I don't understand most of it.
I've done until now is micro controller programming (say 8051 and similar)
Compiling kernel/FS for running on FPGA and few small boards, it was just compiling so I can set up tool chain and stuff but never actually developed / reverse engineered.
I would like to learn if u can point me to a good source.
Click to expand...
Click to collapse
Fortunately for you, the best book is free.
http://lwn.net/Kernel/LDD3/
Start with Chapter 1, I'd read all of that.
In general, I'd go through every chapter there and read the introductions. Stop once it gets to code. Those parts are irrelevant. The introductions alone are a powerful primer on how Operating Systems communicate with hardware.
Chapter 9: Communicating with Hardware is useful, since you're a hardware background.
Now, hacking android phones doesn't typically involve writing device drivers, but that book does a superb job outlining linux kernel interaction with hardware, which is the base of android. It is probably the quintessential book for anything Linux, and it's free!
jnadke said:
Fortunately for you, the best book is free.
http://lwn.net/Kernel/LDD3/
Start with Chapter 1, I'd read all of that.
In general, I'd go through every chapter there and read the introductions. Stop once it gets to code. Those parts are irrelevant. The introductions alone are a powerful primer on how Operating Systems communicate with hardware.
Chapter 9: Communicating with Hardware is useful, since you're a hardware background.
Now, hacking android phones doesn't typically involve writing device drivers, but that book does a superb job outlining linux kernel interaction with hardware, which is the base of android. It is probably the quintessential book for anything Linux, and it's free!
Click to expand...
Click to collapse
Awesome, thanks.
I'm not sure how much time it will take me but I'll try my best and probably will bother u some more
The Nexus S has the same CPU as our phones, same storage, same screen and they get OTA updates right to jellybean. What is the difference between that phone and ours that would make using their ROM's to help with our phones?
One of the reasons the x86 platform has been so successful is that there are thousands of pages of requirements that make most versions of computers running with an x86 CPU "look the same" to an operating system. For example, the video card always has to implement the same set of instructions and the same way to draw things on the screen.
Unfortunately, phones aren't as generous.
While other phones use the same CPU, they often use different chips to handle things like the keyboard, screen, audio, GPS, phone radio, WiFi, Bluetooth, USB,... Each of these requires a different driver (the code that lets the kernel "talk" to the chip in a standard way). Remember Windows 9x when every time you bought a new mouse, video card, or whatever you had to search for the right driver?
Worse than that, there are hundreds of pins on the CPU and no "wiring diagram" for the devs to work from. Some of the big puzzles the devs are working with are figuring out which pin goes where when making these drivers connect up right. Not only is it knowing which pin goes where, but is it rising edge means "1" or falling edge, should the pin be inactive high, or low. How fast can the device take data?
Then are the "proprietary bits" -- this is the biggest "lie" about devices claiming to be "open source." Even though parts of the device may use Linux or have source available for the dev to look at, some things are just "binary blobs" that the manufacturer wrote themselves, or obtained from the chip vendor and added to their device. No source is available. In some cases, they can be re-used with a later kernel version. In others, they are just "too old" and you're stuck because they don't implement certain instructions that a newer kernel needs, or implement it in the "wrong" way -- think trying to use a Windows 95 driver with Windows 7 -- It just isn't going to work.
For the SGS4G, some of the proprietary bits we are stuck with include:
Boot loaders -- the code that runs when the phone starts up that knows how to read the flash and start the kernel
RIL -- The code that runs the "phone" radio
GPS
TV Out
WiFi Calling
I know I've got all three of the Samsung source drops for our phone on my machine, as well as two versions of kernels from AOSP (semi-official Google source), two versions of Linaro, mainline Linux, CyanogenMod, Team Hacksung, and a few more, all of which include drivers for several phones similar to ours. It chews of a bit of disk space, but sometimes can provide insight.
We can't "just build JellyBean" as there have been some very significant changes in the kernel between the 2.6.35 version we have now, and the 3.x line that JellyBean needs to run. For example, how "events" are handled by the kernel has changed. These are things like pressing a key, so they are sort of important to get right.
Thanks. I was just cruising around looking at Sammy phones and saw that and it looked similar specs. I know all about drivers/pcs/different devices/chips used in things, run a repair shop fixing electronics/pc's, I do reflowing, reballing, etc. Just didn't realize they made the Nexus so different. That's fine, I'm happy with the Remi ICS for now.
So... you can remove and replace bga chips?
Sent from my SGH-T959V using xda premium
Once someone tries and screws it up, please send the remains to bhundven so he can trace out the circuit board
(Joking on trying it, not joking on Team Acid being able to benefit from a destroy-able SGS4G.)
There's a galaxy s 4g main board on eBay right now ending in like 20 min currently at about 5 bucks
Sent from my SGH-T959V using xda premium
Hoping this is the right section since its not device specific.
Experienced or not, it doesn't matter. I've been on XDA for a number of years. And am noticing things from my own experience and talking to others. Its hard to get help sometimes. Not all devs want to talk. Teach. Or help people all the time. Devices are being dropped from support. Maintainers are leaving the scene. Currently I have an Oreo and pie ROM for s6e+ and note 5. With the list of devices being dropped, and surprising amount of people reaching out to me for support, I decided it may be beneficial to recruit a few people who want to develop ROMs. This is a great chance to learn. I would like to pick up at least partial support for several more devices, and need some help to do it. My goal in this endeavor is to continue to provide ROMs to people who need them, while teaching other users to develop. This will help to bring fresh life to the scene, and allow support for more devices to be added. If you are interested reply below or inbox me. There is a google hangouts set up, and other methods of team communication will follow. I also have a home server with a 24/7 connection and no data limits on my internet, and an ftp set up to host files directly and not need third party sites.
so basically you have good intentions, no plan and a home server )
what we really need is a unification of all the different but not really different roms and their devs,
then its possible to see a future for long term support for all devices, or at least many.
anyhting else is jsut another project that will or will not die, based on good will and free time of the maintainer, mostly not even reckognized
due to the chaos of fragmented android and even more fragmented custom rom scene.
godkingofcanada said:
Hoping this is the right section since its not device specific.
Experienced or not, it doesn't matter. I've been on XDA for a number of years. And am noticing things from my own experience and talking to others. Its hard to get help sometimes. Not all devs want to talk. Teach. Or help people all the time. Devices are being dropped from support. Maintainers are leaving the scene. Currently I have an Oreo and pie ROM for s6e+ and note 5. With the list of devices being dropped, and surprising amount of people reaching out to me for support, I decided it may be beneficial to recruit a few people who want to develop ROMs. This is a great chance to learn. I would like to pick up at least partial support for several more devices, and need some help to do it. My goal in this endeavor is to continue to provide ROMs to people who need them, while teaching other users to develop. This will help to bring fresh life to the scene, and allow support for more devices to be added. If you are interested reply below or inbox me. There is a google hangouts set up, and other methods of team communication will follow. I also have a home server with a 24/7 connection and no data limits on my internet, and an ftp set up to host files directly and not need third party sites.
Click to expand...
Click to collapse
I respect your Idea but I don't think something like this is required.You see I had been using linux for 4+ years and was pretty adapted to it when I switched to a Note 3.Recently I discovered the Modding part of it and the huge development of custom roms and kernels.and despite having no clue what I was doing I could easily develop a Kernel without a hassle.I went even one step further and made a halium port for it.Sure it didn't boot the first time but by using methods on xda already discussed in detail I was able to make it work.So,the main thing is that someone like me who has no experience could make a ROM in 3 hours without any complications(Except those who could be solved by googling).Then anybody could do it.Currently there isn't a ROM bug or a issue that hasn't been discussed on either xda or other android development sites.But that doesn't mean we shouldn't help newcomers.But it is rare for someone to look on the other side of development and there is enough documentations for him to do it.Maybe too much.qq
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
I respect your Idea but I don't think something like this is required.You see I had been using linux for 4+ years and was pretty adapted to it when I switched to a Note 3.Recently I discovered the Modding part of it and the huge development of custom roms and kernels.and despite having no clue what I was doing I could easily develop a Kernel without a hassle.I went even one step further and made a halium port for it.Sure it didn't boot the first time but by using methods on xda already discussed in detail I was able to make it work.So,the main thing is that someone like me who has no experience could make a ROM in 3 hours without any complications(Except those who could be solved by googling).Then anybody could do it.Currently there isn't a ROM bug or a issue that hasn't been discussed on either xda or other android development sites.But that doesn't mean we shouldn't help newcomers.But it is rare for someone to look on the other side of development and there is enough documentations for him to do it.Maybe too much.qq
Click to expand...
Click to collapse
You can't just make a ROM for any device is 3 hours. It doesn't always work that way. Especially not if building from source
godkingofcanada said:
You can't just make a ROM for any device is 3 hours. It doesn't always work that way. Especially not if building from source
Click to expand...
Click to collapse
I just followed a guide.On an XL VPS. With maybe 22GB ram and 16 xeon cores
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
I just followed a guide.On an XL VPS. With maybe 22GB ram and 16 xeon cores
Click to expand...
Click to collapse
I don't disagree sometimes it is easy. But what if lineage or GitHub don't have all necessary files for the build? And then you need to extract them from your phone manually, or if build won't boot up and needs modifications to the kernel.. fixing drivers that do not work. It's not always so simple as build, flash and finish.
godkingofcanada said:
I don't disagree sometimes it is easy. But what if lineage or GitHub don't have all necessary files for the build? And then you need to extract them from your phone manually, or if build won't boot up and needs modifications to the kernel.. fixing drivers that do not work. It's not always so simple as build, flash and finish.
Click to expand...
Click to collapse
I did face issues.The End of the guide covered the basics of logging stuff and finding things.They were just as same as debugging a linux OS but yeah you're right as I did face the extracting files(dunno what was supposed to do).So I wrote "extract proprietary vendor code from ROM" and boom lineage gave it to me.Also the guide was only for devices that exist on lineage and sometimes we need to start from scratch.And maybe We both are,Who knows what the future might bring,BTW have you heard about Google's new Boy Fuchisa or something like that.I wanted to talk someone in the field of development about this but nobody was bringing up the non-linux version of Google's OS for smartphones.
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
I did face issues.The End of the guide covered the basics of logging stuff and finding things.They were just as same as debugging a linux OS but yeah you're right as I did face the extracting files(dunno what was supposed to do).So I wrote "extract proprietary vendor code from ROM" and boom lineage gave it to me.Also the guide was only for devices that exist on lineage and sometimes we need to start from scratch.And maybe We both are,Who knows what the future might bring,BTW have you heard about Google's new Boy Fuchisa or something like that.I wanted to talk someone in the field of development about this but nobody was bringing up the non-linux version of Google's OS for smartphones.
Click to expand...
Click to collapse
Yes I heard about it. I stumbled across it by accident looking for a way to shim the s6 edge plus cam on my pie rom. It lead me to reading about vulkan, which showed me a new Google os. It looks nice
godkingofcanada said:
Yes I heard about it. I stumbled across it by accident looking for a way to shim the s6 edge plus cam on my pie rom. It lead me to reading about vulkan, which showed me a new Google os. It looks nice
Click to expand...
Click to collapse
Well It seems that it uses a Different type of kernel "microkernel".For someone as stupid as me I don't get it what was the difference between a microkernel and monolithic one on an android device(or a low powered arm processor based board that has a screen attached to it)Will it be performance,Faster loading,Efficiency.I can find a million articles on microkernel vs monolithic but they are in latin for me.But you can just give me the crash course in maybe 3-4 lines.
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
Well It seems that it uses a Different type of kernel "microkernel".For someone as stupid as me I don't get it what was the difference between a microkernel and monolithic one on an android device(or a low powered arm processor based board that has a screen attached to it)Will it be performance,Faster loading,Efficiency.I can find a million articles on microkernel vs monolithic but they are in latin for me.But you can just give me the crash course in maybe 3-4 lines.
Click to expand...
Click to collapse
Device drivers, protocol, file systems moved from kernel to user. It's got less code, more lightweight. And it was created with embedded systems in mind. In theory it should be faster, and more suited to small devices like phones with embedded systems. Giving devices their own dedicated kernel finally instead of butchering a Linux kernel to suit their device needs. It's also universal in terms of cross platform
godkingofcanada said:
Device drivers, protocol, file systems moved from kernel to user. It's got less code, more lightweight. And it was created with embedded systems in mind. In theory it should be faster, and more suited to small devices like phones with embedded systems. Giving devices their own dedicated kernel finally instead of butchering a Linux kernel to suit their device needs. It's also universal in terms of cross platform
Click to expand...
Click to collapse
Now that's more like it.I was afraid that android was finally going to commit close source(or suicicde).But since it's open source and I hear good things from you and 4 other guys who have experience in doing stuff I think,Hope and Pray that it might be a good change.Also thanks for using plain English and being a Open guy.Currently I am thinking that 5 years from now someone gonna run into this post and have a little smirk on his face for you who is reading this,Quote and tell me was it good?Was we good?
Sent from my Pixel 3 XL using Tapatalk
Atifbaig786 said:
Now that's more like it.I was afraid that android was finally going to commit close source(or suicicde).But since it's open source and I hear good things from you and 4 other guys who have experience in doing stuff I think,Hope and Pray that it might be a good change.Also thanks for using plain English and being a Open guy.Currently I am thinking that 5 years from now someone gonna run into this post and have a little smirk on his face for you who is reading this,Quote and tell me was it good?Was we good?
Click to expand...
Click to collapse
I think the changes appear good. Less stuff locked away in private, more easily accessible to all. Treble has the vendor stuff available to roms that aren't stock, this will make the kernel tiny and easy to build. One by one the barriers people have to overcome to build their own roms are being taken away.