On Thu, Feb 11, 2010 at 11:49 AM, Detlev Zundel <d...@denx.de> wrote: > Hi Michael, > >> On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel <d...@denx.de> wrote: >>> Hi Michael, >>> >>>> Working on the POST for our board (which I am going to submit >>>> to the u-boot in the near future) I was asked to output the POST tests >>>> sequence progress to the dedicated LEDs (current test’s index and >>>> test’s result – PASS or FAIL) in addition to the conventional console >>>> output. Such indication can be helpful at the customer premises when >>>> console is not available as well as at the production testing/diagnostics >>>> to understand which POST test has failed while serial console does not >>>> show signs of life. >>>> In order to fulfill this requirement I see two possibilities: >>>> >>>> 1) Common infrastructure change - add pre-test and after test callbacks >>>> to the post_test structure in the tests.c file. Call these callbacks >>>> before and after each POST test in the post_run_single routine of post.c >>>> file. >>>> >>>> 2) Local, board specific change – duplicate all necessary POST tests into >>>> specific board folder and add output to LEDs interface into every >>>> xxxx_post_test routine. >>>> >>>> Please advise. >>> >>> Thinking about it, why can't we 3) introduce show_post_progress(). It >>> seems to me that the show_boot_progress (grep the README) implements >>> exactly the same idea for the boot process, so it would make sense to >>> re-use the implementation idea. Nowadays we could solve the overrideing >>> with weak functions. >>> >>> What do you think? >>> > > [...] > >> Actually the option #3 is very similar to the #1 option about which I thought >> also before my first post… However, option #1 has few advantages as: >> >> a) Flexibility - it is not restricted to the progress status only; >> rather it can be >> customized for additional functionality such as printing of extended user >> notification before and after specific test or doing something else… >> >> b) In the case of slow POST tests it will be especially helpful to know >> which >> test is currently executing, immediately at the beginning of the test (form >> within pre-test phase) while the test’s results will come long time after >> this >> moment and can be indicated via after-test phase. >> >> Again, we need such indication only when POST output for some reason is >> not available via serial console. >> >> Of course, these pre/after callbacks can be added explicitly at the >> beginning/end >> of every post test (what is actually the option #3) but making them to >> be a part of >> the post_test structure keeps code smaller and more readable. >> >> I agree that the show_boot_progress is good approach in general but in the >> POST >> system where we have the callback infrastructure already in place why >> do not use >> its advantages? > > Ok, maybe we should get more specific here. If I understand you > correctly, your original option #1 would add two callback fields to the > post_test structure post_list in tests.c, right? I believe this to be > real overkill - this allows for potentialle 2 times the number of tests > different functions to be called, whereas I would imagine that at most > two functions will be used in reality, i.e. one before a test runs - > called with an argument of what test will be started - and one after the > test ran - again called with an argument indicating the test. > > My original idea of only onw function still makes sense to me in that I > myself would want to keep the code doing indications to the user in one > central place. So maybe we could have a show_post_progress(int index, > int before, int result) which is called from the common infrastructure > with the corresponding values before and after a test. In this setup > one should be able to produce meaningful output through whatever means > are available and it boils down to very little code in the end. > > Do you believe you need more flexibility? > > Cheers > Detlev > > -- > The structure of a system reflects the structure of the organization > that built it. > -- Richard E. Fairley > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de >
If I understand you correctly, you suggest adding of direct “weak” calls before and after call to POST test callback in the post_run_single routine of post.c file instead of adding callbacks to the post_test structure. Agree, its has the same measure of flexibility. Thanks, Michael _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
