2022-05-03

I thought I'd run the mediatek flasher and use stty to capture the serial settings, in case they had changed, but it wouldn't flash either.

It said I needed to remove the battery from the phone and press a key sequence to reflash. The battery is behind a number of small hex screws.

I reviewed its kind rxtx data log and saw it was experiencing the same behavior as my code, so I added a similar message to my code.

What I ended up doing was piping /dev/urandom into the serial port. After some time, this got the serial port to close and the phone rebooted. Doing that doesn't seem to have trashed any partitions yet.

Next time I should log the pipe, see if I can figure a bailout sequence.

1900

1916

i'm logging a complete reflash.

the tty params are roughly:

1804:0:10b2:a20:3:1c:7f:15:1:1:0:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

which appears to roughly mean 115200 baud cs8 cread ignpar ixoff ixany nl0 echok echoctl echoke (and nothing else)

1919

the reflash log finished.

i'm sending mostly the same stuff as the binary but getting a different reply, so some detailed examination pends.

2022-05-04 0905

I just did the first four bytes handshake successfully. also set the dtr and rts flags.

I think some of my successfuly handshakes were reporting as failures simply because I hadn't told my code to stop retrying. this caused both my code and the vendor code to report failure handshaking because it had already happened.

might be more than those four bytes though.

I have a number of appointments today.

1032

appt time. there is very detailed info. it looks like the flasher uploads device bootloader code to do the flashing. I guess that's normal but it's slightly frustrating. there are chunks of code, the first is about 8k*29 bytes long. lots of embedded flashing code.

I think the normal approach is to start by just interfacing with the binary blob. it has an rpc command protocol and the logfile lists the procedure call names, parameters, and results.