git clone https://github.com/Xilinx/u-boot-xlnx.gitInteresting things have already turned up, even undocumented registers in the devcfg.
drivers/fpga/zynqpl.c arch/arm/mach-zynq/include/mach/hardware.hPrior to this discovery I had been looking at sources in the Vivado SDK, such as:
Vivado/2019.1/data/embeddedsw/XilinxProcessorIPLib/drivers/devcfg_v3_5/src/xdevcfg.c Vivado/2019.1/data/embeddedsw/XilinxProcessorIPLib/drivers/devcfg_v3_5/examples/xdevcfg_polled_example.cBut the code in U-boot is both more readable and looks as though it addresses issues that are ignored by the Vivado code.
cd u-boot-xlnx ctags -R .
struct xilinx_fpga_op zynq_op = { .load = zynq_load, };The call is in "drivers/fpga/xilinx.c" in xilinx_load(). This has other interesting code, such as fpga_loadbitstream(), which is quite familiar, calling fpga_load() with the bin file it extracts. This is in "drivers/fpga/fpga.c" and is just a switch that will end up calling back to xilinx_load();
All of this seems to start back in "cmd/fpga.c". The relevant top level calls look like:
fpga_loadbitstream(dev, (void *)fpga_data, data_size, BIT_FULL); fpga_loadbitstream(dev, (void *)fpga_data, data_size, BIT_PARTIAL); fpga_load(dev, (void *)fpga_data, data_size, BIT_FULL); fpga_load(dev, (void *)fpga_data, data_size, BIT_PARTIAL);Here "dev" is a Xilinx device descriptor, which seems to be ignored once we get to the zynq driver level.
Tom's Computer Info / [email protected]