Here are some ideas as to how a boot PROM might be modularized:
Code Actions ---------------------------------------------------------------------------- --- 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)
Notes: 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.
Idea/question -
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.
Thoughts....Comments?
Dave