Maintainers,
I have a series of changes in Gerrit that are ready to be reviewed for
eSi-RISC target support. The changes have been tested and used during daily
development for approximately 18 months. Apart from ironing out any issues
in the code, we've also received permission from EnSilica to release this
source publicly.
For the impatient, the changes in question are:
4078 gdb_server: add support for architecture element
4082 jtag: make cmd_queue_scan_field_clone public
4113 register: support non-existent registers
4121 rtos: support gdb_get_register_packet
4660 esirisc: support eSi-RISC targets
That said, the number of supporting changes I needed to make were
surprising and due to the strange nature of the target itself. First and
foremost, this target is a configurable soft (or hard) core that can be
included in FPGA and ASIC designs. eSi made virtually every aspect of the
target configurable, including number of registers, floating point, and
endianness. The biggest issue encountered was the fact that eSi's port of
GDB does not use linear register numbering. This often means that depending
on your configuration of the core, you would request registers that would
have numeric gaps in them. In order to support this target, I needed to
update each of the RTOS implementations to associate the register number so
that the `p` packet can be supported. It was also necessary to not return
an error when a non-existent register was requested - the eSi port would
often use this method to determine whether or not a given configuration was
correct rather than making use of the target description.
Last but not least, the JTAG protocol for eSi requires the use of bit
packing as it was designed to function over a UART and Update-DR is not
supported. To support this a function from jtag/commands.c was made public
which also had the side-effect of requiring that commands.c be added to all
JTAG targets, including the zy1000 minidriver.
I realize this is a lot to review in one sitting, but I wanted to mention
this to the group to see if it would be possible to work through merging
these changes so we aren't continually rebasing. These changes are as
minimal as possible, but I'm sure there will be plenty of discussion in the
reviews.
Cheers,
Steve
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
