in CoreListFile.txt the high address of the AXI IIC CLOCK lines are wrong

[JohnHay]

The HighRangAddress of the AXI IIC CLOCK lines are wrong. It is 00120FFF, but that is lower than the Low address. I guess it should be 0020FFFF to match the size of the other IIC lines.

grep 'AXI IIC CLOCK' */CoreListFile.txt
TimeCard/CoreListFile.txt:00010002 00000001 02000000 00200000 00120FFF 00000005 00000003 Xilinx AXI IIC CLOCK
TimeCard_200T/CoreListFile.txt:00010002 00000001 02000000 00200000 00120FFF 00000005 00000003 Xilinx AXI IIC CLOCK
TimeCard_LitePcie/CoreListFile.txt:00010002 00000001 02000000 00200000 00120FFF 00000005 00000003 Xilinx AXI IIC CLOCK

[thschaub]

Finally, someone starts using the CoreList :-) It's fixed in a903680d5155aa2600549b9dd2f26e3a086021e7

[JohnHay]

Thank you. :-)

I'm using it in the FreeBSD driver I'm busy with. I also have it working with the LitePCIe firmware. Adding support for that also made me wonder what the better or more future proof way would be for a driver to distinguish between the different firmware versions. But maybe that should be done in a separate issue.

[JohnHay]

BTW It looks like the LitePcie TimeCardOS.bit was missed in the update.

[thschaub]

True, was missing in my release script. Here it is: a4c9739f0526f57c70bb10ad354221c180ab9b50

[thschaub]

Thank you. :-)

I'm using it in the FreeBSD driver I'm busy with. I also have it working with the LitePCIe firmware. Adding support for that also made me wonder what the better or more future proof way would be for a driver to distinguish between the different firmware versions. But maybe that should be done in a separate issue.

The idea is to allow a modular driver. So read out from the CoreList and initialize the driver accordingly with the how many time stampers etc. are instantiated. Of course beside Vendor and Device IDs it could also be used to distinguish between the versions. So feel free to contribute into this direction :)

[JohnHay]

I agree with the modular driver approach. But for that you need to get to the CoreList. :-) So my current understanding is roughly this:

All the cards have a firmware version at offset 0x20000. All the Open Source versions have a CoreList at offset 0x01300000. The LitePcie versions offset everything with 32M, including the above. (except the irq mask) The pre-LitePcie firmware has msi interrupts, while the LitePcie has msi-x and a mask register. For msi interrupts 1 has to be added to the irq in the CoreList to get the vector offset. For msi-x interrupts another 32 has to be added to get the vector offset. The CoreList irq value is used as a bit index in the irq enable/mask register.

The way I currently approach it, is something like this: Determine if it is LitePcie based firmware by reading at offset 0x20000. If that is 0xffffffff, add 32M and try again. If it is still 0xffffffff, give up. If it is not, add 32M to all future offsets. Determine if there is a CoreList by reading at offset 0x01300000. If that is 0xffffffff, assume it is a closed source firmware and use a hardcoded table, else read the CoreList and use that. Determine msi-x/msi by calling the operating system msi-x initialization function. If that fails, try the msi function.

I have this working, although I have not gone back to previous firmware versions to see that I did not break anything. :-)

I guess I just wanted to check if this way have obvious holes or if there is a more robust way, especially if there are already plans for other changes. And also while there is documentation for each firmware stream, I have not found something that describe the differences that can be used by software to add support for multiple versions.

[JohnHay]

One thing I noticed in the updated linux driver is that the PCI_REVISION_ID can be used to distinguish between the LitePCIe and non-LitePCIe firmware. I did not realise that changed. That is a cleaner way than reading at the firmware version offset (0x20000) and knowing it is LitePCIe based because you read 0xffffffff.

Is there a cleaner way to determine if the firmware has a CoreList than just reading at the offset and knowing there isn't one because 0xffffffff was returned?