From: "Tom Taylor" <ttaylor@ateng.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: <gdb@sources.redhat.com>
Subject: Re: PSIM Support for MPC860
Date: Mon, 08 Oct 2001 13:53:00 -0000 [thread overview]
Message-ID: <018f01c1503b$53263530$7c01a8c0@ateng.com> (raw)
In-Reply-To: <o5adz22afy.fsf@touchme.toronto.redhat.com>
"Frank Ch. Eigler" fche@redhat.com writes:
:
: "Tom Taylor" <ttaylor@ateng.com> writes:
:
: : I'm attempting to use the GDB 5.0 PSIM simulator to analyze firmware
: : written for the MPC860T in the OEA mode. [...]
:
: You might have a big job ahead of you.
:
No doubt. However, I only need a limited simulation at first to verify
that
BSP, driver, and application code previously compiled and linked by my
client
using Diab Data tools will operate properly after compilation using GCC
and
linking with pSOS+ and pNA+ libraries. My main concern has been
variable
length argument passing, since Diab Data uses a modified, two argument
version
of the sizeof() operator for walking the arg list. Other concerns are
the correct
translation of Diab-specific '%' function-style operators for loading
32-bit
immediate and address values into more general at-sign suffix versions
supported
by GCC, e.g. using "symbol 'at' ha" instead of "%hiadj(symbol)", as well
as
replacement of extended section directives and the like.
CPM simulation will have to be severely limited. Fortunately, UPM
emulation should be unimportant. I believe that a comprehensive,
general
simulation of the MPC860T would be extremely difficult. I'm more
interested in allowing analysis of interactions with code on
board-specific
peripherals such as the TI 5420 DSP through the HPI than in supporting
all possible 860T internal peripherals. Chip-select simulation will be
required. I guess I'll have to learn a lot about the device tree
approach;
unfortunately it appears that the IEEE 1275 OpenBoot standard has been
withdrawn.
: : and is there any available code that could be used to reduce the
: : time and effort this task will require?
:
: I don't know of any. Building satisfactory simulations of complex
: processors tends to be a big job. (Red Hat does this sort of thing on
: contract basis for example.)
:
Thanks, I'll keep the Red Hat contract services in mind. I'll submit
any of
the more general-purpose code--such as I & D Cache SPR extensions--for
possible inclusion with PSIM when I have it working OK.
Tom Taylor
next prev parent reply other threads:[~2001-10-08 13:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-08 10:35 Tom Taylor
2001-10-08 12:34 ` Frank Ch. Eigler
2001-10-08 13:53 ` Tom Taylor [this message]
2001-10-08 16:42 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='018f01c1503b$53263530$7c01a8c0@ateng.com' \
--to=ttaylor@ateng.com \
--cc=fche@redhat.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox