[U-Boot] [PATCH 2/2] Added serial loopback tests accessible via CLI and POST

[Wolfgang Denk]

Dear Michael Zaidman,

In message <660c0f821003230641s5716a04cn2b15becf7c457462 at mail.gmail.com> you wrote:
> 
> > Then what is the "uart[t]est" command needed for?
> 
> For two reasons:
> 1) It gets parameters such internal/external loopback and COM number
> while "diag run uart" performs only local loopback through all COMs.
> Thus, it can be used at production to perform external loopback tests.

This does not fit into the POST framework then, it seems.

> 2) This test will be available even when compiled without POST for
> reasons of POST tests unavailability for particular cpu/board or
> specific board memory layout constrains.

I don't like such chimera code.

> > I don't get this. Where is the weak part needed? Either I have only
> > one type of UART (then the weak is not needed as only onedriver is
> > enabled), or I have both "CPU specific" and "generic" (16550 based)
> > UARTs, in which case I eventually might ant to test _both_ of them
> > (then the weak will not work).
> >
> Currently, we have only CONFIG_SYS_POST_UART which will cause both
> files to be compiled in the case of mpc8xx or ppc4xx CPUs.  Which will
> lead to the linker failure if no weak definition will be used.
> Do you mean we should do it at the makefile level by adding CONFIG_
> specifing which file should be compiled and linked?

I think this is a consequence of trying to squeeze soemthing into a
framework which doesn't fit.  POST and production test code should be
kept separate. If they share common code, fine.

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
You have the capacity to learn from  mistakes.  You'll  learn  a  lot
today.