RE: [ECOS] printf

RE: [ECOS] printf

[Fabrice Gautier]

> -----Original Message-----
> From: Grant Edwards [ mailto:grante@visi.com ]
> Subject: Re: [ECOS] printf
> 
> > 
> > The best way would be for eCos to use semihosting when using a
> > JTAG device... Does the soon(?)-coming ARM Integrator port plan
> > to suport that?
> 
> I don't see how you could do semihosting when using JTAG.  

Multi-ICE, AXD (the new ARM Debugger) and the ARM C library do it very well.
This is done using a software interrupt. Somehow the debugger or the
multi-ICE catch the call in the swi handler (a breakpoint) then I guess that
the Multi-ICE should detect the parameter passed to the software interrupt,
execute the function on the host set the result in the target and then
restart the target.
 
> AFAIK, user code on the ARM has no access at all to the ICE
> macrocell, so there's no way for application code to send or
> get data from something at the other end of the JTAG port.

In fact it's more like the host loading the information from the target than
the target sending the information throught the JTAG. The target just has to
write his parameters in a well defined set of register.

> The
> Angel Debugging Protocol used by some JTAG interfaces has
> support for semihosting, but I think it's only used if you're
> using the Angel monitor (or other user SW) to process ADP
> packets on the ARM.

I guess the Multi-ICE and other ARM product also use ADP. (even ARMulator
support semihosting )

In the ARM debugger you have some options to enable or disable semihosting,
so probably your gdb would have to handle the call. I think the ARM debugger
has some DLL to do that. The easiest way to handle that with eCos would
probably to have some kind of translator program that catch and handle the
semihosted calls

Regards,
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] printf

[Grant Edwards]

On Thu, Dec 07, 2000 at 10:30:17AM -0800, Fabrice Gautier wrote:

> > > The best way would be for eCos to use semihosting when using a
> > > JTAG device... Does the soon(?)-coming ARM Integrator port plan
> > > to suport that?
> > 
> > I don't see how you could do semihosting when using JTAG.  
> 
> Multi-ICE, AXD (the new ARM Debugger) and the ARM C library do
> it very well. This is done using a software interrupt. Somehow
> the debugger or the multi-ICE catch the call in the swi handler
> (a breakpoint) then I guess that the Multi-ICE should detect
> the parameter passed to the software interrupt, execute the
> function on the host set the result in the target and then
> restart the target.

OK, I can see how that could work.  The user-code doesn't
really do anything with the JTAG interface, it just calls a
dummy output routine (in the printf example) and expects some
sort of devine intervention to notice the call and do something
about it.  Assuming the C compiler doesn't notice that nothing
is being done and optimize the whole thing away completely. :)

> > The Angel Debugging Protocol used by some JTAG interfaces has
> > support for semihosting, but I think it's only used if you're
> > using the Angel monitor (or other user SW) to process ADP
> > packets on the ARM.
> 
> I guess the Multi-ICE and other ARM product also use ADP. (even
> ARMulator support semihosting )

If the JTAG box (Jeeni or Multi-ICE or whatever is generating
ADP packets) does handle semi-hosting functionality and sends
data to the debugger using the appropriate "channel" (or
whatever it's called) of the ADP connection, then it should be
pretty simple for the rdi target code to pass that data up to
gdb using the same method the "O" packet handler does in the
remote target code does.  That could provide a place to which
"printf" could push bytes.  I don't know what other sort of
semi-hosting (file system access, console input) could be
supported by gdb.

OTOH, it could the debugger rather than the JTAG box that sets
the breakpoint and figures out what needs to be done when the
breakpoint is reached.  If you want that functionality built
into gdb, it would require a lot more work: gdb doesn't really
do that sort of thing.

OTOH, you might be able to do it from the gdb command line by
setting a breakpoint and defining a macro to be executed when
the breakpoint is hit.  The macro would display the parameters
of the dummy routine, and then continue.

> In the ARM debugger you have some options to enable or disable
> semihosting, so probably your gdb would have to handle the
> call. I think the ARM debugger has some DLL to do that. The
> easiest way to handle that with eCos would probably to have
> some kind of translator program that catch and handle the
> semihosted calls

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] printf

[Grant Edwards]

On Thu, Dec 07, 2000 at 07:05:41PM +0000, Dave Airlie wrote:

> I've gotten a function now that dumps either a char or a string out
> through the Jeeni debugger... I can post them .. they are not exactly
> integrated into eCos... even though you can tell by them where I started
> from (newlib has some of this already)
> 
> its up on http://www.skynet.ie/~airlied/ecos/jtag_output.c

That's way too cool.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] printf

[Dave Airlie]

Just to update...

I've gotten a function now that dumps either a char or a string out
through the Jeeni debugger... I can post them .. they are not exactly
integrated into eCos... even though you can tell by them where I started
from (newlib has some of this already)

its up on http://www.skynet.ie/~airlied/ecos/jtag_output.c

integrating into eCos is left as an exercise to the reader as I'm up the
walls the moment...

Dave.

On Thu, 7 Dec 2000, Fabrice Gautier wrote:

> 
> 
> > -----Original Message-----
> > From: Grant Edwards [ mailto:grante@visi.com ]
> > Subject: Re: [ECOS] printf
> > 
> > > 
> > > The best way would be for eCos to use semihosting when using a
> > > JTAG device... Does the soon(?)-coming ARM Integrator port plan
> > > to suport that?
> > 
> > I don't see how you could do semihosting when using JTAG.  
> 
> Multi-ICE, AXD (the new ARM Debugger) and the ARM C library do it very well.
> This is done using a software interrupt. Somehow the debugger or the
> multi-ICE catch the call in the swi handler (a breakpoint) then I guess that
> the Multi-ICE should detect the parameter passed to the software interrupt,
> execute the function on the host set the result in the target and then
> restart the target.
>  
> > AFAIK, user code on the ARM has no access at all to the ICE
> > macrocell, so there's no way for application code to send or
> > get data from something at the other end of the JTAG port.
> 
> In fact it's more like the host loading the information from the target than
> the target sending the information throught the JTAG. The target just has to
> write his parameters in a well defined set of register.
> 
> > The
> > Angel Debugging Protocol used by some JTAG interfaces has
> > support for semihosting, but I think it's only used if you're
> > using the Angel monitor (or other user SW) to process ADP
> > packets on the ARM.
> 
> I guess the Multi-ICE and other ARM product also use ADP. (even ARMulator
> support semihosting )
> 
> In the ARM debugger you have some options to enable or disable semihosting,
> so probably your gdb would have to handle the call. I think the ARM debugger
> has some DLL to do that. The easiest way to handle that with eCos would
> probably to have some kind of translator program that catch and handle the
> semihosted calls
> 
> Regards,
> 

-- 
      David Airlie, Software Engineer, Parthus Technologies plc.,
       Mary Rosse Centre, National Tech Park, Limerick, Ireland.
   t: +353-61-508116 / f: +353-61-508101 / David.Airlie@parthus.com

Re: [ECOS] printf

[Jonathan Larmour]

Dave Airlie wrote:
> 
> Just to update...
> 
> I've gotten a function now that dumps either a char or a string out
> through the Jeeni debugger... I can post them .. they are not exactly
> integrated into eCos... even though you can tell by them where I started
> from (newlib has some of this already)
> 
> its up on http://www.skynet.ie/~airlied/ecos/jtag_output.c
> 
> integrating into eCos is left as an exercise to the reader as I'm up the
> walls the moment...

This is useful, and very obviously based on newlib :-), but that's no big
deal since I've just checked and these bits were in fact written by our own
Nick Clifton so no copyright worries.

Would someone be prepared to munge this, test it and put it in a patch? We
don't have any Jeenis here so I couldn't really. One issue is that all
haldiag stuff is platform-specific, but this code would probably be usable
across all ARM platforms. But if someone is prepared to do it for one
platform, I'll see if I can extrapolate to the others.

Another is that cyg_hal_plf_jtag_getc is not written. But this would almost
certainly be all it needs:

static bool
cyg_hal_plf_jtag_getc(char *c)
{
  do_AngelSWI(SYS_READC, (unsigned int *)c);
}

Volunteers? I'd hate this useful feature to not get in.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] printf

[Andrew Lunn]

On Wed, May 10, 2006 at 12:29:44PM +0200, Emmanuel Viollet wrote:
> Hi (again... ;) )
> 
> I know I must be becoming a bit of a pain, but eCOS is really new to me, 
> and I'm sometimes quite lost...
> 
> I'm having trouble compiling the following program :
> /* this is a simple hello world program */
> #include <stdio.h>
> 
> int main(void)
> {
> printf("Hello, eCos world!\n");
> return 0;
> }
> 
> Compilation works fine. But the linker complains that printf() is missing.

eCos is made of packages. The libc is made from a number of such
packages: CYGPKG_LIBC_I18N, CYGPKG_LIBC_SETJMP CYGPKG_LIBC_SIGNALS 
CYGPKG_LIBC_STARTUP CYGPKG_LIBC_STDIO CYGPKG_LIBC_STDLIB
CYGPKG_LIBC_STRING CYGPKG_LIBC_TIME.
  
Normally you use a templete to select a group of packages. eg there is
the net template, the posix template, the minimal template, the
default etc. Most templetes contain all of libc. The exceptions are
stubs and cygmon and redboot (which you shouldn't use for application
anyway), minimal, lwip_ppp, lwip_eth.

