Hi -

On Wed, Aug 21, 2002 at 07:15:24PM +0100, Robert Cragie wrote:
> [...]
> If I specify --trace-semantics in the sid command line I get the following:
> 
> 0x8040: LDR_PRE_INC_IMM_OFFSET	gr[0]:=0x8048
> 0x8044: MOV_REG_IMM_SHIFT	pc:=0x8048
> 0x8048: LDR_PRE_INC_IMM_OFFSET	gr[0]:=0xb000020
> 0x804c: STR_PRE_INC_IMM_OFFSET	memory[0xb000020]:=0xb000020
> 0x8050: AND_REG_IMM_SHIFT
> 0x8054: AND_REG_IMM_SHIFT
> 0x8058: AND_REG_IMM_SHIFT
> 0x805c: AND_REG_IMM_SHIFT
> 
> ...AND_REG_IMM_SHIFT looks like andeq r0,r0,r0 to me (i.e. NOP). [...]

Yup.

> On the PID board, 'str r0,[r0]', where r0 is 0xb000020, changes the mapping
> of the PID board mapping RAM to 0x0000000 instead of ROM - if the REMAP
> board link (LK18) is in place. [...]

Aha.  The remapper is indeed involved, as is the eCos startup sequence.
It seems that after the access to 0xb000020, the 0x0-0xffff mapping window
into 0x4000000 disappears.  In such circumstances, the code can only work
if the running PC switches over to the ROM area (0x40008048).  In some
versions of eCos, this is forced by the first few instructions, apparently
not yours.

There are a couple of possible workarounds.  If you are positive that your
eCos application will run correctly on a board of interest, then you could
toggle sid's remapper setting (add "-normalmap" to the "--board" argument 
sublist as in "--board=pid7t-normalmap").  Other ways would involve tweaking
the eCos startup sequence, or the executable, or sid loading/startup.

Please be aware that in your given mode, sid is attempting to emulate a board
just after powerup.  If your application assumes that it's being loaded by
an already-running monitor, such mismatches need to be corrected some way.


- FChE