Does the vendor software work for you? You could take an USB traffic capture using Wireshark of when the vendor software loads the firmware.

If you are ok with opening up the case, comparing the insides with the images in https://sigrok.org/wiki/Kingst_LA2016 is a good idea also. It may be that there are some part changes due to shortages.

I ran some further tests this morning, using the kernel text-mode usbmon interface, and then Wireshark.

The vendor software does work - at least, it reports that it's successfully initializing the device, and I can see the expected 0x00 reply on the control-in endpoint after the bitstream is downloaded.

It's clear from the usbmon traces that none of the three LA2016 bitstream files extracted from the vendor software match the bitstream that the vendor software is downloading.  The la2016a1 file starts out the same way (with a burst of 0xFF bytes) but doesn't work.  The la2016a2 bitstream file looks completely different - its content seems to be very different in many ways, and its length is less than what the vendor software sends.

So, at a guess, one of two things is happening.  Either the vendor has started encoding their app's version of the bitstream (decoding it before sending to the device) or the extraction utility isn't working correctly and is dicing out this one bitstream image wrongly.

I now have a wireshare capture of the whole vendor-software download sequence, and should be able to reconstruct the correct bitstream from it and see if the sigrok driver can download it correctly.

I opened the case and took a look.  The PCB is labeled LA2016 V3.1.  Its layout is very similar to that of the V1.3.0 board.  The chips:

-  The small U11 is labeled 2CK15 D9PTK
-  The FPGA U1, and the microprocessor U3 have both had their original identifications sanded off.  They've been hot-stamped with a 20221022 date code and four-digit identifiers.

Ok - good progress this afternoon.

I ran a portion of the Wireshark packet log through some Perl and xxd hackery, and ended up with a binary bitstream file 581632 bytes long (a bit less than the 5016a2 version).  I put this into the sigrok-firmware directory in place of the much smaller (158952-byte) bitstream extracted from the Kingst application.

Ran sigrok-cli --scan, and the driver downloaded the new bitstream successfully and things look better:

sr: [00:02.234477] resource: Opened '/home/dplatt/.local/share/sigrok-firmware/kingst-la2016a2-fpga.bitstream'.
sr: [00:04.239787] kingst-la2016: FPGA bitstream upload (581632 bytes) done.
sr: [00:04.312712] kingst-la2016: Run state: 0x85e9 (idle).
sr: [00:04.312991] kingst-la2016: Device should be initialized.
sr: [00:04.313091] kingst-la2016: Device came back after 2200ms.
sr: [00:04.313159] hwdriver: Scan found 1 devices (kingst-la2016).

I ran pulseview, and it saw the device immediately and didn't need to re-download the bitstream.

I haven't tested capture with a real signal yet, so I don't know whether the new device type's definition should use a default (200 MHz) base clock, or 800 MHz.  I'll need to feed it a trustworthy reference signal to figure out.

The next question will be, how is the bitstream image that the sigrok extraction utility finds in the image, related to the actual bitstream which needs to be downloaded?  It can't be a straight encryption because the sizes are so different.  My guess is that it's compressed, perhaps via an algorithm used by the tools for whatever version of FPGA is in this LA2016 model.  Looking at the symbols in the Kingst app hasn't turned up anything yet but I haven't tried very hard so far.

Further speculation:  in looking at the bitstream extraction utility I see that the firmware and bitstream images are stored in the app in Qt resource containers.  The Qt resource system has an (optional) compression feature, which can pre-compress blobs when they're wrapped in resources, using any of several standard algorithms.

If this capability is used (and if the resource compresses enough for the Qt build system to decide to use it), then it's necessary for runtime code to "notice" that the resource blob is compressed, and decompress it into a separate memory buffer prior to use.

The sigrok extraction utility doesn't seem to be compression-aware, nor is the driver.

I'm going to guess that this particular bitstream is (among) the first which Kingst has packaged up in compressed format, and that their Qt app knows to decompress it.

Either the sigrok extraction utility or the driver will need to be upgraded with decompression capabilities, if this sort of image/bitstream file is to be supported in the usual way.

Further confirmation.  I hacked a bit at the sigrok-fwextract-kingst-la2016 code and had it print out some information as it navigates through the RCC directory and entries in the application.

Three FPGA bitstream entries have a flag bit set:

