From: "Lewin A.R.W. Edwards" <larwe@larwe.com>
To: Gary Thomas <gthomas@cambridge.redhat.com>
Cc: ecos-discuss@sources.redhat.com
Subject: RE: [ECOS] New GDB stubs and EDB7212, more questions
Date: Tue, 13 Feb 2001 10:37:00 -0000 [thread overview]
Message-ID: <4.3.2.7.2.20010213133246.00acbf00@larwe.com> (raw)
In-Reply-To: <XFMail.20010213104204.gthomas@cambridge.redhat.com>
> > another if it's EP7209. In few or no places is the 7212 mentioned. Does
> > that mean that if I configure for the 7212, I'm going to get "empty" or
> > "non-defaults" in those values? Should I leave it at the default 7211
>
>Not at all. The 7212 and 7209 are basically the same beast. The 7209
>just doesn't have a DRAM controller - everything else is identical.
>When you select 7212, you also select 7209, and everything just works.
>By my estimation, we've probably tested the 7212 more than the 7211, BTW.
OK. Actually I probably didn't phrase that very well. What I meant is that
I got the impression of the 7212 configuration being derived from one of
the existing configs, and maybe someone hadn't gone through absolutely
every single thing that needed to be altered. But anyway, it's no matter -
normally everything works fine for me.
>This is reasonable. Have you also built your application from these latest
>sources?
Yes.
>Do you have a separate build tree for your application code? You need to
>have a separate configuration for RAM based programs than with the ROM based
>stubs. Thus you can't use the same tree for both.
What I do is to maintain three directories: "ecos" (current), "ecos_rom"
and "ecos_ram". I keep a built copy of the library/header/etc in each of
those directories. The makefile for my main project references "../ecos"
and so when I want to switch configs I do make clean in my project
directory, then cp -r ../ecos_rom/* ../ecos (or cp -r ../ecos_ram/*
../ecos) and rebuild my application.
>If you continue to have troubles, you can send me a binary you've built for
>the 7212/RAM and I'll look at it. Note: send it to me privately so as not
>to clog the mailing list.
OK, I will do - thanks. I've got a couple of other quick debuggery things
to try.
I do have one other issue: when I build for ROM target with the anoncvs
sources, I get a #error "no RESET_ENTRY". Reading the appropriate
sourcefile I see what that is all about, but I don't know where would be an
appropriate _portable_ place to define my own reset entry point. Where
should I define that?
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/
"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."
prev parent reply other threads:[~2001-02-13 10:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-13 9:06 root
2001-02-13 9:27 ` Jonathan Larmour
2001-02-13 10:29 ` Lewin A.R.W. Edwards
2001-02-13 9:42 ` Gary Thomas
2001-02-13 10:37 ` Lewin A.R.W. Edwards [this message]
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=4.3.2.7.2.20010213133246.00acbf00@larwe.com \
--to=larwe@larwe.com \
--cc=ecos-discuss@sources.redhat.com \
--cc=gthomas@cambridge.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).