lwip_* only contain the part of libc they actually need, ie strings.
If you want stdio, you need to add the package
CYGPKG_LIBC_STDIO. Alternatively, just use diag_printf() which always
exists.

        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

[ECOS] printf

[Emmanuel Viollet]

Hi (again... ;) )

I know I must be becoming a bit of a pain, but eCOS is really new to me, 
and I'm sometimes quite lost...

I'm having trouble compiling the following program :
/* this is a simple hello world program */
#include <stdio.h>

int main(void)
{
 printf("Hello, eCos world!\n");
 return 0;
}

Compilation works fine. But the linker complains that printf() is missing.
How are the different parts of the C library defined? I suppose that 
it's possible to implement a subset of the ANSI specifications, but I 
can't find how this is done in the configuration tool.
Any links?

In advance, thanks.

-- 
Emmanuel Viollet
Software engineer
Webdyn
e-mail : Emmanuel.Viollet@webdyn.com
Tel    : +33 (0)1 39 04 29 55


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

[Jonathan Larmour]

Joerg Rapka wrote:
> 
> Hello all
> 
> The default console device is set by the configuration (e.g.
> CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE="/dev/tty0").
> Can this configuration be overridden by the application? 

Obviously it can be overridden in the configuration at configuration time.

> I have two serial
> lines and the application
> should select one for printf.

Presumably you are instead wanting to change it dynamically at run time.
The normal way to do this is freopen() on stdout, but I notice that
freopen(), while by the letter standards compliant, isn't fully
implemented. An fclose() and fopen() on stdout may just work though.

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

[ECOS] printf

[Joerg Rapka]

Hello all

The default console device is set by the configuration (e.g.
CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE="/dev/tty0").
Can this configuration be overridden by the application? - I have two serial
lines and the application
should select one for printf.


Thanks for hints,
Joerg

Re: [ECOS] printf

[Grant Edwards]

On Wed, Dec 06, 2000 at 02:07:39PM -0800, Fabrice Gautier wrote:
> > -----Original Message-----
> > From: Jonathan Larmour [ mailto:jlarmour@cygnus.co.uk ]
> > Subject: Re: [ECOS] printf
> > 
> > Ilko Iliev wrote:
> > > 
> > > Hi all!
> > > 
> > > I have successful compiled hello.c from eCOS examples. I start
> > > the program with arm-elf-gdb (with simulator and JTAG wiggler).
> > > It hangs by printf().
> > > 
> > > How work printf()? Where is the printf() output?
> > 
> > On the relevant serial line of your target. But if you are not
> > using the serial line for debugging, then you will need to
> > configure eCos to use the serial line directly, and not wrap
> > things in GDB packets.
> 
> The best way would be for eCos to use semihosting when using a
> JTAG device... Does the soon(?)-coming ARM Integrator port plan
> to suport that?

I don't see how you could do semihosting when using JTAG.  

AFAIK, user code on the ARM has no access at all to the ICE
macrocell, so there's no way for application code to send or
get data from something at the other end of the JTAG port.  The
Angel Debugging Protocol used by some JTAG interfaces has
support for semihosting, but I think it's only used if you're
using the Angel monitor (or other user SW) to process ADP
packets on the ARM.

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] printf

[Fabrice Gautier]

> -----Original Message-----
> From: Jonathan Larmour [ mailto:jlarmour@cygnus.co.uk ]
> Subject: Re: [ECOS] printf
> 
> Ilko Iliev wrote:
> > 
> > Hi all!
> > 
> > I have successful compiled hello.c from eCOS examples.
> > I start the program with arm-elf-gdb (with simulator and 
> JTAG wiggler).
> > It hangs by printf().
> > 
> > How work printf()? Where is the printf() output?
> 
> On the relevant serial line of your target. But if you are 
> not using the
> serial line for debugging, then you will need to configure 
> eCos to use the
> serial line directly, and not wrap things in GDB packets.

The best way would be for eCos to use semihosting when using a JTAG
device...
Does the soon(?)-coming ARM Integrator port plan to suport that?

Regards,

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] printf

[Jonathan Larmour]

Ilko Iliev wrote:
> 
> Hi all!
> 
> I have successful compiled hello.c from eCOS examples.
> I start the program with arm-elf-gdb (with simulator and JTAG wiggler).
> It hangs by printf().
> 
> How work printf()? Where is the printf() output?

On the relevant serial line of your target. But if you are not using the
serial line for debugging, then you will need to configure eCos to use the
serial line directly, and not wrap things in GDB packets.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

[ECOS] printf

[Ilko Iliev]

Hi all!

I have successful compiled hello.c from eCOS examples.
I start the program with arm-elf-gdb (with simulator and JTAG wiggler).
It hangs by printf().

How work printf()? Where is the printf() output?


best regards
Ilko