Hi Michael,
> On Mon, Feb 15, 2010 at 11:30 AM, Detlev Zundel <d...@denx.de> wrote:
>> Hi Michael,
>>
>>> In continuation to my post where I explained necessity
>>> of user defined post_progress_status facility
>>> (see. http://lists.denx.de/pipermail/u-boot/2010-February/067662.html)
>>> I am looking now for the best way of causing the diagnostics output
>>> interface test to be run first. In my case it is the diagnostics LEDs test.
>>
>> Just out of interest, what exactly do you test there? Do you have any
>> way of measuring if the LEDs work or not?
>
> The test blinks the LEDs few times and performs running “1” ilumination.
> Of course only visual control is possible. 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. For this reason it makes sense to
> validate sanity of this interface as soon as possible.
I see, but still you cannot "validate" anything with such a setup at
all. You run some code and _hope_ that it will do something, so it
really isn't a "test" at all, but simply some board specific output,
right?
>>> I would like to ask which one of the possibilities is preferable:
>>> add the “diagout” test to the head of the post_list array or
>>> override the post_list with proprietary one and make changes
>>> in the board specific file.
>>> Please comment.
>>
>> As always, I would try to keep as much in common code as possible, so
>> I'd vote to prepend the entry in the global variable. After all, it
>> will be CONFIG_SYS_POST_DIAG protected, correct?
>>
>> But then again, the order of the tests should generally be from the
>> simple to the more complex, so I would really need to know what your
>> test does. I.e. will a failure in the test be a general POST failure?
>> Can it run if already available tests will fail?
>
> I supposed that running from the ROM and performing GPIO writes are
> relatively simple things.
>
> The test is not “show stopper case” as far as there is at least one available
> user interface channel to deliver test’s reports.
>
>>
>> Actually, looking at the current order, it is not very clear to me if
>> this is "optimal" in the light of the thoughts laid out in the previous
>> paragraph.
>>
>> It seems I have to think about this a little more. Does anybody else
>> have an idea if the current ordering is in any way sensible?
>
> Alternatively, this kind of testing can be done outside of the POST framework.
> Probably, the better place is the board_early_init_f?
If we agree that this piece of code really isn't a test after all, then
it is better located outside the post system, yes.
Cheers
Detlev
--
The limits of my language stand for the limits of my world.
-- Ludwig Wittgenstein
--
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
