[U-Boot] The post_list array order change
Hi Detlev,
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. 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.
Thanks, Michael
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?
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?
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?
Cheers Detlev
On Mon, Feb 15, 2010 at 11:30 AM, Detlev Zundel dzu@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 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?
Cheers Detlev
-- I think that level of generalization is too abstract for useful thinking. -- Richard Stallman in E19N344-0006Q9-Bt@fencepost.gnu.org -- 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@denx.de
Hi Michael,
On Mon, Feb 15, 2010 at 11:30 AM, Detlev Zundel dzu@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
Dear Michael Zaidman,
In message 660c0f821002150322g34255468re9cf03d2ed49347f@mail.gmail.com you wrote:
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
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.
Best regards,
Wolfgang Denk
On Mon, Feb 15, 2010 at 10:32 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Zaidman,
In message 660c0f821002150322g34255468re9cf03d2ed49347f@mail.gmail.com you wrote:
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
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.
Best regards,
Wolfgang Denk
Ok, got it. I moved the diagnostics LEDs sanity test into misc_init_f which is called even earlier than post_init_f.
Thanks, Michael
Dear Michael Zaidman,
In message 660c0f821002160239w30d02211k66cd1df24c987094@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.
Best regards,
Wolfgang Denk
On Tue, Feb 16, 2010 at 2:02 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Zaidman,
In message 660c0f821002160239w30d02211k66cd1df24c987094@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.
Dear Michael Zaidman,
In message 660c0f821002160556o71b9814dl3bb35f26ff5adfbb@mail.gmail.com you wrote:
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.
Yes, I know.
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.
I have to admit that I don't understand your exact requirements. To me this makes not much sense. Classic system design would probably include a "lamp test" button where you can test the hardware - i. e. if all your LEDs / LED segments are working (but one might discuss if this is still needed with LED's - it certainly was useful with classic light bulbs that would burn through sooner or later).
A temporary display which disappears so you miss it if you don't look at the device in the right moment is not exactly the kind of user interface I would like for a function you seem to consider critical.
I know I repeat myself, but this sort of testing is something that should be done automatically, which automatically determined test results. An interactive test (user has to look at the device at the right moment and realize what some blinking LED means) is inappropriate. Just my 0.02 EUR.
Best regards,
Wolfgang Denk
Dear Wolfgang,
On Tue, Feb 16, 2010 at 5:16 PM, Wolfgang Denk wd@denx.de wrote:
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.
I have to admit that I don't understand your exact requirements. To me this makes not much sense. Classic system design would probably include a "lamp test" button where you can test the hardware - i. e. if all your LEDs / LED segments are working (but one might discuss if this is still needed with LED's - it certainly was useful with classic light bulbs that would burn through sooner or later).
Yes, I remember... (-:
A temporary display which disappears so you miss it if you don't look at the device in the right moment is not exactly the kind of user interface I would like for a function you seem to consider critical.
We are trying to address the situation when quite complicated and expansive board combining analog and digital HW is returned from the field for repair. The board is dead. No serial and Ethernet channels are operational. The technician need to understand which part/module/aria/element of the board should be replaced. After visual inspection, at some point the technician will power up the board. The first thing he will looking for are diagnostics LEDs selftest result. If he misses it he will recycle power again. At the end of the board start up the diagnostics LEDs hopefully will indicate number of the faulted or stuck POST test.
Thanks, Michael.
participants (3)
-
Detlev Zundel -
Michael Zaidman -
Wolfgang Denk