MC7455 in QDL mode

[Sebastian Sjoholm]

Thanks.

Correct with the memorydump, it was able to communicate with device, it
does reset at the end which brought it back momentarily.

# ./ramdumptool_arm9
-----------
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...
1: OCIMEM
 [Base:0xFE800000, Length:0x00008800]
....
15: CMM Script
 [Base:0x07FA9320, Length:0x00000474]
Reading memory...
100% Complete

Resetting device ...
RAM Dump capture SUCCESS!!
Exit Application!
#

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.

-Sebastian


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:
> https://github.com/openpst/libopenpst/blob/master/
> include/qualcomm/sahara.h
>
> 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
> sure...
>
> 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
> me.
>
> 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.
>
>
> Bjørn
>



-- 
Sebastian Sjöholm

Simborgarvägen 116
SE-18439 Åkersberga
Sverige

Mobile : +46 76 335 0667
Email : sebastian.sjoholm at gmail.com
Skype : ssjoholm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libqmi-devel/attachments/20171122/f3ccb0cf/attachment.html>