[U-Boot] The post_list array order change

Michael Zaidman michael.zaidman at gmail.com
Tue Feb 16 14:56:47 CET 2010


On Tue, Feb 16, 2010 at 2:02 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Michael Zaidman,
>
> In message <660c0f821002160239w30d02211k66cd1df24c987094 at mail.gmail.com> you wrote:
>>
>> >> The test blinks the LEDs few times and performs running "1"
>> >> ilumination. Of course only visual control is possible. The general
>> >
>> > This is not acceptable as a POST then. Only sich tests can be used
>> > where it is possible to automatically detect the test result. Tests
>> > that require interactive handling or manual inspection as in your case
>> > do not fit into this setup.
> ...
>> Ok, got it. I moved the diagnostics LEDs sanity test into misc_init_f which=
>>  is
>> called even earlier than post_init_f.
>
> You may of course do that - it's your local code after all. But I tend
> to believe that this does not make much sense. Interactive tests
> should be run at a time when interaction is supported, i. e. _after_
> relocation to RAM.
>
You are right in general, but here we are targeting different purpose rather
than interactively confirm pass or failure. I tried to explain it in
this thread -
"The general idea behind adding simplest user interface
(what the GPIO LEDs are pretended to be) is to supply earlier possible
indication about board status in the cases where board was stuck before
serial console is available or in the field where there is not the serial
console at all" and in my previous posting.
http://lists.denx.de/pipermail/u-boot/2010-February/067662.html.
In order to relate on this indication we must be sure it is operating correctly.
It could be done by observing diagnostics LEDs performing running "1" pattern
or any different algorithm which user is expected. Only afterwards we may
be sure that we correctly interpret number and result of specific POST test
which is indicated on the diagnostics LEDs.

Thanks,
Michael.


More information about the U-Boot mailing list