On Mittwoch, 23. Januar 2019 13:18:31 CET Xen Mann wrote: > >Von: "Matthias Welwarsky" <[email protected]> > >An: [email protected] > >Cc: "Xen Mann" <[email protected]> > >Betreff: Re: [OpenOCD-devel] adding new interface(TAP): need to shift 36 > >bit to read 8 bit, how to handle Buffer?> > >On Montag, 21. Januar 2019 16:36:10 CET Xen Mann wrote: > >> I' m implementing a new TAP-Interface. > >> The dr-regiter of the TAP is 36bit wide. > >> [35:32] status/opcode etc > >> [31:0] data (32/16/8 bit) > >> > >> The read/write wrapper for the target has a buffer which has only the > >> length for the exact number of bytes. target_type.read_memory() / ... > > > >Hm. If you're implementing a new TAP interface, why do you bother with > >target_type? Just curious ... > > > >BR, > >Matthias > > Hey Matthias, > > to add a new interface for OpenOCD I used the arm7_9 files as a sample. > This and all other implementations of interfaces are based on the structure > "struct target_type". So to make this interface usable at least a minimal > subset of those have to be implemented.
Actually, take a look at e.g. adi_v5_jtag.c to see how a tap interface is supposed to work. "struct target_type" is an interface for objects that can be debugged, i.e. a gdb can be attached to it. Your TAP interface is a transport mechanism only, so that's the wrong abstraction. What you need to implement is the "glue" that allows the existing target code for arm9 or RISCV to talk to the hardware through the AHBLite. BTW is the documentation for AHBLite public? I would like to have a look. BR, Matthias > > To archive JTAG-Transactions I need functions provided in <jtag/jtag.h>. > > So those both are my entry and exit points into openOCD when implementing a > new TAP-Interace. > > This is my innocent point of view, which took me some time to figure out.^^ > But if there is an other possibilety to design a new interface, please let > me know =). As I've said, I'm new to open source projects and such huge > codebases. Does this answer your question? > > The idea was that ARM uses in it's arm7/9 implementatiion a 32 bit > dr-register and sends it output dirctly to the provided buffer from the > upper level functions if I'm correct. This does not work for me, because I > clock out 36 bit. So thats why I ask if there's a solution out there > without allocating additional memory. Something like an intermediate step > done on the fly. > > Greatings Xense =) > > > _______________________________________________ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
