[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] scope of target descriptions
|
Here you go:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=146090
I also added a link on the SPIRIT DD page to this bug.
http://wiki.eclipse.org/index.php/DSDP/DD/Spirit
Aaron
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Oberhuber, Martin
> Sent: Thursday, June 08, 2006 12:35 PM
> To: Target Management developer discussions; Device Debugging
> developer discussions
> Subject: RE: [dsdp-tm-dev] scope of target descriptions
>
> Hi Aaron,
>
> thanks very much for re-posting this.
>
> In order to facitiltate further discussions on these
> generalized target descriptions, I'd suggest that you file a
> bugzilla enhancement request against TM, e.g.
> "Need generalized target descriptions", and add a link to the
> bug number on the DD/Spirit page.
>
> Through the bugzilla entry, we'll get discussions that are
> easily trackable, and anyone who wants to get involved can
> register on CC of the bug entry.
>
> Cheers,
> Martin
> --
> Martin Oberhuber - WindRiver, Austria
> +43(662)457915-85
>
>
> > -----Original Message-----
> > From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> > [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > Sent: Wednesday, June 07, 2006 9:09 PM
> > To: Device Debugging developer discussions; Target Management
> > developer discussions
> > Subject: [dsdp-tm-dev] scope of target descriptions
> >
> > Hello all,
> >
> > Per the TM call today, this is a reposting/cross posting.
> > Descriptions
> > of targets is something that is obviously not just related
> to device
> > debugging, but is part of the charter of the TM project as
> well. In
> > general a target can span many things: remote Linux/AIX/Windows/etc
> > server, embedded RTOS via Ethernet, bare iron core via
> JTAG, the host
> > workstation, etc. To date, the target description
> discussions that I
> > have been trying to facilitate discussion about revolve around low
> > level target details. Cores, bits in registers, memory
> maps and such.
> > (see requirements doc on this page:
> > http://wiki.eclipse.org/index.php/DSDP/DD/Spirit , and the many
> > threads on the dd list related to target descriptions or SPIRIT)
> >
> > I am curious what thoughts there are about the need for a more
> > generalized description of targets, where an "embedded" target is
> > perhaps only one type of target. It would seem to me that we need
> > some repository of target description factories, and from it we can
> > get descriptions of different types of targets where the
> information
> > is specialized to the type of target. You can for example have
> > different "views" of the same target. On one hand, debugging a
> > processor with a JTAG probe that happens to be running
> Linux you may
> > see a flat memory map and all peripherals. For a user level Linux
> > application via an agent, for all intents and purposes you see a
> > completely different memory map and limited set of registers. So
> > obviously there must be different target descriptions for these
> > different connection methods.
> >
> > regards,
> > Aaron
> >
> > > -----Original Message-----
> > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > > Sent: Tuesday, May 30, 2006 11:10 AM
> > > To: Device Debugging developer discussions
> > > Subject: RE: [dsdp-dd-dev] How do you want to use target
> > descriptions?
> > >
> > > Hi Ted,
> > >
> > > I think that I will likely start creating something that
> people can
> > > play with to get some more feedback. I am going to poke around a
> > > bit and see if there are any companies using SPIRIT right
> now that
> > > would be willing to contribute some Java code to read
> SPIRIT files.
> > > (hint hint) Next step would be creation of an "target file
> > > importer" that read SPIRIT files into data structures, and then a
> > > simple "target view"
> > > plug-in that shows a tree with details of a target, and is a
> > > demonstration of how to use the new target interfaces.
> > >
> > > cheers,
> > > Aaron
> > >
> > > -----Original Message-----
> > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Williams, Ted
> > > Sent: Wednesday, May 24, 2006 9:30 PM
> > > To: Device Debugging developer discussions
> > > Subject: RE: [dsdp-dd-dev] How do you want to use target
> > descriptions?
> > >
> > >
> > > hi Aaron,
> > >
> > > The "SPIRIT importer" sounds good. I'm uneasy with the two stage
> > > approach, but I don't claim to understand the details
> well enough,
> > > yet.
> > > Are you planning to code the initial version of the library?
> > > ;) I'm working on a gdb prototype built on top of an
> > > osgi/async/expression framework we plan to contribute soon.
> > > At the moment, I'm mainly interested in access to
> register details.
> > > Something more than a hack, but still experimental, would
> be great.
> > >
> > > ted
> > >
> > >
> > > -----Original Message-----
> > > From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> > > [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > > Sent: Wednesday, May 24, 2006 12:44 PM
> > > To: Device Debugging developer discussions
> > > Subject: [dsdp-dd-dev] How do you want to use target descriptions?
> > >
> > > Hello everyone,
> > >
> > > I wanted to kick up another thread to solicit some
> thoughts on what
> > > we should DO with target description information. It seems that
> > > from a requirement standpoint, what I have proposed seems
> to more or
> > > less address everyone's needs. The next steps are
> > > 1) extending SPIRIT such that everything we need is there
> > > 2) actually figuring out what DSDP wants to have in place
> as far as
> > > an architecture to USE this information.
> > >
> > > Regarding use of SPIRIT info:
> > >
> > > >From what I gather, in the EDA world vendors do one of a
> couple of
> > > things with SPIRIT format files.
> > > 1) They use XSLT scripts or other custom translation utilities to
> > > transform SPIRIT files into some other format that they use
> > > internally.
> > > They then read those files into some internal data
> structures that
> > > their tool uses directly.
> > > 2) They directly read SPIRIT files into internal data structures
> > > that their tool uses directly.
> > >
> > > While it would be compelling to have a degree of
> separation from the
> > > details of the format (and thus be insulated from changes), My
> > > colleagues in the EDA side of Mentor have told me that
> many SPIRIT
> > > vendors have run into great pain using the translation
> approach. I
> > > don't really have experience one way or another about this.
> > >
> > > At this point, I am kind of thinking that perhaps we should just
> > > define a set of interfaces/data structures that define
> the target in
> > > terms of our needs, and then write a "SPIRIT importer"
> that can be
> > > used to read information from SPIRIT files into these data
> > > structures. Conceivably then other vendors can write
> importers for
> > > their legacy file formats into these same data structures as well.
> > >
> > > The data structures can have objects to represent targets, cores,
> > > address spaces, memory maps, registers, peripherals, bit fields,
> > > etc.
> > > These objects all have a set of attributes (ISA's and such
> > on cores).
> > > More or less an object representation of what I have in
> the current
> > > doc at http://wiki.eclipse.org/index.php/DSDP/DD/Spirit
> > >
> > > Issues or thoughts about this approach:
> > > 1) I wonder if it would be better to have a less rigid
> description
> > > of targets (not a fixed hierarchy). In particular, I am
> relatively
> > > confident that the model that I see in my head will work fine for
> > > current RISC's and DSP's, but describing a target that is perhaps
> > > not a traditional processor (an FPGA?) might be
> cumbersome. Still,
> > > you have to have the knowledge somewhere.
> > >
> > > 2) This is pretty low level. Do we need "categories" of
> targets? I
> > > am guessing that the link in the RSE to debugging is
> going to have
> > > to leverage these descriptions somehow (and produce the
> interfaces
> > > for a debugger to use when starting to
> > > debug) Not all debuggers will need this sort of level of detail.
> > >
> > > thoughts on this? Sure why not?
> > >
> > > Aaron
> > >
> > > --
> > > Aaron Spear
> > > Debug Tools Architect/Staff Engineer Mentor Graphics
> > >
> > >
> > >
> > > _______________________________________________
> > > dsdp-dd-dev mailing list
> > > dsdp-dd-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > > _______________________________________________
> > > dsdp-dd-dev mailing list
> > > dsdp-dd-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > > _______________________________________________
> > > dsdp-dd-dev mailing list
> > > dsdp-dd-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
> > >
> > _______________________________________________
> > dsdp-tm-dev mailing list
> > dsdp-tm-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> >
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
