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.
Related
Looks like 2.1 was just released! Woot!
Looks like the changes are just being put into the git as well.
Now we are just left waiting for the kernel source drop so we can take advantage of the nifty 3d acceleration stuff.
dchadwick said:
Looks like 2.1 was just released! Woot!
Looks like the changes are just being put into the git as well.
Now we are just left waiting for the kernel source drop so we can take advantage of the nifty 3d acceleration stuff.
Click to expand...
Click to collapse
hmmm I didn't think about this only sounding exciting to me.
dchadwick said:
hmmm I didn't think about this only sounding exciting to me.
Click to expand...
Click to collapse
You are certainly not the only one. Once we get the kernel source will we finally begin to see a healthy amount of ROMs?
I really miss my G1 simply because of the sheer amount of options I had.
illogic6 said:
You are certainly not the only one. Once we get the kernel source will we finally begin to see a healthy amount of ROMs?
I really miss my G1 simply because of the sheer amount of options I had.
Click to expand...
Click to collapse
I miss my G1 too and if the Nexus Wasn't only compatable with T-Mobiles 3g network it would be tempting with the kernel in the Android Source tree and Cynanogen building roms for it.
illogic6 said:
You are certainly not the only one. Once we get the kernel source will we finally begin to see a healthy amount of ROMs?
I really miss my G1 simply because of the sheer amount of options I had.
Click to expand...
Click to collapse
We won't get kernel source compatible with 2.1 until after HTC releases a 2.1 ROM for the Hero, if even then (since HTC thinks they are immune to the GPL). Some bits from the 1.5 kernel source will be useful for uprev'd Android releases, but it will not bring the full feature set.
cmccracken said:
We won't get kernel source compatible with 2.1 until after HTC releases a 2.1 ROM for the Hero, if even then (since HTC thinks they are immune to the GPL). Some bits from the 1.5 kernel source will be useful for uprev'd Android releases, but it will not bring the full feature set.
Click to expand...
Click to collapse
Nah, I think your exactly right. Any kernel release at this point would be helpful.
cmccracken said:
We won't get kernel source compatible with 2.1 until after HTC releases a 2.1 ROM for the Hero, if even then (since HTC thinks they are immune to the GPL). Some bits from the 1.5 kernel source will be useful for uprev'd Android releases, but it will not bring the full feature set.
Click to expand...
Click to collapse
Given the kernel source I am fairly sure we could reverse the rest in a few days, the only thing keeping us back now is the lack of a frame of reference on exactly what they did to make CDMA work on GSM code.
Nanan00 said:
Given the kernel source I am fairly sure we could reverse the rest in a few days, the only thing keeping us back now is the lack of a frame of reference on exactly what they did to make CDMA work on GSM code.
Click to expand...
Click to collapse
There isn't much difference between the gsm kernel and cdma kernel with regards to radio functions. The kernel's job here is to present devices after boot, so that libhtc_ril.so can communicate to the hardware (/dev/qmi# and /dev/smd#). If you look at the code in gsm kernel, there is very little there, all the hard stuff is in the black box libhtc_ril.so. The shared library is called through the system_server process, which ends up being called by the framework, which is called by the phone app (or some other app) to make calls, send sms, etc. Notice that all it really took to get the leaked 2.1 working for basic phone functions was a config change in build.prop, telling the RIL to expect/use CDMA instead of gsm/umts.
The above can be said for other areas where we have difficulties, camera, sensors, lights, etc. All the kernel does is present devices or memory areas that user space things can manipulate. This allows HTC (and other phone makers, like Motorola or Ericsson) to keep their "important" code away from the GPL'ed kernel. A side effect is that when changes are made in Android where it expects stuff in /dev that are not present in the .27 CDMA kernel. This is why sensors and other stuff doesn't "just work", the 2.x code expects things that are not present in the only kernel we have.
Finally, Android framework is for the most part Apache licensed, hence why HTC and other phone makers are not required to release their changes to the Android system. This is why I had to reverse engineer the changes HTC made to send MMS on Sprint, for example. They had no obligation to publish those changes.
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
chuckhriczko said:
Okay everyone. I am working on an optimized 2.6.27 until we can get .29 ported over. But I figure, since I am fairly new to the kernel world, how can we get started porting this bad boy over? I have been looking through the source code but am somewhat lost as to where to get started. I figure if we are able get this going we can make a github account and have the progress set up for everyone. All you devs wanna join in?
Click to expand...
Click to collapse
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Kcarpenter said:
Seems like I just read someones already got a github setup. Can we branch instead of running 2 accounts if this is the case?
I am also very new to the whole kernel. I think I have actually only compilied 3 succesful linux kernels in my short life. Attempted others, but I usually get lazy or run out of time.
Click to expand...
Click to collapse
If someone has made a github project please let me know. I havent made a 2.6.29 github project yet. I am currently doing one for 2.6.27.
I created a 2.6.27 repo this morning when the source was released. And I've checked out 2.6.29, just haven't set it up in github.
Really?
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
It's not that simple. For starters we have to copy over the drivers for our phone and make sure they compile correctly. On top of that HTC modified quite a bit of the kernel. Porting it over will happen but it may take some time. Like I said before I am new to the linux kernel deal but I do know it is more difficult than it seems.
I'd say a completely functional port will take roughly 2 weeks time for a hobbyist. I'm not sure though as I'm still new to messing with linux kernels. I'm looking into a port of my own. Debating 2.6.29 or porting the android specific bits to a newer linux kernel. Chances are porting the hero specific stuff to the android 2.6.29 kernel source will be much simpler. It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight. I wish I was a bit more profficient with C programming too. I guess now I have a good reason to do just that.
lazydev said:
What's the difference between the android kernel and the regular linux kernel? It seems their version numbers are closely related. So why not go up to the newest stable (2.6.32.5)?
Click to expand...
Click to collapse
edit: didnt release chuckriczko answered your question..
obelisk79 said:
It sucks I'm on my laptop at work and it isn't running linux so no compiling, diff patching or coding for me tonight.
Click to expand...
Click to collapse
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
gu1dry said:
Maybe it's time to start carrying around a LiveUSB distro of Linux on a flash drive
Click to expand...
Click to collapse
no kidding... I wasn't expecting to wake up to a new release. Of course I could just run linux on my laptop and call it a day
Yeah, the reason it's better to start with .29 than jump to .32, because a lot of the work has already been done for us in .29. In fact, if you really investigate the kernel source they released, vs the kernel on our phones, you'll notice that HTC has already backported some of the .29 changes in the android-msm-2.6.29 branch into the source they released, which was *not* initially the case in the kernel that they shipped.
What we need to do to get .29 actually working, is the opposite: forward-port the HTC changes for hero/c into the .29 source.
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
maejrep said:
FYI: got an initial codebase that compiles, but does not boot yet:
http://github.com/jhansche/kernel_msm/commit/19a2d673867a8e11b98cce399ed89c94811ebf77
Started from android-msm-2.6.29 branch, with a few modifications that HTC made in our code, ported over (not all of them, mind you). If anyone has any suggestions for debugging why the kernel doesn't boot, I'm glad to hear them If I had a serial debug cable, that would be useful, cause then it would work as a serial console. But for now all I have to go on is the fact that it dies *before* ram_console can be initialized (even with early-init enabled).
I've also disabled several pieces of hardware in the interest of just getting a clean compile -- namely headset, 3.5mm audiojack, EID mddi client (lcd panel) has not been copied over yet, and some other stuff.
Click to expand...
Click to collapse
Great work! As I said before I am new to this linux kernel stuff and don't think I can help but I am cloning the repo so I can take a look anyway.
Any progress with getting it to boot?
Any update on this project?
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
theoottesen said:
I have also been curious about this for a couple of days, just didn't want to sound pushy to the devs... hope theyre seeing progress.
Click to expand...
Click to collapse
I checked the githup out. still doesn't boot
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
maejrep said:
Yeah, I've been hitting a brick wall trying to get some kind of indication that something is happening... On .27 I lucked out by somehow getting it to go past the ram console, then reboot, so I could see the panic messages on /proc/last_kmsg. But in .29, I can't even write directly to the ram console memory space in a pure_init section. The problem is that there's no way to know how far it's getting in the boot process. So we're really just booting blindly.
On top of that, the android-msm-2.6.29-nexusone branch has non-QSD8k bugs (that is, if you select that it's an MSM device, not a QSD device, it won't compile without fixing stuff in their acpu code for arm11, MDP22 code paths, etc. it's like the nexusone branch was only ever tested with scorpion, not arm11 (even though it has the board files for sapphire, so you would expect it to compile for sapphire)
Click to expand...
Click to collapse
So if I understand correctly, the devs that worked on the kernel for the Nexus One got lazy and never tried to see if it compiled on the Sapphire?
If they were developing the kernel for the nexus id hardly call them lazy for not taking the time to check it on other devices.
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!
I have no intention for hacking or anything i just want to use it for pentest on my systems.
Okay so i downloaded aircrack for ubuntu and extracted the sbin files and the bin files and pasted them into my system/bin and afterwards i went to terminal emulator and typed
su
aircrack-ng
and to my supprise it loaded. I have posted some screenshots.
So i think with some efforts and the right scripts it would work.
So anyone with the knowledge can help out.
**************UPDATE**************
i just uploaded the aircrack-ng file.
I am Very Sorrry. If you downloaded the first file i posted, that wont work, i have posted the correct one. so please download this one
aircrack-1.1-static.rar (1.90 MB)
Okay so i have found a site on which a group of developers were able to create some files to allow the Nexus one & Galaxy S II run in monitor mode.
here is the website.
[[ http://bcmon.blogspot.com/2012/09/working-monitor-mode-on-nexus-one.html ]]
If we are able to get the mytouch into monitor mode, we would be able to run "Aircrack" ont the packets.
According to the website, we need to Build the KO for our device.
The problem now is, i have no idea of how to create those KO files.
If anyone finds a nice tutorial, pls share it here and i would try and follow it to get the monitor mode working. (that is if possible).
************************************UPDATE***************************************************************************
Guys i have finnally figured out how to put the mytouch 4g in monitor mode.
here are the steps.
Download glacier_Pac_JB_4.2.2-V22.01_20130325-085620.zip
from here : http://d-h.st/5bA
(please flash Gapps)
Then Download this Kernel it was created by coderz ( i have uploaded it so see below.)
Afterwards head towards my other thread here ( http://forum.xda-developers.com/showthread.php?t=2302678 ) and download ubuntu distro the small image.
After the download load open the apk u downloaded from the other thread and select launch and choose ubuntu.
after it has launched, install aircrack.
from this guide ( http://answertohow.blogspot.com/2012/10/how-to-install-aircrack-ng-on-ubuntu.html )
Next head towards here ( http://pkgs.org/ubuntu-12.04/ubuntu-main-i386/iw_3.2-1_i386.deb.html ) for the IW package since its not available
in the ubuntu distro.
Now you are clear to go.
Now type these in the terminal emulator where the image was launched ( please do not open another tab in terminal emulator, use the one that was opened by the ubuntu distro.)
type
Su
Airmon-ng start 6 p2p0
and voila there it is you would see monitor mode started.
Please forgive me if somethings arent clear.
I am so happy to the extent that i cant even type.
What is that?
Sent from my myTouch 4G using xda premium
mymeatb18 said:
What is that?
Sent from my myTouch 4G using xda premium
Click to expand...
Click to collapse
I thinks it's something to hack wifi with.
Sent from my MyTouch 4G using xda app-developers app
N_otori0us_ said:
I thinks it's something to hack wifi with.
Sent from my MyTouch 4G using xda app-developers app
Click to expand...
Click to collapse
Actually its used for penetration testing but when it is used in the wrong way becomes a hacking tool.
So it can be used by someone to gain access to a secured WiFi network?
Sent from my myTouch 4G using xda premium
mymeatb18 said:
So it can be used by someone to gain access to a secured WiFi network?
Sent from my myTouch 4G using xda premium
Click to expand...
Click to collapse
yea i guess so. Dont really know much about it.
Which package did u download I can't find one that has bin and Sbin in it?
Sent from my GT-P3110 using xda app-developers app
I've been building the kernel module, which is what a "KO" as you called it is, into my customized kernel for about a week now. I've also successfully inserted said module into memory and that's about where I end as the binaries that come packaged with the source code aren't linked correctly for the glacier and can't interface correctly and I haven't taken the time to recompile them yet. The plus side is that this may save me having to do that but that also means that if you want the module you have to use my kernel and that is a hazard in and of itself, haha. I lack the post count to post it in the proper forum and I refuse to circumvent that restriction by posting it in the incorrect forum so for the moment I'm hosting it myself.
If you're interested in taking the chance send me a message but I'll tell you now the kernel variation, D3M0N as I've named it, is not for the faint of heart and you could do real damage to your device if you are careless as mine allows overclocking up to 2Ghz and let me tell you it gets hot enough to blister a finger on the metal battery cover. I have it set to run at 1.4 by default so you may want to adjust it to suit your needs and it's designed for 4.2.x ROMs and I can't guarantee it'll work with any other version of Android but I can build the module for any kernel version as long as the source is available as well.
On a final note, the aircrack suite is a hacking tool and hacking is not bad, cracking is the malicious brother of hacking and either way you're responsible for your own actions, not anyone else. That being said, I'm not liable for what you do or don't do. And to clarify, aircrack itself is only useful for WEP secured networks and it is not useful by itself. This isn't directed at anyone in particular but I thought I'd clear up the assumptions I felt were being made because there's no reason for ignorance and the only crime related to ignorance is refusing the ignorant the chance to be educated wherever possible. I hope nobody takes offense to the term ignorant because everyone is ignorant to something and everyone was ignorant at some point.
Sent from my myTouch 4G using xda premium
zygh0st said:
I've been building the kernel module, which is what a "KO" as you called it is, into my customized kernel for about a week now. I've also successfully inserted said module into memory and that's about where I end as the binaries that come packaged with the source code aren't linked correctly for the glacier and can't interface correctly and I haven't taken the time to recompile them yet. The plus side is that this may save me having to do that but that also means that if you want the module you have to use my kernel and that is a hazard in and of itself, haha. I lack the post count to post it in the proper forum and I refuse to circumvent that restriction by posting it in the incorrect forum so for the moment I'm hosting it myself.
If you're interested in taking the chance send me a message but I'll tell you now the kernel variation, D3M0N as I've named it, is not for the faint of heart and you could do real damage to your device if you are careless as mine allows overclocking up to 2Ghz and let me tell you it gets hot enough to blister a finger on the metal battery cover. I have it set to run at 1.4 by default so you may want to adjust it to suit your needs and it's designed for 4.2.x ROMs and I can't guarantee it'll work with any other version of Android but I can build the module for any kernel version as long as the source is available as well.
On a final note, the aircrack suite is a hacking tool and hacking is not bad, cracking is the malicious brother of hacking and either way you're responsible for your own actions, not anyone else. That being said, I'm not liable for what you do or don't do. And to clarify, aircrack itself is only useful for WEP secured networks and it is not useful by itself. This isn't directed at anyone in particular but I thought I'd clear up the assumptions I felt were being made because there's no reason for ignorance and the only crime related to ignorance is refusing the ignorant the chance to be educated wherever possible. I hope nobody takes offense to the term ignorant because everyone is ignorant to something and everyone was ignorant at some point.
Sent from my myTouch 4G using xda premium
Click to expand...
Click to collapse
Thats cool. So have you tried your new kernel with the aircrack suit i have uploaded or have you tried airmon or monitor mode with the zips found at the website i posted.
And thanks also for clarifying the hacking concept.
I just want to help in unleashing the power of the mytouch 4g. As i have seen and tested, there are many things that the mytouch 4g can do that people didnt really know about. Like Fm transmitting, this feature works on the mytouch 4g. I tried it myself. All its needs is the apk(if anyone needs it He or She should free to ask and i would send it to him or her). All it needs to work is the stock 2.2 Glacier rom as thats which i tested it on.
So as i have already said. You could pass by the website and download the packages and who knows, it might be easier than you think.
Thanks again for contributing. :good:
mickeyasamoah said:
Thats cool. So have you tried your new kernel with the aircrack suit i have uploaded or have you tried airmon or monitor mode with the zips found at the website i posted.
And thanks also for clarifying the hacking concept.
I just want to help in unleashing the power of the mytouch 4g. As i have seen and tested, there are many things that the mytouch 4g can do that people didnt really know about. Like Fm transmitting, this feature works on the mytouch 4g. I tried it myself. All its needs is the apk(if anyone needs it He or She should free to ask and i would send it to him or her). All it needs to work is the stock 2.2 Glacier rom as thats which i tested it on.
So as i have already said. You could pass by the website and download the packages and who knows, it might be easier than you think.
Thanks again for contributing. :good:
Click to expand...
Click to collapse
Yes, I did try the binaries from the OP; unfortunately they weren't the solution to my problem. Fortunately they seem to be just fine and my problem was due to an error on my part (I had duplicate binaries in /system/xbin while I was intending to use /system/bin and failed to realize it right away.) I set up an old Netgear router I had lying around and threw a random string in as the WEP key and was able to reverse it in ~12 minutes with the maximum CPU frequency at 1.4Ghz. Not bad at all as far as I'm concerned given that it takes ~5m on my laptop.
I've stabilized the kernel I've been mutilating so it's far safer than I previously alluded to, haven't had a single panic or hard lock in a good 18+ hours and I've been running it to death so my offer still stands for any who'd rather not deal with compiling it themselves. For those that do, my Github is always open: http://github.com/zygh0st/android_kernel_htc_msm7x30-3.0.git
BTW, thanks for starting the discussion; nice to see I'm not the only one who is interested in mobile devices as possible vectors for breaches of security in ways most people wouldn't consider. The next step is to give Reaver a shot, though I think it has a successor at this point but I can't recall the name of it. I doubt it's feasible, at least not on this device since if the time scales in a similar manner you'd be looking at nearly 24 hours but with something like a Note 2 or S4 one would expect to find a significant reduction in time I'd think, but I could be mistaken.
zygh0st said:
Yes, I did try the binaries from the OP; unfortunately they weren't the solution to my problem. Fortunately they seem to be just fine and my problem was due to an error on my part (I had duplicate binaries in /system/xbin while I was intending to use /system/bin and failed to realize it right away.) I set up an old Netgear router I had lying around and threw a random string in as the WEP key and was able to reverse it in ~12 minutes with the maximum CPU frequency at 1.4Ghz. Not bad at all as far as I'm concerned given that it takes ~5m on my laptop.
I've stabilized the kernel I've been mutilating so it's far safer than I previously alluded to, haven't had a single panic or hard lock in a good 18+ hours and I've been running it to death so my offer still stands for any who'd rather not deal with compiling it themselves. For those that do, my Github is always open: http://github.com/zygh0st/android_kernel_htc_msm7x30-3.0.git
BTW, thanks for starting the discussion; nice to see I'm not the only one who is interested in mobile devices as possible vectors for breaches of security in ways most people wouldn't consider. The next step is to give Reaver a shot, though I think it has a successor at this point but I can't recall the name of it. I doubt it's feasible, at least not on this device since if the time scales in a similar manner you'd be looking at nearly 24 hours but with something like a Note 2 or S4 one would expect to find a significant reduction in time I'd think, but I could be mistaken.
Click to expand...
Click to collapse
Wow Hurray!!!!!!!!!!!!!!. My problem now is that i am not using an AOSP Rom but a Sense Rom (Vipertouch) so would this kernel work on it??
Or wait i checked ur github, is that a package for ubuntu?? cause i can see some makefile in it??
Bro if you really want to pen test from your android download dSploit.
It doesn't require custom kernals or anything. Would you like me to find a link?
Sent from my myTouch 4G using xda app-developers app
I already have that, but it doesnt crack wep passwords.
Sent from my HTC myTouch 4g using xda app-developers app
mickeyasamoah said:
Wow Hurray!!!!!!!!!!!!!!. My problem now is that i am not using an AOSP Rom but a Sense Rom (Vipertouch) so would this kernel work on it??
Or wait i checked ur github, is that a package for ubuntu?? cause i can see some makefile in it??
Click to expand...
Click to collapse
Makefiles are generally going to be found anywhere that there is code written in C and as far as I know, or recall for that matter but that may not be saying much given my poor memory, the Linux kernel has been written in C since its inception. I tried flashing the kernel with Vipertouch earlier today but it never made it past the bootlogo so I'm going to say that it doesn't play nice (which is expected.) I've spent a little time hunting around for source code to the kernel that Team Venom used but I haven't come across it yet. As soon as I find the source for an ICS/Sense compatible kernel I'll see if I can't crank something out for you. Shouldn't be too hard, I'm just preoccupied and haven't had a good stretch of time to devote to finding what I need but I'm sure it'll be easy to find because one of the Sense ROMs ought to link to a repository I'd think (I hope so anyway, haha)
If you're familiar with compiling the kernel in Ubuntu then you're pretty much familiar with compiling kernels for Android, you'd just need to set up your build environment properly which is trivial in Ubuntu. If you're interested at all, here are a couple of links, one to a thread that I referenced a few times myself and one to XDA University's Guide to building a kernel from source. I'm no expert by any means, at least not with regard to Android specific issues, but my mind and the contents therein are at your service for what it's worth :good:
zygh0st said:
Makefiles are generally going to be found anywhere that there is code written in C and as far as I know, or recall for that matter but that may not be saying much given my poor memory, the Linux kernel has been written in C since its inception. I tried flashing the kernel with Vipertouch earlier today but it never made it past the bootlogo so I'm going to say that it doesn't play nice (which is expected.) I've spent a little time hunting around for source code to the kernel that Team Venom used but I haven't come across it yet. As soon as I find the source for an ICS/Sense compatible kernel I'll see if I can't crank something out for you. Shouldn't be too hard, I'm just preoccupied and haven't had a good stretch of time to devote to finding what I need but I'm sure it'll be easy to find because one of the Sense ROMs ought to link to a repository I'd think (I hope so anyway, haha)
If you're familiar with compiling the kernel in Ubuntu then you're pretty much familiar with compiling kernels for Android, you'd just need to set up your build environment properly which is trivial in Ubuntu. If you're interested at all, here are a couple of links, one to a thread that I referenced a few times myself and one to XDA University's Guide to building a kernel from source. I'm no expert by any means, at least not with regard to Android specific issues, but my mind and the contents therein are at your service for what it's worth :good:
Click to expand...
Click to collapse
OOOKay. But the only problem is that my pc fell and had developed some kind of fault so at the moment i am PC-less. But i hope to get it repaired soon. but in the meantime can you upload an already compiled version of the kernel so that i and anyone else who is intrested could download?? you know like a flashable zip or something and did you flash the kernel for the vipertouch through the recovery?? If so i dont think it would work. They created the rom in such a way that they change most of the directories so you would have to use thier inbuilt flasher. I guess. last time i tried flashing a bootanimation through recovery but it didnt work. So i guess u use thier inbuilt one.
mickeyasamoah said:
OOOKay. But the only problem is that my pc fell and had developed some kind of fault so at the moment i am PC-less. But i hope to get it repaired soon. but in the meantime can you upload an already compiled version of the kernel so that i and anyone else who is intrested could download?? you know like a flashable zip or something and did you flash the kernel for the vipertouch through the recovery?? If so i dont think it would work. They created the rom in such a way that they change most of the directories so you would have to use thier inbuilt flasher. I guess. last time i tried flashing a bootanimation through recovery but it didnt work. So i guess u use thier inbuilt one.
Click to expand...
Click to collapse
That's cause bootanimations on sense are in a different location then sense. I think
Sent from my myTouch 4G using xda app-developers app
Yea. So i guess the kernel also might be in a different directory. And also i have just remembered that i flashed a different kwrnel from the recovery and after the bootanimation, it failed to continue and got stuck. Reason why am saying all this is because, when i enter the root of my device, i see many folders that u wouldnt see in a normal rom (cyanogen, aosp, aokp,) as far as i know. So i guess he should create a flashable zip of the kernel and maybe steady the directories of the rom and maybe it might work.
Sent from my HTC myTouch 4g using xda app-developers app
mickeyasamoah said:
Yea. So i guess the kernel also might be in a different directory. And also i have just remembered that i flashed a different kwrnel from the recovery and after the bootanimation, it failed to continue and got stuck. Reason why am saying all this is because, when i enter the root of my device, i see many folders that u wouldnt see in a normal rom (cyanogen, aosp, aokp,) as far as i know. So i guess he should create a flashable zip of the kernel and maybe steady the directories of the rom and maybe it might work.
Sent from my HTC myTouch 4g using xda app-developers app
Click to expand...
Click to collapse
Disclaimer: Some of this may come off harsh, it's unintentional I assure you; I've been told by many people I sound like I'm being a jerk when I simply know no other way to present the information than in as simple a form as possible, so reader be warned and do try not to take offense!
Actually, all of the directories you see under / (the root of the filesystem or root for short) DO exist on every Android installation regardless of the version or ROM for the most part. There are a few alterations between major Android versions (think Gingerbread to ICS or ICS to JB) but those are mostly related to the SDCard or external filesystems in general. There are also differences related to specific devices, for example; you won't find /data/media on devices that don't have an internal storage designed to mimic an SDCard (such as the Samsung Galaxy series.)
That being said, the kernel does not reside in a directory at all, it resides on a partition that is mounted as /. The kernel's ramdisk is actually where /init and /init.rc and such actually are and that is why you can't change them and have the changes persist across reboots even if the root partition is remounted as read/write. In addition to this information, one does not simply "move things around" within a deeply rooted filesystem structure like you were rearranging furniture.
And to get to the real information you're after, the reason your device fails to boot when you flash an incompatible kernel is because the kernel and the ROM, for lack of a better example, don't know how to speak to one another and one get's pissed off and they stop talking; or in other cases one gets severe dementia and repeats itself indefinitely (bootloops anyone?). Oh, and the bootanimation.zip is in the same place on every Android device. You don't need to flash it at all, it goes in /system/media/ but you'll have to remount /system as read/write first (which is why flashable zips are convenient, you don't have to mess with it and you're going to have to reboot anyway to see your new animation, right?)
And in closing, the directory structure of Team Venom's ROM and every other ROM that exists is about 99% the same. You may not have seen it before, but there's no need to drag out Shrodinger's poor cat is there? I assure you it's been there lurking in the shadows What I need is the source code to a kernel that is known to work with ICS/Sense ROMs, and as I previously stated in another post I simply haven't looked that hard yet. I have an errand or two to run this early afternoon, but you have my word I'll do my best to try and get a working kernel to you by 0500 GMT, which is midnight for me. That gives me 12 hours from now, too easy And it'll be flashable, I'm a lazy person to be honest so I have a script that compiles the kernel, builds the ramdisk, makes the boot image from the two, creates a flashable zip, uploads said zip to the device, creates a script for recovery (I use TWRP 2.5.0.0 FYI) to flash the zip and reboot, and then reboots the device into recovery. That way I only have to press return once
I hope you found some of that useful and if you'd like any more information I'd be happy to give you all that I have, it's kind of an uncontrollable thing with me so be mindful of what you ask because you will get a wash of info in return and my stop button seems to work sparingly, haha. Have a good day!
zygh0st said:
Disclaimer: Some of this may come off harsh, it's unintentional I assure you; I've been told by many people I sound like I'm being a jerk when I simply know no other way to present the information than in as simple a form as possible, so reader be warned and do try not to take offense!
Actually, all of the directories you see under / (the root of the filesystem or root for short) DO exist on every Android installation regardless of the version or ROM for the most part. There are a few alterations between major Android versions (think Gingerbread to ICS or ICS to JB) but those are mostly related to the SDCard or external filesystems in general. There are also differences related to specific devices, for example; you won't find /data/media on devices that don't have an internal storage designed to mimic an SDCard (such as the Samsung Galaxy series.)
That being said, the kernel does not reside in a directory at all, it resides on a partition that is mounted as /. The kernel's ramdisk is actually where /init and /init.rc and such actually are and that is why you can't change them and have the changes persist across reboots even if the root partition is remounted as read/write. In addition to this information, one does not simply "move things around" within a deeply rooted filesystem structure like you were rearranging furniture.
And to get to the real information you're after, the reason your device fails to boot when you flash an incompatible kernel is because the kernel and the ROM, for lack of a better example, don't know how to speak to one another and one get's pissed off and they stop talking; or in other cases one gets severe dementia and repeats itself indefinitely (bootloops anyone?). Oh, and the bootanimation.zip is in the same place on every Android device. You don't need to flash it at all, it goes in /system/media/ but you'll have to remount /system as read/write first (which is why flashable zips are convenient, you don't have to mess with it and you're going to have to reboot anyway to see your new animation, right?)
And in closing, the directory structure of Team Venom's ROM and every other ROM that exists is about 99% the same. You may not have seen it before, but there's no need to drag out Shrodinger's poor cat is there? I assure you it's been there lurking in the shadows What I need is the source code to a kernel that is known to work with ICS/Sense ROMs, and as I previously stated in another post I simply haven't looked that hard yet. I have an errand or two to run this early afternoon, but you have my word I'll do my best to try and get a working kernel to you by 0500 GMT, which is midnight for me. That gives me 12 hours from now, too easy And it'll be flashable, I'm a lazy person to be honest so I have a script that compiles the kernel, builds the ramdisk, makes the boot image from the two, creates a flashable zip, uploads said zip to the device, creates a script for recovery (I use TWRP 2.5.0.0 FYI) to flash the zip and reboot, and then reboots the device into recovery. That way I only have to press return once
I hope you found some of that useful and if you'd like any more information I'd be happy to give you all that I have, it's kind of an uncontrollable thing with me so be mindful of what you ask because you will get a wash of info in return and my stop button seems to work sparingly, haha. Have a good day!
Click to expand...
Click to collapse
Thanks very much for your contribution. And dont feel bad or anything for your answers. I love to read especially when they are things that have to do with ICT or electronic Gadgets. So am cool with that.
And once again, thanks for your help and time,this could be a break through or a start to a new life for the mytouch 4g.
With this, we [ you (zygh0st), Notorious, me and some other young developers] could come out with a rom which has the necessary drivers and files to run Most Linux/Ubuntu/ Debian Distros and apps without any difficulties, Reason is that, the Linux/Debian?Ubuntu Images Available now lack some drivers and abilities to do certain things. SOme of which is Wireless tools in Ubuntu. ( I tried searching for wireless tools for these images but there wasn't any, the ones available were those for i386 and amd64. But those images needed one for armel.) So as i said this could be the beginning a very big project for a rom that fully supports Distros and has all the drivers for pentesting.
But until then we would be waiting for the kernel.
Thanks Again Buddy.:good:
Alrighty, well I had a little bit of unforeseeable life happen and I had to tend to that. That being said, undoubtedly it hasn't gone unnoticed that my given deadline is well, dead. It's proven a little harder than I anticipated to get the drivers to compile with 2.6.35 than it was with 3.0 and I haven't sorted it out in the short amount of time I've had this weekend. I'll have some time this evening, barring any additional cataclysms of course; so I plan to try and get it knocked out then. For those running JB, I've decided not to release my currently working (and I use the term working loosely) as I've discovered it causes an interesting issue that I'm having trouble tracking down and it may end with me having to start over from scratch unless I can find it. It works in its current state, however, and it may be an issue unrelated to the kernel itself but whenever I switch to a different one it goes away so I'd rather not risk putting something out there that is known to have frustrating issues. Bugs are one thing but when you press unlock and nothing happens for close to 45 seconds, that's just broken. Anyway, I feel like I'm threadjacking so this will be the last mention of it I make here and to get back onto topic, if anyone would like to try and succeed where I haven't yet I'd be glad to lend a hand with integrating the driver especially since I have the changes required to get it to compile cleanly with kernel version 3.0; though it was really only a single section of code that needed to be changed at all. Once again, my apologies for the delays but better to take time and do it right than to smash it together and hope the tape holds.
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.