[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
