[U-Boot] POST related question

[U-Boot] POST related question

[Michael Zaidman]

Hello,

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.

Thanks,
Michael

[U-Boot] POST related question

[Michael Zaidman]

On Wed, Feb 10, 2010 at 3:28 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Michael Zaidman,
>
> In message <660c0f821002100159i1a956edfx1c76945042f51954@mail.gmail.com>
you wrote:
>>
SGVsbG8sCgpXb3JraW5nIG9uIHRoZSBQT1NUIGZvciBvdXIgYm9hcmQgKHdoaWNoIEkgYW0gZ29p
...
>
> Please do not send base 64 encoded messages.
>
> Please do not send HTML messages.
>
> Please send plain text only.
>
> Message unreadable, ignored. Sorry.
>
>

Ok, sorry, I re-post my question again.

Hello,

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.

Thanks,
Michael

[U-Boot] POST related question

[Michael Zaidman]

On Wed, Feb 10, 2010 at 4:33 PM, Michael Zaidman
<michael.zaidman@gmail.com> wrote:
>
>
> On Wed, Feb 10, 2010 at 3:28 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Michael Zaidman,
> >
> > In message <660c0f821002100159i1a956edfx1c76945042f51954@mail.gmail.com> you wrote:
> >> SGVsbG8sCgpXb3JraW5nIG9uIHRoZSBQT1NUIGZvciBvdXIgYm9hcmQgKHdoaWNoIEkgYW0gZ29p
> ...
> >
> > Please do not send base 64 encoded messages.
> >
> > Please do not send HTML messages.
> >
> > Please send plain text only.
> >
> > Message unreadable, ignored. Sorry.
> >
> >
>
Ok, sorry, I re-post my question again.

Hello,

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.

Thanks,
Michael

[U-Boot] POST related question

[Detlev Zundel]

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?

Cheers
  Detlev

-- 
It's very important  that you sleep because that's  when your brain is
garbage  collecting.  And a  dream is  if you  are interrupted  in the
middle and have junk left in the registers.
                                          -- Gerald Sussman
--
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

[U-Boot] POST related question

[Michael Zaidman]

On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel <dzu@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?
>
> Cheers
> ?Detlev
>
> --
> It's very important ?that you sleep because that's ?when your brain is
> garbage ?collecting. ?And a ?dream is ?if you ?are interrupted ?in the
> middle and have junk left in the registers.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- Gerald Sussman
> --
> 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
>

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?

Thanks,
Michael

[U-Boot] POST related question

[Detlev Zundel]

Hi Michael,

> On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel <dzu@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

[U-Boot] POST related question

[Michael Zaidman]

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

[U-Boot] POST related question

[Detlev Zundel]

Hi Michael,

> 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.

Yes, I was thinking of adding such weak calls before and after the
individual calls to the test routines themselves.

Cheers
  Detlev

-- 
Just the omission of Jane Austen's books alone would make a fairly
good library out of a library that hadn't a book in it.
                               -- Mark Twain
--
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

[U-Boot] POST related question

[Michael Zaidman]

On Thu, Feb 11, 2010 at 1:43 PM, Detlev Zundel <dzu@denx.de> wrote:
> Hi Michael,
>
>> 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.
>
> Yes, I was thinking of adding such weak calls before and after the
> individual calls to the test routines themselves.
>
> Cheers
> ?Detlev
>
> --
> Just the omission of Jane Austen's books alone would make a fairly
> good library out of a library that hadn't a book in it.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -- Mark Twain
> --
> 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
>
Detlev,

Thanks for advice,

I will submit this patch promptly.

Regards,
Michael.