On Monday 29 June 2009, Øyvind Harboe wrote:
> Really what is required is a target .cfg file for *each* FPGA bit
> file, just like a .cfg file is required for each target.
You mean, to handle cases like the config bitstream
linking in more TAPs to the one provided by the FPGA
vendor?
Maybe. We have the model of enabling/disabling TAPs
already, via JRC. That model is a bit weak, in that
it doesn't understand more than one TAP being added
at a time ... and is very fragile, since the code has
no good way to validate the chain.
But basically something like
jtag newtap fpga.cpu0 ... -disable
jtag newtap fpga.cpu1 ... -disable
jtag newtap fpga.cpu2 ... -disable
...
jtag configure fpga.tap -event post-verify {
xsvf fpga.tap bitstream_file_0
jtag tapenable fpga.cpu0
jtag tapenable fpga.cpu1
...
}
should solve the technical problem. And it could be
made properly conditional, so that bitstream_file_1
and bitstream_file_1 enable different TAPs, and are
chosen based on the task at hand.
If someone wanted to package those into different
config files, that could work; but I wouldn't want to
require board files use that model for substructure.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
