yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] dexter35803:
if there HiddenMenu.apk is in the system app folder it should but even then there are dependencies that have to be accounted for in order for it to work your best shot is to be stock or find a way to boot stock to access diag make ur changes then nandroid back to JB or reboot to it if we can dual boot
[Verizon Samsung Galaxy S III] xd.bx:
I may be wrong, but from the "let's sue the planet" JTAG datasheet leak, Qualcomm's management would rather eat rusty nails than provide ANY information whatsoever to anyone who is not a Chinese OEM.

---------- Post added 9th August 2012 at 12:01 AM ---------- Previous post was 8th August 2012 at 11:55 PM ----------

Nice work. Maybe there's a juicy integer overflow in the code that handles this struct?
[Verizon Samsung Galaxy S III] AtLemacks:
This is more of a question than anything. Could shorting out or jumping any of the exposed contacts in the back result in anything similar to the "s-off" capability of HTC devices? Or for that matter, any other contacts that aren't directly exposed by the chassis? I mean, there must be some sort of manual way for an OEM to refurb the device, no?
[Verizon Samsung Galaxy S III] LLStarks:
We won't know until we examine the chip diagrams in the service manual.
[Verizon Samsung Galaxy S III] KennyG123:
Thread cleaned

Stay on topic

Read this:

http://xdaforums.com/showthread.php?t=1822819

Thanks

FNM
[Verizon Samsung Galaxy S III] AtLemacks:
So, short of having a dozen dummy devices to try each combination we need to find the manual? I find it hard to believe that these big companies are so secure that they are able to keep all of their employees quite, as well as all their internal documentation so secure. I will go on a digging spree and see what I can find.
[Verizon Samsung Galaxy S III] LLStarks:
We have the service manual

<_<
[Verizon Samsung Galaxy S III] AtLemacks:
I thought we only have the MSM7xxx manual.
[Verizon Samsung Galaxy S III] LLStarks:
We have a mostly complete SCH-I535 service manual.

I'm not sure if I can post it.
[Verizon Samsung Galaxy S III] AdamOutler:
Apparently alot of websites are following this work. Do not post about this thread on any website which is predominately noobs who can't even use windows. I just took down the original link to the CASUAL I released a couple of pages ago. In hindsight, it may have been a bad idea... An article on droid life linked directly to it and it had 800 downloads in a single day... Anyway.. Link deleted. Please keep it on topic.

See my original CASUAL post: http://xdaforums.com/showpost.php?p=29907190&postcount=162 I can keep this up until the noobs lose interest.

Here is a new CASUAL with additional hacks and scripts. Don't complain to me that it doesn't work on windows.. I don't care. I don't use windows. Be happy IF it works on windows. I'm not supporting your drivers.

This CASUAL package contains:

Root with DebugFSRoot

Install CWM Recovery

Reboot into Download/Recovery modes

Flash Stock Kernel/Recovery

Unroot device

Enable hidden menus

Show PhoneUtil

Still to come: Additional tools, Install less secure bootloaders, additional hacks

Images

Windows:

Linux:

Releases:

7July12 Initial release

8July12 Fixed problem with Windows displaying nothing.

8July12 Added tools

http://www.mediafire.com/?0zfl8hlbyjy1ffu

Download Verizon GS3 CASUAL

http://www.mediafire.com/?0zfl8hlbyjy1ffuj

I will release this in a new thread soon.
[Verizon Samsung Galaxy S III] NotATreoFan:
Perhaps it may be best to give this it's own thread. I can move this post, if you want.
[Verizon Samsung Galaxy S III] AtLemacks:
'

No biggie, you can PM me it to me if that is kosher with everyone. I have some experience in digital electronic circuitry. I have my Rezound still I could always go back to while I poke around.

I actually was doing my typical Google search today for keywords on topics I mentally "subscribe" to and one in fact was about the GS3 bootloader. Overwhelming number of results featured your name.
[Verizon Samsung Galaxy S III] LLStarks:
There was also a dedicated MSM8960 manual just sitting in a HTC One X thread since June. This is separate from the I535 manual that popped up today.

XDA is so silly at times.
[Verizon Samsung Galaxy S III] AtLemacks:
I'm going on vacation Thursday until Sunday so I'll dive in Sunday night. I'm surprised I missed the manual as I had a one x for a month, lol.
[Verizon Samsung Galaxy S III] NegativeOne:
Is this the manual? On phone now, so I can't get the tar...
[Verizon Samsung Galaxy S III] pyrostic:
No the manual won't be released here due to the "leaker" required sting us not to. If you need it you'll figure out how to find it.

