yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] E:V:A:
You mean this one? Are you sure its a diagnostic port? Seem just like extra solder pads for the SIM connectors. If so, I guess it could be useful to sniff SIM traffic, but I don't think you can actually use it for anything else without more serious SIM reading/writing equipment... If you really want to know whats going on in your SIM, you might wanna get a programmable SIM + sniffer card, where you can read and re-program both STK and new features. May I ask why you think this may be useful/important?
[Hardware Hacking General] AdamOutler:
No, I mean this one..

I modified my rear case to be able to get to this port.

Also I'm taking Linux+ and that's slowing me down too :)
[Hardware Hacking General] AdamOutler:
alright... rooted and installed busybox in CASUAL format. I pushed the scripts to the SVN repository as well. http://code.google.com/p/android-casual/source/detail?r=117 I'll release that later.

Anyway... here we go. I'm not finding what you were looking for.

shell@android:/ # find / -iname "*service*"
/system/app/DefaultContainerService.apk
/system/app/DefaultContainerService.odex
/system/app/GoogleLoginService.apk
/system/app/GoogleServicesFramework.apk
/system/bin/sensorservice
/system/bin/service
/system/bin/servicemanager
/system/framework/services.jar
/system/framework/services.odex
/system/lib/libcameraservice.so
/system/lib/libmediaplayerservice.so
/system/lib/libsensorservice.so
/system/vendor/lib/libPVRScopeServices.so
/data/data/com.google.android.gsf/databases/gservices.db
/data/data/com.google.android.gsf/databases/gservices.db-journal
/data/data/com.google.android.gsf/shared_prefs/CheckinService.xml
/data/data/com.google.android.gsf/shared_prefs/StatsUploadService.xml
/data/data/com.google.android.gsf/shared_prefs/EventLogService.xml
/data/data/com.android.nfc3/shared_prefs/NfcServicePrefs.xml
/data/data/com.rageconsulting.android.lightflowlite/shared_prefs/com.rageconsulting.android.lightflowlite.service.LightFlowService.PREFS.xml
/data/dalvik-cache/system@app@GoogleLoginService.apk@classes.dex
/data/dalvik-cache/system@app@GoogleServicesFramework.apk@classes.dex
/data/system/registered_services
/data/backup/com.google.android.backup.BackupTransportService
/dev/socket/property_service

I'm not seeing the dialer service.

shell@android:/ # shell@android:/ # hexdump -C /mnt/.lfs/param.blk
sh: shell@android:/: not found
127|shell@android:/ # hexdump: /mnt/.lfs/param.blk: No such file or directory
sh: hexdump:: not found
127|shell@android:/ # cd /mnt
shell@android:/mnt # la
asec
obb
sdcard
secure
shell@android:/mnt #
[Hardware Hacking General] chrisrotolo:
try *#*#[android_secret_code]#*#*

PhoneUtil menu: *#*#7284#*#*

ServiceMode menu : *#*#197328640#*#*

you should notice a servicemode.apk in system/app

if the dialer codes dont work, you can always go old school and install any cut free in play store, select activity > all activities.. for a list of all available actions.

you guys are great!

Tremendous work!

thanks.
[Hardware Hacking General] E:V:A:
Ha! That look like a modified JTAG header!

Ouch, that is weird. Can you post (to pastebin) the output of:

[SIZE=2][B]HINT[/B]: type "ash" first so that you can use command completion, and thus avoid a lot of typing!
$ su
# busybox ash
# mount
# busybox ls -al /system/app/
# busybox ls -al /system/bin/
# busybox ls -al /system/xbin/
# busybox ls -al /mnt/[/SIZE]

Seem that hexdump is not included in your busybox... try to find it. Perhaps in one of the "other" toolboxes from GalaxyS hackpack? Its not really needed, as you can just use a hexeditor on your PC, after having copied the file.
[Hardware Hacking General] AdamOutler:
I got the output you wanted here: http://pastebin.com/G89SnRcg

Busybox has hexdump.. it can't find the param.blk.

shell@android:/ # hexdump -C /mnt/.lfs/param.blk
hexdump: /mnt/.lfs/param.blk: No such file or directory
ash: precmd: not found
shell@android:/ # which hexdump
/system/bin/hexdump

Also, none of the service modes are working on this i9250.
[Hardware Hacking General] E:V:A:
Suddenly I got a really creepy feeling that the Samsung Dev's are closely following what we do here. (Not a real surprise, since they rarely seem to know what they do themselves, but their silence is.) I don't recognize much in that FS anymore, as I only run GB, I guess we need to get an ICS dev in here, who knows his way around this place. BTW. Is your device a CDMA version by any chance? (Does your interior match with that of Chipworks and iFixit's teardowns?)
[Hardware Hacking General] AdamOutler:
Samsung is always watching ;)

