[Info-vax] Hobbyist RX2620

[FredK]

IA64 system disk 101... (or more informatin than is probably useful):

A standard IA64 boot disk will have 5 partitions (it can be fewer if you get 
rid of the HP Service Partition).  If you locate and copy the EFI 
application DISKPART.EFI (Windows uses this tool) it can show you the 
partition layout from EFI.  In V8.4 you can use the foreign command line 
interface for "sys$setboot -s -e" which will show you the partitioning in 
detail.

The entire disk - except for the MBR/GPT portions - are covered by the 
partitions.  Two of them have FAT file systems on them - the EFI System 
Parition (ESP) and the HP Service Partition (HPSP).  When EFI finds the 
MBR/FAT information - it creates File Structured (FS) "devices" for them. 
The other three do not have a recognizable format to EFI - in them resides 
the contents of the disk that are not SYS$EFI.SYS and SYS$DIAGNOSTICS.SYS. 
If we did not create partitions for that portion of the disk (left it 
unallocated) then theoretically some non-VMS software partitioning tools 
might see it as unallocated.

Partitions can't overlap.

The typical disk looks like:

MBR
GPT
Partition 1 - VMS (low)
Partition 2 - ESP
Partition 3 - VMS (mid)
Partition 4 - HPSP
Partition 5 - VMS (high)
GPT backup

EFI can do file system (FAT) operations on Partition 2 and Partition 3 in 
this case, and you can use the shell to look at the contents etc.   All 
partitions have a "type" GUID that can be used to determine what the 
partition is - and the ESP and HPSP have registered (well known, published) 
GUIDs.   The VMS partitions have type GUIDs that OpenVMS has created - but 
since we are the only consumer there is no need to publish them.  We don't 
actually use the GUIDs today except to write them - since we don't support 
mixed OSes on a single disk ("dual boot" like having multiple Windows 
versions, or Linux and Windows on a single disk)...  to do that VMS would 
need to add support for partitioning to the OS.

[Not to confuse the issue, but the disk and the partitions also have 
"signature" GUIDs that are unique to the disk itself and are created when 
the disk is initialized or when SETBOOT is done without the option to 
preserve the signature GUID]

EFI applications can perform block IO to the partitions or the raw disk.  In 
fact, we use this capability in some cases when we create a "memory disk" 
for some types of booting - for example booting from a USB DVD.  Our EFI 
application (VMS_LOADER in this case) has primitive ODS filesystem code that 
uses EFI block IO to copy all of the files needed to boot VMS into the 
"memory disk".  This prevents us from (in this example) having to have an 
entire USB stack in the boot code for a USB DVD boot - we "boot" from the 
memory disk we fabricate until the runtime drivers are loaded during 
SYSBOOT/INIT_IO_DB.  We could use that as the single method for booting... 
except that we need primitive boot drivers to do crash dumps.

>From the VMS perspective the same disk looks like:

GPT.SYS
Random disk contents
SYS$EFI.SYS
Random disk contents
SYS$DIAGNOSTICS.SYS
Random disk contents
GPT.SYS


"JF Mezei" <jfmezei.spamnot at vaxination.ca> wrote in message 
news:00008762$0$2141$c3e8da3 at news.astraweb.com...
> FredK wrote:
>
>> A VMS disk will contain two FAT partitions (and 2 FS devices).  The EFI
>> system partition (ESP) and the HP Service Partition (which is empty 
>> unless
>> you install the diagnostics).
>
> Does this mean that at the EFI level, the ODS2 data/disk reside in
> non-allocated space ?  Always though that EFI would see a partition for
> the ODS2 disk that would include all of the disk to prevent any other OS
> from using that drive).
>
> Or is it impossible to have overlapping partitions ?
> eg: EFI blocks 0 to 100
>    ODS2 blocks 0 to 5 million