I am, however, curious as to what this sextape leak might have in it.
[Verizon Samsung Galaxy S III] OldManJames:
This post has a whole bunch of pdfs that could be helpful including the 8960 schematic that LLStarks was referencing.
[Verizon Samsung Galaxy S III] LLStarks:
There are 2 more documents floating around.

I think they have what we need in the boot department.
[Verizon Samsung Galaxy S III] pyrostic:
Are they still floating or do we have them?
[Verizon Samsung Galaxy S III] LLStarks:
I posit that they are in the right hands :)
[Verizon Samsung Galaxy S III] AdamOutler:
important stuff.. download now.

Boot guide http://www.rd211.com/docu/78897.html.

Service manual http://stadium.weblogsinc.com/engadget/files/EN_LG-VS930_SVC_ENG_120704.pdf

Service manual http://www.mediafire.com/view/?81e7t2y1ttysc8f

Hope I don't get anyone in trouble.
[Verizon Samsung Galaxy S III] LLStarks:
Fixed link for the SCH-I535 service manual: http://d-h.st/LA5

Also, I managed to flash the LG1 kernel to my phone using the entire 1.2 GB LG1 flash.

COMBINATION_I535VRALG1_I535VZWALG1_743127_REV09_user_low_ship.tar.md5

Edit: Rehosts of the other files

http://d-h.st/cIv

http://d-h.st/xJ9
[Verizon Samsung Galaxy S III] E:V:A:
Damn! This place is really exploding with new fun and juicy info.

This will be the first of a few posts collecting what we (you?) need.

First thing of, let me help you locate the boot pins on your

Qualcomm Snapdragon S4 Plus (aka. MSM8960) that is running

the show in your SCH-I535.

In the schematic diagram below we see how these are connected on the MSM8960

that is labelled "UCP700-1". The reason there is a "-1" added to the label,

is that this is a PoP (Package-on-a-Package) located directly under the 16GB

LPDDR2 DRAM memory labelled as "UCP700UP" and is a Samsung part known as:

"K3PE0E000A-XG(2)" in this document.

So for the SCH-I535 we have:

[SIZE=2]-------------------------------------------------------------------------------
pad gpio name connection boot Rxxx
-------------------------------------------------------------------------------
AH32 119 BOOT_FROM_ROM ANT_SW_SEL0
AH33 118 BOOT_CONFIG_0 ANT_SW_SEL1 * R745
AM31 117 BOOT_CONFIG_1 ANT_SW_SEL2 * R746
AM30 116 BOOT_CONFIG_2 ANT_SW_SEL3
AN30 115 BOOT_CONFIG_3 BC0_SW_SEL0
AM29 114 BOOT_CONFIG_4 BC0_SW_SEL1
AN29 113 BOOT_CONFIG_5 BC1_SW_SEL0
[COLOR=Red]AK28 112 BOOT_CONFIG_6 ANT_SW_SEL4 * R747[/COLOR]
C30 - RESOUT_N MSM_RESOUT_N
-------------------------------------------------------------------------------
* ANT_SW_SEL[1,2,4] == BOOT_CONFIG_[0,1,6] are kept high through
R = [R745, R746, R747] via Q700 when MSM_RESOUT_N in high (???).
-------------------------------------------------------------------------------
R 2007-008516 R-CHIP;10Kohm,5%,1/20W,TP,0603 ERJ1GEJ103C
Q700 0505-002341 FET-SILICON;Si1013X-T1-GE3,P,-20V,-400mA SI1013X-T1-GE3
UCP700 1205-004465 <Snapdragon S4 Plus> MSM8960
UCP700UP 1105-002388 <16 GB DRAM> K3PE0E000A-XGC2
-------------------------------------------------------------------------------
[/SIZE]

The General Boot Function Table is:

[SIZE=2]------------------------------------------------------------------
[B]c1[/B][/SIZE] [SIZE=2] [B]c0[/B] function
------------------------------------------------------------------
0 0 Emergency Boot from SDC3 (SD) followed by USB-HS
0 1 SDC3 followed by SDC1 (eMMC)
1 0 SDC3 followed by SDC2 (not used?)
1 1 SDC1 (eMMC)
------------------------------------------------------------------
[B]c6[/B][/SIZE] [SIZE=2] 0 - Secure Boot
1 - Fast Boot
------------------------------------------------------------------[/SIZE]

