I have gotten my bare metal implementation of the CoaXPress Host and Device IP cores working on the Aper-Oculus. Happy Chance:

The host side has been verified working with an accredited CXP 2.0 Camera (the Basler Boost). The Device side is tested using a loopback of the Host side to the Device side. I would use Basler's Frame grabber, but their driver doesn't work on Ubuntu 20.04, and I'm too lazy to downgrade just for this test. Maybe I'll make my own PCIe frame grabber just to support 20.04+. That'll show them to support LTS Ubuntu versions!

It took a bit of troubleshooting to get this working from the ZCU104. First obvious change was the rate limit of 10.3125Gbps for the GTH transceivers which is NOT reflected very well by Xilinx documentation. Their website claims 12.5Gbps for Kria SOMs, but the Vivado GUI disagrees (DS987 of July 07 2022 states 12.5Gbps on page 29, but the GTH GUI's max value is 10.3125Gbps). The nice part is that register setup for GTH transceivers seems to be normalized across Ultrascale+ Parts with GTH transceivers, so there was no need to update my dynamic reconfiguration ROMs. An interesting future test would be to crank the GTH to 12.5Gbps using their register interface, and see if it's stable without the GUI limiting our setup of the register interface.

Once the pinouts were updated, and the Zynq MPSoC BD part was updated, the next difficult update was the Vitis platform. For some reason, the port kept many of the old address values, and was not reporting correct reads to known version addresses in the UART debug output. The best tips I had for solving these issues were:

1. Ensure all AXI4 Lite addresses are reset and then re-assigned when you port to an old block diagram to a new architecture.
   1. If you have custom AXI4 Lite IP cores, ensure you're not using more bits than needed for the address port, as this will cause Xilinx to apply more memory than actually needed to address your cores. I'll provide a tutorial on packaging IP with my AXI4 Lite regbase + slave interface at a later date.
2. When you build the new Vitis project, just make a new one and import the source files. It's not worth it trying to debug old platform projects. Start a clean repo.
3. Ensure the FPGA is in JTAG programming mode (all boot pins are zero) if you are programming the FPGA via JTAG. You can overwrite the boot mode register and still program it if you load from QSPI or the SD Card, but I found all the AXI addresses were wrong. Weird. If anyone knows why, I'd loved to be enlightened.

The next interesting finding was using Xilinx's ff.h library's behavior changes based on which logical drive you are writing to. In my original ZCU104 example design, I was writing to logical drive 0, but in the Kria SOM, SD card 0 is reserved to a emmc on the SOM. We must use logical drive 1 to save xml files read from the CoaXPress Device.

The working code snippet tested on ZCU104 for logical drive 0:

//Setup vars
FRESULT Res;
BYTE work[FF_MAX_SS];
static FIL fil;
static FATFS fatfs
static char *SD_File;

//initialize SD interface
TCHAR *Path = "0:/"
Res = f_mount(&fatfs, Path, 0);
if(Res != FR_OK) {
    return XST_FAILURE;
}

Res = f_mks(Path, FM_FAT32, 0, work, sizeof work);
if(Res != FR_OK) {
    return XST_FAILURE;
}

SD_FILE = (char*)"cam.zip";
Res = f_open(&fil, SD_File, FA_CREATE_ALWAYS | FA_WRITE | FA_READ);

//Execute necessary control reads as per CXP 2.1 spec to gather xml file

Now, the above works fine for logical drive 0, but when you use logical drive 1, the f_open statement will fail. The solution is to change the above to:

TCHAR * Path = "1:/";

//.... same

SD_File = (char*)"1:/cam.zip";

//..same

 And everything works again like magic. Why does this work this way? Not sure, but I'm just happy when I get my SD card to grab XML files to read on the computer and for future storing and parsing of the files when I get this design into PetaLinux.

The only real bug/difference from the ZCU104 implementation and the Kria SOM is that the video on the PS-GTR DisplayPort from the CoaXPress input is delayed by about 2 seconds. I'm not sure what is causing this delay in video, as the interface should be able to support 4K@30 when at 10Gbps with no issue. Again, this is not something to obsess over, as I have other interfaces to troubleshoot and bring up.

Next up is MIPI CSI-2 with a IMX219. I will next verify with an IMX477R, and then finally do some DSI! Raspberry Pi Displays Ftw. See you there!