|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
printf not working in ARM simulatorHi,
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 |
|
|
Re: printf not working in ARM simulatorOn 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
|
|
|
Re: printf not working in ARM simulatorGreetings.
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: printf not working in ARM simulatorThank 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 |
|
|
Re: printf not working in ARM simulatorActually, 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 |
|
|
Re: printf not working in ARM simulatorOn 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 |
| Free embeddable forum powered by Nabble | Forum Help |