So here we can see that when the Dragon is reset by a high on MSM_RESOUT_N,

BOOT_CONFIG_0,1,6 are also pulled high, so that we have: c0:c1:c6 = 111,

which means Fast Boot from the eMMC (SDC1).

(Contrary to what was mentioned before? Correct me if I'm wrong.)

EDIT (2012-08-12): ---

Apparently this behavior have not been resolved, since there are arguments

saying that MSM_RESOUT_N is using inverted logic ("_N"). This also seem

supported by the emergency download USB device appearing after soft-bricking.

(See post #271.)

If this is true, then c0:c1:c6 = 000.

------

Here is the location of these components on the PCB.

...

So the next step is; how can we determine the Qfuse settings?
[Verizon Samsung Galaxy S III] AdamOutler:
Great work E:V:A. Has anyone found a processor pin-out diagram? I need to sit down and go through those schematics when I get a chance.

Ah ha.. Found it at the end of the service manual.. http://d-h.st/LA5

If someone can, rehost those files I posted earlier on dev-host.. I can't access any of them from work and I can't send an email that large to my work.. So that leaves me with the option of viewing them on my phone.
[Verizon Samsung Galaxy S III] E:V:A:
Here is the MSM8960 BGA pin map showing the BOOT_CONFIG_x pads.
[Verizon Samsung Galaxy S III] AdamOutler:
Great work as usual EVA. Can you get a higher Res version?

As hackers, we can't work with the pins themselves, so that map needs to be flipped either horizontally or vertically before it can be laid on top of a processor for overlay pin mapping
[Verizon Samsung Galaxy S III] LLStarks:
(Adam, I mirrored the files in my previous post)

I'm a little confused on how the Qfuses work and the overall terminology used to described them. Are they one-way deal? How does our situation now compare to Motorola and their use of Efuses?
[Verizon Samsung Galaxy S III] M4gicM@:
If the gate and source are connected as somewhat appears, it is called a diode connected mosfet and is excellent at modifying current however that would not be very useful because it would just be off all the time. I think the gate and source are separate but a simple multiplier test can confirm. The _N means active low so when MSM_RESOUT_N is pulled low the three lines are pulled high through a 10k. As I stated earlier though qualcomm has BOOT_CONFIG_6 internally pulled low so it is odd they pull it high through a resistor instead on directly to VDD. This tell me it is a very weak pull-down internally.

I will reiterate that the internal fuse for secure boot is blown since the schematic indicates we should boot in fast boot but we do not. However if the schematic is to be believed perhaps the gate is tied to the source meaning that all three pins are floating (except for BOOT_CONFIG_6 which is pulled down internally). This would produce secure boot even though the qfuse may not be blown! this also produces 00 for the boot mode which is emergency which is not what is happening so maybe those fuses are blown internally as well.

By the way I had some of this info a few posts back but i guess you didn't catch it :)
[Verizon Samsung Galaxy S III] AdamOutler:
There's two things to keep in mind here...

1. Samsung has always used resistors between any voltage or ground source and the processor.

2. The new generation of devices which Samsung is putting out encorperate a sort of UnBrickable Mod(ish) design. You insert an SDCard, then short a resistor from one side to the other which causes the device to boot from SDCard. The device is not a dual-boot development board as in UnBrickable Mod, but it is a temporary hardware method of altering the boot mode.

You are basing your information on the fuse being blown based on shematics. I've proven Samsung schematics wrong several times in the past. We will verify that. Also, these boot modes are important because we want to come up with a bootloader recovery.

Has anyone found the memory location of the BOOT_CONFIG register set? Testing should be real easy if someone can find that memory address.
[Verizon Samsung Galaxy S III] E:V:A:
Unfortunately not, since I don't have that document. (As you can barely see from the watermark, it's from the MSM8960 TRM, which I don't have.) I don't see how this flipping is gonna help you in this case?

Has this been confirmed?

I saw your post, and that's why I wrote what I did. But how can I edit my post #212 so not to mislead anyone? (I admit to be a bit rusty on the EE details.)
[Verizon Samsung Galaxy S III] M4gicM@:
All very true! I was just pointing out what appears to be fact based on information thus far. As soon as we read the fuse registers it will put to rest any of my theories. How would we even go about finding these fuse settings. We know they are mapped to a shadow register do you think they would then be accessed via an mcr arm command?

Did the Samsung models that used the unbrickablemodish design also have qualcomms and have their boot mode select fuses blown? Where were the fuses located on msm7xxx or other qualcomms?

I mean no disrespect to you Adam I am just trying to question all things and come up with an answer then question it again. Keep up the amazing work! I am trying to learn what I can from everyone and I hope I am not frustrating you.
[Verizon Samsung Galaxy S III] alquimista:
I know that there are 2 strings in SBL1 that refer to "boot_config.c". I believe the hex address for the string starts at 00008644.

Ralekdev is better suited to find any functions that ref those strings.

Ta,

ALQI
[Verizon Samsung Galaxy S III] Ralekdev:
That's part of a function that looks up the next image in the bootchain to load.

void __fastcall boot_config_load_entry(boot_config *config_ctx, load_config *load_cfg)
{
int (__fastcall *v4)(boot_config *); // r1@2
int v5; // r8@5
int v6; // r1@9
char *v7; // r10@15
boot_flash_dev_if *v8; // r0@16
char *loaded_by; // r1@22
char *v10; // r1@30
int v11; // r0@35
char v12; // zf@35
void (__fastcall *func_24)(boot_config *); // r1@42
int v14; // r0@44
char v15; // zf@44
void (__fastcall *func_28)(boot_config *); // r1@54
sbl_header sblhdr; // [sp+0h] [bp-48h]@17

if ( !load_cfg )
{
BL_FAIL("boot_config.c", 150, 12301);
while ( 1 )
;
}
boot_config_call_func_list(config_ctx, load_cfg->early_init_funcs);
// sometimes there's no func
v4 = load_cfg->func_test_should_start;
if ( v4 && v4(config_ctx) == 1 )
load_cfg->should_start = 0;
v5 = boot_log_get();
if ( load_cfg->should_start == 1 )
{
v6 = load_cfg->hash_type;
if ( v6 )
{
if ( v6 == 1 )
{
if ( !load_cfg->mmc_part_id )
{
BL_FAIL("boot_config.c", 216, 12301);
while ( 1 )
;
}
if ( load_cfg->use_authentication == 1 )
{
set_sbl_header_sub_2A005A50(&sblhdr);
j_boot_pbl_authenticator::sub_2A007348(config_ctx, load_cfg->software_version_id);
}
}
else if ( v6 != 2 )
{
BL_FAIL("boot_config.c", 243, 12373);
while ( 1 )
;
}
}
else
{
if ( load_cfg->partition_id == 0x1B )
{
v7 = load_cfg->mmc_part_id;
if ( !v7 )
{
BL_FAIL("boot_config.c", 185, 12334);
while ( 1 )
;
}
v8 = get_boot_flash_dev_if();
v8->field_4->set_user_parti_id_sub_2A007DF4(v7);
}
get_sbl_header_sub_2A006DFC(load_cfg->partition_id, &sblhdr);
config_ctx->load_addr = sblhdr.image_dest_ptr;
if ( load_cfg->use_authentication == 1 )
{
set_sbl_header_sub_2A005A50(&sblhdr);
j_boot_pbl_authenticator::sub_2A007348(config_ctx, load_cfg->software_version_id);
}
if ( load_cfg->load_id >= 0x1Cu )
loaded_by = image_source_unknown;
else
loaded_by = image_sources[load_cfg->load_id];
sub_2A01160C("Image Loaded by %s, Start on 0x%x\n", loaded_by, sblhdr.image_dest_ptr);
}
}
v10 = load_cfg->load_complete_string;
if ( !v10 )
{
BL_FAIL("boot_config.c", 247, 12301);
while ( 1 )
;
}
boot_log_msg(v5, v10);
// func_24 and func_28 are mutually exclusive for some reason, and sometimes neither are present
if ( load_cfg->should_call_func_24 == 1 )
{
v11 = load_cfg->should_call_func_28;
v12 = v11 == 0;
if ( !v11 )
v12 = load_cfg->should_start == 1;
if ( v12 )
{
if ( load_cfg->use_authentication != 1 )
{
BL_FAIL("boot_config.c", 259, 12373);
while ( 1 )
;
}
func_24 = load_cfg->func_field_24;
if ( !func_24 )
{
BL_FAIL("boot_config.c", 262, 12301);
while ( 1 )
;
}
func_24(config_ctx);
}
}
boot_config_call_func_list(config_ctx, load_cfg->init_funcs);
v14 = load_cfg->should_call_func_28;
v15 = v14 == 1;
if ( v14 == 1 )
v15 = load_cfg->should_call_func_24 == 0;
if ( v15 && load_cfg->should_start == 1 )
{
if ( load_cfg->use_authentication != 1 )
{
BL_FAIL("boot_config.c", 282, 12373);
while ( 1 )
;
}
func_28 = load_cfg->func_field_28;
if ( !func_28 )
{
BL_FAIL("boot_config.c", 285, 12301);
while ( 1 )
;
}
func_28(config_ctx);
}
}

This code is common to sbl1, sbl2, and sbl3
[Verizon Samsung Galaxy S III] AdamOutler:
Not at all. We are all troubleshooting this problem.

I removed BOOT_MODE_6 and booted into FACTORY MODE. The "QUALCOMM SECURE BOOT: ENABLED" message was still present. . I'm not sure which type of logic is being used nor if the schematics are correct... So, I still must apply a high and a low to the active side of the bootmode resistor.

I was wondering what the voltage was on VREG_BOOT_CONFIG, so I looked up the schematic for the Q13 NDS332P. and I found this. http://www.fairchildsemi.com/ds/ND/NDS332P.pdf

This Q13 is a P-Channel Logic Level Enhancement Mode Field Effect Transistor and states that is allows allows "direct

operation in 3V circuits".

So, I need to find a 3V source somewhere on the board to apply to BOOT_MODE_6. Then to verify the schematics, I will apply a ground to it. If "QUALCOMM SECURE BOOT:ENABLED" does not change, then we can safely assume that the E-Fuses are blown and the solution must be applied to either hardware or an alternate boot method.

Searching for a good 3V high source. Suggestions?
[Verizon Samsung Galaxy S III] AdamOutler:
E:V:A, where did you pull this table from??? From the QUALCOMM schematics, it would appear that GPIO 117,118,119 go to the same place... but we need GPIO 112.. Your picture shows 3 resistors next to each other.

GPIO_112|GRFC_31|BOOT_CONFIG_6
GPIO_113|DRX_MODE_SEL2|GRFC_30|BOOT_CONFIG_5
GPIO_114|DRX_MODE_SEL1|GRFC_29|BOOT_CONFIG_4
GPIO_115|DRX_MODE_SEL0|GRFC_28|BOOT_CONFIG_3
GPIO_116|ANT_SEL3|GRFC_27|BOOT_CONFIG_2
GPIO_117|ANT_SEL2|GRFC_26|BOOT_CONFIG_1
GPIO_118|ANT_SEL1|GRFC_25|BOOT_CONFIG_0
GPIO_119|ANT_SEL0|GRFC_24|BOOT_FROM_ROM

From the schematics I think I may be playing with BOOT_FROM_ROM.
[Verizon Samsung Galaxy S III] M4gicM@:
The schematic represents a pmos transistor so at least that is correct. Can you see if the gate and source are tied together? I bet you have a multimeter lying around :). I will look up the power part of the schematics and tell you a nice 3v place to tap. Keep in mind that you may want to connect a 10k resistor to the lines you are toying with. After boot those three lines all become outputs so be careful driving them.

{UPDATE}

I believe a better idea is to drive the lines via the 1.8v net hooked to the source of Q700 basically by doing Q700 job for it. The best thing to do would just measure the lines and use a logic analyzer on MSM_RESOUT_N to see if it indeed drops low on reset and the three boot config lines drive high. But you can also just drive em and see what happens :) as this is much faster and wont ruin anything. I do not suggest 3v as you may over drive the io drivers on the S4. I cant wait to see what you find out!
[Verizon Samsung Galaxy S III] E:V:A:
Nooo, probably a bad idea, since the MSM is 1.8V device, AFAIK...

