[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-tm-dev] RSE & Multicore
|
Title: RSE & Multicore
Hi Tom,
this proposal is interesting.
I definitely see some value in allowing the user to create
System Definitions,
which act as a template for creating System Connections (do
I get your idea
right?).
Currently, the RSE's System Definitions are quite static in
terms of the properties
supported -- as we get more (potentially lots more!)
properties for system connections,
your proposal seems to be a logical next
step.
I think an alternative to your solution might be that the
system definition templates are
selected as part of the connection definition wizard, e.g.
by providing a "choose from
template" dropdown on the first page of the "new
connection" wizard. Take this just
as food for thought, since I personally do like your
proposal.
I still don't understand how the user would associate a
connection defintion with a
system defintion in your proposal. And I think I don't
understand your idea behind
the Launches. Would a Launch just connect the debugger to a
given Core? -
If yes, then a context menu action like "attach debugger"
might be sufficient
and Launches would not need to be
maintained?
Could you elaborate a little bit more?
Thanks,
Martin
--
Martin Oberhuber -
WindRiver, Austria
+43(662)457915-85
Hi All,
I've been thinking of how to integrate
multi-board/processor/core hardware configuration information into Eclipse,
specifically through RSE. Please let me know what you think.
Starting at the top, the first change would be to
create two new types of configuration data, System Definition and Connection
Devices, to go along with the existing Connection. The idea is to use
the System Definition to collect data that is inherent to all systems of a
given type, including the types of connection supported by the system. A
Connection Device is used to collect information for any extra hardware device
providing the connection to the actual system, such as an Ethernet JTAG
probe.
The existing Connection type is used to collect
information specific to an actual physical system, which would include a
reference to the appropriate System Definition, Connection Device(s), and
Launch Config(s). It would probably make sense to have the System
Definition and Connection Device be optional, in which case the existing AIX,
Linux and Unix Connections would continue to work as-is.
Given these definitions, since a system represented
by a Connection could contain multiple physical connections, I think it would
be appropriate to rename this to System, in which case we'd have Systems,
System Definitions, and Connection Devices. The Remote Systems pane
might then look like this:
- CONNECTION DEVICES
- New Device
+ Ethernet
Probe...
+ USB Probe...
+ My Probe 1
+ My Probe 2
- SYSTEM DEFINITIONS
+ New Board...
+ New Chassis...
+ My Board Definition
+ My Chassis Definition
- SYSTEMS
- New System
+ AIX...
+
Linux...
+ Unix...
+ My Board...
+ My
Chassis...
- My
Chassis
- My Board, Card Slot 1
-
Processor A
+
Core 1 <--> My Core 1 Launch
+
Core 2 <--> My Core 2 Launch
+
Core 3 <--> My Core 3 Launch
+
JTAG Connection <--> My Probe 1
- My Board, Card Slot 2
-
Processor A
+
Core 1 <--> My Core 1 Launch
+
Core 2 <--> My Core 2 Launch
+
Core 3 <--> My Core 3 Launch
+
JTAG Connection <--> My Probe 2
For one stop-shopping,
we might want to mirror the relevant settings of the launch panel in the
Remote Systems pane as well:
- LAUNCH CONFIGS
+ New
+ My Core 1 Launch
+ My Core 2 Launch
+ My Core 3 Launch
Why do we need all this? The separate
Connection Devices info makes it easy to share System Definitions and/or
Systems while using different instances of the same hardware. The System
Definition makes it easy to share hardware information (like flash, memory
layout, register layout, processor layout, etc.) with different combinations
of hardware. The Systems info makes it possible to associate one or more
launch configurations with one or more debuggable cores and one or more
physical connection devices.
Does this make sense? Is this a logical next
step for RSE?
Best regards,
Tom Hochstein
Freescale Semiconductor, Inc.