[ECOS] New GDB stubs and EDB7212, more questions

[ECOS] New GDB stubs and EDB7212, more questions

[root]

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.

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

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.

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

[Jonathan Larmour]

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.

Don't read too much into the actual #defines. Some of them can be
misleading because of how they are set (if you are interested look at
CYGPKG_HAL_ARM_EDB7XXX_CFLAGS_ADD in the CDL).

Instead simply make sure that CYGHWR_HAL_ARM_EDB7XXX_VARIANT is set to
EP7212.

> 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]

At this point change CYGHWR_HAL_ARM_EDB7XXX_VARIANT

> ecosconfig tree
> make
> dl_edb7xxx install/bin/gdb_module.bin 115200 /dev/ttyS0
> 
> 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.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

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

[Gary Thomas]

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.

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

[Lewin A.R.W. Edwards]

Hello, Jonathan!

>root wrote:

I'm sorry, I will control my root in future ;) I'd just been updating 
something and was still logged in as root.

> > 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
>
>Don't read too much into the actual #defines. Some of them can be
>misleading because of how they are set (if you are interested look at

OK, I will ignore it...

> > mkdir ecos_temp
> > cd ecos_temp
> > ecosconfig new edb7xxx stubs  [a few "attention" messages about changing
> > defaults]
>
>At this point change CYGHWR_HAL_ARM_EDB7XXX_VARIANT

It didn't make any difference, unfortunately.


=== 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."

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

[Lewin A.R.W. Edwards]

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