- Samsung android at commands
- Samsung android at commands
- Команды 3GPP AT на Samsung Galaxy: что это такое, зачем нужна?
- История АТ
- Особенности команд на смартфоне
- Коды и комбинации
- Компьютерный форум
- Работа с модемом командами AT на Android устройствах
- Работа с модемом командами AT на Android устройствах
- AT-command
- AT-command
- [A][SGS2][Serial] How to talk to the Modem with AT commands
- Breadcrumb
- Rebellos
- solarj
- Rebellos
- XdxH62
- PaulKocialkowski
Samsung android at commands
Добрый день уважаемые форумчане и разработчики!
Мучаясь над решением одной задачи, общение с 3g модемом Android планшета с помощью АТ команд, решился к Вам обратиться за помощью.
Надеюсь выйдет интересная тема и кто-то из разработчиков возьмется за создания приложения, которое, я уверен на 100 %, можно будет коммерциализировать на Плей Маркете ). Планшеты с 3G модемами очень популярны и спрос растет непомерными шагами. Модемы производители устанавливают урезанными в функционале для экономии затрат.
Имея 3g планшет (с отключенной возможностью звонков, смс, проверки остатка на счету и пр. излишек полноценного радио) я с помощью терминала в режиме SU и АТ команд пытался в чем-то успешно, в чем то безуспешно:
1. Подключиться к диагностическому порту 3g модема (/dev/ttyUSB2) и послать стартовую команду АТ — успешно
2. Отслеживать лог радиомодуля logcat — b radio — успешно
3. Получить информацию о модеме ati0 — успешно
4. Отправлять USSD команды проверки баланса AT+CUSD=1,*111#,15 — безуспешно
Поэтому хочу начать дискуссию о возможности ат команд на Android что-бы:
1. Отправлять USSD запросы (команда CUSD) — и обработка их ответов (в т.ч. стандартные заготовки — счет, перевод, пополнение ваучером, и пр. реализовать шаблонами)
2. Отправки СМС (команда CMGS) — с возмоностью хранения отправленных
3. Получение (формально чтение с якейки сим карты) СМС (команда CMGL) — с памяти сим карты, и после прочтения чтобы удалялись с катры и сохранялись локально
4. Перевод модема в режим толко 2g\ только 3g\предпочтительно 2g\ предпочтительно 3g
5. Подключаться к интернету , в т.ч. через ручные APN точки
прочее по мере дальнейшего пользование что-то еще захочеться
Я на нетбуке имею 3ж модем и к нему вотчер, даю скриншот может поможет к.л.
Сообщение отредактировал B_B — 24.12.12, 22:58
Источник
Samsung android at commands
Добрый день уважаемые форумчане и разработчики!
Мучаясь над решением одной задачи, общение с 3g модемом Android планшета с помощью АТ команд, решился к Вам обратиться за помощью.
Надеюсь выйдет интересная тема и кто-то из разработчиков возьмется за создания приложения, которое, я уверен на 100 %, можно будет коммерциализировать на Плей Маркете ). Планшеты с 3G модемами очень популярны и спрос растет непомерными шагами. Модемы производители устанавливают урезанными в функционале для экономии затрат.
Имея 3g планшет (с отключенной возможностью звонков, смс, проверки остатка на счету и пр. излишек полноценного радио) я с помощью терминала в режиме SU и АТ команд пытался в чем-то успешно, в чем то безуспешно:
1. Подключиться к диагностическому порту 3g модема (/dev/ttyUSB2) и послать стартовую команду АТ — успешно
2. Отслеживать лог радиомодуля logcat — b radio — успешно
3. Получить информацию о модеме ati0 — успешно
4. Отправлять USSD команды проверки баланса AT+CUSD=1,*111#,15 — безуспешно
Поэтому хочу начать дискуссию о возможности ат команд на Android что-бы:
1. Отправлять USSD запросы (команда CUSD) — и обработка их ответов (в т.ч. стандартные заготовки — счет, перевод, пополнение ваучером, и пр. реализовать шаблонами)
2. Отправки СМС (команда CMGS) — с возмоностью хранения отправленных
3. Получение (формально чтение с якейки сим карты) СМС (команда CMGL) — с памяти сим карты, и после прочтения чтобы удалялись с катры и сохранялись локально
4. Перевод модема в режим толко 2g\ только 3g\предпочтительно 2g\ предпочтительно 3g
5. Подключаться к интернету , в т.ч. через ручные APN точки
прочее по мере дальнейшего пользование что-то еще захочеться
Я на нетбуке имею 3ж модем и к нему вотчер, даю скриншот может поможет к.л.
Сообщение отредактировал B_B — 24.12.12, 22:58
Источник
Команды 3GPP AT на Samsung Galaxy: что это такое, зачем нужна?
Разбудить скрытые резервы мобильного устройства и использовать аппаратную начинку можно при помощи АТ-команд, которые облегчат цифровой набор и поиск необходимой функции.
История АТ
АТ – аббревиатура английского происхождения от слова attention. Удачное решение короткого набора информации и символов текстового режима послужило стандартом для производителей. Международной ассоциацией был разработан стандарт команд, который постоянно дополняется пояснениями.
Производителям разрешено использовать собственные разработки, которые могут расширять специфические функции.
Особенности команд на смартфоне
Исследователи обнаружили в смартфонах Samsung странную проблему, которая решается. Подключенное устройство USB- кабелем к персональному компьютеру отправляет АТ-команды в заблокированном состоянии.
Воспользоваться такой ситуацией возможно только при наличии доступа к аппарату. Подключенное устройство к USB абсолютно открыто и может принудительно открыться.
Используется интерфейс для отправки произвольных АТ-команд в виде голосовых и текстовых сообщений, хотя механизм блокировки должен предотвращать ряд таких действий.
Смартфоны старых моделей более уязвимы с данной проблемой.
Существует ряд системных настроек, которые можно осуществлять таким способом. Команды могут быть как для голосовых сообщений, вызовов, так и для настроек. С их помощью можно использовать возможности предоставленных функций на смартфоне на 100%.
Коды и комбинации
Сервисные коды полезны для пользователя и предоставляют доступ к дополнительным функциям, которые в обычном режиме недоступны. Изначально разрабатывались для тестирования устройства, позже стали применять при вызове меню или для получения скрытой информации о смартфоне.
Продвинутые пользователи пользуются командами на постоянной основе. Полезные сервисные коды достаточно ввести через номеронабиратель с цифрами и знаками, которые соответствуют выбранной функции для выполнения. При вводе последнего символа меню запускается автоматически без лишних дополнительных действий.
Не следует изменять настройки самостоятельно о которых нет понятия, так как возникнет проблема потери данных и повреждения программного обеспечения.
С помощью набора определённой комбинации символов можно вызвать меню, узнать номер телефона, инженерное меню, потребление данных, состояние сети и потребление аккумулятора, инженерное меню, меню управления, режим звука, статус регистрации сети и регион.
Полезные системные команды очень удобны и могут пригодиться при использовании их с двойной осторожностью.
Источник
Компьютерный форум
Здесь решают различные задачи сообща. Присоединяйтесь!
Работа с модемом командами AT на Android устройствах
Работа с модемом командами AT на Android устройствах
Сообщение alex martin » 05 май 2017, 10:59
Здравствуйте. Кто-нибудь имел опыт в управлении модемом телефона посредством AT-команд? Читал эту статью https://habrahabr.ru/post/185012/ и не нашёл у себя в устройстве /dev/ttyACM0 или /dev/smd0 или /dev/ttyUSB0.
Вот список устройств моего телефона https://pastebin.com/HCbGdwTu
Я пробовал работать с этими устройствами ч-з интерфейс ADB:
Список из директории /dev/
crw-rw—- system system 250, 0 2017-05-02 20:39 ttyGS0
crw——- root root 250, 1 2017-05-02 20:39 ttyGS1
crw——- root root 250, 2 2017-05-02 20:39 ttyGS2
crw——- root root 250, 3 2017-05-02 20:39 ttyGS3
crw——- root root 4, 64 2017-05-02 20:39 ttyS0
crw——- root root 4, 65 2017-05-02 20:39 ttyS1
crw——- root root 4, 66 2017-05-02 20:39 ttyS2
crw——- root root 4, 67 2017-05-02 20:39 ttyS3
crw-rw—- bluetooth net_bt_stack 204, 64 2017-05-02 20:40 tt
crw-rw—- root system 204, 65 2017-05-02 20:39 ttySAC1
crw——- root root 204, 66 2017-05-02 20:39 ttySAC2
crw——- root root 204, 67 2017-05-02 20:39 ttySAC3
но не одно из них не ответило на команду «AT».
AT-command
Сообщение DesignerMix » 05 май 2017, 11:12
AT-command
Сообщение alex martin » 05 май 2017, 14:31
При попытке переименовать любое из них и последующем перезапуске rild у меня пропадает сеть. Возможно я ошибаюсь, но вероятно одно из этих устройств является интерфейсом для работы с AT-командами.
Далее я попробовал приконнектиться к каждому из устройств с попытками отправки тестовой «АТ» команды:
1|[email protected]:/dev # busybox microcom -t 500 /dev/umts_boot0
microcom: can’t tcsetattr for /dev/umts_boot0: Invalid argument
1|[email protected]:/dev # busybox microcom -t 500 /dev/umts_ipc0
microcom: can’t tcsetattr for /dev/umts_ipc0: Invalid argument
1|[email protected]:/dev # busybox microcom -t 500 /dev/umts_rfs0
microcom: can’t tcsetattr for /dev/umts_rfs0: Invalid argument
Но как видно безуспешно.
Далее я решил посмотреть, с какими ресурсами вообще работает rild
130|[email protected]:/dev # busybox lsof | grep /rild
12853 /system/bin/rild /dev/null
12853 /system/bin/rild /dev/null
12853 /system/bin/rild /dev/null
12853 /system/bin/rild pipe:[57388]
12853 /system/bin/rild pipe:[57388]
12853 /system/bin/rild /dev/log/main
12853 /system/bin/rild /dev/log/radio
12853 /system/bin/rild /dev/log/events
12853 /system/bin/rild /dev/log/system
12853 /system/bin/rild /dev/__properties__
12853 /system/bin/rild /dev/log/main
12853 /system/bin/rild socket:[57061]
12853 /system/bin/rild socket:[57064]
12853 /system/bin/rild /dev/log/radio
12853 /system/bin/rild /dev/log/events
12853 /system/bin/rild /dev/log/system
12853 /system/bin/rild pipe:[57067]
12853 /system/bin/rild pipe:[57067]
12853 /system/bin/rild pipe:[57068]
12853 /system/bin/rild pipe:[57068]
12853 /system/bin/rild pipe:[57073]
12853 /system/bin/rild pipe:[57073]
12853 /system/bin/rild pipe:[57074]
12853 /system/bin/rild pipe:[57074]
12853 /system/bin/rild /dev/alarm
12853 /system/bin/rild /dev/umts_ipc0
12853 /system/bin/rild socket:[57086]
12853 /system/bin/rild /dev/umts_rfs0
12853 /system/bin/rild pipe:[57455]
12853 /system/bin/rild pipe:[57455]
12853 /system/bin/rild socket:[57456]
12853 /system/bin/rild socket:[57459]
12853 /system/bin/rild /sys/power/wake_lock
12853 /system/bin/rild /sys/power/wake_unlock
12853 /system/bin/rild /dev/binder
12853 /system/bin/rild socket:[57468]
12853 /system/bin/rild socket:[57173]
12853 /system/bin/rild socket:[57560]
Я не силен в линуксе, но возможно ли что демон взаимодействует с модемом не с помощью устройства в /dev/ а посредством сокетов или пайпов? У кого-нибкдь есть идеи как это проверить?
Отправлено спустя 22 минуты 43 секунды:
DesignerMix, опишите пожалуйста чуть подробнее процесс поиска устройства модема на вашем телефоне
Источник
[A][SGS2][Serial] How to talk to the Modem with AT commands
Breadcrumb
Inactive Recognized Developer
This is a LIVE guide to communicating with your phones modem by AT commands. The information contained here is collected on a continuous basis from various places after having some trouble finding all relevant information in one place. Now this place is here, and if not please post a comment on what’s missing and where to find it, if you do know.
All results in this guide have been obtained using a Samsung Galaxy S2 running a stock rooted GB 2.3.4 with PDA:XWKI4 and PHONE:XXKI1 on the 2.6.35.7 Kernel.
The key documents to have as a reference when working with the Android AT command set are found at the 3GPP site. In particular these 2 documents:
[1] The ETSI GSM 07.07 (3GPP TS 27.007) specifies AT style
commands for controlling a GSM phone or modem.
[2] The ETSI GSM 07.05 (3GPP TS 27.005) specifies AT style
commands for managing the SMS feature of GSM.
These documents exists in many different versions, so they are not all equal in content. Make sure to check what document version you are using.
To better understand mobile phone modems and the underlying hardware I strongly recommend reading Harald Welte’s «Anatomy of contemporary GSM cellphone hardware» [3] and Telica’s «Challenges in integrating modems on Open Platforms» [4]. To summarize enormously, I can say this. On a modern Android based «smart phone», there are essentially two processors. The Application Processor (AP) where your Android operating system (AOS) and user interface (UI) lives, and the Baseband/Cellular Processor (BP/CP) where all the GSM and other high-tech communication magic happens, including the modem we wish to communicate with. In the most modern phones the BP and the AP and all possible other peripheral devices are integrated into one piece of hardware, loosely known as a Smartphone or System on a Chip (SoC). On this SoC there are a number of peripheral devices such as RTC, UARTs, SPI, I2C, USB ports, SD/MMC card controllers and an ISO7816 SIM card reader. However, to preserve the layered hardware structure, the AP and BP still communicates via UART (serial line), USB, SPI or through shared RAM and/or a combination of these. Therefore there will always be some path directly accessible from the outside that we should be able to use to communicate directly with the BP. Exactly how this is done, is mostly unknown due to the closed source and protectionisitc nature of the SoC manufacturers, to the great dismay of the developer community.
Although there are several methods for invoking and controlling modem services, the two most common are through the AT Commands (ATC) and/or through Remote Procedural Calls (RPC). The ATC method is by far the most popular and the ATC set can be categorized as follows.
The AOS provide support for this framwork in the Radio Interface Layer (RIL), which acts as the interface between the radio HW and the Java Applicaiton Programming Interface (API). However, the RIL is divided into 3 parts or layers if you want. (These are just arbitrary, and not GSM layers!)
L3. The Java RIL (AOS API) accessible to all but with a limited set of commands.
L2. The RIL Daemon (RILJ) acting as an interface between AOS and the Vendor RIL.
L1. The Vendor RIL, which is a closed-source and HW-specific implemetation.
L0. The OEM/Vendor modem HW and firmware then acts on the L1 ATC’s. (?)
Thus the job of the RIL is to translate all the telephony requests from the Android telephony framework and map them to the corresponding AT commands to the modem, and back again.
Here are two useful pictures that try to explain the various RIL layers.
Finding the correct serial device for the phone modem
In your phone you will find hundreds of devices listed under /dev. Knowing which one is the serial device(s) used for communicating with your Baseband Processor’s (BP) Modem, is key in getting a useful AT communication going. Here it is also good to know that there are several serial devices connected to the BP. These connections are working in parallel through a MUX. So it is very likely you will be able to use several different devices to send AT commands with.
So how do we find an appropriate local serial device on the phone? One way is of course to try to connect via some terminal application to all devices and send some AT commands and look for a response, but that is not very scientific or practical. Different phones may use different default (Modem) serial devices. One way to find the serial devices is by listing available tty drivers.
So what are these doing and which one should we try?
After Googling around we suspect that:
rfcomm = Used by Bluetooth serial devices
ttySAC = Used by serial SAmsung Console
g_serial = «DataRouter» (also see dun: (10,123) )
In addition and thanks to the documentation in Adam Outler’s info package [5], it can be inferred from the block diagram that perhaps:
(PMIC = Power Management IC)
The block diagram is this one, from the SGS-2 service manual.
Connecting using: a local terminal application or the ADB shell
So from our previous results, we would suspect that we could use /dev/ttyGS0. Since Busybox contain the microcom terminal program, we can simply do:
However, although the connection is successful, there is no AT reaction on that line.
[ EDIT ] (See notes in a later post.)
If you are using Windows, you can go into Device Manager (DM) to find the correct port(s) used by your phone. However, depending on whether you set your phone to be used as a «USB mass storage» device or not, there may appear different devices in the DM. Here we assume that we just physically connect the phone and do nothing more. I.e. We’re not using the device as a USB storage.
Next, under the device class listed as «Modems», you will probably find at least two modem devices. For example, I have one called «HDAUDIO Soft Data Fax Modem with SmartCP«, which has nothing to do with Samsung and most likely came with the computer with some bloatware. The other one is called «SAMSUNG Mobile USB Modem«, which is what we want. Then right-click to open Properties of the USB Modem device and navigate to the «Diagnostics» tab. Click on the «Query Modem» to send some test AT commands to your modem. If this doesn’t work, you have a problem, and I don’t have an answer. The result should look something like this:
See below for an explanation of these commands.
Now try this yourself with some terminal application. My personal favorite is the free and fully feature loaded «RealTerm«. In the Display tab, use ANSI and check the «newLine mode» box, then in the Port tab, find your port as listed in Device Manager. For example, for me the modem port is located on COM port 12. This is listed as «12=\ssudmdm0000» in RealTerm.
Connecting using: Cygwin (on Windows)
First thing to know about using Cygwin, is that the windows COMn ports are addressed as /dev/ttyS[n-1], thus if you have connected your phone with a USB cable, and you find it is connected to COM port 12, then it will be accessible only through /dev/ttyS11 under Cygwin. Other terminal applications may use different ports. In addition you need to have installed/compiled some terminal program like: picocom, microcom or cu etc. Also make sure the COM port is not already occupied by another terminal program.
This works as expected.
Some basic AT command structure
I’m not going to say much about the AT commands themselves, as they are almost as old as home computers themselves. However, let’s have a brief look at the «Modem Query» above.
NOTE: AT commands can be concatenated on one line with each line starting with AT, and each command separated by «;». In some cases the semicolon is not needed. Typically a command without «=» or «?» is a general command, that sets or gets some parameters. But any command with «=» is a setting command, unless it is directly followed by «?», in which case you are querying the available/allowed parameters and their range. If the command is followed by «?» without a «=» it is a query, asking the values for something.
DO NOT SEND RANDOM COMMANDS/CHARACTERS TO YOUR PHONE MODEM
Many AT commands can easily wipe or brick your phone or SIM card!
I am in no way responsible for anyone bricking their phones, and
I cannot help you if you do so. So you better know exactly what you
send before you send anything at all.
General AT command list extracted from 3GPP TS 27.007
Here is a list with general AT commands and a brief description of their functions and the document section they are found at. The document version I used for the info extraction is shown on the first line.
Note: Several of these commands are deprecated or simply not available on the Android/Samsung phone modems, at least not int he form shown in that document.
Questions and Help Needed
Q1: What is the correct device on the SGS2, for ATC communication to the modem?
Q2: How and where is this device selected/configured?
Q3: What do the various Proprietary AT commands (AT+X. ) do?
Q4: Where can I find more documentation on the BP/CP?
Keywords: AT Commands, Modem, Terminal, CDC-ACM, RIL, Serial, UART
If you like this work, please hit the thank you button!
Inactive Recognized Developer
The GT-I9100 Baseband Processor (BP/CP) Specifications
Currently I have got two different specifications regarding what BP is used in the SGS2, most likely due to the different versions available of the SGS2 in Europe vs. USA. The ones I have are:
- Intel/InfineonXMM6260 is the «platform» that consists of:
a) The X-GOLD 626 (ARM1176?, 40nm) baseband processor
b) The SMARTi UE2 RF-transceiver (65nm CMOS)
c) The 3GPP Release 7 HSPA+ protocol stack with:
Downlink: Category 14, Uplink: Category 7
d) Alternative Names*: Infineon IFX6260 = Intel IMC6260 = Intel XMM6260
e) Picture: http://www.infineon.com/export/sites/default/media/press/Image/press_photo/X-GOLD626.jpg
f) Datasheet: N/A
g) Most likely used in European phones
h) is apparently also present in the iPhone 4S.. (check!)
i) Closest available documentation:
- XMM6160 (X-GOLD 616, ARM1176) which is also used in the SGS-1:
http://www.infineon.com/dgdl/X-GOLD. f0004&fileId=db3a30431ed1d7b2011f5bee88ef75eb
The biggest difference is in the SMARTi-UE RF-chip. BP remains similar.
a) BP: ARM926EJS @ 192 MHz
b) + QDSP @ 96 MHz (also on BP)
c) Modem: IS-95 A/B, 1X Rel.0, EVDOr0, EVDOrA
d) is apparently also present in the «Verizon Wireless USB760 Modem»
e) Picture: N/A
f) Datasheet: N/A
g) Most likely used in North American (US) phones (CDMA)
*It should be noted that Infineon Technologies (Wireless Division) has been acquired by Intel Mobile Communications, in early 2011.
In fact these two differences just made a whole lot of sense from the available AT command sets. Basically the modem specific AT commands immediately give up the manufacturer of the modem firmware. (Yes, competing OEM developers do work together!) Because the command sets usually consists of 3 types.
- The old school «Hayes» AT standard given by ETSI GSM 07.07.
- Vendor Proprietary AT commands, specific for each OEM.
- Carrier Proprietary AT commands, specific to some service providers. (E.g. AT&T, Sprint, T-mobile, Verizon etc.)
So for our 2 modem cases above we have the obvious Proprietary AT extensions:
Here is the FBGA pin-out of that chip:
Fig.4.
A small addendum about the SMARTi UE2 chip
The BP is communicating with the RF-tranceiver chip called SMARTi UE2
(labelled «5712«), using a communication interface that corresponds to
the (MIPI) DigRF 3G (V.3.09) standard. Through this protocol the BP
(or other device) can also control some aspects of the RF to some
minor extent. But without the proper specifications of the 5712, it
may also contain other interfaces.
The DigRF connections:
Fig.5.
The SMARTi UE2 chip:
Fig.6.
Here are more link for the interested reader:
Inactive Recognized Developer
Complete AT command list for Samsung Galaxy S2 (GB 2.3.4, KI4)
These were obtained by sending the «list all available AT commands» request: AT+CLAC .
Their functions have been collected from many different sources, none of which originates
from Samsung. Thus many ATC’s are marked with one or more «?» to signify the uncertainty.
The standard AT set as shown in the OP, I have not bothered to describe here.
As you can see there are quite a few OEM commands here, whose functions I have not been able to
figure out yet. Please post if you know anything or have any documentation on these. They all
start with: AT+X . There are also others that, that are not documented at all, AFAIK.
[2012-02-05]
On this list, the most interesting ATC’s for our purposes are AT+XSIO and AT+XTRACE as described here:
Additional hidden AT commands on the SGS-2
Runing strings on the stock /system/bin/drexe , you will find the following AT commands embedded.
These are probably not directly supported by Modem, but rather interpreted by drexe, as
they’re not present in the +CLAC list. In addition, some of them just don’t work and maybe only
provided for backward compatibility for other devices and modems.
Rebellos
Senior Recognized Developer
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)
solarj
Member
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
Inactive Recognized Developer
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:
[ 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.
* 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.
Rebellos
Senior Recognized Developer
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?
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.
XdxH62
Member
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.
Inactive Recognized Developer
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:
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/
PaulKocialkowski
New member
I am the Replicant developer who worked on Nexus S port and also did the work on aries (galaxy s, galaxy tab) devices and wrote a big part of the free RIL.
Replicant is a fully free Android derivate running on some devices (mostly Google phones).
If you have any question regarding samsung modems in Android phones, i’d be happy to answer them!
I’ll attach the mail I sent back to E:V:A next
———- Post added at 08:27 PM ———- Previous post was at 08:22 PM ———-
Modems on Android devices is a wide domain.
Phones differ on many things, like:
* modem chipset
* modem firmware
* transport modem AP
* modem protocol
* user-space integration (Android RIL)
First thing is the modem chipset. There are quite a few. For instance on
HTC phones, you’ll have the ones included in the MSM or QSD SoCs (which
is quite unusual, modems aren’t often part of the SoC) IIRC.
On other devices, it’ll be a separate chip connected to the SoC via
various transport methods.
I know better the case of recent Samsung phones, like Nexus S, Galaxy S,
Galaxy Tab (first gen), Galaxy S2, etc.
There, you have the modem, usually an intel x-gold 6xx, that is wired to
the SoC. So transport is done via serial line and/or some dedicated RAM
memory (not from the main sticks).
Even though a phone can have the same modem wired (at hardware level)
the same way, the kernel drivers can be different. That’s the case of
nexus s and galaxy s. On the first one, modem Rx/Tx with AP is done via
ioctls while on galaxy s it’s done via a PHONET network interface
(svnet0). SO it’s not (and particularly on Samsung phones) only a serial
interface you can open with screen: you need to understand how it’s done
and write dedicated software to reproduce this (cf. the code on
libsamsung-ipc/devices/ that is device-specific).
So once you have transport set up, you need to know about the protocol
the modem speaks. This depends on the firmware the modem is running.
I know that the modem used in Nexus S is also used in some iPhone (4G
IIRC) but it has a different firmware and so speaks a different
protocol. I suspect it to be AT on the iPhone while Nexus S speaks a
samsung-specific modem protocol. They invented that protocol and
rewritten the modem firmware to use it instead of AT or anything else.
This protocol is usually called «Samsung IPC Protocol» and we have a
free implementation of it in libsamsung-ipc and samsung-ril.
On the Nokia N900, transport is also a PHONET socket and the protocol is
neither AT nor Samsung IPC but some protocol made by nokia and
implemented in ofono.
So you have exemples of different transport methods and modem protocols.
I could give you more exemples.
Of course, on Android, you need to have the user-space programs (the RIL
mainly) to match both the transport scheme and the modem protocol to
have anything working.
> Please have a look at our XDA-forum thread:
>
> «How to talk to the Modem with AT commands»:
> http://forum.xda-developers.com/showthread.php?t=1471241
Apparently you were able to contact the modem with some AT commands.
Either the modem has an AT mode that can run along with IPC (would
surprise me, but why not), but it may very well be uncompleted and is
anyway not used at all in official binaries, either this is Android
emulating and AT device while sending back stuff from and to the RIL,
either this is not the modem.
Anyway I can tell you for sure that this is absolutely not the way to
talk to the modem properly. The correct way is to use the IPC protocol
and appropriate transport handling (which is way more complex than only
opening a serial line).
I just started the work on galaxy s2, I’ll soon have done the transport
layer and we already know the protocol.
Источник