EM7565 firmware updates

[Bjørn Mork]

Bjørn Mork <bjorn at mork.no> writes:
> Reinhard Speyerer <rspmn at arcor.de> writes:
>
>> AFAIK MC7xxx_Image_Management is actually an older application which
>> may not have been updated for the EM7565 (yet). Could you please retry
>> with the Firmware_Download sample application from version 04.00.12 of
>> the Linux QMI SDK and see if you get any further?
>
> Yes, I will.
>
> But AFAICS, both these applications simply defer everything interesting
> to the "magic" in UpgradeFirmware2k().  Which is part of the binary only
> library. That's why we have to guess what they do based on USB snooping,
> and why we might as well use the Windows application as guide.

I got my hands on a Windows7 laptop and captured a successful firmware
update there (81M file):
https://get.ze.mork.no/em7565-win7-firmware-upgrade.pcap

There is some noise in this file, as I played a bit with the unknown
system before it wanted to start the upgrade.  The modem boots into QDL
mode in frame #2107.  From there you can see much of the same initial
sahara sequence leading up to the XML dialogue.  But I note that there
is no weird 'UTUVUTUV UTUVUTUV UTUVUTUV' packet in the hello exchange.

There are a few interesting elements in the XML:

#2130: A nop request
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<NOP value="ping" />
</data>

#2136: the inititial configure request looks similar to the Linux one.
Notable differences are claiming to be 'ZlpAware' and a much larger
'MaxPayloadSizeToTargetInBytes':
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<configure MemoryName="eMMC" Verbose="0" AlwaysValidate="0" MaxDigestTableSizeInBytes="8192" MaxPayloadSizeToTargetInBytes="1048576" ZlpAwareHost="1" SkipStorageInit="0" TargetName="8960" />
</data>

#2137: the inititial configure request is NAKed here too, with the same
(naturally) new values:
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<response value="NAK" MemoryName="NAND" MaxPayloadSizeFromTargetInBytes="2048" MaxPayloadSizeToTargetInBytes="8192" MaxPayloadSizeToTargetInBytesSupported="8192" TargetName="9x55" />
</data>


#2153: the program request is identical to the Linux one, except for the
order of the attributes:
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<program PAGES_PER_BLOCK="64" SECTOR_SIZE_IN_BYTES="4096" filename="spkg.cwe" num_partition_sectors="20339" physical_partition_number="0" start_sector="-1"  />
</data>

#2157: and we get the same ack
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<response value="ACK" rawmode="true" />
</data>

#2158: we send 8192 bytes of firmware
#2159: we send a ZLP!  Wonder if this is the major difference here?

It then continues sending pairs of 8192 bytes followed by a ZLP until it
is finished transferring the image, and sends the final part:

#22496: we send 4096 bytes
#22497: ZLP

Note that this totals to 83308544, which is slightly more than the file
size 83306532.  The last frame is zero padded to 4096 bytes for some
reason.

The bootloader has been silent while the transfer was going on, but now
we receive a number of log lines with the image processing status. The
we get

#22511: transfer ack
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<response value="ACK" rawmode="false" />
</data>


#22512: preparing for next transfer, with the values which were
successful above:
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<configure MemoryName="eMMC" Verbose="0" AlwaysValidate="0" MaxDigestTableSizeInBytes="8192" MaxPayloadSizeToTargetInBytes="8192" ZlpAwareHost="1" SkipStorageInit="0" TargetName="8960" />
</data>

#22529: next program request
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<program PAGES_PER_BLOCK="64" SECTOR_SIZE_IN_BYTES="4096" filename="spkg.cwe" num_partition_sectors="1" physical_partition_number="0" start_sector="-1"  />
</data>

#22533: ack
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<response value="ACK" rawmode="true" />
</data>

#22534: sending the 3757 byte SWI9X50C_01.02.01.00_GENERIC_001.015_000.nvu
file zero padded to 4096 bytes
#22534: ZLP

Getting a few processing log entries, followed by:

#22540: ack
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<response value="ACK" rawmode="false" />
</data>


#22541: important new request
<?xml version="1.0" encoding="UTF-8" ?>
<data>
<power DelayInSeconds="0" value="reset" />
</data>


Then there are a few more log entries and an ack, before the modem boots
back to application mode.

I wonder if the ZLPs were the missing part in the failed Linux upload?
There isn't much else different before the transfer is finished.  We
should be able to support this.  The protocol is pretty simple if this
is all there is.




Bjørn