From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Zaidman Date: Thu, 11 Feb 2010 10:53:36 +0200 Subject: [U-Boot] POST related question In-Reply-To: References: <660c0f821002100159i1a956edfx1c76945042f51954@mail.gmail.com> <20100210132826.3221C4C04E@gemini.denx.de> <660c0f821002100633p25db73aaybd3aa42fca94f4e1@mail.gmail.com> <660c0f821002100636l2e6f892ak7e435d7b069ed371@mail.gmail.com> Message-ID: <660c0f821002110053r651933cbl7e2e6f7030ab367c@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wed, Feb 10, 2010 at 5:54 PM, Detlev Zundel 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