Archive-Date: Tue, 5 Oct 1999 14:23:49 +0200
Message-ID: <37F9EDE9.A2338FB4@radar.no>
Date: Tue, 05 Oct 1999 14:24:09 +0200
From: Magne =?iso-8859-1?Q?M=E6hre?= <magne@radar.no>
Reply-To: Free-VMS@lp.se
MIME-Version: 1.0
To: Free-VMS <Free-VMS@lp.se>
Subject: Boot process
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I've been hacking on some code to create an ODS-2 volume
on a disk (or partition) from Linux.  What I'd like to do
is to make the disk/partition bootable via LILO, and load
a VMB.EXE - equivalent.

I'd like to know a little more on what happens at this stage
in "real" VMS?  I understand that WRITEBOOT.EXE creates the
bootstrap block, but what is exactly written?  Is it just
a pointer to where VMB.EXE is located on the disk, or is
it actual working code (I tried to disassemble the
bootstrap, but it didn't tell me much) ?

--Magne
================================================================================
Archive-Date: Tue, 5 Oct 1999 16:02:11 +0200
MIME-Version: 1.0
Date: Tue, 5 Oct 1999 10:56:55 -0500
Message-ID: <000ED7C3.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re: Boot process
To: Free-VMS@lp.se
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

   I think you might do better to try to reverse-engineer 
   WRITEBOOT. That would tell you more about what it does. 
   Doing so to the boot block just tells you what's in the 
   boot block. From the little I know about WRITEBOOT, you 
   tell it the name of the boot file (VMB or APB) and the 
   path to it, and WRITEBOOT will translate the addres of 
   that file into cylinder / sector / head and extent size 
   (how many sectors - VMB or APB must be contiguous), and 
   write those data into the boot block along with the 
   necessary boot code to find that extent and load it into 
   memory at a pre-determined address.
   
   Also, remember: since the boot BLOCK (singular) is only 
   512 bytes, you're likely not to find any embedded strings 
   or messages. It's gotta do a lot in very little code. All 
   it really does is locate and load VMB (or APB) and then 
   transfer control to it.
   
   If you try to reverse-engineer VMB (or APB) you're likely 
   to find that while begins to provide more support for 
   ODS-2, it doesn't do much beyond locate and load things 
   like SYS.EXE (which I believe is the most primitive part 
   of the VMS kernel, but don't quote me 'cuz I'm kinda 
   guessing here) and SYSBOOT (which I believe begins the 
   process of setting up the in-memory data structures, 
   including loading - and to a limited degree, verifying - 
   the system parameters; again, just a guess, I really 
   don't know for certain).
   
   Although the LILO paradigm does provide a frame of 
   reference, I would discourage using that as a model. 
   You'd do better, IMHO, to analyze and emulate the actual 
   VMS boot process. Others will, I'm sure, disagree with 
   me. Seems to me you'd do best to write boot code that can 
   read ODS-2 for starters, with perhaps some common 
   strategies for booting from diskette, ATAPI ZIP drives, 
   EIDE hard disks, Orb (2 GB) and ZIP (250 MB) drives, 
   and/or SCSI hard disks, ZIP, Jaz and/or Orb drives in 
   ODS-2 format. ODS-2 eats up a lot of space on a diskette; 
   so, you probably can't load much that way besides maybe 
   the primary and secondary bootstraps. Still, it may prove 
   useful at some point in the development process.
   
   Also, remember that "real" VMS doesn't know about disk 
   "partitions" - it considers the whole disk as a single 
   unit of storage. Building partition support into the boot 
   straps and loaders might be useful, but would differ from 
   the way "real" VMS works.
   
   A disk "partition" might be compared to a logical/virtual 
   disk container file. That is to say, the VMS operating 
   system must be fully loaded and running before that level 
   of support becomes available.
   
   (Orb drive info.: http://www.castlewood.com/ )
   
   David J. Dachtera
   dba DJE Systems
   http://home.earthlink.net/~djesys/


______________________________ Reply Separator _________________________________
Subject: Boot process
Author:  Free-VMS@lp.se at PO_EXTERNET
Date:    10/05/1999 7:24 AM


   
I've been hacking on some code to create an ODS-2 volume 
on a disk (or partition) from Linux.  What I'd like to do 
is to make the disk/partition bootable via LILO, and load 
a VMB.EXE - equivalent.
   
I'd like to know a little more on what happens at this stage 
in "real" VMS?  I understand that WRITEBOOT.EXE creates the 
bootstrap block, but what is exactly written?  Is it just
a pointer to where VMB.EXE is located on the disk, or is 
it actual working code (I tried to disassemble the 
bootstrap, but it didn't tell me much) ?
   
--Magne
================================================================================
Archive-Date: Tue, 5 Oct 1999 16:42:37 +0200
MIME-Version: 1.0
Date: Tue, 5 Oct 1999 11:34:17 -0500
Message-ID: <000ED9AA.C21492@advocatehealth.com>
From: David.Dachtera@advocatehealth.com (David Dachtera)
Reply-To: Free-VMS@lp.se
Subject: Re: Boot process
To: Free-VMS@lp.se
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

   Here's some more info. about boot-time stuff in "real" 
   VMS...
   
   Intel machines, with no known exceptions, lack an 
   "intelligent console". They locate their boot device 
   device according to rules setup (or defaulted to) in the 
   BIOS. The idea of passing parameters to the boot process 
   is a foreign concept.
   
   Early VAX-11 machines weren't much different. They needed 
   to read and load from a QIC-like tape device such things 
   as the primary boot-strap, the data indicating the boot 
   disk and boot file name, etc.
   
   VAX 8200's (and others) replaced the tape device with 
   diskettes which made system management somewhat easier, 
   but still required a running system to manage the 
   boot-time scenario.
   
   Then, newer VAXes, including the now famous MicroVAX(-II) 
   began to include a "console" subsystem. The console 
   provides a rather primitive terminal interface with a 
   command line. The system manager could now specify the 
   device that VAX/VMS should be booted from, as well as 
   specifying parameters by way of the registers. Many 
   system managers are familiar with console commands such 
   as "B/R5:1" which would result in a "conversational" boot 
   (SYSBOOT solicits input from the console terminal before 
   proceeding, allowing changes in system parameters), 
   "B/R5:10000000" indicating that VAX/VMS should use "SYS1" 
   as the value of SYS$TOPSYS, which means that the system 
   will find it's node-specific parameters, files, etc. by 
   way of the SYS$SYSDEVICE:[SYS1...] path, etc. which is a 
   key part of the way that VMS clusters work and 
   distinguish one node's files from another's on a common 
   system disk.
   
   At one point in earlier discussions (probably last year 
   some time), it was suggested that the early work on 
   VMS/x86 ("Free-VMS") include an emulation of the way that 
   some early VAXes would boot by way of a "console 
   diskette", thus obtaining key boot time information such 
   as which disk to boot from, flags to be passed to the 
   boot straps, SYSBOOT and the kernel, etc. Perhaps THIS is 
   where the LILO paradigm can be useful.
   
   Hopefully, this info. will save some digging through the 
   mailing list archive.
   
   David J. Dachtera
   dba DJE Systems
   http://home.earthlink.net/~djesys/