[Top] [All Lists]

Re: DECStation Linux native partition format ?

Subject: Re: DECStation Linux native partition format ?
From: Harald Koerfgen <>
Date: Tue, 16 Mar 1999 12:52:32 +0100
Organization: Ford Motor Company
References: <>
Hello all,

I had a quick glance at the topic and I even installed NetBSD on one of
my DECstations to make a few experiments.

Houten K.H.C. van (Karel) wrote:
> Paul M. Antoine wrote:


> > I think the problem here is that the DECstation boot proms only know how to
> > read ULTRIX partition tables, so if we're going to allow folks to boot from
> > the bootprom on power up we're going to have to live with the ULTRIX 
> > partition
> > table format.  Short of re-writing the boot prom, or writing a multi-stage
> > boot loader (which must be stored on an ULTRIX partition table entry??)...
> >
> > At least that's what I believe to be the case.  It could be that the boot
> > proms know how to read a boot loader, which we could replace with a lilo
> > lookalike that understands whatever partition table format we want... but
> > that's not my memory of how the DECstation works.  Anyone else??


> As far as I can tell, the PROM's don't know about ULTRIX partitions,
> they are only able to read the bootloader from the first disk sectors,
> and pass the boot command line on to the bootloader.

>From what I have been able to find out so far the PROMs load block 0 of
the boot device and depending on the information in there continue to
load blocks in one of the following manners:

0) load a number of blocks starting from a start block

1) similar to 0 but using a a zero terminated list of (nr_of_blocks,
start_block) ranges. This list has to fit into block 0 which limits this
list to 61 entries.  

Or, to be more precise (sprite/dev/devDiskLabel.h):

--- start code snippet ---

typedef struct Dec_BootMap
    int numBlocks;      /* Number of blocks to read.
    int startBlock;     /* Starting block on disk.

 * Boot block information on the 0th
 * The boot program is stored in sequences of contiguous
 * If mode is 0, there is just one sequence of blocks and one
 * is used.  If mode is 1, there are multiple sequences of
 * and multiple Dec_BootMaps are used, the last with numBlocks =

typedef struct Dec_DiskBoot
    int         magic;                  /* DEC_BOOT_MAGIC
    int         mode;                   /* Mode for boot info.
    int         loadAddr;               /* Address to start loading.
    int         execAddr;               /* Address to start execing.
    Dec_BootMap map[61];                /* Position of boot program.
--- end code snippet ---

That would give us a lot of freedom to put the bootloader wherever we
like, and, most important, is absolutley independant of partitioning
schemes and filesystems.

> My vote would be to use the NetBSD scheme, because we have a working
> bootloader for NetBSD in source. Getting this working for linux would
> involve the following steps:
> - get the netbsd bootloader to compile under linux
> - change the bsd ffs code to ext2 code
> - change fdisk to support netbsd tables.
> (My kernel already supports NetBSD partition tables)
> Regards,
> Karel.

I guess there are a number of people who want to have Ultrix or *BSD and
Linux residing on the same disk, are there? If so, we have to use Ultrix
or *BSD partition tables and in either case we have to hack fdisk to
support them.

Another point is, if booting via multiple sequences of blocks really
work, we don't have size restrictions on the bootloader where Ultrix and
*BSD are limited to 7.5 KB, probably for historical reasons. Looks like
time for some further experiments...


<Prev in Thread] Current Thread [Next in Thread>