Re: [ECOS] Re: Fw: [ECOS] diag serial port and debug serial port conflict?

["Charles Feng" <charles@zh.t2-design.com>]

Ling Su, Sorry for leaving so long. I haven't got time to look at what's
wrong with the optimized serial port initialization code. Until now we're
still using unoptimized compilation here because for us performance is not
yet a problem. Several weeks ago I tried to delete the serial port
initialization code in platform.S (or some file else, I don't remember) and
compile it with -O2. It works, but it is surely not a good solution. I think
it shouldn't be the delay loop problem. You can try to disassemble the
optimized and unoptimized code and find out what the difference is. If you
find out the problem, remember to tell me. :)
Jifl, do you have the plan to add ethernet debug support for vr4373 board?
The serial port is really too slow and problematic. Just see how painful
Ling Su is. :)

Charles

----- Original Message -----
From: "Nick Garnett" <nickg@cygnus.co.uk>
To: "Ling Su" <lingsu@palmmicro.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Thursday, August 31, 2000 1:21 AM
Subject: [ECOS] Re: Fw: [ECOS] diag serial port and debug serial port
conflict?


> "Ling Su" <lingsu@palmmicro.com> writes:
>
> > I met the same problem as descriped in following message, and I tried
what
> > Nick siad, actually I doubled the ZDEL, the result is the same. Any
> > suggestion? Thanks!
> >
>
> I do not now recall what the final solution to this problem was, but I
> know it was solved. If Charles is listening, maybe he can remember
> what the solution was.
>
>
>
>
> > -Ling
> >
> >
> > > "Charles F." <charles@202.96.178.16> writes:
> > >
> > > > I am sure they are initialized to the same speed. Yesterday I tried
to
> > use
> > > > non-optimization setting (delete the -O2 switch in general build
> > settings)
> > > > to compile ecos and it works! I guess there is something wrong with
the
> > > > optimized serial port intialization code. I have experience porting
> > WinCE to
> > > > 4373 board and once I met this kind of problem too. Am I right?
> > >
> > >
> > > This raises one possibility:
> > >
> > > The HAL_DUART_WRITE_CR() macro contains a delay loop that is used to
> > > keep the Z8530 happy. It looks like with -O2 this loop maybe being
> > > eliminated or optimized so it is too short. However, exactly the same
> > > code appears in the initialization for the stubs, and GCC shouldn't
> > > eliminate such loops. So it is not at all clear what the difference
> > > here is.
> > >
> > > I have just compiled this code with -O2 and it seems to keep the delay
> > > loop intact. Maybe your board has a faster CPU? The code is currently
> > > set up for a 133MHz part. Try changing the value of ZDEL in
> > > plf_z8530.h to something greater (and compiling with -O2) and see if
> > > that makes a difference.
> > >
> > > --
> > > Nick Garnett, eCos Kernel Architect
> > > Red Hat, Cambridge, UK
> > >
> > >
> >
> >
> >
>
>
> --
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK