Could be they store different firmware/streams in the windows and linux
versions of their software, still waiting for the hardware to arrive so this
experiment will have to wait until that time.
--Ray
On 2021-01-07 1:03 p.m., Kevin Grant wrote:
>
> Ray,
>
> FYI to extract the bitstream from USB packets I used (Windows, sorry) Eltima
> Software USB Analyzer, free 14 day evaluation.
>
> Run it, select LA2014, start Kingst software. Select all the 4096 size
> packets (INs and OUTs, so 90 frames) and select export to bin. This will give
> you the bitstream already padded with zeros at the end (to reach whole number
> of 4096 packets, plus one packet of 4096 zeros at the end). File size 184,320
> bytes CRC32 == 0x31a1cffe. I suspect there is also some obfuscation of the
> bitstream size sent to the FX2 just prior to the bitstream, so use the size
> from the control transfer immediately preceding the 4096 bulk packets (size
> 0x02b8ba) in line protocol.c line 126. I'll tidy up my python a bit before
> posting.
>
> Another method for testing is to allow the Kingst software to initialise the
> board, then close it and connect with your code. The Kingst software disables
> the FPGA when closing, so I open the 'About' box (or any modal) and then
> force close/kill with task manager. That leaves the board functional.
>
> Rgds
>
> Kevin
>
> On 2021-01-07 19:07, Ray Molenkamp wrote:
>
>> 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
>>> <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
>>> <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
>> <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
