public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
Cc: "Ecos-List \(E-mail\)" <ecos-discuss@sourceware.cygnus.com>
Subject: Re: [ECOS] communications channel concepts
Date: Sat, 16 Sep 2000 08:48:00 -0000	[thread overview]
Message-ID: <39C3965F.74666B95@redhat.com> (raw)
In-Reply-To: <8AE4B526B977D411841F00A0CC334020052C5A@cuz-exchange.sdesigns.net>

Fabrice Gautier wrote:
> 
> Hi,
> 
> I'm still confused about the communication channel concept in eCos.
> What I'm saying is based on what I've seen on the 1.3.1 release and
> particulary in the i386 platform.

The i386 platform is not a good example unfortunately. No-one is currently
keeping it up-to-date.

> For example I think there is a confusion between the diag channel and the
> gdb channel.
> And for what I've seen in the code, the gdb debug channel is always com1 and
> 38400 bauds (except if you hack the stub).

That is a failing fairly specific to the i386 pc target.

> But either the diag channel is com1 or com2, there is still an
> initialization of the com port. When the diag channel is the same as the gdb
> channel we shouldn't need this.

There is rarely any harm in reinitializing it - it's not like it could
possibly work if you tried to use different baud rates on the same port
anyway, so the settings must be the same.

> And it don't understand very well how the
> gdb stub and the diag channel send and receive chars. It would be logical to
> have a read function for the stub and a read function for the diag channel,
> and maybe when the channel is the same one would call the other but in the
> current code i can't see a clear distinction between waht belong to the
> stub, and what belong to the diagnostic stuff.
> 
> It seems that the last cvs update bring a lot of new stuff, Redboot and all,
> Is there any stuff adressing this problems ?

Yes, but not for the i386-pc target. We now use a system called virtual
vectors which rationalizes the stub and diag output, and allows better
interworking between a ROM stub and a running program.

Look at the ARM PID target in CVS. It has a good example of how it works
because it (like the PC) has two serial ports.

> I've seen that RedBoot only use ethernet for the moment.

No, it uses serial as well. 

> What shoudl be the
> amount of work to have serial support for Redboot? What kind of driver does
> redboot would use? the common eCos serial driver or a special serial driver
> (like this is the case currently for the gdb stubs)

The i386 pc target would need to be converted to use virtual vectors for
the diag routines. There would need to be some extra work involved to port
RedBoot as well. It doesn't use a special serial driver.

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

      reply	other threads:[~2000-09-16  8:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-15 16:56 Fabrice Gautier
2000-09-16  8:48 ` Jonathan Larmour [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39C3965F.74666B95@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=Fabrice_Gautier@sdesigns.com \
    --cc=ecos-discuss@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).