RE: [ECOS] New GDB stubs and EDB7212, more questions

[Gary Thomas <gthomas at cambridge dot redhat dot com>]

On 13-Feb-2001 root wrote:
> Sorry guys, I've got some more dumb questions.
> 
> First, reading through the ECC's I see that there are a lot of places
> where something is assigned one value if the CPU variant is EP7211 and
> 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
> configuration? The impression I get is that things have been actively
> maintained for the 7211 and 7209, and the 7212 is not so actively
> tested.
> 

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.

> Second, I've built new stubs from the current CVS sources and
> successfully flashed them. However now I'm worse off than I was using
> the 1.3.1 stubs; I load my new binary (rebuilt, and linked against
> latest anoncvs). When I continue, the board just sits there. I
> breakpointed cyg_user_start and main and either breakpoints aren't
> working, or it never got that far, because gdb just sits there at the
> "Continuing." message. Is there some special pre-initialization I was
> supposed to add to my program?
> 
> Should the below generate a valid set of stubs for EDB7209 (with
> EP7212)?
> 
> mkdir ecos_temp
> cd ecos_temp
> ecosconfig new edb7xxx stubs  [a few "attention" messages about changing
> defaults]
> ecosconfig tree
> make
> dl_edb7xxx install/bin/gdb_module.bin 115200 /dev/ttyS0
> 

This is reasonable.  Have you also built your application from these latest
sources? 
> When I load the binary and try to single-step, I get "cannot find bounds
> of current function", so it's hard for me to see if anything is actually
> happening.

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.

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.