This is an unlocked GSM version. I think this is the 'official' device. Not the carrier device.
[Hardware Hacking General] E:V:A:
Very strange that you don't have .lfs directory... Perhaps it's hidden?

So to get you on your command line feet. (See "code" edit above.)

In order to avoid an awful lot of unnecessary re-writing, all commands you don't want to write "busybox" in front of, need to be soft-linked with:

# ln [-s] <target> <filename>

(For some reason this doesn't work for me right now...) Then you need to set your file permission so that your xbin directory lists something as follows:

# busybox ls -al /system/xbin/
...
lrwxrwxrwx 1 0 0 20 Dec 15 14:55 ash -> /system/xbin/busybox
-rwsr-xr-x 1 0 2000 1075144 Dec 15 14:55 busybox
...

(Of course your path to the busybox binary must match with where you have it.) In fact, this should already have been setup by your root tool...

Can you also post the output (right after you have rebooted) of:

# dmesg >/mnt/sdcard/dmesg.log
# cat /proc/cmdline

(You need to send it to a file first or you risk overflowing your terminal buffer.) For a "live" kernel message log, you can use:

# cat /proc/kmsg

Use CTRL-C to exit.

EDIT: See if you can get anywhere with this:

[B]*#*#4636#*#*[/B]
[Hardware Hacking General] AdamOutler:
dangit... that code worked. I don't know what's going on because now SMS stopped working. I can't send any text messages. Rebooted, same thing. I don't think I made any changes, but something definately happened when I went into that last code you posted.
[Hardware Hacking General] Entropy512:
Check to see if you didn't accidentally clobber your SMSC setting... I forget where that is on stock ICS though. I know having it go poof for no reason at all was common on Touchwizz Gingerbread.
[Hardware Hacking General] AdamOutler:
That was it.. that fixed it. For some reason that field is destroyed when you enter that menu. It does not persist through entering and exiting the *#*#INFO#*#* menu. So here's the fix....

From dialer type: *#*#4636#*#*

Select "Phone Information"

In the SMSC field (for AT&T):07913121139418F0 then update, then refresh

I used CASUAL Keyboard Input script to make it easier to type... it sucks doing long hexadecimal from Android Keyboard...

You can download the CASUAL I used here: http://www.mediafire.com/?c1nd7yvoox61s39

Anyway... Back on track.
[Hardware Hacking General] E:V:A:
That's probably made to not be persistent, just so that things like you just mentioned doesn't happen. From my i9100:GB experience, you have to "back-out" in order to make changes persistent. Hit menu-button and then "back". If you just hit "exit", it doesn't save. Other changes may require reboot.
[Hardware Hacking General] E:V:A:
^^ This is great!

1) In your first "code" box in post #36, you got the output:

debug> Kernel Debugger commands:

Which seem to imply you typed something to get the Kernel Dbg cmds??

2) What does it mean: "I was able to obtain that last one by typing in 'gedit' "?

a) Which "last one" and

b) where did you type this in?

3) Would the line (from what I suppose is from the iROM) that say: "Device type: HS, DEBUG OFF", imply that there is a way to turn Debug ON (for even more debug messages)?
[Hardware Hacking General] AdamOutler:
I think thats the 'kernel' commands. It added the console prompt

For #2 i typed it in gedit and copied it, then pasted repeatedly to the terminal that way i was sending enter enter console.
[Hardware Hacking General] E:V:A:
Have you actually managed to figure out on what (serial?) device ( /dev/xxxx ) all this output is coming from?

I.e. Given that the Kernel is loading in the background, while you're in the FIQ debugger, you should be able to get a shell at the same time (by connecting through BT/WiFi or by local shell on telephone). Now assuming you have this, what device is your serial FIQ debugger located on? (You should then be able to intercept and/or inject [echo] FIQ commands on that device.)
[Hardware Hacking General] gblues:
I have a different Samsung phone, but I suspect the same process will work. But as I am new to hardware hacking, I want to make sure I understand exactly how to read the output.

Here's what I _think_ I would need to do:

1) Get a mini-USB breakout dongle.

2) Obtain a 619kOhm resistor and wire it as Adam illustrates on page 2.

3) Wire GND, TX, and RX to the matching pins on the FTDI Friend

4) Connect the breakout dongle to my phone, and connect mini-USB cable from the DTDI Friend to the PC

