EM7565 firmware updates

[Reinhard Speyerer]

On Thu, Mar 08, 2018 at 10:44:27PM +0100, Bjørn Mork wrote:
> 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.
> 

Hi Bjørn,

perhaps the sources available here
https://portland.source.codeaurora.org/quic/imm/imm/qdl/
could give you some additional insights into the protocol.

Regards,
Reinhard