[ECOS] More RedBoot questions

[ECOS] More RedBoot questions

[Grant Edwards]

A few more RedBoot questions:

 1) Does RedBoot require RAM that is preserved by the user
    application, or can RedBoot's bss/data/stack segments get
    clobbered by the user app?

 2) Is there any particular advantage to running RedBoot from
    RAM vs ROM?  Copying to and then running from RAM makes
    flash manipulation simpler, but running from ROM makes
    startup a little simpler.

 3) It looks like the RedBoot sources include TCP support. What
    is it used for?  Console via TCP?  Gdb via TCP?

    If I use RedBoot, I'm going to have to add support for
    downloading an image via TCP using a homebrew protocol. Is
    that going to be a herculean task?

    I'd rather ditch that use the existing tftp scheme, but
    I've got to provide a way for a host-initiated download,
    and there will be much rending of cloathing and gnashing of
    teeth if I don't support the same TCP-based scheme used by
    our other products.

    I've also got to support download via a non-IP based
    protocol, but I can put hooks for that into the Ethernet
    driver poll routine, so RedBoot need not know about it.

 4) I understand that I can still use a standalone eCos app
    with gdb stubs, but I'm a bit fuzzy on how debugging via
    RedBoot works.

    If I want to do gdb debugging of eCos apps via RedBoot,
    where are the gdb stubs located -- RedBoot or the eCos app?

    How does network debugging work once the eCos app takes over?
    Does the eCos IP stack watch for TCP packets destined for
    the gdb stubs and pass them off to RedBoot?

 5) The docs say that you can't load images via serial port
    only via Ethernet. If you can run gdb via serial port why
    can't you load images via serial port?

I've got more questions, but that's probably plenty for now.  ;)

Thanks

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] More RedBoot questions

[Jonathan Larmour]

Grant Edwards wrote:
> 
> A few more RedBoot questions:
> 
>  1) Does RedBoot require RAM that is preserved by the user
>     application, or can RedBoot's bss/data/stack segments get
>     clobbered by the user app?

If you are not going to use RedBoot at all (including for any virtual
vectors), then you can just clobber it. Of course you can't actually make
your application use that memory by changing the memory layout to put
sections there - when RedBoot loads the app, obviously it can't overwrite
itself then!

>  2) Is there any particular advantage to running RedBoot from
>     RAM vs ROM?  Copying to and then running from RAM makes
>     flash manipulation simpler, but running from ROM makes
>     startup a little simpler.

Well it uses more memory, gives more chance for something to go wrong. But
it's your call really!
 
>  3) It looks like the RedBoot sources include TCP support. What
>     is it used for?  Console via TCP?  Gdb via TCP?

Yes. Ethernet debugging including Ctrl-c support.
 
>     If I use RedBoot, I'm going to have to add support for
>     downloading an image via TCP using a homebrew protocol. Is
>     that going to be a herculean task?

I'd doubt it. If you look at redboot's src/load.c and
src/net/tftp_client.c, you'll see that all redboot expects is some fairly
simple primitives - effectively open, read, close. Unless there's something
really odd with your protocol :).
 
>  4) I understand that I can still use a standalone eCos app
>     with gdb stubs, but I'm a bit fuzzy on how debugging via
>     RedBoot works.
> 
>     If I want to do gdb debugging of eCos apps via RedBoot,
>     where are the gdb stubs located -- RedBoot or the eCos app?

Strictly either :-). With virtual vector support, the gdb stubs can stay in
redboot if you like. But if you include stubs in your app, those stubs
should be used instead if present. That's the intention anyway - we have
had a few glitches in some HALs trying to get this right.
 
>     How does network debugging work once the eCos app takes over?
>     Does the eCos IP stack watch for TCP packets destined for
>     the gdb stubs and pass them off to RedBoot?

Yes. For ctrl-c support, see io/eth/current/src/net/eth_drv.c and
specifically eth_drv_run_deliveries(). HAL_CTRLC_CHECK comes from
hal/common/current/include/hal_if.h i.e. the ethernet stack calls into
redboot using the virtual vector support. 
 
>  5) The docs say that you can't load images via serial port
>     only via Ethernet. If you can run gdb via serial port why
>     can't you load images via serial port?

The docs are out of date. You can now download using X/Y-modem. Also you
can use RedBoot's GDB stub to load into RAM, but then you lose control of
the Redboot prompt. (Although there is a workaround for this - type $k#6b
directly at the serial port and redboot will restart, but whatever you
loaded into RAM will be retained - this is not officially supported
though).

I don't know why we don't support direct loading over the serial port
though - I'd have thought it would be pretty easy. No time I suppose. Gary?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] More RedBoot questions

