From mboxrd@z Thu Jan  1 00:00:00 1970
From: Grant Edwards <grante@visi.com>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] More RedBoot questions
Date: Fri, 05 Jan 2001 15:38:00 -0000
Message-id: <20010105174137.B3349@visi.com>
X-SW-Source: 2001-01/msg00047.html

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