Hi -


On Thu, Aug 22, 2002 at 12:48:55PM +0100, Robert Cragie wrote:
> [...]
> Adding the -normalmap argument worked - thanks. I will point this out on the
> eCos mailing list, as the default sid flags for the RAM build won't work.

This may not concern (interest) the eCos guys.  SID can do a better job
of emulating the RAM startup environment that eCos expects.  This
"normalmap" option is just one possibility.  Another one is to actually
run a copy of RedBoot or cygmon or whatever on SID.  Then you can upload
your application via a simulated serial port, making it look to gdb etc.
much more like it was a real board.


> Next step is to try to work out why printf() doesn't work, however this
> seems to be an eCos issue. However, while I'm here, can you tell me how the
> serial ports work on the simulation (i.e. what happens when I write a
> character), or point me at some appropriate docs.?

For the pid7t configuration, sid models two uarts.  The arm-elf-sid script
can take options to let you tell it how you'd like these simulated uarts
to be connected to the real world.  This is done with more --board options.
For example "--board=pid7t-uart1:stdio-uart2:3000" would connect the
simulated uart1 to the simulator's console, and uart2 to a tcp (listening)
socket at port 3000.  One can also add a tk-based terminal window, or add
one after startup if using tksm.


> > 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.
> 
> I think I misunderstood the way the gloss component works - I guess it's
> more like an on-chip ICE than a debug monitor.

I suspect that the sid gloss component proper (simulated system calls) is
not even used in these configurations.  If you mean the usual simulator
debugging interface, then yes, that's right.


- FChE