[Hugo Tyson]

Jonathan Larmour <jlarmour@redhat.com> writes:
> Grant Edwards wrote:

> >  5) The docs say that you can't load images via serial port
> >     only via Ethernet. If you can run gdb via serial port why
> >     can't you load images via serial port?
> 
> The docs are out of date. You can now download using X/Y-modem. Also you
> can use RedBoot's GDB stub to load into RAM, but then you lose control of
> the Redboot prompt. (Although there is a workaround for this - type $k#6b
> directly at the serial port and redboot will restart, but whatever you
> loaded into RAM will be retained - this is not officially supported
> though).
> 
> I don't know why we don't support direct loading over the serial port
> though - I'd have thought it would be pretty easy. No time I suppose. Gary?

FAOD, "load images" here means "get a binary image from a file on some
server, straight into RAM, usually in order to program it into flash"

It doesn't mean "load an image to run using GDB in the usual manner"
because of course that is supported by GDB stubs over either serial or
net.

Just in case there was confusion there.

	- Huge

Re: [ECOS] More RedBoot questions

[Jonathan Larmour]

Hugo Tyson wrote:
> >
> > I don't know why we don't support direct loading over the serial port
> > though - I'd have thought it would be pretty easy. No time I suppose. Gary?
> 
> FAOD, "load images" here means "get a binary image from a file on some
> server, straight into RAM, usually in order to program it into flash"
> 
> It doesn't mean "load an image to run using GDB in the usual manner"
> because of course that is supported by GDB stubs over either serial or
> net.

Sure. But there's a good chance that you've already got GDB sitting around,
so why not use it as the loader, rather than trying to find a terminal
emulator that reliably supports x/y-modem. Or for that matter, why not just
cat foo.bin > /dev/ttyS0 ;). If RedBoot had a checksum command, you could
verify it uploaded correctly.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Un cheval, pas du glue. Pas du cheval, beaucoup du glue. || Opinions==mine

Re: [ECOS] More RedBoot questions

[Grant Edwards]

On Mon, Jan 08, 2001 at 12:04:26PM +0000, Hugo Tyson wrote:

> > >  5) The docs say that you can't load images via serial port
> > >     only via Ethernet. If you can run gdb via serial port why
> > >     can't you load images via serial port?
> > 
> > The docs are out of date. You can now download using X/Y-modem. Also you
> > can use RedBoot's GDB stub to load into RAM, but then you lose control of
> > the Redboot prompt. (Although there is a workaround for this - type $k#6b
> > directly at the serial port and redboot will restart, but whatever you
> > loaded into RAM will be retained - this is not officially supported
> > though).
> > 
> > I don't know why we don't support direct loading over the serial port
> > though - I'd have thought it would be pretty easy. No time I suppose. Gary?
> 
> FAOD, "load images" here means "get a binary image from a file on some
> server, straight into RAM, usually in order to program it into flash"
> 
> It doesn't mean "load an image to run using GDB in the usual manner"
> because of course that is supported by GDB stubs over either serial or
> net.

That's good.  I still need to support debugging via serial port.

> Just in case there was confusion there.

A bit.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] More RedBoot questions

[Grant Edwards]

> >  1) Does RedBoot require RAM that is preserved by the user
> >  application, or can RedBoot's bss/data/stack segments get
> >  clobbered by the user app?
> 
> If you are not going to use RedBoot at all (including for any
> virtual vectors), then you can just clobber it. Of course you
> can't actually make your application use that memory by
> changing the memory layout to put sections there - when RedBoot
> loads the app, obviously it can't overwrite itself then!

I could put non-loadable sections like stack and bss on top of
RedBoot's RAM as long as I don't let my app call any of the
RedBoot system calls (virtual vectors).

> >     If I want to do gdb debugging of eCos apps via RedBoot, where
> >     are the gdb stubs located -- RedBoot or the eCos app?
> 
> Strictly either :-). With virtual vector support, the gdb stubs
> can stay in redboot if you like. But if you include stubs in
> your app, those stubs should be used instead if present. That's
> the intention anyway - we have had a few glitches in some HALs
> trying to get this right.

I'll probably try to use RedBoot to start with, but since
RedBoot is probably not going to be field-upgradable, I have to
have the option of making the eCos app completely stand alone.

-- 
Grant Edwards
grante@visi.com

[ECOS] more redboot questions

[Michael Dorin]

Ok, so I changed the memory map to use 0xfe000000
as the boot prom starting address.  That was easy.

Now, how can I build  and get a map? 
Also, is debug information included when I build?
I do have a bdm cable, I would like to step
through a bit.

Thanks,
 Mike

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