[Bitpim-devel] Some amusements

[Roger Binns]

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. Stephen, you should
also take a look at examples/mystery.txt and see what
you think they are about.

I have also hooked in raw USB device access. The library
is mature on Linux and works really well with the VX6000.
The library is also mature to my knowledge on Mac.

But with the VX4400, you will never guess what happens.
Yes, thats right. Those damn timeouts. I have spent
several hours trying to figure out exactly what is going
on. Unfortunately the usb sniffer tool I have doesn't
work with the (busted) FutureDial driver and only with
the (ok) LGE driver.

However I think I have finally stumbled onto what the
LGE driver does. It looks like that when you send a
write request, it seperately sends a read request
first. Then it does the write, gets back confirmation,
and then gets the read results.

ie when I do this at a hight level: send("command")
it actually does:

- sends read request
- sends write request ("command")
- receives confirmation of write
- receives read response

I would assume that the phone receiving the read request
before the command means that it sets up some buffers
etc and they are ready to fill when it gets the write
request and wants to fill in its response to a write.

(You can multiple outstanding packets each with seperate
timeouts sort of like SCSI. It also explains the silly
error I was getting from the LGE drivers that I was
able to work around).

It is going to be really hard to do this same behaviour
(they got to do it inside a device driver). I have to
do it from user space using a blocking library and
some sort of thread coordination.

Well, if anyone does manage to get someone from FutureDial
who cares I can tell them exactly how to fix their driver.
LG also should take some heat for somewhat substandard
behaviour of the hardware in the phone itself.

Roger

[Stephen Wood]

Post by Roger Binns
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.

Post by Roger Binns
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

Post by Roger Binns
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).
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

[Roger Binns]

Post by Stephen Wood
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?

It was once to the VX4400 and once to the VX6000.

Roger