Here are some ideas as to how a boot PROM might be modularized:
Boot_commander Reads boot table and calls each boot function (1)
Init_CPU Initialize CPU (2)
Init_Cset Initialize Chip set (2)
Init_MMU Initialize Memory management system (2)
Init_BUS Initialize BUS controller (2)
Init_Display Initialize VGA (2)(3)
Init_Kbd Initialize Keyboard (2)(3)
Init_Console Initialize alternate console device (3)
Init_BootDev0 Initialize First boot device (2)(4)
. Initialize other boot devices (2)(4)
Ident Identify the boot prom (5)
Prompt Prompt user (6)
Read Read boot record from boot device (7)
Validate Expand boot record, validate and store into memory (8)
Execute Execute the validated executable (9)
1) A simple executor that reads a table of addresses and executes
each program, one at a time. The table would be created by the
make file (or other utility) that links the pieces of code into
the single file burned into the PROM.
- Executor could (optionally) be responsible for initializing
an alarm card, watchdog timer or other failure detection
and notification device (for use in un-manned situations).
2) Perform minimal diagnostic, report error codes to POST address
then initialize the device.
- Maybe the first digit of the post code would show the step in the
boot process (first entry in the boot table is 1, second entry
is 2 etc)? Maybe the second should be specific to the code
running at the time??
- Maybe the POST address should be expanded to multiple
bytes for more detail? Problems with other hardware???
3) If no display device is present, default to using an alternate
device as console. This would be very useful for blind nodes
and embedded systems. A simple version of this would be to
use the serial port. I could see future versions using the IRDA
port or another communication device.
4) Check for and initialize each of the possible boot devices.
A simple system may only have one boot device, a more complex
system may have many.
5) The "ident" code makes a call to each of the other
blocks of code (listed in the boot commanders table), for
the purpose of allowing them to identify themselves,
their state and revision numbers.
6) The prompt code interacts with the user to
select the boot device (or use the default boot sequence
to pick the first avalable boot device if no response),
get a username/password or other validation id.
7) Read boot record from boot device. Maybe use the password or other
validation id to authenticate the users access to the boot device?
8) Expand the boot record into an executable. Maybe use the password
or other validation id to decrypt and expand the boot record??
9) After the boot record is expanded into memory, execute it. I suggest
this as a separate step purely for instinctive reasons. I don't
know exactly what else should be done here, maybe some cleanup?
Maybe just update the POST register?? Probably other ideas in the
future will make it a good idea to separate the execution from
expansion of the code.
I am probably missing some things. Let me know if you see something that is
missing or doesn't make sense.
Can all code be limited to using relative addressing so no linking is
necessary? Is this possible/reasonable? It would be nice to be able to
create a boot ROM by simply selecting blocks of code and listing the
starting address for each block in the executors table, no make files,
assembly, compiling or linking required.
This would be a very desirable feature. A boot prom could be assembled with
a very simple utility in any computing environment (maybe even written in
Java for portability). You would not need to have specific compilers,
assemblers or other development tools to assemble a collection of code,
create a binary and burn it into PROM.