In read_dir_entries, entry 'fwfpga' flags 2
Entry 0, full_name 'fwfpga/LA1016A1' flags 0
Entry 1, full_name 'fwfpga/LA1010A0' flags 1
Entry 2, full_name 'fwfpga/LA1010A1' flags 0
Entry 3, full_name 'fwfpga/LA1010A2' flags 1
Entry 4, full_name 'fwfpga/LA2016A1' flags 0
Entry 5, full_name 'fwfpga/LA2016A2' flags 1
Entry 6, full_name 'fwfpga/LA5016A1' flags 0
Entry 7, full_name 'fwfpga/LA5016A2' flags 0
Entry 8, full_name 'fwfpga/LA5032A0' flags 0
Entry 9, full_name 'fwfpga/LA1016' flags 0
Entry 10, full_name 'fwfpga/LA2016' flags 0
Entry 11, full_name 'fwfpga/LA5016' flags 0
Entry 12, full_name 'fwfpga/MS6218' flags 0

Those three bitstream files all look very different than the ones without that flag bit, as a dump of the first block shows:

kingst-la1010a0-fpga.bitstream: 0000000 00 01 e5 fc 78 9c ec bd 0d 74 5c d5 79 2e fc 9e
kingst-la1010a1-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la1010a2-fpga.bitstream: 0000000 00 05 39 fc 78 9c ec bd 0b 98 5c c7 55 20 7c aa
kingst-la1016a1-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la1016-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la2016a1-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la2016a2-fpga.bitstream: 0000000 00 08 d1 64 78 9c ec bd 0b 9c a5 c5 5d 28 f8 af
kingst-la2016-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la5016a1-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la5016a2-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la5016-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-la5032a0-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
kingst-ms6218-fpga.bitstream: 0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

I haven't found a definition yet for the format of the compressed data, but infer that the 00 byte at the beginning may indicate which compression algorithm was used.

More progress.  A little test script determined that stripping off the first 4 bytes of the compressed blob, results in something recognizable as zlib compressed data.

I installed zlib-flate (from the qpdf package) and used it to decompress the la2016a2 compressed blob (after removing those four bytes).

The result is shorter than the bitstream I reconstructed from the Kingst USB download... but the difference is only zero padding to the final 4k boundary, as far as I can tell.

So, it looks as if extending the bitstream-extractor tool to keep track of the flags from the resources, and using this to conditionally run the blob through a Python zlib deflator, may be enough to fix the problem.

Easy-peasy.  Running this patched fwextract utility on the KingstVis application image results in a 577892-byte kingst-la2016a2-fpga.bitstream file, identical with the
USB-capture-reconstructed one (except for the zero padding at the end).  The
driver loads it successfully and the LA2016 responds that it's in idle.

diff --git a/firmware/kingst-la/sigrok-fwextract-kingst-la2016 b/firmware/kingst-la/sigrok-fwextract-kingst-la2016
index 3575b04..0bcf9bf 100755
--- a/firmware/kingst-la/sigrok-fwextract-kingst-la2016
+++ b/firmware/kingst-la/sigrok-fwextract-kingst-la2016
@@ -99,24 +99,31 @@ class qt_resources(object):
             child_count, first_child = which[2:]
             for i in range(child_count):
                 child = table[first_child + i]
-                if child[1] & RCCFileInfo_Directory:
+                flags = child[1]
+                if flags & RCCFileInfo_Directory:
                     read_dir_entries(table, child, parents + [child[0]])
                 else:
                     country, language, data_offset = child[2:]
                     full_name = "/".join(parents + [child[0]])
                     self._resources[full_name] = data_offset
+                    self._resource_flags[full_name] = flags
 
         self._res_datas = self._get_elf_sym_value("_ZL16qt_resource_data")
         self._res_names = self._get_elf_sym_value("_ZL16qt_resource_name")
         self._res_struct = self._get_elf_sym_value("_ZL18qt_resource_struct")
 
         self._resources = {} # res_fn -> res_offset
+        self._resource_flags = {} # res_fn -> RCC_flags
         table = read_table()
         read_dir_entries(table, table[0])
 
     def get_resource(self, res_fn):
+        RCCFileInfo_Compressed = 1
         offset = self._resources[res_fn]
+        flags = self._resource_flags[res_fn]
         data = self._get_resource_data(offset)
+        if flags & RCCFileInfo_Compressed:
+            data = zlib.decompress(data[4:])
         return data
 
     def find_resource_names(self, res_fn_re):

It's good to see that progress of yours!

So the firmware extraction utility lacked support for optional compression 
of Qt resources, and you successfully added it?

Notice that padding before/during netlist upload is done in the driver. 
Maybe the chunk size needs another check, too. Currently 4KiB is assumed. 
Holding uncompressed firmware on disk and keeping the driver simple is 
preferred indeed.

Can you make the sigrok-util commit available in a public git repo, or 
send its format-patch output to the ML or attach it here? So that it 
can be taken to mainline, and your work properly gets attributed. See 
`git log` for how commit messages are written in this project.

Alternatively I can create a commit (the above is a diff and lacks meta 
information). Would ask you to ACK it in that case before submission.

Thank you for working on that issue.

