Hi all, I'm looking at adding OpenRISC 1000 support to OpenOCD.
At present, the OpenRISC GDB port implements reading and writing to individual CPU registers by an "spr" command within GDB. This sends out CPU register access requests as remote commands, and they are handled in by the RSP server as commands beginning with the "qRcmd" string. The two commands to write and read the registers are "writespr" and "readspr". A "writespr" command is followed by a register number and a value, and if all goes well GDB expects an "OK" back from the server. A "readspr" command is followed by an address, and expects the 8 ASCII character representation of the 32-bit data returned over the socket. >From what I can tell, it's not so hard to implement the SPR write command, as we can register a command which will go and do it and just return. However, I'm more concerned about how I go about implementing the SPR read. What I need here is the ability to write back to the GDB client via the socket, but as far as I can tell there's no mechanism allowing this from target code. Also, from looking at the gdb_query_packet() function in src/server/gdb_server.c, the "OK" that appears to be sent back to GDB unconditionally whenever handling a "qRcmd," string wouldn't make this workable, either. One solution is we make our GDB port not use these remote query commands and instead rely on the register cache fetched with the "g" RSP command. However, I'd really like something which would allow custom RSP commands (which can write back to the socket) to be handled. The problems I see are that, even though the gdb_put_packet() function is declared and could be used by target code, I can't, for the life of me, figure out where I could get the right connection* to be putting the data out at the right place. Also, the unconditional "OK" being sent isn't great either - perhaps that could be conditional on a return value from command_run_line() or something. What are people's thoughts on this? Maybe I've misunderstood something and this is actually doable. If so, any pointers would be appreciated. Thanks, Julius _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
