[U-Boot] POST related question

[Michael Zaidman]

On Thu, Feb 11, 2010 at 11:49 AM, Detlev Zundel <dzu at denx.de> wrote:
> Hi Michael,
>
>> On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel <dzu at 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: dzu at 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