From: "Frank Ch. Eigler" <fche@redhat.com>
To: warhurst_brandon@bah.com
Cc: sid@sources.redhat.com
Subject: Re: Running "eprommed" code
Date: Thu, 24 Apr 2003 19:12:00 -0000 [thread overview]
Message-ID: <20030424191231.GA3373@redhat.com> (raw)
In-Reply-To: <3EA8346E.5060804@netscape.net>
Hi -
On Thu, Apr 24, 2003 at 03:01:02PM -0400, Brandon Warhurst wrote:
> I asked a question a while back about running "precompiled" (aka, only
> binary image, no source) code. You gave me a good answer. I finally
> got sid up and running. The question is: how do I point SID to the
> first instruction to execute? Is that where the insn-count option comes
> in? I have scoured the documentation to no avail on this point. I've
> only found a reference to setting the !run pin. Am I going to have to
> compile some sort of startup program?
This is tricky. In the hardware, presumably the ROM sits in a memory
range that includes the powerup-reset PC address. If you do the same
with sid, it should just work. If on the other hand your ROM is
not complete, you indeed need to find a way of jumping into whatever
entry point the ROM has. A related problem is just how much
initialization does your ROM thingie assume to have taken place?
> (This may be a problem seeing as
> I can't seem to compile a cross-compiler to save my life. It ALWAYS
> fails for one reason or another. Especially the arm-elf target. It
> seems to not find the correct assembler (which I apparently can
> compile). I cannot force it through any configure options to locate the
> assembler it should use once it has built xgcc. Actually, if I remember
> correctly, after stage1, it shouldn't even build stage 2 because stage 2
> is built with stage 1 meaning I couldn't even run it anyway. But for
> some reason it wishes to build stage 2.
You can try building out of the sources.redhat.com "uberbaum", which
contains an integrated source tree for gcc, binutils, the lot. The
stage2/3 thing shouldn't occur if you configured the build tree with
the usual "--target=arm-elf" option.
> Anyway, I think I'm much closer if I can just figure out how to start
> SID running the code and get GDB in there, I'll get exactly what I want.
With GDB, this is possible without extra startup binaries. Start sid as
before, but add the "--gdb=PORT#" argument, and connect an arm-elf-gdb
instance there. SID will just sit there, before startup. Then you can
issue a PC change from within GDB, as in something like:
(gdb) jump * 0xdeadbeef
- FChE
parent reply other threads:[~2003-04-24 19:12 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <3EA8346E.5060804@netscape.net>]
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=20030424191231.GA3373@redhat.com \
--to=fche@redhat.com \
--cc=sid@sources.redhat.com \
--cc=warhurst_brandon@bah.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).