All, I'm following up on the following changes, which are still waiting for review:
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 These changes have been reviewed and are waiting for a +2/merge: 4078 gdb_server: add support for architecture element Cheers, Steve On Thu, Aug 30, 2018 at 1:13 PM, Steven Stallion <[email protected]> wrote: > 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 >
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
