[U-Boot] [PATCH 1/3] [RFC] Add support for early serial debug console

[Wolfgang Denk]

Dear Peter Tyser,

In message <1218877618.24773.49.camel at ptyser-laptop> you wrote:
> 
> If the debug console is being used, it would generally mean that the
> board is not bootable.  Thus the absolute worst (and somewhat unlikely)
> outcome of using the debug console would be to render the already
> unbootable board further unbootable.

Well, that's definitely the point where you want to attach your
debugger.

> >From my experience, there are a few shortcomings to using a debugger to
> bring up a board and diagnose hardware issues:
> 1. Its time consuming/complicated to accurately diagnose hardware issues

Isn't that always the case, no matter which tools you use? ;-)

> 2. Its much harder to bring out "tricky" issues like floating DDR
> address lines, improper DDR termination, improper CPU DDR timing
> parameters, etc

Hm... I'm not sure why you think so. But of course there  are  always
situations where special debug code may be necessary. I guess many of
the  U-Boot  developers  have  their  own  special  bag of tricks and
snippets of code they pull out when needed. All this stuff is usually
pretty useful in the given situations, but it is not adequate  to  go
into the mainline U-Boot source tree.

> 3. Not everyone has a debugger readily available

OK. Then you have to dig deeper in your bag of tricks, of course.  On
the  other  hand  you should consider how much time you spend and how
much a BDI3000 costs, and which on eis cheaper.  If  you  are  not  a
student,  and this is not a one-time job for you, the investment into
a BDI3000 always wins.

> 4. Some boards might not have JTAG/debugger signals brought out to a
> header at all, which makes using a debugger impossible

And how do you program U-Boot to flash then?

Frankly, in such a situation you should find out the hardware guy who
is responsible for such a design and kick him really  hard  where  it
really hurts until he gives you a written guarantee never again to do
such a stupid thing.

> I personally feel that a debugger is not always the best tool for
> initial board bringup/debugging.  After manufacturing, we program the
> majority of our boards over the PCI bus (much faster than JTAG), then

Sure. There are many ways to skin a cat. For  example,  many  of  our
customers  fit  pre-programmed  flashes  on their boards. That's even
faster :-)

> run them through a manufacturing test from U-Boot/Linux.  Assuming some
> hardware tests fail, it is no trivial matter to modify JTAG tests to try
> and narrow down the problem.  Having access to a basic debug console
> greatly speeds up this debug process.

If this works for you, fine.

> I don't disagree that the implementation isn't the cleanest, but I
> really do think an early debug console is very useful for board bringup,
> debug, tuning, etc.  In my opinion, the few extra bytes of memory the
> feature adds and the 20 lines of convoluted code are outweighed by the
> usefulness of the feature.
> 
> Is there any way the debug console could be implemented in a cleaner
> manner that would be more readily accepted into U-Boot mainline?

Given the inherent severe  limitations  of  the  implementation,  the
added  code  complexity and the fact that it's only useful for a very
small percentage of use cases, I tend to reject it.

It's weekend, and not many people are active now. Let's  wait  for  a
few  more  days  if  anyboy  shows  up with arguments to support your
patches.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
COBOL is for morons.                                 -- E.W. Dijkstra