Can you ACK the commits that I prepared, or NAK them and provide something 
that should be taken instead? Thank you for checking. (Hope the two URLs 
make it here, and don't get clobbered.) Especially check the meta data.

https://repo.or.cz/sigrok-util/gsi.git/commitdiff/64859badb1221edccb103b6eadfbda9e760ed9a9
https://repo.or.cz/libsigrok/gsi.git/commitdiff/e7c7aa119d49c9a8f25cb32858c74bfe5a4efb23

Have also moved the RCC constants after your zlib enhancement. The branches 
which the above commits are part of are here:

https://repo.or.cz/sigrok-util/gsi.git/shortlog/refs/heads/kingst-la2016-1825
https://repo.or.cz/libsigrok/gsi.git/shortlog/refs/heads/kingst-la2016-1825

I will check out your commits this afternoon, patching them into clean copies of the repo heads.  I'll do a fresh extraction of the firmware images, and then test PulseView with my device and a signal source.  The only big question in my mind at this point is, which setting of the base clock is appropriate for this device... capturing an accurate 1 MHz waveform should tell us that, I think.

I'll either ack your commits, suggest a small tweak, or go through the process of forking the github repos and pushing changes to them and sending you a pull request.

As far as the driver download process goes, I've noticed only one real difference between the behavior of the sigrok driver and KingsVis.  The vendor app always sends the bulk data in 4096-byte blocks - it zero-pads the last (partial) block out to 4096 bytes and sends it in a single transfer.  It then ends the bulk transfer by sending a 0-byte block.

The sigrok driver sends most of the firmware in 4096-byte blocks, sends the last part as a short block, and then sends a separate zero-padding short block to round up the whole bulk transfer to a multiple of 4096 bytes.

I haven't seen any indication so far that this difference matters at all.  It wouldn't be hard to change the sigrok code to mimic the KingsVis behavior but at this point I don't see any real reason to do so.

Glad to be able to help out with this.  sigrok looks like an amazing collaboration - the list of protocol decoders people have written is extremely impressive.

I think your commits are good to go.  I patched them into a clean script-build of the libraries and apps, the device is working, and the commit metadata looks fine.

The bitstreams and firmware all seem to have extracted OK.

With the new model information added, the driver recognizes the new device model and successfully downloads the firmware and the decompressed bitstream.  Out of three runs (unplugging in between) the bitstream load timed out once... I'm not sure why.  The other times it worked fine and the device came up.

The new model seems to capture correctly with the definition in your commit (default base-clock value).  I fed it a 20 MHz square wave from my signal generator:

dplatt@worker:~$ sr/bin/sigrok-cli --driver kingst-la2016 --config samplerate=200M -C CH0 --samples 1000
FRAME-BEGIN
libsigrok 0.6.0-git-0db1b18
Acquisition with 1/18 channels at 200 MHz
CH0:11100000 11111000 00111110 00001111 10000011 11100000 11111000 00111110
CH0:00001111 10000011 11100000 11111000 00111110 00001111 10000011 11100000
CH0:11111000 00111110 00001111 10000011 11100000 11111000 00111110 00001111
CH0:10000011 11100000 11111000 00111110 00001111 10000011 11100000 11111000
CH0:00111110 00001111 10000011 11100000 11111000 00111110 00001111 10000011
CH0:11100000 11111000 00111110 00001111 10000011 11100000 11111000 00111110
CH0:00001111 10000011 11100000 11111000 00111110 00001111 10000011 11100000
CH0:11111000 00111110 00001111 10000011 11100000 11111000 00111110 00001111
CH0:10000011 11100000 11111000 00111110 00001111 10000011 11100000 11111000
CH0:00111110 00001111 10000011 11100000 11111000 00111110 00001111 10000011
...

10 sample-times per cycle, just as it should be.  A couple of tests with different sample rates and signal frequencies also seem consistent.  Here's a 16 kHz signal at a lower sample rate:

FRAME-BEGIN
libsigrok 0.6.0-git-0db1b18
Acquisition with 1/18 channels at 200 kHz
CH0:00111111 00000011 11110000 00011111 10000001 11111000 00001111 11000000
CH0:11111100 00000111 11100000 01111110 00000011 11110000 00111111 00000001
CH0:11111000 00011111 10000000 11111100 00001111 11000000 01111110 00000111
CH0:11100000 00111111 00000011 11110000 00011111 10000001 11111000 00001111
...


My locally-built pulseview crashes during startup (throws a bad-parameter exception) with or without the Kingst LA plugged in.  I'm not certain why, but suspect that I have a build dependency problem (the script can't find the C++ bindings unless I install the stock Debian -dev set, and those are probably out of date with the main sigrock tree).  I'll work on this separately.

Merged, thank you for submitting this input. See sigrok-util 64859badb122 
and libsigrok e7c7aa119d49. Setting status to resolved.