public inbox for sid@sourceware.org
 help / color / mirror / Atom feed
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

           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).