| devicename | driver | uart address | irq | connects to |
|---|---|---|---|---|
| COM1: | serial.dll | a8030000 | 0010 | external serial cable |
| COM3: | ircomm.dll | infrared port | ||
| COM2: | serial3.dll | a8050000 | 000f | gsm multiplexed protocols |
| COM8: | usb.dll | a8000000 | 000d | serial over USB |
| COM9: | serial2.dll | a8010000 | 0011 | gsm bootloader |
DeviceIoControl (hCom,0xAAAA5679L, {0x84,0}, 2,0,0,0,0) multi channel protocol
This protocol is what is sent over the internal port ( the strongarm serial port 1 at virtual address 0xa8050000, or physical 0x80050000 ). and it is what atdbg ( or rilcomtemp.exe ) dumps.| command | protocol channels supported |
|---|---|
| normal | 11 14 16 17 |
| dualtrace | 11 14 17 |
| dual | 11 14 17 |
| protocol | description |
|---|---|
| 11 | trace messages |
| 12 | other gsm trace |
| 13 | PCO trace |
| 14 | unknown |
| 16 | gsm at commands |
| 17 | peripheral control ( led, vibrator, battery) |
Wait for turn on GSM... GSM already on -> RESET !! GSM turn on successed!! -----------------------ULYSSE MODE--------------------------- Normal mode(UART2 --- UART3) ****************************************************** InitDebugSerial using SERIAL PORT 2 ****************************************************** GSM RESET...after which things get interesting: in hex:
02 11 00 00 00 20 03 "Trace module started by the environment" 02 02 11 00 00 00 00 01 "RVT: Lost Message" 02 02 17 "4D01FF00004D" 02 02 16 "AT-Command Interpreter ready\r\n" 02now there are several things I can do:
| request | reply |
|---|---|
| 11 02 | Exception: Unexpected Software Interrupt this seems to crash the gsm |
| 14 02 | 02 14 00 10 10 10 10 02 |
| 17 02 | 02 17 "0000" 02 |
| 16 "at%ureg?0,4\r" 02 | 02 16 "a" 02 02 16 "t%ureg?0,4\r\r\n\r\n" "+EXT_UREG EA000446\r\n\r\n\r\n" "OK\r\n" 02 |
channel 17 - peripheral control
in this protocol everything is sent encoded as hexadecimal characters. the first digit indicates the length of the command sequence, the second digit is probably a device address. followed by the number of bytes ( in hex, so 2 digits per byte ) indicated by the first digit.these devices are available I think:
| address | description |
|---|---|
| 1 | led/vibrator |
| 2 | unknown |
| 5 | battery via cal |
| 7 | unknown |
| 8 | unknown |
| 9 | phone audio control |
| b | unknown |
| d | battery via ssp |
in replies, the length+device nyble are followed by a hex-status byte, followed by <length> result bytes
| sequence | action |
|---|---|
| 51 00 00 00 00 00 | led off |
| 51 00 01 01 05 05 | red led on |
| 51 00 00 01 05 05 | red led off |
| 51 01 01 01 05 05 | green led on |
| 51 01 00 01 05 05 | green led off |
| 51 02 01 01 05 05 | orange led on |
| 51 02 00 01 05 05 | orange led off |
| 51 03 01 00 01 00 | vibrator on |
| 51 03 00 00 01 00 | vibrator off |
| 19 xx | phone mode ? something audio related |
| 0d | request battery status via scc answer: 4D0180021FEF |
| 05 | request battery status via cal answer: 45FFFF0274B9 |
rsupgrade/monitor protocol
This protocol is what rsupgrade.exe uses to upload and execute the monitor to the gsm, used to flash a new radio stack.(this talks to the strongarm serial port 3 at virtual address 0xa8010000, or physical 0x80010000 ) you can also use this protocol on the external serial port, when entering the utilities menu, selecting the option 'gsmrom to sd', with an sd card inserted. the xda then prompts the user to start 'pc-monitor'. (after close inspection of the bootloader code, it turns out that you are talking to an emulation of the gsm, in the bootloader.)
the code in the gsm rom handling this protocol is in the first 4K of the gsm rom. this code is never updated(well, not that I have seen) by radio stack upgrades, thus always leaving an option to rescue your radio stack if something went wrong upgrading.
I have not yet figured out what rsupgrade does to be able to talk to com9:
I think I did everything the same as I see rsupgrade doing, it just doesn't work for me.
the general request format is:
| position | value | description |
|---|---|---|
| 0 | 0xaa | header byte |
| 1 | length byte | |
| 2 | 0x00 .. 0x0b | command byte |
| >=3 | data, if 0xaa occurs, it is escaped by doubling it |
| position | value | description |
|---|---|---|
| 0 | 0xaa | header byte |
| 1 | length byte | |
| 2 | 0x00 .. 0x0b | command byte |
| 3 | status byte, 0x00= OK | |
| >4 | data, if 0xaa occurs, it is escaped by doubling it |
below the packet formats, ( leaving out the '0xaa' )
with the number of 'x' specifying how many digits in each parameter.
| command | request format | answer format | |
|---|---|---|---|
| cmd00 | get_monitor_id | 01 00 | 05 00 00 ii mi ma info byte, minor, major version nr |
| cmd01 | get_flash_memory_id | 01 01 | 03 01 00 xx |
| cmd02 | get_chip_id | 01 02 | 03 02 00 xx |
| cmd03 | get_board_id | 01 03 | 03 03 00 xx |
| cmd04 | erase_flash_memory | 01 04 | 01 04 |
| cmd05 | write_flash_memory | 01 05 | 10 05 00 xxxx xxxx xxxxxxxx first 16bit word is a checksum, last 32bit word is a crc |
| cmd06 | 01 06 | 03 06 00 xx | |
| cmd07 | read_parameters | 04 07 xxxx xx | ?? 07 00 xx [xxxx ...] |
| cmd08 | write_parameters | ?? 08 xxxx xx [xxxx ...] | 01 08 |
| cmd09 | write srecords | 01 09 | 06 09 00 xxxx xxxx first word is file checksum, second is ram checksum |
| cmd0a | execute monitor | 05 0a xxxxxxxx | 01 0a |
| cmd0b | write_flash_memory | 01 0b | 0a 05 00 xxxx xxxx xxxxxxxx |
test program
I created this pocket pc tool to be able to test various bits and ioctls in the xda. the source is browsable hereon the top line, there are checkboxes, to control this: otherwise it is sent as ascii, followed by a CR (carriage return)
| DTR, RTS | controls these rs232 lines |
| BREAK | sends a break |
| Infrared-mode | sets the uart in Infrared mode. |
| hex | the input edit box is interpreted as hexadecimal data. |
the next line contains status indicators for this:
| DSR,CTS,DCD,RING | the status of these rs232 lines |
| BRK | break was detected. - MS Comm api does not tell when the break ends |
| RLSD | ? - [see ms docs] |
| rcv,xmit | these toggle on and off, with each packet received/sent |
below each of these indicators is a counter, counting how often they have changed
then follows the userinput box, with a 'transmit' button
then a big output window
followed by 2 lines of bit indicators, the first line are the gpio bits, the second line the port at 0xa4000068 ( with the now I think wrong assumption, that 0xa4000064 controls the direction of these bits ). red means it is an input bit, black means it is an output bit. you can switch from input to output by tap+holding the bit. you can toggle its output value by tapping ig. a filled square is a '1' bit, an empty squere is a '0'.
playing with these bits may damage your device, so first research by reverseengineering code that touches them, before just randomly fidling with them.
the bottom is a bit chaotic, and contains experimental checkboxes enable.disable it. for COM2: this enables shared use of the GSM at command channel. this seems to control the power of the gsm part. this seems to enable control of the power of the gsm part.
| ril | send ioctl 0x03000318/0x03000314 to the RIL1: device, |
| com | send ioctl 0xaaaa5679 to the current device |
| dbg | enable/disable debugging info in the output window |
| gsm | controls bit 6 of 0xa4000068 |
| mode | controls bit 6 of 0xa4000064 |
| mem | toggles the value of 0xac0203c8 between 0 and 1 |
| open | opens or closes the selected device |
trace tools
on the xda-ii you can see raw output from the multichannel protocol in \Storage\XPanelLog*.pco files.the at commands are logged in \Storage\Atdbg*.log
problem is however that these log files are not -always- written. or maybe only closed after they reach their maximum size ( about 2M )
to enable logging, set these registry keys:
[HKLM\SOFTWARE\HTC\ATDbgLog] Enable=1 [HKLM\SOFTWARE\HTC\XPanel] Enable=1
0 件のコメント:
コメントを投稿