Dear Matthias,
you probably hit the nail on the head!
Yes I do not want to add a new target, so this is the wrong approach, i think.
So my entry point would be the following structure and my exit point remains in
the functions from jtag/jtag.h?
struct dap_ops {
/** connect operation for SWD */
int (*connect)(struct adiv5_dap *dap);
/** DP register read. */
int (*queue_dp_read)(struct adiv5_dap *dap, unsigned reg,
uint32_t *data);
/** DP register write. */
int (*queue_dp_write)(struct adiv5_dap *dap, unsigned reg,
uint32_t data);
...
}
I have to provide a read(), write(), and the AHBL needs to have a init().
If I've fit this in in the structure, how can I tell a RISCV or a arm
tarteg_type to actually make use of those functions AHBL provides?
Is this done in config file, or do I need some more glue and stings which tie
which tie my addon into the system?
#AHBL-Spec
I'll have a look for the spec. Righ now it's just internal, but there should be
a draft providing more infos, arround Monday.
Perhaps some words to describe the unit some more:
- It's the interlink between TAP/JTAG and AHB.
- It is only designed for this purpose
- It does not support any paging
- It is only ment for a single processor with one core
- It can't do memory paging or any advanced stuff the coresight can do.
- For now it's used to counicate withe one Arm9 or one RISCV
-- for one controller with limited 32bit addresspace where memory and registers
are mapped in, this is fully ok
- You can activate the AHBL with the IR-Register, every following communication
is done via the DR-Regirster
- There are just 6 commands for excanging data and 3 additional for read and
writes with less overhead
- The benefit is a simpel interface and a really small footprint on the silicon
> Gesendet: Donnerstag, 24. Januar 2019 um 08:52 Uhr
> Von: "Matthias Welwarsky" <[email protected]>
> An: [email protected]
> Cc: "Xen Mann" <[email protected]>, "Matthias Welwarsky"
> <[email protected]>
> Betreff: Re: [OpenOCD-devel] adding new interface(TAP): need to shift 36 bit
> to read 8 bit, how to handle Buffer?
>
> 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
