This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: download application with tcp/ip



This message is not in MIME format at all.  This makes it easier to read.

"Nicolas Gerber" <nge@teamlog.fr> writes:

> I want to download program via the tcp port, with a Cirrus Logic edb7xxx
> target.  So, i would like to get my tcp/ip stack in flash memory.
> Is it possible to create a gdb stub with config tool which include the
> tcp/ip stack in order to debugg my application via ethernet?

Of course it's possible.  This is software, you have the source, *anything*
is possible. ;-)

We have not done the work to support either of these features, but we can
advise where to start.

A TCP/IP boot loader is quite easy:

The network stack as is currently available features bootp/DHCP support,
including acquisition of a "boot filename" from the DHCP server.  We also
have a tftp client - which I think is not in the Beta network stack that's
available from the web.  We do plan to make the network stack available via
anoncvs soon (intentionally vague), including the tftp client.  Watch this
space for announcements of that.

So, when the anoncvs network is available, you will easily be able to make
a little program that does the bootp thing (like the network tests do) then
uses tftp to load the specified file into RAM, then jumps to the start of
it.  You can test such a program by moving around where it lives in RAM so
that it does not destroy itself in loading the 2nd program; after that you
can build it for ROM, put it in your flash, and off you go.

The file that you load must be stripped and objcopy'd to format binary and
loaded straight into whatever start address it was built for.  Looking at
the 7211 as an example, if you want to use the default layout, for RAM
startup, rom_vectors is placed at 0x8000 so that's where you must load the
file.  Your ROM loader can use the default ROM memory layout (starting at
0xe0000000 and using RAM from 0x1000-0x7fff; if it needs more RAM you must
choose some elsewhere).  You can edit the memory layout using the MLT or by
editting the .ldi files.

TCP/IP based debug stubs are rather harder:

I *think* the GDB net protocol just sends the same textual content back and
forth down a socket as it does for serial protocol, but there might be more
to it than that.  You'd have to alter the GDB pseudo-device to read/write a
network socket and see what GDB makes of it all.  We will be working on
network debugging using eCos built-in stubs in future, but I can't be more
specific now.  (Some CygMon ports have network debug already, BTW).

I advise using the tftp method suggested above to speed up loading, then
(if you arrange to hit a hard breakpoint in your ROM app so that it stops
in the stub) you can connect to the board over serial with gdb, set the PC
to the entry point (0x8000 by default) and continue, you're then in a
normal debugging environment - but with much faster loading.

HTH,
	- Huge



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]