While many tend to fixate on OpenVMS' First Boot on Intel x86-64, there are actually a number of key milestones, or proof points, before we achieve First Boot.
We want to share our excitement about the significant engineering progress we have made to date, by listing the status of some of the significant Proof Points on the way to the First Boot of OpenVMS on Intel x86-64.
This page replaces the "State of the Port" powerpoint slides that we used to release on a quarterly basis in the past. Archival links to these "State of the Port" presentations are also listed in the Side Bar below.
After First Boot, we will provide the status of Proof Points for our next major porting milestone: the first Early Adapters Kit (EAK 1). We look forward to inviting select customers to provide input on the architecture and field tests for this EAK 1 release.
Proof Points to x86-64 First Boot
Click on the proof points below to see their contents
Execute DIRECTORY command
Reach the end of SYSINIT
Create logical names
Mount system disk
Initialize file system
Establish interval timer
Set system time
Create I/O database
BRK - END OF INIT BREAKPOINT
VSI VMS X86 XDELTA Debugger [SYSTEM_DEBUG], XEWO, Dec 17 2018 19:02:11
Brk 0 at FFFF8300.10200756
%EXECINIT-I-ACTIVESET, joining ACTIVE set
%EXECINIT-S-CIAO, transferring to the scheduler
%SWAPPER-I-SHUFFLE, executing SWAPPER initialization code
%SWAPPER-I-POOL, initializing paged pool
%SWAPPER-I-INIT, calling initialization routines
%SWAPPER-I-RSDM, joining system resource domain
%SWAPPER-I-P1, initializing SWAPPER P1 cells
%SWAPPER-I-PAGED, paged system initialization
%SWAPPER-I-HASH, creating the logical name hash tables
%SWAPPER-I-DEFINE, defining the system logical names
%SWAPPER-I-CREPRC, creating the SYSINIT process
Create PFN database and allocate pool
Stop in the debugger and list the images, including their address space layouts loaded by SYSBOOT, after transitioning execution from the boot environment to the operating system environment.
Click here to display a PDF of the image list.
Calling a system service involves proper setup of dispatch tables, initializing the x86 SYSCALL mechanism, and successfully returning from the call. Much of this operation is new code for x86 integrated with the existing VMS system service interface.
We achieved our second Proof Point on June 29, 2018, by successfully making the transition from executing in the boot environment to executing a routine running in the runtime environment. This requires successfully switching to system context.
This proof point represents work in the compiler, the linker, the loader, and the executive code which manages context switching. Also, the XDELTA debugger was a necessary component for verifying the result. An underlying facilitator of this accomplishment is the calling of a routine in another image which, in and of itself, is a significant milestone.
Proof Point #1 is defined as – stopping at the end-of-SYSBOOT breakpoint and issuing “;L” to XDELTA to get the list of images, including their image sections, SYSBOOT has loaded.
On 29-May-2018 we demonstrated ";L" at the end of SYSBOOT. Its output is at the end of this posting. Everything is not perfect yet but the current result is as expected. It shows many things have been accomplished and the overall underpinnings for the next step are in place.
The following work remains in order to make things complete at this point in the boot process.
- There are four more exec images to be loaded: ERRORLOG.EXE, SYSTEM_SYNCHRONIZATION.EXE, SYS$PLATFORM_SUPPORT.EXE, and SYSTEM_PRIMITIVES_0.EXE. The first two will be picked up within the next week. The latter two require more compiler and memory management work.
- We need to read the parameter file X86_64VMSSYS.PAR and populate system data cells with the appropriate values.
- XDELTA needs to update its “;L” output formatting as some values are 64b that are 32b on Alpha and IA64.
Boot Path Output
Click here to see the full boot path from BOOTMGR> BOOT to ;L. The linked PDF is the output from a captured terminal session from a network boot of the memory disk file, which was created on our development cluster.