Further modularization ideas

[Dave]

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

AW: Further modularization ideas

[Stephan Müller]

> 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.

Perhaps an interface for some NICs. (Telnet)
We can try to get specs of 3Com and other popular NICs and build a simple
code that acts
as a interface between the nic and openBIOS. So we can store this
interface-code on the
bootrom-socket on the NIC. And as an option openBIOS can have an interface
for Telnet.
Or SIO. Then you can connect an ordinary terminal to a system. :)
> 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.

if more than one bootable device detected, there could be the posibility of
flashing a bootmanager-module that displays a list of bootable medias and
partitions.
> 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.

only in compiled version. Then we have to build a "customer-package" with
all available
modules inside. A menu-driven configurator that puts the desired modules
together and
packs them (LH5-algo?), so we can save much mem.

Cya,
    Stephan