Sure. (Sorry, I didn't see the Anonymous post before now.) Binary for 64-bit Windows, not tested.
linting etc fixes merge request
If you look at the latest git version you can see that I already put in placeholders for these chips, with some values filled in. It even has a complete and active (but not verified) entry for the 585xx chips. Some values differ from yours. So we should try to find out which values are best.
Thank so much! Can you please also tell where you have the information from (datasheet revision, other document references) so that it can be double-checked? The option bytes and sectors can be tricky for some systems but it helps to know what your assumptions are based on.
If you are asking about the same issue in different forums, it is useful (and polite) to mention this and provide links. https://github.com/libusb/libusb/issues/1717
Xilinx (AMD) bootloader (FSBL) issues on Windows
It is not often that ELF files are used to provide firmware to end users as in this example. However it is often the primary build artifact so it would be convenient for development. It is interesting that StmDfuUsb supports ELF files because it is not mentioned on the home page https://yatrim.com/stmdfuusb I am not hugely in favour of adding all kind of file formats to dfu-util, because it adds complexity, maintenance burden and probably build dependencies. I would prefer it being added to the dfuse-pack.py...
You mention StmDfuUsb but not anything about what device and bootloader it is. Please see https://sourceforge.net/p/dfu-util/tickets/new/ You can convert the ELF file to a binary using objcopy. If it is a standard DFU 1.1 device then that's all fine, but if it a DfuSe bootloader you must know where to load it, this information is in the ELF file but not in the binary file.