
On 25. 06. 19 17:53, Robert Hancock wrote:
On 2019-06-25 7:01 a.m., Michal Simek wrote:
On 21. 06. 19 18:10, Robert Hancock wrote:
On 2019-06-21 12:19 a.m., Michal Simek wrote:
If it helps, here is part of our board file that does the FPGA GPIO and SPI initialization and initializes the FPGA callbacks. We are using an ITB image that has the FPGA .bit file as one of the entries and which gets loaded as part of the bootm command.
thanks for this.
static struct gpio_desc fpga_done; static struct gpio_desc fpga_prog; static struct gpio_desc fpga_init_in;
static struct spi_slave *fpga_slave;
...
/*
- Initialize before download
*/ static int fpga_pre_fn(int cookie) { /* Initialize GPIO pins */ dm_gpio_set_dir_flags(&fpga_prog, GPIOD_IS_OUT); dm_gpio_set_value(&fpga_prog, 1);
return cookie; }
/*
- Set the FPGA's active-low program line to the specified level
*/ static int fpga_pgm_fn(int assert, int flush, int cookie) { dm_gpio_set_value(&fpga_prog, !assert); return assert; }
/*
- Test the state of the active-low FPGA INIT line. Return 1 on INIT
- asserted (low).
*/ static int fpga_init_fn(int cookie) { return !dm_gpio_get_value(&fpga_init_in); }
/*
- Test the state of the active-high FPGA DONE pin
*/ static int fpga_done_fn(int cookie) { return dm_gpio_get_value(&fpga_done) ? FPGA_SUCCESS : FPGA_FAIL; }
static int fpga_wbulkdata_fn(void *buf, size_t len, int flush, int cookie) { int ret = spi_xfer(fpga_slave, len * 8, buf, NULL, SPI_XFER_BEGIN | SPI_XFER_END); if (ret) { printf("Failed to transfer %zu bytes of SPI data: %d\n", len, ret); } return cookie; }
static int fpga_post_fn(int cookie) { return cookie; }
static int fpga_abort_fn(int cookie) { return fpga_post_fn(cookie); }
static int fpga_busy_fn(int cookie) { return 0; }
static xilinx_virtex2_slave_fns fpga_fns = { .pre = fpga_pre_fn, .pgm = fpga_pgm_fn, .init = fpga_init_fn, .done = fpga_done_fn, .wbulkdata = fpga_wbulkdata_fn, .busy = fpga_busy_fn, .abort = fpga_abort_fn, .post = fpga_post_fn, };
static xilinx_desc fpga = { .family = xilinx_virtex2, .iface = slave_serial, .size = 6692572, .iface_fns = &fpga_fns, .cookie = 0, .operations = &virtex2_op, .name = "7k160tffg676"
This doesn't look like virtex2. It looks like kintex-7. What do you really have there?
Correct, it's a Kintex 7 part. The slave serial protocol doesn't appear to have changed much from Virtex2 onward, so the same driver can be used.
Question here is if we should be really using virtex2 file and not any generic one if this can be used for multiple fpgas. But enabling virtex2 driver for programming kintex7 is weird for sure.
I did note in the Kconfig help text that the driver can be used for a bunch of newer FPGA families as well. However we could rename the driver to be more generic - I'm just not sure what to call it, since there are some older FPGAs like Spartan3 that still have specific support elsewhere.
ok. Fair enough. I have applied this series and I think will be good to take out generic stuff to one file. I don't have any HW for this that's why I have no way to test this and do closer look. Anyway if you want to do I am happy to review it or someone else can do it.
Thanks, Michal