yashsingh1/xdaforums huggingface dataset:
[Galaxy S II Q&A, Help & Troubleshooting] Rebellos:
Very good to read, thanks for linking me that. :)

But just to correct - AT is abit deprecated interface in SGS, SGS2 and similiar models. It can be used to control modem directly from PC (not sure if PC is really directly talking to modem or to part of Android's HALs, which is then talking to modem, for eg. USB-UART multiplexer in I9000 and S8500/S8530 is capable to switch phone MicroUSB port between AP USB/UART and CP USB/UART.

The main controlling interface used in above models is RPC through oneDRAM shared-memory area. You can find devices like "dpram", "onedram", "modemctl" in kernel - these are critical for proper working of modem. Even if RIL is using AT commands, it does send them through RPC.

AP-CP UART connection seems to be used only for early booting stage (at least in I9000 and S8500, haven't analysed I9100 but guess that's similiar)

Ad1. There may be no real ability to communicate with modem directly on SGS2 and AT responses you are getting may be from Android, working on AP only, not AMSS (Advanced Mobile Subscriber Software - RTOS working on Qualcomm's CP)

Ad4. These datasheets are most guarded secrets of manufacturers. Only single, incomplete manuals leak from Qualcomm, not really useful. Also AP-CP RPC protocol is proprietary of Samsung, they got AMSS sources from Qualcomm and they are adding their own drivers there.

Oh yes, I gave Qualcomm as example, but is CP in SGS2 Qualcomm? It wasn't QC product on SGS1 but tbh it is also very closed source.

While AP-CP low level protocol is opensource (you can find it in dpram/onedram/modemctl drivers in kernel), higher level of that layer - compiled into sec-RIL, is not.

AP-CP protocol is different between I9000 and S8500 (general concept remains the same, just it has been rewriten so packet types and structures are different), but if you are interested - we're creating opensource RIL for S8000/S8500/S8530/S8600 device series, supposed to work with Android ports for them - http://code.google.com/p/bada-modemril/ (branch experimental-MochaIPC)
[Galaxy S II Q&A, Help & Troubleshooting] solarj:
As I understand, SGS2 use intel's xmm6260 platform, which might also contain it's own interface/firmware etc.

As long as the modem works well, there is little need to dig into the details of how ril communicate with modem, but when the modem does not work as it should (In my case it refused to register on only one specific mobile operator), an AT command which can do a factory reset of the modem might be helpful
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
EDIT: 2012-02-01

Hi, thanks for deep insight! I had to read your post 5+ times to take it all in.

That the AT is deprecated is no secret, but the fact (at least according to some firmware specialists) is that it will still be a while before the OEM's can get rid of the (AT) dependence of their secret and crappy proprietary firmware, that often need to be backward compatible...

Regarding whether I'm talking to AP or CP. You are probably correct that I am talking to AP through HAL. At least from SGS2 block diagram, UART-3 is in the AP, but connected to a level-shifter in the PMIC (still on the same SoC), which is in turn connected to the BP UART-X. (I don't have a clue why this is done so.) So in any case it seem that the AT's are reaching their destination, through some abstraction layer, which may explain why I can only talk ATC's from Samsung Drivers and not from a local (phone) terminal shells.

The question is, what happens if we try to use the Bada trick, to go into ServiceMode (SM) and enable the corresponding BP access? But the SM is different on SGS and that option is not clearly available. However, there is:

MAIN MENU --> COMMON --> DIAG CONFIG
[1] LOG VIA USB *
[2] LOG VIA UART
[3] LOG VIA IPC
[4] SPEED 115200
[5] SPEED 921600 *
[6] DBG MSG OFF (toggle)
[7] RAMDUMP OFF (toggle)
[8] DUMP ALL TRACE

But these do not seem related to AP/BP connections...

[EDIT]

I found it! The selection of AP/BP connection behavior

when connecting your phone as a USB client, to a PC

host, can be manually set in the PhoneUtil (PU) menu.

This sets the behavior of your phone when connecting it

to a PC, so that you can select whether you like it to act

as a Modem or PDA, on the USB and/or UART port.

The PU menu is different from the ServiceMode menu.

Dial: *#7284#

UART:
[[B]o[/B]] MODEM[B]*[/B]
[ ] PDA
USB:
[ ] MODEM
[[B]o[/B]] PDA[B]*[/B]

* is default SGS2 setting.

However, after making the change to use USB in MODEM mode,

my host is asking for new drivers, which I cannot find... :(
​

Now, if the modem controlling interface is using RPC, how is this reflected at the OS level? Still, any Linux based kernel is device based, so there have to be a way to talk to that device. (I have no idea how to work with RPC's...)

A: There is no AMSS, since we are not using a Qualcomm BP in this device...

A: Agree, but HW hackers are often too much concerned with getting the exact datasheets. Rather try to get an old/similar one that is available... The old device drivers probably have not changed THAT much, but at least it would be a start.

Can you be more specific? (I'm starting to get lost here somewhere...)

Yes, I am. How/where can I find what these differences are?

PS. Regarding the BP on the SGS2, see my 2nd post...
[Galaxy S II Q&A, Help & Troubleshooting] Rebellos:
Doesn't matter that much at all, it's likely almost the same stuff. :P

Not hard to get lost, it took me literally few months to understand all these things. Sources are very messy - pay attention to Makefiles, some of drivers aren't even compiled in.

I9000 GB driver (it was reorganised, comparing to Froyo)

https://github.com/project-voodoo/l...erbread-samsung/drivers/misc/samsung_modemctl

I9100 driver is in I9100 kernel sources in /drivers/svnet/ and /drivers/dpram/ (maybe also somewhere else, couldn't find direct link)

You can find my implementation of SHP OneDram frames-protocol there, based on I9000 GB driver - http://code.google.com/p/bada-modemctl/ (it isn't working yet - noone tested it)

As you can see - it's only lowlevel interface of sending frames and few parsers.

Real parsers and senders of frames are in libsec-ril.so library of platform - you can open it with IDA (I suggest 6.0+, it does deal with GOT of linux DLLs much better than previous versions) and find booting modem, installing callbacks inside of dpram/modemctl, parsing and sending packets and so on. Have fun. :P
[Galaxy S II Q&A, Help & Troubleshooting] XdxH62:
I have to say I'm pretty lost on the topic already. I've read about such stuff at the replicant project a while ago. Maybe you find some useful information there.

replicant.us (can't link yet)

Looks to me like they have free ril implementations for dream, n1 and nexus S.
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Copy that! I don't even know where to begin...

But I have collected (thanks to you guys) the following very interesting links:

Available Source Code:

XGOLD-RIL (Omapzoom):

http://dev.omapzoom.org/?p=modem-int/xgold-ril.git;a=tree

Voodoo SGS-1 GB modem:

https://github.com/project-voodoo/l...ung/drivers/misc/samsung_modemctl/modem_ctl.c

https://github.com/project-voodoo/l...erbread-samsung/drivers/misc/samsung_modemctl

General...

https://github.com/GalaxySII/samsung-kernel-galaxysii

bada-modemril: Android RIL library for communication with baseband processor using Samsung OneDram.

https://code.google.com/p/bada-modemril/

bada-modemctl: Android kernel driver for communication with baseband processor using Samsung OneDram.

http://code.google.com/p/bada-modemctl/

Samsung H1 / Nexus S RIL/Modem support:

http://replicant.us/

http://trac.osuosl.org/trac/replicant/wiki

https://gitorious.org/replicant

https://gitorious.org/replicant/samsung-ril

http://github.com/morphis/libsamsung-ipc

http://ftp.osuosl.org/pub/replicant/

Nice!

http://trac.osuosl.org/trac/replicant/wiki/How_to_port_Replicant

https://github.com/morphis/libsamsung-ipc/tree/master/samsung-ipc/device/aries

Unrelated?

Android USB-to-serial: IOIO API

https://github.com/ytai/ioio/wiki

Android App: android-serialport-api

https://code.google.com/p/android-serialport-api/

Great USB GSM/3G stick hacking:

http://blogs.gnome.org/dcbw/category/drivers/

ModemManager Hmm??

https://launchpad.net/modemmanager

http://cgit.freedesktop.org/ModemManager/ModemManager/tree/README

http://cgit.freedesktop.org/ModemManager/ModemManager/tree/libqcdm/src/dm-commands.h
[Galaxy S II Q&A, Help & Troubleshooting] alextreme:
So no way to talk with the modem in Nexus S? Also if I use the REPLICANT rom?

Thanks.
[Galaxy S II Q&A, Help & Troubleshooting] PaulKocialkowski:
Oh Nexus S status is very good (actually the best). That's the device we initally created libsamsung-ipc for (before, it was for samsung H1 and wasn't called libsamsung-ipc).

State of the modem using libsamsung-ipc and samsung-ril is at: redmine.replicant.us/projects/replicant/wiki/SamsungModems

basically, we have calls, sms, network registration and much more. Data is working but it's unclean on the code and needs more work. Note that I'm the only active dev on samsung-ril, and we're 2 on libsamsung-ipc. I'm also the one who added support for galaxy s and galaxy tab devices.

So in Nexus S, you can talk with the modem very easily, using libsamsung-ipc (which is a lib, so you need to use a binary, like modemctrl that comes with libsamsung-ipc).

Also, note that the SHR GNU/Linux distribution supports Nexus S as well and uses libsamung-ipc.
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Hi Paul!

Thank you very much for your important contribution,

which really helped sort out, clarify and confirm many things!

I have just prepared a long response, but while writing it, more

fog has cleared and I will just go straight to my questions.

The rest (which is now less relevant) will be posted later as

a reference to others following this thread.

So my Questions to you at this point are:

Given the above pictures of the various abstraction layers,

how/where does the PHONET network interface fit in?

.

How does the "Samsung IPC Protocol" fit into this picture, regarding the translation and transmission of external terminal AT commands and their interpretation. [Perhaps you have link to a good/easy explanation of this protcol?]

.

How could we use this, to send ATC's from a local terminal?

I guess the ultimate reason for wanting to do this, is to be able to get closer to the radio-interface-layer, and thus be able to get access to those radio parameters, not normally available to applications via the limited Java API.

.

Alternatively, how would you propose a better way to obtain the various low-level modem variables such as the ones shown here? (Freesmartphone.org)

.

From the (poor) OMAPedia RIL-layer picture and the GT-I9100 block-diagram, it seem that there might perhaps be other channels available to communicate with the BP/Modem. (I.e. Through the UART, GPIO, McSPI?) Any ideas on how/if this could be done?

.

How could we build our own RIL(s) with minimal effort and test it?

.

For example, here is a copy of this, which is an example how to build Replicant RIL and then replace the local rild from command line to test with. Would be great to be able to do the same on the SGS2...without having to flash new ROMs.

.

How does the Replicant "libsamsung-ipc" differ from that used in the "Project-Vodoo: samsung_modemctl" ?

That was a bunch...

However, I would be happy to help contribute to Replicant if possible,

although you should keep in mind that I am not a professional

programmer in any way.

Here is the direct link to Replicant's Samsung RIL status page:

http://redmine.replicant.us/projects/replicant/wiki/SamsungModems
[Galaxy S II Q&A, Help & Troubleshooting] alextreme:
Okay but I would like to send AT Commands from Android terminal to the modem or from an APP in Android. Can I find using REPLICANT ROM the folder /dev/smd0?
[Galaxy S II Q&A, Help & Troubleshooting] AdamOutler:
I found this an interesting read. http://download.maritex.com.pl/pdfs/wi/GSM-TM2.pdf It has a lot of information in it.
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Sorry, but I just can't see how it is relevant. Did I miss something? It's just another GSM module without HW specs as usual... Thanks anyway.
[Galaxy S II Q&A, Help & Troubleshooting] AdamOutler:
It has AT command descriptions which may assist in adding more descriptions to the first page. I noticed alot of yours were incomplete, so I posted that.
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Ahh, yes. I was just updating the AT+Xzzzz sets form various sources. (The best one by far was the Google available: "AMOD HSPA Modules_AT_Command Specification".) I had to move the list to post #3. Now there are only a very few missing. The others I did not bother to re-explain/merge with the already known and "standard" ones...
[Galaxy S II Q&A, Help & Troubleshooting] PaulKocialkowski:
There are a lot of implementations of the AT set. There are official documents with all the standard commands. Take a look at wiki.openmoko.org page: Hardware:AT_Commands (links to ETSI and 3GPP documents).

---------- Post added at 09:15 PM ---------- Previous post was at 08:41 PM ----------

IIRC, there is an UART debug line that can be used to talk to the modem directly. On Nexus S, the ttyFIQ0 node was related to UART. Maybe you can route the modem to ttyFIQ0 by dealing with /sys/class/sec/uart_switch/UART_SEL/value

Important fact: note this on Galaxy S2 init.rc:

chown radio system /sys/class/sec/uart_switch/UART_SEL/value

Really try to look at that sys node and you'll perhaps succeed to get it (modem UART line) routed on ttyFIQ0 on the device.

Also, look at the FSA something component in the kernel sources: it's highly related to the UART line. It was FSA9480 on Nexus S. Look at NexusSBootloader#Serial-Console on Replicant Redmine wiki to see how we used it.

I seriously doubt there is any kind of protocol converter that converts Samsung IPC data to AT commands on this line. In my opinion the line you get is most probably the modem debug UART line.

It looks like this:

Modem <-> UART line <-> FSA9480 <-> USB <-> Host PC

|<-> kernel driver <-> RIL <-> Android framework

And the idea would be to redirect the modem uart line to ttyFIQ0. I don't know if you have to do the routing via the FSA component. I know someone who perhaps knows better about that.

---------- Post added at 09:21 PM ---------- Previous post was at 09:15 PM ----------

The logs with DataRouter are really interesting. These are not part of the RIL (I checked with strings) but there is definitely something *software* between the modem and your terminal on PC.
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Funny you should mention this. I just recently looked at the built in PhoneUtil application, as described in my post #6 . It seem that all it does is writing a "0" for "MODEM" or a "1" for "PDA" to the virtual device file: /sys/devices/virtual/sec/uart_switch/UART_SEL But this is a soft-link to the virtual device directory: /sys/devices/virtual/gpio/gpio225 . So that value probably end up in the file called "value", just as you suggested. This I could not confirm though...

However, I have no idea what is that device you refer to as "ttyFIQ0" ?? I suppose it must be Nexus S specific... There are a whole bunch of devices all over the place, and honestly I've lost track long ago as to which does what and which is virtual etc... It's a mess!

If you have an SGS-2 in your possession, you will see that there is no such "device" present. If you want to search for funky devices I also suggest having a look in:

/sys/devices/virtual/

/sys/devices/platform/

/sys/devices/platform/modemctl

Nope, because they're linked to the mysterious executable "drexe". (Which is also referenced in init.)

Also Note:

I noticed that some of the strings are in some kind of two byte format, so you may need to give the strings command the -l (L) or -b switches, in case the strings are embedded as Unicode/UTF-16 or with 16-bit endianess, and you get nothing out.

/dev/dun is also related to DataRouter...

The only UART serial lines I know are:

/dev/s3c2410_serial[0-4]

/dev/ttyS[0-4]
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
I just found to my great surprise that I already have the following tools:

ipcdump and ipctool. (Apparently they were installed with my root kit.)

Does anyone know how to use them?

ipcdump [options] [filter] [filter] ...

options:
-w <filename> : save IPC message.
-e : output for ipctool.
-i <filename> : input from a file stream.
-d <filename> : parse dpram.log or ram dump file.
-x : print hex code.
-v : verbose messages.
-h : show this screen.
filter : power,call,cdmadata,sms,sim,phonebook,display,network,sound,misc,
svc,ss,gprs,sat,cfg,imei,gps,sap,factory,omadm
(main command number is allowed as well, e.g. 1 2 3 or 0x01 0x02 0x03

ipctool [option] <hex> [hex] ...
- eg) ipctool 0c 00 00 00 02 0d 03 01 01 00 00 02
- eg) ipctool -d 0c 00 00 00 02 0d 03 01 01 00 00 02
Options:
-d : send IPC message to modem (default: ipctool->AP)
-n : number of IPC messages to wait (default: 0)
-t : timeout for each IPC message (default: 5000)
-r : request oem hook raw

I'd like to know how to form a modem IPC message, equivalent to let's say the simple "AT" command.

Or anything else that would give a some kind of decent response...and no, I didn't try the hex above,

as I don't know what it would do. I would not be happy to have a factory restore at this point,

but if someone have a phone to test on...

In addition I found this very useful tool called rilspy, but it need to be compiled, but I don't have all

that setup. So I would be very happy if someone could provide me with a binary!

Here is a very useful collection of HW hacking tools:

http://o2droid.phj.hu/trac/browser/img/beta/system/xbin?rev=38
[Galaxy S II Q&A, Help & Troubleshooting] alextreme:
I tried ipctool -d 0c 00 00 00 02 0d 03 01 01 00 00 02 and the result was only: "12 bytes sent!."

---------- Post added at 03:30 PM ---------- Previous post was at 03:05 PM ----------

I know about AT commands, someone can give me more information about IPC messages?? I have seen that comunication between vendor RIL and baseband can be realized using AT or IPC messages.

But I never heard about IPC.

Thanks.
[Galaxy S II Q&A, Help & Troubleshooting] Rebellos:
WRITE:

Writing IPC packet with ipctool (or by RIL) causes tool to use ioctl/pipe/whatever (that depends mainly on driver revision and implementation, I'm pretty sure they changed abit driver topology SGS Froyo and SGS GB for eg.) to write to modem driver (SVNET or whatever you/Samsung call it this time, they got really huge mess in names for literally everything there) that does make modem driver prepare IPC frame, locks OneDram Semaphore, write frame to AP IPC TX buffer in OneDram share (there is determined area, known for AP and CP where it should suspect new frames), then it does increment AP TX HEAD (also under hardcoded address, right before buffer) by size of just written frame, and release semaphore.

IRQ and READ:

Releasing of semaphore triggers interrupt in CP. CP does read its RX HEAD and TAIL dwords (TAIL is next to HEAD) and compare them, if values of these differs - that means there is unfetched frame in buffer. It does read frame header (usually 12 bytes - u32 magicval, u32 frametype, u32 bufferlen) and basing on bufferlen does read rest of frame data. Then it does increase TAIL by just read amount of data (headerlen+bufferlen), this way HEAD is again equal to TAIL (of course this is rechecked, because AP could write 2 frames at once). Such fetched frame goes into parser-thread's queue.

This is general concept of communication, it is the same for devices like Wave, Jet and SGS. Of course implementations and protocols does vary, more or less.

It is exactly the same for CP->AP packets, with that difference that second buffer and buffer HEAD and TAIL are used there.

Please note that AP TX = CP RX and AP RX = CP TX
[Galaxy S II Q&A, Help & Troubleshooting] PaulKocialkowski:
The IPC protocol as mentioned in ipcdump and other ipc* utils present on sgs2 concern the samsung IPC protocol, the one that is used by the modem and the IRL to communicate.

The links to "Android IPC" are irrelevant. Even though it has the same name, these are not modem-related.

We do have an (almost) complete implementation of the Samsung IPC protocol:

* the headers (all the IPC strings you noticed), along with the per-device boot and transport code are in libsamsung-ipc: github.com/morphis/libsamsung-ipc/tree/master/include

* the implementation of the RIL is done in samsung-ril, at the replicant project (see gitorious.org/replicant/samsung-ril)

Btw, if you want to chat it real time, I'm available in the replicant IRC chan, #replicant on Freenode. I could as well answer inquiries about samsung modems there (and the other people who worked on it are there too).

---------- Post added at 10:30 PM ---------- Previous post was at 10:25 PM ----------

If you want me to do so, I could largely explain any aspect of the protocol, as I have a very good knowledge of it. Note that even though transport is different between sgs2 and nexus s or galaxy s, the IPC protocol (used on the top of the transport layer) is the same (it's Samsung IPC protocol V4 as we know). It's also the same in galaxy nexus FYI.
[Galaxy S II Q&A, Help & Troubleshooting] Rebellos:
Oh yes, it's very plausible that there is 1:1 AT routing. In SHP's TAPI (telephony API) there's something called AT interface (next to NetText, Call, Network and SS interfaces), that is subgroup of IPC packets.
[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Thanks! We'd definitely appreciate any further explanation. A pictorial diagram of the protocol would indeed be extremely helpful. I could make one, unless you already have one, that I could post.

[EDIT After having waken up and re-read...and realized my former stupid response. :D ]

However,

a) What is the HW transport in our case?

b) Further, if ipctool is the right way to communicate, where is the translation from "AT" to IPC done (or from IPC to "AT")?

c) What device (and type) is ipctool using? ( I tried to find the source code of that tool, but failed... very strange! I wonder where it came from...)

In fact I managed to accidentally reboot modem by sending ipctool a copy/pasted HEX code from RIL logcat. But that is not very scientific... Perhaps you could provide some examples of a proper input strings?

Sorry, I have no idea what you're talking about... Could you be a little more pedagogical please? (This is all new stuff to me, so you have to be a little extra patient in you explanations.) Where do I find this SHP TAPI ??
[Galaxy S II Q&A, Help & Troubleshooting] Rebellos:
Translation from IPC to AT is done in CP IPC parser.

SHP is Samsung Handset Platform (I do believe that is such acronym) - something developed by Samsung since ~2000, used probably in most of their phones released through last ~10years, recently called Bada. ;)

Looks like before it has been using OS called ESAL as it's core, but Samsung Jet has been already based on Nucleus RTOS.

TAPI is set of functions exposed by drivers to SHP applications, I've got some of them identified in Jet and Wave image there http://dl.dropbox.com/u/32145655/tapi_funcs.txt

OemTapi~ does handle telephony on low level (in this case it does build and parse AP-CP packets), while applications that does provide GUI for telephony and so on can call high level TAPI functions and install handlers there. Probably Tapi~~ functions remains very the same as in early SHP releases. While OemTapi got adjusted, on single-chip solutions these were probably talking directly to RF stuff.