Still waiting on hardware, but i prodded around a bit over the Christmas break
to prepare
while the current script extracts the FX2 firmware for all models it only seems
to extract a single bitstream.
You can extract the others with this patch. Do any of them match the stream you
captured off the bus?
diff --git a/firmware/kingst-la/sigrok-fwextract-kingst-la2016
b/firmware/kingst-la/sigrok-fwextract-kingst-la2016
index a583218..8c5fc7f 100755
--- a/firmware/kingst-la/sigrok-fwextract-kingst-la2016
+++ b/firmware/kingst-la/sigrok-fwextract-kingst-la2016
@@ -192,5 +192,13 @@ if __name__ == "__main__":
res = qt_resources(sys.argv[1])
writer = res_writer(res)
+ writer.extract("fwfpga/LA1016A", "kingst-la1016a-fpga.bitstream")
writer.extract("fwfpga/LA2016A", "kingst-la2016a-fpga.bitstream")
+ writer.extract("fwfpga/LA5016A", "kingst-la5016a-fpga.bitstream")
+ writer.extract("fwfpga/LA1016", "kingst-la1016-fpga.bitstream")
+ writer.extract("fwfpga/LA2016", "kingst-la2016-fpga.bitstream")
+ writer.extract("fwfpga/LA5016", "kingst-la5016-fpga.bitstream")
+ writer.extract("fwfpga/MS6218", "kingst-MS6218-fpga.bitstream")
+ writer.extract("fwfpga/LA1010A_1", "kingst-LA1010A_1-fpga.bitstream")
+ writer.extract("fwfpga/LA1010A_0", "kingst-LA1010A_0-fpga.bitstream")
writer.extract_re(r"fwusb/fw(.*)", r"kingst-la-\1.fw",
decoder=maybe_intel_hex_as_blob)
--Ray
On 2021-01-07 11:27 a.m., Kevin Grant wrote:
>
> Hello Helge,
>
> I have been researching the LA2016 a little to see if I can help with the
> Sigrok integration. In summary, I would say it cannot work on Linux or
> Windows at present.
>
> There are certainly issues in the protocol.c [1] file, for example some FPGA
> SPI register addresses are wrong; CTRL_THRESHOLD should be 0x68 and
> CTRL_TRIGGER should be 0x20. So, I don't understand how this could have been
> tested, unless the manufacturer has recently changed the fw and FPGA
> bitstream.
>
> That brings me to the next issue; the bitstream extracted from the OEM
> software using the python script [2] is different to the bitstream downloaded
> to the LA by the OEM software. I have some experimental code here to run the
> LA and found that while the LED would fade in/out as normal the unit would
> not run correctly. I then extracted the bitstream directly from the OEM
> software USB packets (it was different) and my experimental setup ran fine
> with that. So, either the python extractor code is somehow causing bitstream
> errors or the OEM is obfuscating the on-disk bitstream.
>
> Adjacent to the board LED there is an SO8 IC, no useful markings. It is a
> challenge-response authentication device, with one-wire UART comms on pin 3
> at 12900 baud. Some of the 'unkown commands' mentioned in protocol.c are
> related to this device. One of those commands reads a serial number as shown
> in the OEM software 'About' box. However, the purpose of this device is to
> prevent their software working with any cloned boards and shouldn't prevent
> any hardware functions. I recommend the 'unkown commands' (bRequest 96) are
> ignored/removed.
>
> IMO using the OEM fw and bitstream is an interim workaround, and a workaround
> should not be confused with a solution :-) It would be a better user and
> developer experience if we had open solutions; the fw is not too complicated
> (the FX2 is just passing bytes around, controlling endpoints) but the FPGA is
> perhaps a little tricky.
>
> Anyway, if anyone on this list has an LA2016 (or LA1016) working with
> PulseView, please let me know your setup and where you got the bitstream.
>
> Best regards,
>
> Kevin
>
> [1] src/hardware/kingst-la2016/protocol.c
>
> [2] https://sigrok.org/wiki/Kingst_LA2016
>
> On 2021-01-04 06:14, Helge Kruse wrote:
>
>> Am 03.01.2021 um 16:39 schrieb Gerhard Sittig:
>>> Sorry, but I cannot see how this is "a compiler bug".
>>
>> Well, the C standard doesn't specify how the compiler builds the layout
>> of structs. The GCC add an implementation specific extension with the
>> __attribute__ to force packing of the struct. If the source code
>> specifies to pack and the compiler doesn't pack it is, hmm at least
>> strange. But there comes the -m-ms-bitfield option to the game. I
>> actually curious how this evolved. I didn't found the story behind this.
>>
>>> The number
>>> of leading underscores in the application source code should make
>>> the alarm bells go off, screamingly loud.
>>
>> Do you mean the underscores in __attribute__((__packed__) or did I
>> missed something else?
>>
>>> The proper thing to do is what you suggested. Use structs for
>>> internal application purposes. Translate the data at boundaries
>>> between the application and a communication channel, where one
>>> specific memory layout is expected. Leave the application part as
>>> transparent as it should be, don't "constrain" your application
>>> with the details of a physical transport. BTW using packed
>>> structs in the transport conversion isn't right either, it's as
>>> non-portable as packed structs in application code are.
>>
>> I found this in several OSS projects and use it in my personal
>> applications too. But if the sigrok coding style at least discourages
>> the use, I will improve my idea and use the write_uXX/read_uXX functions
>> for the conversion between transfer layout and information struct in the
>> application.
>>
>> I am not the author/maintainer of the LA-2016 driver, but I hope to
>> contibute to the project.
>>
>>> Moving existing drivers that suffer from portability issues can
>>> be considered low hanging fruit for those who want to help other
>>> users, and unbreak the operation of existing drivers in
>>> environments where they did not work before. Such a proper fix
>>> would no doubt get accepted into mainline, since it's a clear
>>> improvement, not just moving the problem to a different location.
>>
>> So, let's do it.
>>
>>
>> Best regards,
>> Helge
>>
>>
>>
>> _______________________________________________
>> sigrok-devel mailing list
>> sigrok-devel@lists.sourceforge.net
>> <mailto:sigrok-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>> <https://lists.sourceforge.net/lists/listinfo/sigrok-devel>
>
>
>
>
> _______________________________________________
> sigrok-devel mailing list
> sigrok-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
