[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
X-GOLD 626 Firmware:	Internal Command Summary

As have been shown before and mentioned many times elsewhere. The X-GOLD series ATC (AT Command) set is surprisingly wide and flexible, and extends far beyond the publicly available ETSI GSM 07.07/5 (3GPP TS 27.007/5) standard sets. One of the common ways to understand what is available for ATCs is to issue AT+CISP, which displays a long list of supported ATCs. However, this set is extremely limited and only show those ATCs that will be available to 3rd party software developers and OEMs outside the Infineon/Intel brotherhood. These all conform to a certain shared standard within the executive clan of Modem chip manufacturers. However, scratching on the surface of the X-GOLD firmware and vendor specific RIL libraries, it can be immediately inferred that there is another universe of vendor specific baseband functionality that is accessible through a hidden internal ATC set, including a complete internal API and CLI for these additional features. These are used in everything from calibrating and programming the RF-transceiver (RF-DSP), reading and writing NV-RAM parameters, setting various handset factory test modes, updating internal baseband processor (BP) boot-loaders and firmware. Essentially everything else that is needed, but not seen during regular phone operation, can be done through this interface. So let us start to explore the general structure of the various ATC's we know of to date.

[B]AT@[/B]<if_tag>:<function_calls> - Vendor API/CLI calls and programmming
[B]AT[/B]<char:[A-Za-z0-9]+> - mostly standard ATCs except for [B]l/m[/B]
[B]AT+[/B]<command> - standard + vendor ([B]+X[/B] prefixed)
[B]AT++[/B]<???> - unknown
AT$ - ?
[B]AT#[/B]<something> - Old style #'s have been moved to AT@
[B]+++[/B]; - getting out of "hash" / hex mode (??)
<general_cli_calls> - CLI

For the non-public API ATC's used in the AT@ class, we have an object oriented functional structure, reminding us slightly of JAVA/C++ code. However, without documentation, we can only get a rough approximation to the various API classes and functional calls available. These are fairly easy to obtain by looking at strings in the firmware, and subsequently infer the use from their location and related function calls, although this is only approximate and possibly erroneous. The only way to know for sure what the various function calls and parameters does, is by disassembling the functions themselves, which is not trivial, because of the large quantity of code available and the fact that the firmware image also contain code for bootloaders, RTOS, IO, encryption etc. Without an explicit BP memory map, it can be very frustrating. But let's get back on topic, finding the AT@ structure. A typical AT@ command, may look something like this:

at@nvm:cal_rf_ue2.afc_cal.default_dac_value?

This is the command to read the default DSP calibration value from NV-RAM, used as an initial value in the automatic frequency calibration (AFC) of the voltage-controlled temperature-compensated crystal oscillator (VCTCXO). From this we can make an initial guess of the syntax structure using some pseudo-tags:

at@<api-class>:<api-protocol>.<api-function>.<api-variable><query/setting>

where:

<api-class> = nvm = NV-RAM operation
<api-protocol> = cal_rf_ue2 = SMARTi-UE2 RF-tranceiver calibration (DigRF?)
<api-function> = afc_cal = Automatic Frequency Control calibration
<api-variable> = default_dac_value = variable to be set or read.
<query/setting> = ? = ["?" = query, "= <value>" = set to <value>]

Fortunately there is a built-in help command; at@help which yields:

Syntax:
at@[1234567890<CRC>][&][<channel id>][,<transaction id>][<#>/<##>][<interface tag>:]<command sequence>

(The real CRC digits was replaced.)

Thus we see that our initial syntax guess was not too far off. However, its not known what the CRC is used for or calculated from. Perhaps from the bootloader, IMEI or some other RTOS part, but not the firmware image itself. Now when we have the various command structure parts, we can find more, by searching in the same code regions and praying that the binary code layout, has been well organized.

Here are some interface tag classes:

0 -
2 -
G0 -
G1 -
fspeed - "Full Speed test interface"
gcal - GSM calibration interface **OR** 2G RF driver and calib. interface
ucal - UMTS (3G) calibration interface
utif -
gticom - GTI command "sequencer" interface
gtif ?
getif -
nvm - NVM interface
platform ?
prodctrl - Production Control Interface
prodif - Production Interface
sio: - Configuration trace and modem (AT) interfaces (+XSIO)

There are probably many more interface tags available, so please have a poke around and share if you find anything else. The more popular tags and related commands are:

prodctrl:
pmode_normal
pmode_ptest
set_startup_mode
get_startup_mode
set_mode
get_mode
prodif:
production_mode
at_hash_cmd

Some character I/O:
-------------------
print
print_num

Various:
--------
enable - Set the AT# mode in PTEST mode
enable - Enables/disables performance measurements for GTI Parser.
get_mem_info - get info about specific memory area

There are several hundreds more!

ThreadX / RTOS

It is now clear that the X-GOLD series fully or at least partially implements the ThreadX RTOS, including the ARM RealView Debugger (RVD) kit. The RVD-kit also include a GUI and CLI shell that can use their own scripting language, known as the RVDS. Probably the command structure observed above is all part of this. In our particular firmware the version is:

"ThreadX ARM11/RVDS Version G5.3.1.5.2"

while the Infineon specific serial number is giving away its internal use as a Service Shell:

"Infineon_SVC_SH_Version"

However, probably due to backward compatibility, it seem that many parts of the widely popular Nucleus RTOS are still available...