EM7565 firmware updates

Thu Mar 8 12:41:41 UTC 2018

Hello,

don't know if you've noticed, but Techship have made a "new" (still from
2017...)  firmware available, as part of a new Windows driver package:
https://techship.com/downloads/sierra-wireless-em7565-b4782-windows-driver-package-and-firmware-01020100-update/

And Google helps those of us who aren't qualified to be Techship
customers...

But I am still facing the issue I saw when I tried faking a firmware
update on the EM7565: No matter how I switch it into "QDL mode", it ends
up speaking the "sahara" protocol.  And the qmi-firmware-update tool
just bugs out when it receives the sahara hello (this is the end of the
attahced full log):

[08 Mar 2018, 13:16:33] [Debug] [qfu-qdl-device] opening TTY: /dev/ttyUSB3
[08 Mar 2018, 13:16:33] [Debug] [qfu-qdl-device] setting terminal in raw mode...
[08 Mar 2018, 13:16:33] [Debug] [qfu,dload-message] sent sdp:
[08 Mar 2018, 13:16:33] [Debug] [qfu-qdl-device] >> 70:00:00 [3, unframed]
[08 Mar 2018, 13:16:33] [Debug] [qfu-qdl-device] >> 7E:70:00:00:14:46:7E [7]
[08 Mar 2018, 13:16:33] [Debug] [qfu-qdl-device] << 01:00:00:00:30:00:00:00:02:00:00:00:01:00:00:00:00:04:00:00:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 [48]
error: error creating device: HDLC trailing control character not found

And the bootloader does not want to switch to sahara "command mode" the
way I know MC74xx/EM74xx can.  So the trick where you could change from
sahara to the "normal" download protocol does not work with the EM7565.

Just to be sure, I even tried the "MC7xxx_Image_Management" sample
application from the most recent version of the Sierra Wireless QMI SDK.
It doesn't explicitly state EM7565 support, but it has gotten a test for
eGOBI_DEV_SERIES_9X07_9X50 so I assume it us supposed to support it.
But this application is even less successful.  It doesn't even detect
the failure, but just gets stuck after receiving

1) a sahara hello (having mode = 2 - "memory debug"):

bjorn at miraculix:~/docs/hardware/sierra/em7565$ hexdump -vC in1 
00000000  01 00 00 00 30 00 00 00  02 00 00 00 01 00 00 00  |....0...........|
00000010  00 04 00 00 02 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030

2) and sending a weird packet (what and why is this?????):

bjorn at miraculix:~/docs/hardware/sierra/em7565$ hexdump -vC out1
00000000  55 54 55 56 55 54 55 56  55 54 55 56 55 54 55 56  |UTUVUTUVUTUVUTUV|
00000010  55 54 55 56 55 54 55 56                           |UTUVUTUV|
00000018

3) followed by a sahara hello reply (selecting mode = 3 - "command"):

bjorn at miraculix:~/docs/hardware/sierra/em7565$ hexdump -vC out2 
00000000  02 00 00 00 30 00 00 00  02 00 00 00 02 00 00 00  |....0...........|
00000010  00 00 00 00 03 00 00 00  01 00 00 00 02 00 00 00  |................|
00000020  03 00 00 00 04 00 00 00  05 00 00 00 06 00 00 00  |................|
00000030

Then there is nothing more in either direction.  Which is a bit
suprising, because I usually see an error from the bootloader when I try
this manually.  I guess the fact that the applications sends a hello
reply indicates that sahara isn't entirely unexpected at this point.
But then again, this is also a possible situation with the MC74xx/EM74xx
as mentioned.  And there it would have worked...

Now I am wondering if it is just me having these problems?  Maybe there
is something wrong with the bootloader on the modem I have?

Or is this how things are supposed to work now?  If so, then what does
Windows do when updating?  I wanted to snoop on that, but I don't have
access to any Windows system where I'm allowed to install driver
software. Anyone else? If you see the same issues as me on Linux, and
are going to let Windows do this firmware update, then please set up USB
snooping on Windows before starting the update.  I'd really like to know
what they do.  I've previously had great success with the open source
USBPcap tool on older Windows versions: http://desowin.org/usbpcap/
But you'll probably need something else for the lastest Windows
versions.

I guess it is possible that Sierra Wireless have started using the
sahara image transfer mode.  Or maybe there is some new magic command
you can use to switch modes?

This GUI tool from the "openpst" project is quite useful when trying to
figure out what the bootloader does when it talks sahara:
https://github.com/openpst/sahara

You can use it to download a full memory dump for example, similar to
the functionality provided by the SDK "ramdump" tool.  But it is
similarily unsuccessful when attempting to switch to command mode.

Bjørn

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: qfu.log
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20180308/b9deeffd/attachment-0001.ksh>