<azonenberg> Wanda[cis]: my understanding is that the university program parts are the same as the regular ones
<azonenberg> for devkits etc too
<azonenberg> they're just marked as such so they're "not for commercial use"
<Wanda[cis]> mhm
<Wanda[cis]> they seem to have identical firmware but different usb id
<azonenberg> interesting
<azonenberg> the only difference i was aware of was silkscreen markings on the pcb
<azonenberg> wrt XCF* i am not aware of any documentation on the programming protocol
<azonenberg> i do know the die is made by stmicro
<azonenberg> at least for the xcf02
<azonenberg> i dont think i ever uploaded my decap anywhere because the die broke and the pictures i got weren't pretty
<azonenberg> here's the descriptors. this is on a machine which AFAIK doesnt have the drivers installed
<Wanda[cis]> excellent! thank you
h_ro has joined #prjcombine
<h_ro> Wanda[cis]: I have lsusb dumps (and WIP openocd driver) for DLC10, DLC9G, and ML605: Wanda[cis]: I have lsusb dumps for DLC10, DLC9G, and ML605 with and without firmware: https://github.com/hansemro/openocd/tree/xpc_usb/doc/usb_adapters
<h_ro> There are some commands present or missing in different ISE/Vivado releases that I am looking to track down and identify
<Wanda[cis]> commands as in USB control requests?
<h_ro> Yes
<Wanda[cis]> huh.
<Wanda[cis]> btw do you know of the oneliner to get the firmware revision out of a .hex file?
<h_ro> I don't
<Wanda[cis]> grep '^:0219B900' *.hex
<Wanda[cis]> strip off the last byte (that's the checksum), the two bytes right after 0219B900 are the hex version code
<Wanda[cis]> seemingly the versioning runs separately for each device type
<Wanda[cis]> this is the same version that is returned from request 0xb0/0x50/0x0000 (it's where it's returned from, in fact)
<Wanda[cis]> I have no idea why that thing is at a fixed address (pretty much everything else is basically shuffled), but it's consistent across firmwares
<azonenberg> if i had to guess, it's for a reason
<azonenberg> i actually do similar in a lot of my firmwares where i have a well known address (typically 32 byte alignment right after the ARM vector table ends) that i store a firmware ID string and version number in
<azonenberg> that my bootloaders, DFU utilities, etc know how to read
<azonenberg> so i can verify an image is for the right chip and it'll refuse to boot an image that's for a different board
<azonenberg> and it also uses it as a key to a hash of the firmware in flash
<Wanda[cis]> well yeah, that's a reasonable thing to do
<Wanda[cis]> except. 0x19b9. that's a completely random address.