VREG_S4_1P8 is supplied by PM8921 chip, labeled U900, and probably "1P8" = "1 point 8" volts.

Why are you looking at Q13? (And what/where is that BTW?) I said above, its Q700 which is a:

Vishay Si1013X-T1-GE3.

I made it from the I535 Service Manual, the Qualcomm Reference Design Schematics, show a difference, because of changes... Not sure which we should trust...
[Verizon Samsung Galaxy S III] AdamOutler:
You're right... I'm looking at the wrong damn manual. That other service manual keeps popping up when I'm looking to open a PDF for some reason. Thanks for making me look at it again.

Do we know what that BOOT_MODE_6 GPIO drives, or do we know the location of the register in memory?
[Verizon Samsung Galaxy S III] E:V:A:
Yes, C108:7(CTRL)? Next we need to determine the Qfuse settings. Unfortunately we can't just read

the Qfuse settings from the GPIO pins, as these are masked by shadow RAM. Normally,

to read GPIO settings we use the command:

cat /sys/kernel/debug/gpio

Please post the output of this.
[Verizon Samsung Galaxy S III] AdamOutler:
1|shell@android:/ # cat /sys/kernel/debug/gpio
/sys/kernel/debug/gpio: No such file or directory
1|shell@android:/ #

I've been exporting GPIOs to read them... I don't know if they're active high or lows by default though.
[Verizon Samsung Galaxy S III] E:V:A:
Wow! This is great, look just like the manual description of the boot procedure. But what is this? I think it is more useful if we can better explain everything we post, so that people working behind the scenes can follow. What I mean is, for example in this case:

- Why did you choose that address? (Where is it mentioned?)

- What does this memory show? Is it just strings from the bootloader code or an actual log (file?) from something else?

- Is that address to physical memory or virtual?

- What does the {nnnn} show? (Address byte offset or something else?)

- Can you separate the output (within data tags) more clearly?

Also, I think the hardware version is set by the pins:

[SIZE=2]pin gpio name
------------------------
G33 89 HW_VER_0
F33 90 HW_VER_1
F31 91 HW_VER_2
H33 94 HW_VER_3
[/SIZE]

What? That sucks. What do they use then? Try to find/list any sub-directory called "gpio"...

Can you access the modem? If you do, try to issue these AT commands, which should list the GPIO's and EBI's:

[SIZE=2]AT@EBI_CFG
AT@GPIO_IN?
AT@PMIC_LEVEL
[/SIZE]

EDIT ========================

Apparently the Huawei u8650 has an option in its Service Menu (*#*# 2846579 #*#*) to query the Qfuses in its MSM7227. We could reverse this app and see how it's done!
[Verizon Samsung Galaxy S III] AdamOutler:
Look at the first few lines of the UART output on the first page.

[ 0.000000] sec_dbg_setup: str=@0x88d90004
[ 0.000000] sec_dbg_setup: secdbg_paddr = 0x88d90004
[ 0.000000] sec_dbg_setup: secdbg_size = 0x40000
[ 0.000000] etb_buf_setup: str=@0x8fffb9c0
[ 0.000000] etb_buf_setup: secdbg_paddr = 0x8fffb9c0
[ 0.000000] etb_buf_setup: secdbg_size = 0x4000

These show where the debug logs are in memory. There is no UART log, it is done by logging to memory!

Physical. address offsets. no I cannot....

There is a directory, but there aren't too many of them. The ones we are looking for are not present. I don't know how to access the modem.

There's some intersting stuff here..

{1835398} Image Loaded by SBL3, Start on 0x88e00000
{1835429} sbl3_efs_handle_cookies, Start
{1835429} sbl3_efs_handle_cookies, End

and here.. can someone check to see if that debug level is in the PARAMS partition somewhere?

check_ramdump_mode :: k_param.debuglevel[0x574f4c44]

It looks like the boot sequence is IROM -- SBL1 -- SBL2 -- TZ -- RPM -- SBL3 -- EFS -- PARAMS -- Kernel
[Verizon Samsung Galaxy S III] E:V:A:
Great, thanks for info.

To see the modem you should be able to just connect your phone with your USB cable and then open a terminal (on your windows PC) to the appropriate COM port. Look in device manager to find the COM port... I can't do anything from here since I don't have the device!
[Verizon Samsung Galaxy S III] LLStarks:
I'm wondering if we can use Diag mode to access serial output. Querying the modem with traditional means doesn't seem to work.

http://xdaforums.com/showthread.php?t=1802024

When I putty into the serial port (COM# or /dev/ttyACM0), I get a response, but no interface.