5) Not sure what happens here; I assume Windows loads a serial USB driver and creates a port I can access from a terminal emulator?
[Hardware Hacking General] E:V:A:
Well don't be silly! Search the proper threads for "your phone" and post your question there. It is very likely, it's been answered already! For all we know your phone may be completely different from this one and thus use completely different resistor values. Also make sure your FTDI friend is using 5V levels or you'll need to add a level shifter as well...but then again it depends on your phone. And if you have already used your FTDI device before, windows will automatically detect and install the right device driver, or you'll need to download and install it... Then you download Realterm and connect to the new serial COM port.
[Hardware Hacking General] AdamOutler:
well, I have not yet... however /proc/cmdline contains this

console=ttyFIQ0 androidboot.console=ttyFIQ0

And by default on most OMAP kernels the debug serial ports are /dev/ttyO0 (that's the Letter O and a zero), or /dev/ttyO2(that's letter O and a 2). The odd thing is that ttyO2 is missing from this device...

However this device has ttyGS0, G1, G2, G3... ttyGS3, a ttyO0, O1, O3, and ttyFIQ0

The problem is that when FIQ is active, the debug output is not displayed. In order to get the kernel messages, FIQ must be removed and a new kernel needs to be compiled. Standard UART is not possible on a stock Nexus.
[Hardware Hacking General] gblues:
Sorry I wasn't more clear--my phone is the SGH-T589 and it uses the FSA9280 chip, so I'm confident the resistor values are identical. Thanks for the info!
[Hardware Hacking General] E:V:A:
Aah, yes, that makes sense...or does it?

I'm confused. On the one hand, from my previous observations mentioned above, it seemed that debug/Kernel messages was still produced in the "the background" while you were entering the FIQ-db. But that could just be apparent. Because it would make more sense, if FIQ does indeed stop all debug output. Why? Because FIQ is a processor debug state, and thus you should halt everything apart from the FIQ debugger itself. But then we have more than one processor core, so I have no clue as to what happens in/to them while in FIQ-debugger...

Also could you clarify your statement: "Standard UART is not possible on a stock Nexus."

(What do you consider standard and why not?)
[Hardware Hacking General] AdamOutler:
Fiq debugger starts and then stops. It is worthless after 3 seconds unless you enter commands

When I say standard UART, I mean kernel/bootloader output messages and console.
[Hardware Hacking General] E:V:A:
So after having watched part of this excellent video by Mike Anderson, (PTR Group), titled: "Using OpenOCD JTAG in Android Kernel Debugging", it seem that the FIQ debugger may be part of some JTAG activation state.

He further says that for multi-core processors, the uboot debuggers never use more than one core, becuase of possible problems. However, it does not seem (to me) if this FIQ debugger is started from bootloader and thus it is still possible that all kernel have already been loaded.

http://www.youtube.com/embed/JzMj_iU4vxs

Had it not been for the missing sound in the first half of this 1:50 hr long video, and the unreadable screen shots, this could have been one of the best AOS specific JTAG introductions I have seen so far.

His presentation slides are available here.

An interesting side note from this video and some other documents I have read. Is that the JIG resistor values are indeed use to activate JTAG. If you look at block diagram, you'll see that USB_ID is connected to the JTAG port. Thus when you connect a JTAG, you can/are also change the USB_ID...to something.

Sorry, if this was a little off topic.
[Hardware Hacking General] E:V:A:
Having been Googling around for the hidden/secret menu codes for the i9250, just for fun, have not resulted in anything! Strange.

@Adam: Did you find any additional hidden codes for this device?

Soon I'll post some more general and detailed instructions on finding the hidden codes. But for your phone I'm quite confident you'll find the Samsung "Secret Codes" in either:

Phone.apk

TelephonyProvider.apk

GoogleServicesFramework.apk

ApplicationsProvider.apk

However, I noticed you have odex'ed files, so you need to either find the de-odexed files or do it yourself, if you know how to. Then you can use jed to decompile the entire apk's and eventually find all the codes. Look for java/class files called something like "ServiceModeApp" or "KeystringBroadcastReceiver"...
[Hardware Hacking General] E:V:A:
This is what I have been suggesting several times before. You should try to use a different resistor value for your jig. I think the 150K value (labelled as "UART") may help. You can also try with the 523K, 255K values, as shown in this post, and also mentioned in this thread.

