MC7455 in QDL mode
sebastian.sjoholm at gmail.com
Wed Nov 22 18:58:05 UTC 2017
Correct with the memorydump, it was able to communicate with device, it
does reset at the end which brought it back momentarily.
RAMDUMPTOOL version undefined
Creating output directory: MemDumpOut
Initiating RAM Dump capture...
Detecting device ...
Port open Success : /dev/ttyUSB0
Querying device parameters...
Querying Memory Debug Info...
15: CMM Script
Resetting device ...
RAM Dump capture SUCCESS!!
Thanks for the info regarding the Sahara communication, I will take a look
and see if there is something that I can do. I will try to manually
re-produce the fault as well, so I can easier test.
As the current MC7455, after couple of ramdumps (and reboots), it stayed
stable enough for me to quickly run qmi-firmware-update which succeeded.
Of course it would have been easier if I could only initiate the reboot via
Sahara, the whole ramdump process takes some time.
I get back on this when I have something to share.
On Wed, Nov 22, 2017 at 9:59 AM, Bjørn Mork <bjorn at mork.no> wrote:
> Bjørn Mork <bjorn at mork.no> writes:
> > I believe the bootloader places the modern in some sort of debug mode
> > when it falls to boot. And it speaks a different protocol (Sahara?) in
> > this mode. You can download a memory dump using the ramdump tool from
> > the SDK. Unfortunately, the firmware tools don't speak this protocol.
> > But you can switch to a mode which allows firmware updates using some
> > magic Sahara command. I have done this once a long time ago. Will see
> > if I can find my notes from back then.
> OK, found it. But I see that I made a run-once-for-me-only tool, which
> was too heavily inspired by the ramdump tool from the SDK. Which means
> that it is copyrighted Sierra Wireless, and not distributable in any
> form AFAICS. So I cannot provide you with that, unfortunately.
> But luckily, the most interesting parts of it did not come from the
> SDK. I found them here: https://github.com/openpst/libopenpst
> This header is particularily useful, and GPL:
> The necessary pseudo code is something along these lines:
> - probe sahara protocol support by sending a "switch mode" command (0x0C)
> - if it responds with a sahara "hello" (0x01) then continue
> - send "hello response" (0x02)
> - send "switch mode" (0x0C) again, requesting command mode (0x03)
> - send "hello response" (0x02) again on successful mode switch
> - send "cmd exec" (0x0D), where the command to execute is either "switch
> to DMSS" (0x04) or "switch to stream dload" (0x05)
> You'll find all the emums and structs in the referenced header file.
> That's supposed to be all. I don't remember which one of the dload
> protocols I had success with. Looks like I implemented both to be
> The above might be a unecessarily complicated. I'm not sure you need to
> go through the "hello" exchange twice, for example. But it worked for
> I guess minimalistic sahara support would be a nice addition to
> qmi-firmware-update. At least enough to detect the protocol and
> (opionally?) switch to one of the supported download protocols.
Mobile : +46 76 335 0667
Email : sebastian.sjoholm at gmail.com
Skype : ssjoholm
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libqmi-devel