Related
I've been reading up on SGS hardware and bootloaders, and I feel like there's a very good chance that there's a way (within reach? ??) to to fix a totally bricked phone.
NOTE: I'm no expert on this stuff. If I'm missing something totally stupid, please forgive me. Anyways, here goes...
The user manual for the s5pc110 chip describes the booting process; it has 3 levels. On hw reset the cpu begins executing code that lives in ROM. The ROM code loads the primary bootloader from a source selected by external pin inputs. The PBL pretty much just loads the SBL, which does the major setup and loads the kernel.
The important thing, which I haven't seen anyone discuss, is that the initial ROM code includes the ability (poorly documented, of course) to load the PBL from UART or USB.
Repeat : non-eraseable code in our phones which is executed on hw reset can load a bootloader over serial or USB into memory and then execute it.
From other threads, we know that Samsung is able to restore a bricked phone without opening it up. Why should they have all the fun?
The first step is asserting the proper pins. This is done by connecting the proper resistance betw pins 4 & 5. The 'jig' thread describes using 301k to get into download mode, but this is happening in the SBL. Many other R values are desribed in the 'fun with resistors' thread and in the fsaXXXX-i2c.c kernel source. One of them does a reboot and connects a (3.3V) UART to the D+/D- pins.
One thing that is described in the docs is that the ROM code tries UART first and then fails over to USB. Since UART is so much simpler, I'd say that's where to begin.
We already learned in that thread that connecting at 115200 baud and banging on RETURN brings up a "SBL>" prompt with lots of cool commands available. But as TheBeano pointed out, that's not much use if the SBL is toast.
What I'm wondering is whether there's a way to interrupt the normal boot while its still running ROM code. There's no reason the ROM would set up the UART at the same baud rate as the SBL and kernel. Maybe just a lower baud and banging on RETURN is enough.
For anybody with the time and the hardware, that should be easy enough to try. TheBeano?
There's probably some handshake/protocol issues to figure out to get a bootloader loaded and executing, but we do have a known good one (the PBL) to play with.
If that can be made to work, it would be a huge step towards a working solution. There is code floating around (I saw it on the teamhacksung git) that ports u-boot bootloader to our phones. AFAIK, nobody around here has tried it. But if we are able to test bootloaders w/o flasing, then maybe we (someone with a clue about bootloaders,that is) can open the door to safe, open-source booting.
So that's it. Is this crazy-talk, or do you guys n gals think it just ... might ... work?
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
I will add a little insight without giving too much away
Its also possible to start the phone via JTAG and pass the control over to USB or UART, even to enter DLM and flash the phone without repairing the current IBL/PBL/SBL within the phone which are damaged, e.g. the loaders are running in RAM this is done via CMM or JNAND ...
I have the full unstripped source code for the PBL and SBL and may consider releasing them if some input starts in this thread, its all too easy just to give them out without the scene thinking on its feet
Oh BTW: My dog spoke to another dog who's owner works for Samsung and he told him that the 2.3.3 release, will be released when its f**king ready and not 1 day before.
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?
I've looked at the schematic fragments from the service manual but they weren't much help. If anyone has a schematic that shows what is connected to the application processor OM pins that would be a big help. Obviously the bootloader sources would be great too!
TheBeano said:
Obviously the bootloader sources would be great too!
Click to expand...
Click to collapse
Come on guys, lets have some input here, and I will give out snippets of info to help, just in case anyone is in any doubt to what I said, take a look at the attached screendump
Odia said:
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
Click to expand...
Click to collapse
Maybe this thead has to move to Rom development not many devs in general
If you have the sources then its possible to make our own bootloaders and dual boot whatever we want maybe win 7 (it's a joke)
TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
http://megaupload.com/?d=C0JHS7A8 - service training manual 01/2011
manosv said:
Maybe this thead has to move to Rom development not many devs in general
If you have the sources then its possible to make our own bootloaders and dual boot whatever we want maybe win 7 (it's a joke)
Click to expand...
Click to collapse
Hey, off topic here, but i have seen these phones on ebay, chinese own brand of course, but dual boot, runs both android and windows on one phone.
so it is possible for someone who knows how to.... would be very interested in seeing this develop
http://cgi.ebay.co.uk/W6000-Dual-Ca...ile_Phones&hash=item230f1eea0a#ht_3411wt_1139
Fuma said:
TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
Click to expand...
Click to collapse
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.
TheBeano said:
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.
Click to expand...
Click to collapse
different phone? I9000B? sorry. thought it was all I9000.
well i tired...
Fuma said:
different phone? I9000B? sorry. thought it was all I9000.
well i tired...
Click to expand...
Click to collapse
It's the schematic for a cheap phone with the Mediatek MT6225 processor, the "CSL Blueberry" I think. They have an "i9000" model so maybe that's how it started.
mmm...well if i stumble upon more stuff i'll send your way . it might help.
TheBeano said:
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?
Click to expand...
Click to collapse
Yeah, it's got to be the fsa9480. That plus (possibly) the volume/power/etc buttons are the only possibilities. The fsa switches which lines from inside the phone are connected to the micro-USB pins 2 & 3 (aka D+/D-). But it also has (at least) 2 digital outputs called JIG and BOOT which feed back to the CPU. BOOT presumably causes a hardware reset, so the JIG line is free to determine the boot mode.
We know the normal boot is from OneNand. Looking at table 6.3 of the data sheet tells us that the only pin that matters is OM5. Pins OM[4:0] determine which of the 4 different OneNAND boot modes is used, and that mode is the same regardless of OM5. So they are almost certainly just fixed. If OM5 is 0, the chip boots normally (directly from OneNAND). If it is 1, the ROM will first try to negotiate a UART connection, then try a USB connection, and only then (if I'm reading it right), fail over to a normal OneNAND boot.
So it's hard to imagine any scenario other than pin OM5 connected to the JIG output of the fsa9480.
From the Samsung source code linux/drivers/usb/gadget/fsa9480_i2c.h, there are a few interesting resistor choices (I'm not sure what the 5 bits represent; maybe they are for setting/reading the switch state over i2c) :
Code:
1 0 1 1 0 150K UART Cable
1 1 0 0 0 255K Factory Mode Boot OFF-USB
1 1 0 0 1 301K Factory Mode Boot ON-USB
1 1 1 0 0 523K Factory Mode Boot OFF-UART
1 1 1 0 1 619K Factory Mode Boot ON-UART
The 301K case (Factory Mode Boot ON USB) is the familiar "jig" people on xda use. But USB protocol is fairly complex, and since the whole idea of using the fsa switch is very non-USB compliant (the thing sends analog audio over D+/D- lines !) I don't think we can assume anything about what the ROM code does to "negotiate a connection". In addition, I think that all the people who have already looked into this were specifically trying to get into "download mode" (i.e., Loke protocol to talk with Odin). So who knows what else was going on beforehand.
I'm most curious about the behavior with a 619k resistor (Factory Mode Boot ON UART). The nice thing with UART mode is that we already know from TheBeano's thread that there is output at 115200 baud that appears at some point in the boot process. By putting a scope probe on the Tx line and simultaneously watching the text output in a terminal emulator, it should be very simple to see if any kind of negotiating is going on at an early (ROM) bootloader stage. Maybe it involves different baud rate, banging on a key, or pressing/holding a button. But (for someone with time and the right hardware) this is very do-able. If there is any hint of negotiation going on before the NAND-based bootloaders begin, we know we're onto something promising.
Like Odia pointed out, any stuff that we load during the ROM bootloader stage is not being flashed to the OneNAND; it is simply being loaded into RAM and executed. So even with no clue how to write a bootloader, I can imagine writing a "hello world"-grade program to, say, toggle a GPIO. That would clearly establish that the UART bootload procedure works.
So I think its an exciting prospect. Some of it is way beyond my abilities, but there are some easy steps early on that could really generate some intense developer interest.
I've got a I897 and a scope, but no connectors or cables to sacrifice. I may get a breakout board from Sparkfun to mess around with. In the meantime, I'd love to hear if anybody with a resistor/cable combo can sniff out anything interesting.
Also, I'm glad to see some response. I guess my title was a little cryptic, but at first it was just me and the crickets.
Found an interesting post about the ROM bootloader : http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/
Another interesting link : http://chdk.wikia.com/wiki/GPL_Disassembling
Lets just say that the ROM code from my phone (Captivate) is definitely talking to the serial ports (all 4) and the USB OTG port.
I just sent off a quick order to Sparkfun for their USB micro-B breakout (the male connector with all 5 pins broken out) and a 3.3V FTDI (USB/serial) board. Just in case I find myself w/ too much time on my hands.
js22 thats actually sounds promising.
waiting for more updates.
Goodluck
e-fuse bits anybody ?
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.
I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?
After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.
I tried a viewmem dump of this stretch of memory, and got all zeros.
So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.
Does anybody have any more info on the e-fuses ?
Oops. I just checked and any read from the SFR address range (0xE0E00000 and up) returns zero. At least if you're using viewmem.
js22 said:
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.
I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?
After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.
I tried a viewmem dump of this stretch of memory, and got all zeros.
So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.
Does anybody have any more info on the e-fuses ?
Click to expand...
Click to collapse
Its using none secure boot and your quite right JTAG access is also none secure.
So, the source code to the IROM would answer all our questions.
It would probably take me a week to reverse engineer it, unfortunately, I don't have the time right now.
The I9000 is a fairly open platform. Would samsung themselves be prepared to give this source code out.
If we could get to a point where any hacker could un-brick their own phones without even having to unscrew the case, using pin 4-5 resistors, and a 3 Volt UART cable or a USB cable, developers would be much more willing to experiment more.
I have a method to force the IROM to try alternative boot methods, and specifically not run the PBL, SBL, but without more information on what to try in order to talk to the IROM directly, is it difficult to proceed further.
To force IROM to ignore PBL and SBL, just do a heimdall dump in Linux and press CTRL-C half way through. It results in a bricked phone, with only the IROM working. I have been told a 301K Resistor will help switch it back to loading PBL and SBL but I have not tested this yet.
Does anyone have contacts within Samsung that might be able to help, or shall I try to use my contacts to source the information?
The IROM looks like it would try to use the USB in OTG mode. Thus expecting the external USB device to be a gadget and not a PC Host. This can have advantages and disadvantages.
1) Disadvantage: Not many Android developers will have USB Gadget test hardware.
2) Advantage: The I9000 itself might be a good USB gadget development tool. Changing the kernel usb driver so that it can respond correctly to commands from the IROM over USB. Potentially, we could then use one I9000 connected directly to another I9000 and the healthy I9000 could automatically unbrick the bricked I9000.
For development though, I think using the UART option would be easier to do, as any Android developer would have a serial port, and then just need a RS232 levels RS232 to 3.3V levels converter, wired up to a Micro-USB connector and the correct resistor on the ID pin.
It is also easier to write a Serial port controlling application than USB controlling applications.
I think that we would still need to reverse engineer the IROM in order to analyze it and discover what the protocol is for loading software directly into the I9000 RAM and running it without going through the boot of IBL/PBL/SBL.
We would then need to write our own boot loader to put in this RAM in order for it to reach a mode where it can program the flash and possibly provide the same functions as the current "download mode".
If we can get it as far as partitioning, and writing the IBL/PBL/SBL. That would be enough.
There are other advantages of this IROM interface. We could use it to root the phone by writing an "su" to the /system folder.
A stepping stone to this could be a "hello world" program that simply controls a GPIO. For example, flashing the LEDs that light the BACK key or writing a message to the screen.
Having the current source code to the IBL/PBL/SBL would really help here as it contains the routines to display characters and graphics on the display etc.
I'm partway through disassembling the ROM boot code, it's pretty interesting! The serial protocol is definitely in there, but I haven't worked with ARM code before so it may take some time. If anyone has already worked it out or is nearly there please let me know now!!
Stumbled upon this a bit ago, a company called Mobile Tech is offering an "unbricking" service on all versions of the Galaxy Tab. At the time of this writing they charge $50. I have not used this service, am not in any affiliated with this company and cannot vouch for their work, so beware. Just thought someone out there might use this when other options aren't available.
They have a nifty video up on youtube showing how they do it:
it will be a good help for those who brick their tab because they ain't follow the steps .. thanks for sharing this out
I can actually vouch third party for this service. Have had two friends use it and the device was returned within a few days. If I'm not mistaken, the guy lives in the southern US, but can arrange international he says.
Sent from my "better than an iPad" tab... Running Overcome GINGERBREAD!!!
This is cool, but I would recommend trying to go through Samsung first if you are still under warranty. I screwed up my primary bootloader and contacted them. They took care of shipping costs, fixed it up, and sent it back in about a week and a half. If Samsung hadn't fixed it I would defiantly have payed the $50 here though.
WOW, that seems like a lot of work for $50.
Thanks for the info, should I ever screw something up its nice to know there are people out there who can clean up my mess!
spacemoose1 said:
a company called Mobile Tech is offering an "unbricking" service on all versions of the Galaxy Tab.
Click to expand...
Click to collapse
Hi spacemoose1
Thanks for link and as always, thanks for honeycomb port. I would like to ascertain the definition of BRICK? with your help, if I may.
(disclaimer: pls forgive my wrong terms or exagerated explanation, but most importantly, pls correct me if I'm wrong)
BRICKed = software total lost, must use JTAG to force revive it, Samsung has it, or buy from web supplier around 300 USD ??? 500 USD ???
JTAG is a device to push software into all newly borned IC. I.E. when factory make IC, it's empty software inside, hence has a special device to push voltage into all sections of the IC, then force the code in.
Another term is ???CRASH??? or ???HANG???, (I don't know) anyway is not BRICKed, hence a reflash can recover it.
Samsung uses proprietary method a lot, not follow conventional, make usb driver very complex. USB driver install EXE around 15MB to 28MB depends on version, ALL work the same.
but, when the device = sgt7 in different state/condition, the driver must RE-ESTABLISH again, or else cannot work.
I.E.
state 1 = "OPERATIONAL"device in android operation, normal use, surf web, phone call etc
state 2 = "SLEEP" device powered off, show battery big icon charging when powered by charger
state 3 = RECOVERY mode
state 4 = DOWNLOAD mode - this is one of the way to FORCE flash to recover, as long as bootloader and something still intact
state 5 = PHONE-!-PC mode
stage 6 = "COMA" device powered off, NO show of battery big icon, even when charger supplied. Don't panic, let it charge fully 4 hours from 2 amperes supply, 10 hours from PC 500mA. It will start again !!!. Battery big icon will appear around 30% battery charged, I know because that's what I saw. I didn't check when it's in 10% or 20%. The 1st time I check was already 30% up from no-boot or no respone.
User need to plug device into PC during each of the state above at least once, in order for various flashing functions to work.
i.e. when it's a newly arrived device, usually install the usb driver 1st, with device state in android OS running properly, then plug in to USB and see "new device detected" installing, pls wait. Finished.
But when flashing via Odin using state 4 = DOWNLOAD mode, user may experience no connection, no COM3 or something. Because device must be unplugged in USB, power-up in state 4 = DOWNLOAD mode, plug in USB, "new device detected" installing = RE-ESTABLISH, done. UNPLUG USB, replug in usb, then COM3 appears FLASH will be succesfull.
same goes for other state.
p.s. many users reported BRICKed but then recovered WITHOUT JTAG is misleading beginners, hence should rename the term to ???CRASH??? or ???HANG???. although some previously use "SEMI-brick", which is acceptable.
stage 3 = ClockWorkMod flashing (super convenient, especially on the move without PC)
stage 4 = Odin / Heimdall both works (still convenient and easy )
stage 5 = Odin / Heimdall both works (still convenient and easy )
???CRASH??? or ???HANG??? or "SEMI-brick" is usually SUCCESFULLY recovered via restock+PIT
(final disclaimer, incase above is correct and help and is copied, pls correct whatever mistakes found, feel free.)
*** Thanks for all those who taught me my mistakes *** devs and fellow forumers
ManticoreX said:
This is cool, but I would recommend trying to go through Samsung first if you are still under warranty. I screwed up my primary bootloader and contacted them. They took care of shipping costs, fixed it up, and sent it back in about a week and a half. If Samsung hadn't fixed it I would defiantly have payed the $50 here though.
Click to expand...
Click to collapse
Yeah, warranty repair is always a better choice. But sometimes you've already voided the warranty, lol.
I guess, if u change factory installed rom/kernel warranty gonna be history
thanx for the post ... it might gonna be the last resort...
cx5 said:
Hi spacemoose1
Thanks for link and as always, thanks for honeycomb port. I would like to ascertain the definition of BRICK? with your help, if I may.
(disclaimer: pls forgive my wrong terms or exagerated explanation, but most importantly, pls correct me if I'm wrong)
BRICKed = software total lost, must use JTAG to force revive it, Samsung has it, or buy from web supplier around 300 USD ??? 500 USD ???
JTAG is a device to push software into all newly borned IC. I.E. when factory make IC, it's empty software inside, hence has a special device to push voltage into all sections of the IC, then force the code in.
Another term is ???CRASH??? or ???HANG???, (I don't know) anyway is not BRICKed, hence a reflash can recover it.
Samsung uses proprietary method a lot, not follow conventional, make usb driver very complex. USB driver install EXE around 15MB to 28MB depends on version, ALL work the same.
but, when the device = sgt7 in different state/condition, the driver must RE-ESTABLISH again, or else cannot work.
I.E.
state 1 = "OPERATIONAL"device in android operation, normal use, surf web, phone call etc
state 2 = "SLEEP" device powered off, show battery big icon charging when powered by charger
state 3 = RECOVERY mode
state 4 = DOWNLOAD mode - this is one of the way to FORCE flash to recover, as long as bootloader and something still intact
state 5 = PHONE-!-PC mode
stage 6 = "COMA" device powered off, NO show of battery big icon, even when charger supplied. Don't panic, let it charge fully 4 hours from 2 amperes supply, 10 hours from PC 500mA. It will start again !!!. Battery big icon will appear around 30% battery charged, I know because that's what I saw. I didn't check when it's in 10% or 20%. The 1st time I check was already 30% up from no-boot or no respone.
User need to plug device into PC during each of the state above at least once, in order for various flashing functions to work.
i.e. when it's a newly arrived device, usually install the usb driver 1st, with device state in android OS running properly, then plug in to USB and see "new device detected" installing, pls wait. Finished.
But when flashing via Odin using state 4 = DOWNLOAD mode, user may experience no connection, no COM3 or something. Because device must be unplugged in USB, power-up in state 4 = DOWNLOAD mode, plug in USB, "new device detected" installing = RE-ESTABLISH, done. UNPLUG USB, replug in usb, then COM3 appears FLASH will be succesfull.
same goes for other state.
p.s. many users reported BRICKed but then recovered WITHOUT JTAG is misleading beginners, hence should rename the term to ???CRASH??? or ???HANG???. although some previously use "SEMI-brick", which is acceptable.
stage 3 = ClockWorkMod flashing (super convenient, especially on the move without PC)
stage 4 = Odin / Heimdall both works (still convenient and easy )
stage 5 = Odin / Heimdall both works (still convenient and easy )
???CRASH??? or ???HANG??? or "SEMI-brick" is usually SUCCESFULLY recovered via restock+PIT
(final disclaimer, incase above is correct and help and is copied, pls correct whatever mistakes found, feel free.)
*** Thanks for all those who taught me my mistakes *** devs and fellow forumers
Click to expand...
Click to collapse
I pretty much agree, but I might refine:
BRICK= Unit does not power up, visibly charge, reach a boot-screen of any kind including a service or "download" screen. A device in this state requires service from the manufacturer or an individual equipped with the proper tools. There is no other way to recover a device in this state.
SOFT-BRICK= Unit powers up, reaches a "download" or service screen, visibly charges but does not boot into an OS. Crashing, hanging etc. all apply here. It is easy to recover a device from this state so long as one has access to a firmware that was designed for the device and the ability to flash said firmware.
SEMI-BRICK= See soft-brick above
JTAG= Provides access to system hardware by applying the correct voltage to the correct pins in order to push software via an external program.
In regards to the usb drivers, there are only actually 4 states
1. Active userspace
2. Serial gadget mode
3. Recovery
4. USB storage mode
And there is a separate driver for each of these (except recovery) in the Samsung driver package that should install automatically when the device is plugged in during normal use on a stock rom, or with the installation package available on the web.
The rest of it you've got pretty much correct.
Money seems right, but the amount of work that guy has to go thru is amazing, so much to tare it apart, and reassemble. Then again when it is put back toether, he checks it, what if it did not take the fix... all over again.
Hardbricked Tab Save by Mobile Tech
I hardbricked my galaxy tab bought in Cambodia. My little brother open the tab trying to take the battery off and put it back on, thus void the warranty, found him on the Samsung vibrant forum, sent the tab to him got it back good as new. This person is professional, honest and good communication with his customers, you'll be happy with his work, if he can't fix it you get your money back (minus shipping and diagnosis)...Glad he is arround to help...
spacemoose1 said:
I pretty much agree, but I might refine:
BRICK= Unit does not power up, visibly charge, reach a boot-screen of any kind including a service or "download" screen. A device in this state requires service from the manufacturer or an individual equipped with the proper tools. There is no other way to recover a device in this state.
SOFT-BRICK= Unit powers up, reaches a "download" or service screen, visibly charges but does not boot into an OS. Crashing, hanging etc. all apply here. It is easy to recover a device from this state so long as one has access to a firmware that was designed for the device and the ability to flash said firmware.
SEMI-BRICK= See soft-brick above
JTAG= Provides access to system hardware by applying the correct voltage to the correct pins in order to push software via an external program.
In regards to the usb drivers, there are only actually 4 states
1. Active userspace
2. Serial gadget mode
3. Recovery
4. USB storage mode
And there is a separate driver for each of these (except recovery) in the Samsung driver package that should install automatically when the device is plugged in during normal use on a stock rom, or with the installation package available on the web.
The rest of it you've got pretty much correct.
Click to expand...
Click to collapse
You should post this in Q/A thread on its own as its very helpful and maybe it will stop the 1% of people saying help my phone is bricked comments ... the other 99% don't read anyway otherwise they would discover their phone isn't bricked and if they read properly it would not have gotten to the state in the first place .. and no I never posted something like that myself >:¬}
but well done on this..
alexgogan said:
You should post this in Q/A thread on its own as its very helpful and maybe it will stop the 1% of people saying help my phone is bricked comments ... the other 99% don't read anyway otherwise they would discover their phone isn't bricked and if they read properly it would not have gotten to the state in the first place .. and no I never posted something like that myself >:¬}
but well done on this..
Click to expand...
Click to collapse
+1
Sent from my GT-P1000 using Tapatalk
Nice find. For that amount of effort disassembling, and reviving, $50 is a very realistic price. I'll keep these guys in mind if I run into issues with my tab.
$50 for that much work is an absolute bargain! I wish I didn't live in a country where you get charged $200/hr for someone to pick their nose.
It's actually not that much more difficult than popping an OS install CD into a hosed computer and pressing 3 keys to let it run through the installation after flashing a corrupt motherboard BIOS. Yes, it takes familiarity with the software and hardware, but it's by no means a feat that requires a special skillset.
Granted, few people have JTAG stuff handy, so $50 is definitely worth it if you've hosed your device, but don't make it sound like he's sweating and coding the bootloader by hand, strenuously manipulating micro tools to disassemble the tablet and flipping DIP switches to restore the bootloader. You spend 5 minutes taking apart the tablet, you attach the JTAG cable, run the supplied software on your computer, and sit there recording the screen with your video recorder while the progressbar moves from 0 to 100.
Again, it's worth $50 simply because not everyone and their mother has JTAG hardware sitting around, but by no means is it hard. It's the same reason I can get away with charging $100 to clean viruses off of a computer. People either don't have the tools or don't know how to use them. That being said, I don't know a damn thing about using JTAG to restore a corrupt bootloader, nor do I have the right hardware, so I'd pay $50 if I were ever in the situation.
Edit: And yes, $100 for a virus clean is a lot, but people generally change their mind when I explain to them why they got viruses, as well as installing proper antivirus software and then instructing them on how to avoid infection in the future. I rarely get repeat business from the same customer but I get A LOT of referrals ;p They're happy paying that much when the person educates them instead of cleaning, not installing/explaining, then having to bring the computer in again two weeks later for another wallet-gouge, which most other computer 'repair people' gladly do over and over.
Everything in this world is rinse and repeat... The money comes from time spent learning to use the hardware properly, micro soldering skills (which isn't easy, no matter who you are), confidence enough to offer it as a service, not to mention the couple hundred bucks for the jtag software and hardware.
Now, the fact that if you have your device in a bricked state you likely voided the warranty, it's a 600 dollar brick if your samsung tech recognized it... 50 bucks is a steal to not deal with samsung anyway.
Try to be less pompous next time oh savoir of the hundred bone virus... Your poop stinks too, promise.
Sent from my "better than an iPad" tab running Overcome Hermes.
LycaonX said:
It's actually not that much more difficult than popping an OS install CD into a hosed computer and pressing 3 keys to let it run through the installation after flashing a corrupt motherboard BIOS. Yes, it takes familiarity with the software and hardware, but it's by no means a feat that requires a special skillset.
Granted, few people have JTAG stuff handy, so $50 is definitely worth it if you've hosed your device, but don't make it sound like he's sweating and coding the bootloader by hand, strenuously manipulating micro tools to disassemble the tablet and flipping DIP switches to restore the bootloader. You spend 5 minutes taking apart the tablet, you attach the JTAG cable, run the supplied software on your computer, and sit there recording the screen with your video recorder while the progressbar moves from 0 to 100.
Again, it's worth $50 simply because not everyone and their mother has JTAG hardware sitting around, but by no means is it hard. It's the same reason I can get away with charging $100 to clean viruses off of a computer. People either don't have the tools or don't know how to use them. That being said, I don't know a damn thing about using JTAG to restore a corrupt bootloader, nor do I have the right hardware, so I'd pay $50 if I were ever in the situation.
Edit: And yes, $100 for a virus clean is a lot, but people generally change their mind when I explain to them why they got viruses, as well as installing proper antivirus software and then instructing them on how to avoid infection in the future. I rarely get repeat business from the same customer but I get A LOT of referrals ;p They're happy paying that much when the person educates them instead of cleaning, not installing/explaining, then having to bring the computer in again two weeks later for another wallet-gouge, which most other computer 'repair people' gladly do over and over.
Click to expand...
Click to collapse
I've got to call you out on this one. Mis-connecting or shorting any wires will lead to a damaged PCB and an un-resurrectable TAB. I'm also a Systems Admin for a living so I understand where you are coming from. You must realize that I solder at levels of .1mm in spacing on the Captivate, Vibrant and Nexus S. Electrical engineers and technicians have first hand talked with me about the difficulty of doing this and is NOT something that anyone can do. You'd think twice when you burn up a phone or two valued at $500 a pop trying to JTAG them. There is more skill involved than you would think. Not to mention the liability when dis-assembling the device. JTAG software is decent but it's not fully automated. There are TCK frequencies, RTCK frequencies different PBL partition sizes, full dcc loader read/writes and the requirement of EXACT voltage from an external power supply that are needed in MANY cases. Plus, there is little to no support when fixing a device. This means that if you can't figure it out, nobody else is going to for you. I'm not trying to brag but yet point out that this isn't like plugging in your phone for an ODIN flash. I've taken hundreds of hours of time and 1000's of dollars to create what I feel is the most trusted JTAG authority online ANYWHERE. I greatly appreciate having the opportunity to help the community and enthusiasts in this community. If this was as easy as you are claiming, you could get JTAG hardware and a manual at Best Buy. I have to say you put it best when you said you don't know anything about JTAG... Ok end of rant I was just a bit bothered by your post.
Ok with that being said, thanks for the personal testimonies and compliments. I will be here whenever anyone needs JTAG assistance in the future or around the forums to help answer Q&A when it doesn't require JTAG. Here is a Nexus S promo to realize how tiny some of these things are
http://www.youtube.com/watch?v=Ecp8jKmm48k
i would love to learn more on how to do stuff like this if i had moneyz. the .1mm ext.
not just for android but to make my own ish.
thanks for the awsome videos.
Thanks for the link, hope I won't need it ;-)
Sent from my GT-P1000 using XDA App
So here's the story, bought my Galaxy 10.1 7 days ago, It was working perfectly, I turned it off, and plugged for a nice charge... a couple of hours later..
I tried to turn it on.. and nothing..
So far I have tried:
Holding the power button for several minutes with the tab plugged did not woked.
Holding the power button for several minutes with the tab un-plugged did not woked.
Holded PWR+Volume Down
I connected the tab to my pc and the USB detects that there's something there but nothing else..
is there anyway to use adb or fastboot to kick the thing out?
Please help
Sorry if double posted but I'm going nuts with this problem
Pwr button alone for 15 sec kicked my tab over every time I've locked it, and I'm screwin with pershoots kernel and overclock
lbrenes said:
So here's the story, bought my Galaxy 10.1 7 days ago, It was working perfectly, I turned it off, and plugged for a nice charge... a couple of hours later..
I tried to turn it on.. and nothing..
So far I have tried:
Holding the power button for several minutes with the tab plugged did not woked.
Holding the power button for several minutes with the tab un-plugged did not woked.
Holded PWR+Volume Down
I connected the tab to my pc and the USB detects that there's something there but nothing else..
is there anyway to use adb or fastboot to kick the thing out?
Please help
Sorry if double posted but I'm going nuts with this problem
Click to expand...
Click to collapse
Sent from my SPH-D700 using XDA Premium App
Have same problem, exactly as yours dont know what to do. Should send it to support but i live abroad so im fuc...
condorazul said:
Have same problem, exactly as yours dont know what to do. Should send it to support but i live abroad so im fuc...
Click to expand...
Click to collapse
I have exactly the same problem I live in Costa Rica and now I need to send it to USA, and it is going to be very expensive...
Mine is not coming up with any button combination at all...
can't you simply let it deplete his charge using headphones or so?
dcc22 said:
can't you simply let it deplete his charge using headphones or so?
Click to expand...
Click to collapse
Don't know what do you mean by this... the tablet is not even turning on... how am I going to discharge it?
I Will try to reflash it if finally dont manage to send it to USA. I've been reading some post and the drivers it need are available to download, but the firmware has not been released yet, none the less I will charge all the tab to my home insurance cos it seems to be an electric failure.
If someone gets the solution please help us
condorazul said:
I Will try to reflash it if finally dont manage to send it to USA. I've been reading some post and the drivers it need are available to download, but the firmware has not been released yet, none the less I will charge all the tab to my home insurance cos it seems to be an electric failure.
If someone gets the solution please help us
Click to expand...
Click to collapse
Can you share those posts? how can it be flashed in this state?
I've read some Post about passing the information through cmd in windows but I would have to read it again, think it was in nvidia developers or something similar, I guess that if the Pc recognizes the apx something can be done but I'm not an expert and this is my first and Perhaps last android tablet. I'll take a look and told you if I find something
I have the same problem. Bought the tab on Friday in the US and then returned home to the UK. It died last night - 2 days later.
Samsung technical support said it would need to be returned to a service centre. UK service centers can't deal with it as the tab isn't out here yet.
I have called Samsung US this evening and spoke to a very helpful guy who said I can send it back to the us to be fixed under warranty, but will have to pay to ship it there and for them to ship it back to me.
Unfortunately samsung's systems can't cope with my uk address so I will have to speak to the warranty company company direct - who are closed today as it's 4th July.
As a final point - I also spoke to best buy - to see if I could return it to them. As I bought it in store, I have to return it to store. Bunch of ............
Sent from my GT-I9000 using XDA App
tmbk said:
I have the same problem. Bought the tab on Friday in the US and then returned home to the UK. It died last night - 2 days later.
Samsung technical support said it would need to be returned to a service centre. UK service centers can't deal with it as the tab isn't out here yet.
I have called Samsung US this evening and spoke to a very helpful guy who said I can send it back to the us to be fixed under warranty, but will have to pay to ship it there and for them to ship it back to me.
Unfortunately samsung's systems can't cope with my uk address so I will have to speak to the warranty company company direct - who are closed today as it's 4th July.
As a final point - I also spoke to best buy - to see if I could return it to them. As I bought it in store, I have to return it to store. Bunch of ............
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Yeap same here, I will be sending mine on wednesday if I cannot find a resolution on my own, I spoke to best buy as well and we have 14 days to get an exchange for a new one..
Just one question to all is anybody using the Invisi shield on your tab?
Here us the place where I read it it's inthat forum
http://forum.xda-developers.com/showthread.php?t=1130574
Think they are speaking about our problem
So if you send it to best buy they change it, but my problem is that my fifteen day will expire on the deliver, tomorrow I will try the solution posted before and see if it works, nothing to loose
condorazul said:
So if you send it to best buy they change it, but my problem is that my fifteen day will expire on the deliver, tomorrow I will try the solution posted before and see if it works, nothing to loose
Click to expand...
Click to collapse
Official policy is that if it was bought in store it has to be returned to store you got it from. The lady on customer services said some managers will accept returns by post but at their discretion. I got one that chose not to!
Sent from my GT-I9000 using XDA App
power button for about 10 seconds reboots for me (stock everything)
joebob1 said:
power button for about 10 seconds reboots for me (stock everything)
Click to expand...
Click to collapse
Lucky you... I was able to access my tab with nvflash and I think the problem is that my bootloader is broken
C:\nvflash>nvflash --bl bootloader.bin --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x037c704641bff4d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
downloading bootloader -- load address: 0x108000 entry point: 0x108000
download command failed NvError 0x120002
command failure: bootloader download failed (bad data)
bootloader status: Bct file not found (code: 21) message: flags: 1073840124
So if someone knows how to fix that It might bring the tab back up
same problem in mine lets wait for some illuminate to fix it
lbrenes said:
Lucky you... I was able to access my tab with nvflash and I think the problem is that my bootloader is broken
C:\nvflash>nvflash --bl bootloader.bin --go
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 3
chip sku: 0x8
chip uid: 0x037c704641bff4d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
downloading bootloader -- load address: 0x108000 entry point: 0x108000
download command failed NvError 0x120002
command failure: bootloader download failed (bad data)
bootloader status: Bct file not found (code: 21) message: flags: 1073840124
So if someone knows how to fix that It might bring the tab back up
Click to expand...
Click to collapse
can you get into odin or no?
I have also been able to access via nvflash. Tried Odin 1.3, 1.7 and 1.8 (might have been 1.83) and none detect it.
Sent from my GT-I9000 using XDA App
ericc191 said:
can you get into odin or no?
Click to expand...
Click to collapse
In this state it is impossible to get in to DOWNLOAD mode,and for what I have read the Tab is only flashable with a special service cable so I guess unless we get a very skilled Dev to find a workaround our only option is to return them
MODS: I AM NOT 100% SURE THAT THIS GOES HERE. MOVE THIS IF NEEDED.
Ok. So all my android phones up to this one have had the ability to have their bootloader unlocked. I know that this specific phone has only been out for about 8 months now and we are seeing little to no progress on the unlocking of the bootloader.
My question is, how?
Where do you even start to unlock a bootloader?
What tools are needed?
Once you find a way to unlock your device (the one you have been working on) how do you package it and test it on other devices?
The reason I ask is because I have a bit of time on my hands and I know a bit about code.
I understand that trying to do something like this is EXTREMELY hard or it would have been done by now, but the way I see it the more heads banging against the same wall. Sooner or later the wall is going to give.
If you want to look into trying to do this I would guess the threads Adam Outler left in the VZW Note 2 forums on how he did it.
Sent from my SM-N900V using Tapatalk
The N3 takes full advantage of ARM Trustzone technology in the Snapdragon 800 SoC. This involves a microkernel running on a separate ARM core from processor ROM space and SoC private memory to do things like key storage and crypto computations, as well as chain-of-trust bootstrapping where each image loaded in the boot sequence is cryptographically verified before loading.
There is a portion of the eMMC flash memory chip (rpmb - Replay Protected Memory Block) which can only be accessed via a hardware protocol that re-keys every read-write transaction. So, even if you could sniff the eMMC (hardware) bus, you might be able to passively read data, but the key used to generate the transaction nonce is never exposed... meaning you won't gain control of it.
In addition, as of the MJ7 release, part of this boot sequence (aboot - the part which interacts with Odin) stores & uses anti-rollback protection information which disallows even valid *prior* Samsung firmware from being re-flashed onto the device. This is to prevent vulns discovered in prior releases from becoming a gateway to device customization.
Sounds complicated, right? Well, that's only the start of it. In addition there are "trustzone applets" that are running during the normal boot that continuously perform a variety of attribution measurements that detect tampering of kernel memory, changes to certain partition signatures, etc. It is sort of unknown at this point whether or nor these live "tripwires" also blow irreversible tamper fuses on the SoC or merely write tamper detection into the rpmb via the TZ api. In either case though, the possibility exists that "harmless" activity such as a kernel exploit that writes into volatile private kernel memory could result in semi-permanent disabling of the device.
In any event, there isn't a playbook for exploit discovery, other than this: understand approximately how a given subsystem works, and look for/test against implementation errors. If one is found, the dev needs to create and test hypotheses that might allow a minor exploit to be leveraged up into increasing privilege or control.
I'm not optimistic that a "class break" exploit of the hardware trustzone technology will occur; but the normal OS requires services from the trustzone, so perhaps there are implementation errors that exist that are close to the exposed APIs.
Probably there are private methods known to Samsung ARCs (Authorized Repair Centers) for reprogramming/resetting devices. These are probably low-hanging fruit in the sense that (a) if known they would enervate devs to experiment, knowing they have a rescue method, and (b) are the type of thing which could be exposed through social methods, and (c) are close in function to the goal of loading altered images onto the phone.
This phone has a *ton* of security stuff going on compared to phones that are only one year old. Given Samsung's dominance in the Android "premier device" segment, if I were CyanogenMod's new investors, I would be worried about what this portends for the future for aftermarket ROMs which require a custom kernel.
Maybe the right approach is to beat Samsung up over their horrid track record for making developer devices available - or maybe it is time to start rewarding OEMs who are happy to allow opt-out of device lockdown through market mechanisms. Samsung boycott, anyone?
Personally, I find it objectionable that my phone needs to be locked down and bristling with security armament on the off-chance that it might someday become a corporate BYOD device. That puts the interests of a low-probability straw-man ahead of the actual device owner... namely, me.
bftb0
I agree with you that it is a load of rubbish that our phones are locked down, but I still have hope that we will get an unlock procedure. Adam Outler, despite saying he was done with Samsung devices, has somehow managed to get past Secure aboot and turn it off. He posted a picture of it on his G+, which he promptly deleted because people were sending massive amounts of hate simply because they didn't understand that bypassing aboot was not an unlock.
I still have hope for an unlock but it fades everyday, I think one of our best hopes would be Outler if he is truly looking into to bootloader unlock us. There are so many devs looking into it though that any one of them could do it any day.
Sent from my SM-N900V using Tapatalk
Hi,
I wrote a patch to make the Moto G recognize the buttons of headsets/headphones. The hardware is capable of detecting the buttons, Motorola simply didn't write the code for it because at the time Android was not able to make use of them.
I have a minor problem that I can't easily overcome without help.
The chip that takes care of the detection simply reports some value when a button is pressed and this value depends on the specific headset used. It's up to the kernel decide what to do with that value. Each headset implements the buttons in a different way, so I need to gather some data. I think there's some sort of standard in the industry, so probably it will be possible to implement a generic solution (how can other devices do that otherwise?).
At the following address, you can find a simple patch that makes the kernel print that value whenever a button is pressed. It really does nothing other than that.
Code:
https://pastebin.com/raw.php?i=h9dnhmKr
To get the data I need, run from Terminal Emulator/adb the following (as root):
Code:
cat /proc/kmsg | grep TPA
(the command must be stopped manually: close Terminal Emulator/Ctrl+C/Vol down+C etc...)
Now, every time you press a button, you should see a new line (maybe more), for instance:
Code:
<6>[ 97.148228,0] TPA: value: 67
I'm interested in those values and their corresponding button, i.e. the button you pressed to get the line.
The value is not constant, you'll get different values for the same button. It's not a problem.
EDIT: I forgot to mention that the prebuilt kernel here below is for falcon. If you are using CM made for falcon, then this image is OK.
At the following address you can find a prebuilt kernel image made for the current CyanogenMod 12.1, anything not too distant from the currently nightly should be fine (I built the kernel three days ago) (do whatever you want with this prebuilt image, mirror it, repackages it etc...):
Code:
https://mega.nz/#!7A4SjQqZ!DPzO18k56e9364PciH7RC6rVCbrkuuUyqAcX9eFyd4I
Sources:
Code:
https://github.com/CyanogenMod/android_kernel_motorola_msm8226/ at acfe66c6fee + patch linked here above
If you want to test the prebuilt kernel image without flashing it, use fastboot:
Code:
fastboot boot path/to/the/boot.img
In this way, all you need to go back to your kernel is rebooting the phone.
PS: Most likely headsets made by Apple won't be recognized.
Any chance of doing the same work for Peregrine (XT1040)? Very interesting reading by the way...
If you want to know whether peregrine can detect these buttons or not, the answer is yes. Peregrine uses the same chip, if I saw things correctly (which also means it uses the same kernel driver).
If you want a bootable image, I might be able to provide one, but it would be better if someone with a peregrine does that. The patch can be applied as is.
@tpa-moto great work
i personally feel this thread suppose to be in development sub forum.
Hi, great work! This is a sore spot for me because I want to use one of those selfie sticks that plug in as a headset
I followed your instructions and pressing the button of the selfie stick gave no output. It does, however, work normally on another phone I have access to (LG G3 Beat).
I plugged in a headset with a microphone, but no volume buttons. Holding the mic button on the headset activates voice search as it should, but pressing it logs no lines.
While plugging the headset in and out however, I get some erroneous triggers. The jack has 3 black bands, and a sample of the keycodes I'm getting by plugging the jack in and out two times is below.
I know this is not exactly the data you're seeking but it's all I can generate right now, I don't have a headset with a volume button, other than the selfie stick (which is supposed to emulate a volume button, and does so, on the other phone). I'm posting in the hopes that it's useful somehow. Thank you for your hard work and best of luck!
<6>[ 615.271014,0] TPA: value: 13
<6>[ 615.370970,0] TPA: value: 23
<6>[ 615.470890,0] TPA: value: 25
<6>[ 615.570900,0] TPA: value: 26
<6>[ 620.080889,0] TPA: value: 13
<6>[ 620.181147,0] TPA: value: 14
<6>[ 620.280899,0] TPA: value: 14
<6>[ 620.380899,0] TPA: value: 24
<6>[ 620.480906,0] TPA: value: 24
<6>[ 620.580912,0] TPA: value: 24
<6>[ 620.690932,0] TPA: value: 24
<6>[ 620.790923,0] TPA: value: 24
<6>[ 620.890936,0] TPA: value: 26
<6>[ 620.990932,0] TPA: value: 25
<6>[ 621.090917,0] TPA: value: 24
<6>[ 621.191007,0] TPA: value: 25
<6>[ 621.290872,0] TPA: value: 24
<6>[ 621.390886,1] TPA: value: 24
<6>[ 621.500946,0] TPA: value: 24
<6>[ 621.600897,0] TPA: value: 12
<6>[ 621.700952,1] TPA: value: 13
I followed your instructions and pressing the button of the selfie stick gave no output. It does, however, work normally on another phone I have access to (LG G3 Beat).
Click to expand...
Click to collapse
I didn't even know these existed. I just looked it up and it seems that selfie sticks simply send a volume up/down keypress. If nothing gets printed, then the stick is most likely not detected. I see some comments in the code mentioning workarounds for some accessories (e.g. Paypal card reader, Jawbone), probably your selfie stick needs something similar. Needless to say it's really hard to debug the problem without actually owning the stick.
You could try to see if something gets printed when you insert the jack:
Code:
cat /proc/kmsg
(this will print a lot of stuff and then stops. Insert the jack once no lines/almost no lines are printed).
Debug messages are disabled, so it's unlikely you'll see something useful.
I plugged in a headset with a microphone, but no volume buttons. Holding the mic button on the headset activates voice search as it should, but pressing it logs no lines.
Click to expand...
Click to collapse
The chip detects two types of buttons presses and the kernel driver currently does something only for one of them.
If the phone is responding to button presses, the patch I wrote should make no difference as the kernel is already doing what's supposed to do. Most of the headsets with a single button work (e.g. the ones Motorola shipped with this device in some countries). If they have multiple buttons, at most one of them work.
If the phone does not respond to button presses, then this patch should make the kernel print lines similar to the ones you posted.
Also, the patch I posted/applied to the kernel is very simple and doesn't try to avoid spurious events.
I merged this patch to my kernel, however the compiler gave me this while building:
Code:
sound/soc/codecs/tpa6165a2.c:836:13: warning: 'tpa6165_detect_multi_button' defined but not used [-Wunused-function]
static void tpa6165_detect_multi_button(struct tpa6165_data *tpa6165)
^
Is this normal? I'm using GCC 5.2.1 + a modified Uber 5.2 toolchain to build my kernel
That's definitely not normal. Did you use patch to apply the patch? If not, check again what you did.
tpa-moto said:
That's definitely not normal. Did you use patch to apply the patch? If not, check again what you did.
Click to expand...
Click to collapse
Actually i had edited the file manually but i've reverted my commit and then used patch to apply the patch. No more build warnings
Did anyone send him some values privately atleast? I personally did, honestly, i can keep doing what i do right know, building the kernel myself with the patch from gerrit and values for my current headset and i get all the buttons working perfectly, he is just doing you a favor and he is asking just a 1 minute of your life to get those values from /kmsg, because the official implementation of this feature on CM or any other ROM, depends on how much users will report those numbers, i really don't care about this, because, i repeat, that i already did my job and sent him the values of my headsets and i can still compile the kernel myself with the working patch for my headsets. I don't believe there is no one that owns an headset with buttons, just do something useful, instead of flashing 4 different ROMs in 2 hours, flash this kernel and report those values, thanks.
It's also true that probably not many saw this. In any case, I'm not sure we will be able to collect enough values to have anything that can be made "official".
@zackwire Sorry, I didn't bother making an image for peregrine yet.
tpa-moto said:
It's also true that probably not many saw this. In any case, I'm not sure we will be able to collect enough values to have anything that can be made "official".
@zackwire Sorry, I didn't bother making an image for peregrine yet.
Click to expand...
Click to collapse
I don't really understand what you're supposed to do to get the values. Are you able to elaborate a bit more? I'd really like to help out, but I'm not sure what I'm supposed to do.
Also, how many values do you need?
ahmad.o said:
I don't really understand what you're supposed to do to get the values. Are you able to elaborate a bit more? I'd really like to help out, but I'm not sure what I'm supposed to do.
Also, how many values do you need?
Click to expand...
Click to collapse
There isn't much to add to what I already wrote.
Boot the kernel using fastboot and use adb or Terminal Emulator to run the followings:
Code:
su
cat /proc/kmsg | grep TPA
The second command should print a line each you press a button of you headset.
Each button is ideally associated to a value, in practice you'll get different values all close to each other, one per button press. You shouldn't get many different values, once you notice that you can't get anything you didn't get before, you can stop.
Note: I'm also interested in knowing which button generated which line.