In addition, as I have also mentioned before (I can't recall where), the possibility of being able to get serial console without the use of a serial converter, by using the correct USB (virtual serial over USB) drivers. I have no idea how these drivers work, but I'm convinced this should work, as both adb, OEM JTAG tracing (SWT) and "usb GSM modem" are using these (at least in windows). I have been looking at some of these (windows) drivers .inf files for a number of similar phones, and I am sure someone could just change the USB ID/VER codes to the correct ones.

For example, in some of the drivers they are named as:

"Samsung Modem Diagnostic Serial Port" (0x04E8:6601/6640)

and in yet another driver it is called:

"Samsung USB Diagnostic Serial Port Driver" (ssuderserd.inf, 0x04E8:6860)

Now that would be a really great thing, as it would eliminate all additional hardware, in order to get early console/debug output!!
[Hardware Hacking General] Rebellos:
Kurokrosk, do you have any clue why would they assign IRQ instead of FIQ to FIQ_debugger? While it's possible - it kinda breaks main assumption, as IRQs are much often unavailable than FIQs in case of kernel panics, so it becomes unusable.

According to FSA driver - 150K resistor would indeed trigger the desired mode with stock driver. As EVA stated.

It might be possible that there's serial port emulating module inside of kernel somewhere. Just for debugging purposes. But I doubt it's possible to get very early/bootloader output logs without serial converter - FSA9280 for which we got datasheet doesn't have USB interface inside like FTDI232 used in converters, it's multiplexer only. If FSA9480 doesn't differ in this case - it's not possible to get early logs without kernel USB driver, which of course fails together with kernel in case of panic or hang.
[Hardware Hacking General] Rebellos:
The thing is that whole UART driver might be put in about 40opcodes, thats 160bytes of code. USB driver with the very basic functionality fits in 2-4kb. Sending any character through UART is fully hardware handled, all software has to do is put character into certain SFR. Sending single byte through USB needs passing through at least 1-2 virtual layers, usually software FIFOs and so on. As USB is much more universal. :P So usually you won't meet USB-UART debug interface in bootloader. I think there might be such thing in kernel. But due to its complexity and RAM requirement it's not really good debugging thing - will fail in too many cases where kernel crash.

I know pretty well what FIQs are :P. The thing is that these are much less often used by kernel. When IRQ fires, other IRQs are disabled by default until that IRQ handler enables nested IRQs. If something happens before that enabling - FIQ debugger set on IRQ becomes trash. Also if something corrupts IRQ stack - same thing, FIQ debugger is unusable.
[Hardware Hacking General] kurokrosk:
Yep. I did read extensively the resources you have posted before, but could not resolve myself to try the 150k resistor. I went for the 619k resistor which had been confirmed to work. Now I am, however, pretty convinced that the 150k will work (although I won't do it, as I had quite some trouble setting up the cable already).

About early prints via USB, I am buying Rebellos explanation. Printing outputs to USB from the bootloader does not make much sense to me, as USB is so much more convoluted that the standard UART. I doubt bootloader developpers added such a functionality (print to USB) when they surely have the hardware to do with UART.

Of course, data transfer is another thing, and USB link is de facto necessary...

From what I have collected (OMAP TRM and www-riveywood-com/fiqvsirq.html):

Each ARM core has one FIQ input pin (nFIQ), and one IRQ input pin (nIRQ). Only two pins. Interrupts can come from many sources, so having two input lines is obviously not enough. So interrupts are centralized by an interrupt controller, which exposes many interrupts lines to the multiples components of the device. The interrupt controller will manage incoming IRQs, check their priority, and dispatch them to the ARM core(s). Fact is this interrupt controller (at least in OMAP4460, the GNex chip) exposes only one FIQ line which bypass all the interrupt arbitration logic, and is directly linked to nFIQ. This line can also be used as a classic IRQ line.

The FIQ mode is rarely used though. Using it would mean that we have only one very high priority source linked directly to nFIQ, which has priority over every other IRQs (that would include radio, touch screen, button, etc...).

Is making the FIQ debugger "the single very high priority interrupt source" reliable/correct/reasonable ? FIQ debugger has been designed as such, but Google/Samsung may have not intended to use it with FIQ. After all, from their point of view, FIQ debugger could have been only a quick and dirty way to get some register info or a uart console, but it is very lacking in debugging power. If there was a case where a IRQ got stuck somewhere, they have means to use JTAG.

Also, and I have not put much though in it to confirm, is such a complex piece of code like a debugger compatible with the FIQ philosophy of "make it quick and get out" ?

Another explanation is that something else may be using the FIQ line already.
[Hardware Hacking General] E:V:A:
^^ http://www.riveywood.com/fiqvsirq.html
[Hardware Hacking General] E:V:A:
Samsung is a major participant in the MIPI consortia.

See some of the MIPI documents regarding JTAG (1149.1, 1149.7, NIDnT) and the SWD (Software Dubug) interface.

"MIPI_TDWG_whitepaper_NIDnT_V1_0" (pdf)

"MIPI_TDWG_whitepaper_v3_2" (pdf)

and
[Hardware Hacking General] xd.bx:
Hi,

I tried both values (619 KOhms and 150 Kohms). Contrary to Adam, there was no difference in the bootloaders's output. The only difference was that the kernel did not recognize the 619 Kohms value for the FIQ and stopped outputting anything - whereas with the 150 Kohms it worked fine (see pid below).

I used the following parts:

http://www.sparkfun.com/products/10031 USB MicroB Plug Breakout Board

http://www.dealextreme.com/p/usb-to-uart-5-pin-cp2102-module-serial-converter-81872?item=18 USB to UART 5-Pin CP2102 Module Serial Converter

You will also need a 150 Kohms resistor and a 5 pin row header which is easy to find. Note: VCC is not connected, which is normal.
[Hardware Hacking General] Tordred:
I am trying to access UART in order to configure the GPS chip in the i9250, but I do not need to access it from the PC. A terminal app should be qsufficient. The /vendor/sirfgps.conf says that the UART of the GPS chip is directed to the ttyO0. But when I try to access and read the output of ttyO0 I only get weired characters. What parameters do I have to consider accessing the ttyO0?
[HD7 Q&A, Help & Troubleshooting] iCraft:
Hello xda community!

I recently broke the screen on my current android phone, and decided instead of replacing the screen, I would buy a new phone.

I have been researching various windows phones because I love their UI so much.

I found the HD7 on amazon for $240 refurbished, and I love the overall look and feel of the phone.

Before deciding to commit to my purchase, I came here to ask about the phone itself.

Is this phone worth it? Does it have a good dev community?

Or do you reccomend another windows phone?

Any feedback would be greatly appreciated!
[HD7 Q&A, Help & Troubleshooting] jhonny:
i think that its a very good phone.

before you buy it, just check the model number?HSPL????

if you cant install cotulla HSPL and then rom dont bother with it !

iam still waiting for HSPL... for mine, actually iam doing back to the HD2 as (looks) like all problems have been fixed,

cheers
[HD7 Q&A, Help & Troubleshooting] sh4d0w86:
i love the phone. it is my favorite purchase from 2011.

even if i could pick up the Titan or the Radar for the price i got my HD7, i would still go for the HD7.

size is right. Titan is too big, Radar is too small.

removable battery, unlike the Radar.

only three things i wished the HD7 had: physical keyboard, higher resolution screen (not yet, available, though) & newer [read: more power efficient] cpu.

also, i find the HD7 community to be larger then the other WP7 devices' communities.
[HD7 Q&A, Help & Troubleshooting] jatienza930:
i have a spare htc hd7, bought it from tmobile and its updated to mango 7.5 and is sim unlocked. im considering selling it because its a spare phone, if you are interested let me know. BTW its a great phone if you want to see if the OS is for you ^_^ tnx
[HD7 Q&A, Help & Troubleshooting] xuninc:
Get the HD7. All of the big WP7 Development just happens to be centering around the HD7 resulting in dozens of custom roms to choose from.. The kick-stand is a very small feature, but it has proven to be extremely useful.. When showing friends a video it's much easier to be able to set the phone down and watch it like a mini-tv of sorts.. If it were up to me, all future phones would have the HD7 design, the only thing I'm willing to change are the internal components, (CPU, Memory, etc)

I suggest getting the HD7.
[HD7 Q&A, Help & Troubleshooting] kkutsarov:
Hi guys i am also thinking of getting one i know how to check hspl and versions but with which one i will be to use custom roms, from what i've read so far 1. 2. 3. are flashable others 4. and 5. require downgrade if not halfbricked by now... i got really lost with all that info can anyone provide what should be a valid id of hd7 so i don't get a brick ... Thanks :)
[HD7 Q&A, Help & Troubleshooting] iCraft:
I'm interested, though I won't have money to afford it for a bit, due to me being a full time college student.

I can keep in touch though.
[HD7 Q&A, Help & Troubleshooting] laofeng80:
U really should buy a HD7 to experience the Windows Phone UI. Anyway I have to tell you it is very troublesome to costum/define the ringtunes....
[HD7 Q&A, Help & Troubleshooting] iCraft:
I don't care a whole lot about ringtones..and not sure why it would be hard to change.

Im planning to purchase this phone from Amazon for 200$ used, as soon as I acquire funds for it.

Not sure if I should spend the extra 40$ for a refurbished/new one.

Luckily this phone is T-Mobile native, and I can just pop my sim card in.

Plan on seeing me in this community soon!