Dear Michael Zaidman, In message <660c0f821003230641s5716a04cn2b15becf7c457...@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: w...@denx.de You have the capacity to learn from mistakes. You'll learn a lot today. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
