Boot sequence callouts?

[Dave Richards]

I think this is an excellant approach and I've used it in the past.  The
rationale I apply is as follows:

	1. You know the executive is valid,
	2. You don't know the BSP is valid (you assume it's not),
	3. You may not know if the board is valid

How do you attack this problem?  You can use whatever platform-dependent
mechanism is available to you to debug the boot loader and pre-executive
initialization BSP code.  Once you call Initialize_Executive, though, now
what?  You know (assumption 1) that the kernel is valid, so if you don't get
very far you must assume your BSP (or possibly board) is invalid.  But which
part?  A CPU info callback which makes you aware of the executive's progress
will let you know pretty quickly where to start looking.  If code 10 is
"initializing heap" and you die, then you can guess that your memory sizing
parameters may be wrong, for example.

This is effectively the approach used by PC BIOSes.  It's very handy.  At
work, we implemented a port 80 POST code decoder in an FPGA for exactly this
purpose.  We shipped the product with the decoder and port 80 software
enabled.  The customer will never know or care, and its useful in
manufacturing/test.

I applaud the approach.  Most of the "work" would be in the executive, IMO.

I would suggest the code space be kept to one byte (UARTs could dump this as
2 nybbles with relative ease).  7-segment or discrete LEDs could either
blast it out as a byte like PC POST code cards, or multiplex it as
necessary.

I would reserve a chunk of the code space for the boot loader / BSP so they
can use the same mechanism as the exectuive without getting in each others
way.  (They will anyway, but at least the output will indicate which entity
initiated the checkpoint).

	Dave

> -----Original Message-----
> From: Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de]
> Sent: Wednesday, August 27, 2003 6:55 AM
> To: rtems-users
> Subject: RFC: Boot sequence callouts?
>
>
> Hello,
>
> in the past, I have brought up RTEMS on various boards,
> sometimes with almost no debugging tools. Today in a private
> email contact I once again got the question "My board does not
> boot. What's wrong?".
>
> I just got an idea that might help a bit to find the reason
> for a hanging boot sequence. How about a standard callout
> function pointer (let's say "BSP_boot_checkpoint_reached")
> that is called, whenever a new part of the boot sequence has
> been reached.
>
> Normally this pointer would be NULL and therefore no call
> would be executed at all, but in the basic startup code, this
> pointer could be tweaked to a useful function (like blinking
> an LED, sending a character to the UART, beeping a beeper or
> so), just to monitor, which checkpoints have been reached (and
> which have not).
>
> My recommendation is still very rough (and I hope no software
> patents already claim this fantastic idea as IP :-> ), but
> maybe this would be of some help...
>
> Any comments appreciated,
>
> 	Thomas.
> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_keys.htm
>
>