[ECOS] printf not working in ARM simulator

[ECOS] printf not working in ARM simulator

[Portos]

Hi,

We're trying to run the eCos examples such as hello.c and twothreads.c under
arm-elf-gdb with "target sim" (cygwin on a Pentium). They seem to work when
we remove the calls to printf.

We use the default configuration given by the template ARM Evaluation Board
(AEB-1), and configtool-060710.exe

malloc seems to work. Why doesn't printf work?
It hangs for a while and then exits with the message "ARMulator can't
allocate VM page: Cannot allocate memory".
On some occasions we got the message "unknown SWI encountered - ffffff -
ignoring" but we can't remember how we got it (perhaps when running Insight.
The number wasn't always ffffff).
This is similar to the message reported here:
http://ecos.sourceware.org/ml/ecos-discuss/2003-10/msg00300.html

If someone could tell us how to get printf to work under ecos and ARM
simulation mode, it would be really helpful.

Thank you,

Roy
-- 
View this message in context: http://www.nabble.com/printf-not-working-in-ARM-simulator-tp21193516p21193516.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] printf not working in ARM simulator

[Portos]

On a related note, cyg_thread_delay() also doesn't seem to work. It hangs,
perhaps because there is no active timer that is counting. It doesn't work
on a simulation platform?

Thanks,

Roy



Portos wrote:
> 
> Hi,
> 
> We're trying to run the eCos examples such as hello.c and twothreads.c
> under arm-elf-gdb with "target sim" (cygwin on a Pentium). They seem to
> work when we remove the calls to printf.
> 
> We use the default configuration given by the template ARM Evaluation
> Board (AEB-1), and configtool-060710.exe
> 
> malloc seems to work. Why doesn't printf work?
> It hangs for a while and then exits with the message "ARMulator can't
> allocate VM page: Cannot allocate memory".
> On some occasions we got the message "unknown SWI encountered - ffffff -
> ignoring" but we can't remember how we got it (perhaps when running
> Insight. The number wasn't always ffffff).
> This is similar to the message reported here:
> http://ecos.sourceware.org/ml/ecos-discuss/2003-10/msg00300.html
> 
> If someone could tell us how to get printf to work under ecos and ARM
> simulation mode, it would be really helpful.
> 
> Thank you,
> 
> Roy
> 

-- 
View this message in context: http://www.nabble.com/printf-not-working-in-ARM-simulator-tp21193516p21193556.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] printf not working in ARM simulator

[Robin Randhawa]

Greetings.

On 28 Dec 2008, at 16:03, Portos wrote:

> We're trying to run the eCos examples such as hello.c and  
> twothreads.c under
> arm-elf-gdb with "target sim" (cygwin on a Pentium). They seem to  
> work when
> we remove the calls to printf.

AFAIK, GDB's 'sim' target is more of an instruction level simulation  
and does not include
much else, timers and console centric devices included.

You would fare much better if you used a platform simulator such as  
qemu or skyeye for ARM.
Googling should provide more information.

> We use the default configuration given by the template ARM  
> Evaluation Board
> (AEB-1), and configtool-060710.exe
>
> malloc seems to work. Why doesn't printf work?
> It hangs for a while and then exits with the message "ARMulator can't
> allocate VM page: Cannot allocate memory".
> On some occasions we got the message "unknown SWI encountered -  
> ffffff -
> ignoring" but we can't remember how we got it (perhaps when running  
> Insight.
> The number wasn't always ffffff).

A lot of ARM simulators try to provide glue for implementing a semi- 
hosting system. This allows
rudimentary I/O with an external host and this scheme uses SWIs. The  
"unknown SWI" message might
be the simulation environment complaining that it doesn't know how to  
service an SWI invocation in code.

> If someone could tell us how to get printf to work under ecos and ARM
> simulation mode, it would be really helpful.

Rinse and repeat your experiments with a platform simulator is what I  
would advise.

Cheers,
Robin

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] printf not working in ARM simulator

[Portos]

Thank you Robin. We will look into emulators.

But out of curiosity, and since it's easier to work with gdb, and possibly
faster, does the gdb target simulator on cygwin have some escape sequence
that let's it print a character to the screen?

In other words, imagine a particular SWI, or "fake" instruction, or mov byte
to particular address, that once the simulator sees, it prints (or putc) the
character to the screen (cygwin prompt).

Is it easy to add such a feature to the simulator, if it doesn't exist?

gdb's watch point performs something similar but not quite. It can stop the
program when we write to a given address. But we need it to quietly print
the character without stopping the program.

Thank you,

Roy

-- 
View this message in context: http://www.nabble.com/printf-not-working-in-ARM-simulator-tp21193516p21383601.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] printf not working in ARM simulator

[Portos]

Actually, we may have found a temporary solution, a hack...

A watchpoint can call commands and resume the program.
So we can have printf send characters to some buffer (possibly hack the code
a bit for that), and when some location is changed, a watchpoint catches
that, gdb prints the content of the buffer, and then resumes execution. If
we can make watchpoint silent such that only the buffered characters are
printed, it would be ideal.

If someone knows of a clean solution along these lines, please let us know.
We'll try to implement something, otherwise.

Thank you,

Roy

-- 
View this message in context: http://www.nabble.com/printf-not-working-in-ARM-simulator-tp21193516p21388042.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] printf not working in ARM simulator

[Andrew Lunn]

On Sat, Jan 10, 2009 at 05:17:00AM -0800, Portos wrote:
> 
> Actually, we may have found a temporary solution, a hack...
> 
> A watchpoint can call commands and resume the program.
> So we can have printf send characters to some buffer (possibly hack the code
> a bit for that), and when some location is changed, a watchpoint catches
> that, gdb prints the content of the buffer, and then resumes execution. If
> we can make watchpoint silent such that only the buffered characters are
> printed, it would be ideal.
> 
> If someone knows of a clean solution along these lines, please let us know.
> We'll try to implement something, otherwise.

Take a look at the TX39 Architecture simulator. It includes a
simulated serial port, interrupt controller, timers etc. A proper
solution to your problem is to write similar simulations of your
hardware devices. 

Probably better options is to use the eCos Synth target on linux, or a
Virtual x86 machine, eg Bochs, which will also have virtual serial
ports etc, or maybe SkyEye.

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss