[Coco] Request for Discussion new level 2 Nitros9 booting.

[Tormod Volden]

On Wed, Oct 29, 2014 at 3:24 AM, Brett Gordon wrote:
> Ladies and Gentlemen,
>
> I need help from the more experienced contributers and "old timers" of
> the Nitros9 community.  I'm trying to iron out some proposed changes
> to my new way of booting Nitros9 Level 2.   I believe I have
> modernized the CoCo's Boot process to make it more dynamic and save a
> smidgen of system memory.  My way of booting is one step of separating
> the booting of Nitros9 from the main Nitros9 runtime.  To the
> uninitiated here is a simplified synopsis of current Nitros disk
> booting:
>
> - DECB's DOS command loads the boot track from disk
> - the boot track contains:  REL BOOT and KRN modules.
> - REL setup up some system state and moves BOOT and KRN up to high memory
> - REL calls KRN.
> - KRN sets up some more system state and call BOOT
> - BOOT loads the OS9Boot file from the actual RBF filesystem into high memory
> - BOOT returns control back to KRN
> - and KRN finishes up system initialization and continues to call INIT.
>
> There is some drawbacks to this bootstrap sequence:
> 1. BOOT is left in memory and it's space is never reclaimed.
> 2. ALL three modules (BOOT,KRN,and REL) do some setup. They are
> tightly coupled, and near inseparable as implemented.
> 3. Because of the limited space of the boot-track (4608 bytes) BOOT is
> limited to 768 bytes of static code, which limits dynamics (AKA
> loading from anything but drive 0 is possible but difficult)
> 4. Separate BOOT source files have to be maintained for each hardware
> device (IDE,SCSI,DW, etc...), and likewise, only one OS9Boot file can
> exists on any particular RBF partition (..err... drive).  Ideally the
> runtime device drivers would be used to do this, but because of the
> limited size of the boot-track, Nitros9 keeps a seperate source files
> just for the boot devices. There is none to little code reuse between
> BOOT device's and nitros9's runtime devices.
> 5. The idea of a boot track is a DECB fiction.  Should DECB dictate
> how we boot a total different system?
> 6. The RBF filesystem make no official allowance for the existence of
> a boot track.   The two main boot files, the Boot track and OS9Boot,
> are not regular RBF files.  Boot track must be in a certain place, and
> OS9Boot must be linked into the RBF super-block (LSN0).  This is
> illogical, un-beautifull, and NOT simple.
>
> I have read many times on this mailing list, people having trouble
> understanding this process. It seems to be a lengthy process of
> rebuilding Nitros9 to change anything, let alone changing OS9Boot.
>
>
> My proposed changes to Nitros9:
>
> 1. Creating a chain-loader.   A chain loader is a booter that loads
> another OS, then goes away.  The OS, in this case Nitros9, barely
> knows this chain-loader exists.  The loaded OS, doesn't load itself -
> it depends on chain loader to do this.  In short, we need a LILO or a
> GRUB for the CoCo.  ( sorry windows people, these are PC boot loaders
> associated with Linux, but it's the closest fitting example I know
> of).  My implementation of one such chain loader is my CoCoBoot
> project.
>
> 2. Modify, simplify, Nitros9:
>      a.  There is no BOOT or REL, this is the chain booter's job now.
>      b.  Nitros9 can assume OS9Boot is already in-place.
>      c.  Nitros9 receives parameters from the booter in a pre-defined
> way.  Mr. Pitre  referred to this as a software "contract" between the
> booter and the OS.
>
>
> I have made a rough, parallel hack of the current Nitros9 ver 3.3.0 to
> demonstrate proof-of-concept. it:
>
> - Creates a separate distinct KRN module on the RBF called "CCBKRN".
> This replaces KRN as found in the current boot-track boot method.
> This new KRN module has been modified just enough to NOT load OS9BOOT,
> but take single parameter from the booter as to the location of the
> start of the preloaded "OS9BOOT" file.  There a few minor
> modifications (a bug fix, automatic padding, LWASM compatibility )
>
> Questions remain:
>
> 1. F$BOOT no longer "fits" logically.  What do we do when we press the
> reset button? We used to cause a *near* clean reboot of the system.
> but not anymore?
> 2. Where to put the new "CCBKRN" module on the RBF filesystem?  I have
> put it in the root directory, but it could potentially be placed
> anywhere.  My booter, CoCoBoot can navigate the RBF filesystem, but
> realistically, the more directories down, the slower booting this way
> will become.
> 3. What should the contract be between the booter and Nitros9 ?!?!
>
> I'm hoping to get this added to the standard Nitros9 branch, and I
> have faith this this in no way defeats the old way of booting.   If
> you want to boot Nitros9 the old way, it will still work.  The only
> drawback would be the parallel maintenance of two KRNs and their
> related system calls (F$NPROC and F$RQSYSMEM change slighty)
>
> There's great potential in this:  Having multiple OS9Boot files per
> RBF filesystem. Saving some system memory (no BOOT or REL).  We could
> even eliminate the idea of a OS9Boot file.  The booter could load each
> module one-at-a-time.
>
> I'll do some work to create a workable trial system, most likely a
> DriveWire image. and post some Nitros9 patch files on my site soon:
>
> https://sites.google.com/site/cocoboot2/home
>
> Please let me know what you think!  Boisy and I have had a few
> discussions on this ( the whole thing was his idea, as far as I know).
> Please seriously consider, my changes.  Its time we leave the old ways
> behind, and head into the software future!
>

Brett,

First of all, thanks for this excellent overview of the (existing)
boot system and its shortcomings. It is half-way explained in the wiki
(http://sourceforge.net/p/nitros9/wiki/The_NitrOS-9_Boot_Process_Explained/)
but I haven't seen it anywhere explained so well as you just did.

I think your suggested approach makes a lot of sense.

This should work for Level1 also, I suppose. The boot structure is
pretty much the same, isn't it?

I also think this will be great for other platforms which run NitrOS-9
or might do in the future. Why should it be called /coco/ boot? As a
loyal Dragon user I have problems with this ;) You can call it
brettboot for what I am concerned. Or brub :) Of course the program
you write for the Coco can have that name, but this new boot system
and "contract" between NitrOS-9 and the chainloader deserves a better
name.

As for adding it to the repo, I see no problem at all - in fact most
of it is in there already. I have wondered what the ccb* files were
about and nobody could tell me.

The difference between fsrqmem.asm and ccbfsrqmem.asm is so small that
they can be merged with conditionals. This might wait until it has
settled a bit, but it will avoid unnecessary double-maintenance or
divergence in the future (if both systems are kept). The same is maybe
true for krn.asm/ccbkrn.asm. Some of the changes (e.g. the fill)
should probably be applied to krn.asm in any case. It would be good if
you can work on making the difference as small as needed.

In ccbfsrqmem.asm you have hardcoded $FF00 as top of memory. I believe
there should be macro for this, to make it easier to port to systems
where top of RAM is elsewhere or somebody wants to reserve some memory
for something.

BTW, I have noticed the persistence of REL and BOOT in my level-1
system. Especially with only 32K RAM a few modules make a large
difference :) Independent of your solution, wouldn't it be possible to
make REL and BOOT "disposable"? I can see very little use for direct
rebooting, if something goes wrong, a full cold boot is likely needed
anyway.

Best regards,
Tormod