Difference between revisions of "More about the NitrOS-9 Boot file"

Revision as of 16:29, 21 May 2017

The NitrOS-9 Boot file is used during the second stage of the boot process. It contains the additional modules required to bring the system to a running state. See also The NitrOS-9 Boot Process Explained, More about the NitrOS-9 Kernel file and More about SysGo.

The Boot file is created by concatenating multiple binary modules.

This works because each NitrOS-9 module is relocatable code and because there is a header on each module which allows the modules to be treated as a linked list that is searchable by module name.

How to create a Boot file

There are two ways to create a Boot file:

• If you create a boot file during the NitrOS-9 build process, the contents of the Boot file is specified in a makefile -- typically, the makefile for a particular target will define multiple Boot file variants and create disk images for some or all of them.
• If you create a boot file on a running NitrOS-9 system, a utility called os9gen can be used to create a new Boot file and to update the pointer in LSN0. The contents of the Boot file are typically defined by a file in the NITROS9/<target>/BOOTLISTS directory. After running os9gen on a disk, rebooting the system using that disk will use the new Boot file.

Boot file examples for Level 1

The Boot files for Coco1 Level 1 are defined in level1/coco1/bootfiles/makefile

Here is the definition of a sample Boot file for Coco1 Level 1 from that file:

  BOOTFILE_COVDG  = $(MD)/ioman \
                    $(MD)/rbf.mn \
                    $(FLOPPY_40D) \
                    $(MD)/ddd0_40d.dd \
                    $(MD)/scf.mn \
                    $(VTIO_COVDG) \
                    $(MD)/scbbp.dr $(MD)/p_scbbp.dd \
                    $(MD)/scbbt.dr $(MD)/t1_scbbt.dd \
                    $(PIPE) \
                    $(CLOCK60HZ) \
                    $(MD)/sysgo_dd
   
  VTIO_COVDG      = $(MD)/vtio.dr $(MD)/covdg.io $(MD)/term_vdg.dt

The VTIO stuff is code to control text output on the memory-mapped/character mapped display, including code to do scroll under software control.

Here is an example of a minimal Boot file, from level1/mc09/bootfiles/makefile

  BOOTFILE_MC09SD = $(MD)/ioman \
                    $(MD)/rbf.mn \
                    $(MD)/dds0_80d.dd \
                    $(MC09SDC_80D) \
                    $(MD)/scf.mn \
                    $(TERM_MC09) \
                    $(PIPE) \
                    $(CLOCK50HZMC09) \
                    $(MD)/sysgo_dd
  
  TERM_MC09       = $(MD)/mc6850.dr $(MD)/term_mc6850.dt $(MD)/term_mc6850_t0.dt $(MD)/term_mc6850_t1.dt
  MC09SDC_80D     = $(MD)/mc09sdc.dr $(MD)/s0_80d.dd $(MD)/s1_80d.dd $(MD)/s2_80d.dd $(MD)/s3_80d.dd

The MC09 only supports VT100-style terminal I/O through physical and virtual UARTs, and so the VTIO modules are not needed; instead, modules drivers for serial I/O are present.

Boot file examples for Level 2

The Boot files for Coco3 Level 2 are defined in level2/coco3/bootfiles/makefile

Here is the definition of a sample Boot file for Coco3 Level 2 from that file:

  BOOTFILE_80D    = $(MD)/krnp2 $(MD)/ioman $(MD)/init \
                    $(MD)/rbf.mn \
                    $(FLOPPY_80D) \
                    $(MD)/ddd0_80d.dd \
                    $(MD)/scf.mn \
                    $(VTIO_COGRF_80) \
                    $(PIPE) \
                    $(CLOCK60HZ)
  
  VTIO_COGRF_80   = $(MD)/vtio.dr \
                    $(MD)/keydrv_cc3.sb $(MD)/joydrv_joy.sb $(MD)/snddrv_cc3.sb \
                    $(MD)/cogrf.io \
                    $(MD)/term_win80.dt \
                    $(MD)/w.dw $(MD)/w1.dw $(MD)/w2.dw $(MD)/w3.dw $(MD)/w4.dw \
                    $(MD)/w5.dw $(MD)/w6.dw $(MD)/w7.dw

The VTIO stuff is code to control windowed text output on the memory-mapped/character mapped display.

Here is an example of a minimal Boot file, from level2/mc09l2/bootfiles/makefile

  BOOTFILE_MC09SD =  $(MD)/krnp2 $(MD)/ioman $(MD)/init \
                     $(MD)/rbf.mn \
                     $(MD)/dds0_80d.dd \
                     $(MC09SDC_80D) \
                     $(MD)/scf.mn \
                     $(TERM_MC09) \
                     $(PIPE) \
                     $(CLOCK50HZMC09)
  
  TERM_MC09       =  $(MD)/mc6850.dr $(MD)/term_mc6850.dt $(MD)/term_mc6850_t0.dt $(MD)/term_mc6850_t1.dt
  MC09SDC_80D     =  $(MD)/mc09sdc.dr $(MD)/s0_80d.dd $(MD)/s1_80d.dd $(MD)/s2_80d.dd $(MD)/s3_80d.dd

Bootlist examples

Here are some example bootlist files:

• level1/coco1/bootlists/standard.bl
• level1/mc09/bootlists/standard.bl
• level2/coco3/bootlists/standard.bl
• level2/mc09l2/bootlists/standard.bl

What to include in a Boot file

A bootfile stays in memory for the life of the session; there is no way to unstitch parts of it. For Level 1, the restricted amount of memory means that the bootfile should only contain what's necessary to boot the system. For Level 2, the additional memory made available by the MMU means that you may not need to be so determined to restrict what's present.

At one point, I planned to make 2 different disks for Multicomp09 Level 2: one without DW support and one with. In the end though, I decided that it was sufficient to just do the "without" version. It's possible to load the DW stuff later. The only reason to have a DW version would be if DW was required for the boot process, and I don't have that as a goal: we always need the SD card to be present, so we should do the whole boot from there.

To load DW later (explanation from Kip)

1/ append all the driver and associated descriptor modules into a file:

merge driver descriptor1 [descriptor2..]>somename

2/ make it executable:

attr somename e pe

3/ load it:

load somename

You can see all of the loaded modules like this:

mdir

You can remove a module from memory like this:

unlink somename

You should only unlink modules that have been placed in memory by use of 'load'.

SysGo or not SysGo?

The Level 1 boot files all include the sysgo module. The Level 2 boot files do not. There is a comment in level2/coco3/bootlists/standard.bl:

 * Choose which startup module you wish to use. (sysgo_dd is recommended
 * for most configurations.)
 *
 * Alternatively, this module can reside in the root directory of the
 * boot device, saving precious system RAM.

There is no such comment in the level1 boot list files. It's not clear to me that there is any *difference* in this regard between level1 and level2, but I have not yet performed the experiment of trying to start up a level1 system with sysgo removed from the bootlist and added to the boot device root directory.

Don't know/see where the sysgo module is searched for in the root directory. In all cases, the *name* of the module is set by the entry in init.asm: "SysGo" but, of course, that tells you nothing about the name of the file that it might reside in.