Re: [Bitpim-devel] Some amusements

[Stephen W. <sa...@us...>]

On Mon, 2003-12-08 at 05:36, Roger Binns wrote:
> I have added a firmwarerequest and an offlinerequest
> method to com_brew.  You can also reboot the phone from
> offline request.  Turns out Stephen already knew about these
> from the Sanyo which requires them.

These seem to have been around a while.  I got these from the PROTOCOL
document in qcplink (http://qcplink.sourceforge.net/).  The protocol is
for the Qualcomm QCP-2760.  There are a few differences.  The firmware
request returned 53 bytes for the QCP-2760, for my Sanyo it returns 117
bytes.  The offlinerequest command (called begin/end update in qcplink)
didn't work as described for qcplink (Packet=0x29, 1 or 2, checksum,
7e).  I had to add an extra zero byte after the 1/2 for the Sanyo. 
Also, as far as I can tell, the 0x29,2 sequence did not reboot the
qcp-2760, but it does for the sanyo.  

>
>   Stephen, you should
> also take a look at examples/mystery.txt and see what
> you think they are about.

The qcplink PROTOCOL guesses this to be "Get Phone Programming
Status".   It can be used to check if the phone is ready for updates
after putting the phone into update mode with 0x29/1.  I havn't seemed
to need it with the Scp-4900.  Here is what qcplink says about it:



>0x0C - Get ?Phone programming Status?
>--
>
>The get ?Phone programming Status? request appears to be used both to
>monitor the phone for change and to determine when the phone is ready 
>to accept updates after its been told to begin updates (See 0x29 
>command).
>
>The request/response packet layouts are:
>
>	     Byte 0             Byte 3
>             +-----+-----+-----+-----+
>   Request:  | 0C  | 14  | 3A  | 7E  |    (Checkword = 0x3A14)
>             +-----+-----+-----+-----+
>
>	     Byte 0                                     Byte 7
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>  Response:  | 0C  | 43  | 43  | 43  | lsb-  Phone ESN  -msb |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x08: |flg0                                           |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x10: |                                         |flg1 |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x18: |     |flg2 |                                   |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x20: |flg3 |                                         |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x28: |                                               |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x30: |                                               |
>             +-----+-----+-----+-----+-----+-----+-----+-----+
>       0x38: | Checkword | 7E  |
>             +-----+-----+-----+
>
>I see the ESN in the response. and I see three other fields change 
>(flg0-2).  While I see data in the other locations I don't know what
>the use is so it's not shown here...  I believe the values in the 
>other fields can be safely ignored if all we want is simple phone book 
>maintenance behavior.
>
>Once the phone has been instructed to prepare to accept updates this 
>command is issued repeatedly until the status changes to 
>"go-ahead-with-your-updates".  This transition appears to be indicated 
>by  flg1=0x05, flg3=0x00 transitioning to flg1=0x00, flg3=0x02.  These
>flags both appear to change at the same time.  So while I don't know
>which indicates what, I do know that when the transition occurs I'm
>clear to start sending 0x27 Set Attribute commands.

I'll try this packet with my phone and see what I get.  I see you sent
this command twice and it returned different results each time.  What
were you doing each time, what mode where you in?

				Steve