RE: disklabel MAXPARTITIONS reversal (was: installboot is broken)

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Friday, March 29, 2013 6:48 AM, Christos Zoulas wrote:
> In article <20130329092457.GA8841%mail.duskware.de@localhost>,
> Martin Husemann  <martin%duskware.de@localhost> wrote:
> >Oha, this is a bit trickier...
> >
> >while fixing installboot was simple and the simh 780 boots fine (after
> >fixing an unrelated mscpbus bug), I now hit a wall and would like to
> >see some more input:
> >
> >I found that the bump of MAXPARTITIONS from 8 to 16:
> >
> >http://mail-index.netbsd.org/source-changes/2012/07/02/msg035340.html
> >---8<--
> >Module Name:    src
> >Committed By:   abs
> >Date:           Mon Jul  2 22:42:18 UTC 2012
> >
> >Modified Files:
> >        src/distrib/vax/miniroot: Makefile.inc
> >        src/sys/arch/vax/include: disklabel.h types.h
> >        src/sys/sys: bootblock.h
> >
> >Log Message:
> >- Increase MAXPARTITIONS for vax from 8 to 16, using the standard
> >NetBSD
> >  mechanism to ensure all existing /dev nodes continue to work
> >- Adjust boot block layout to fit additional partitions
> >- Adjust number of inodes on install media
> >
> >--->8---
> >
> >missed the necessary changes in /boot/xxboot/start.S, so now d_end_
> >still reflects the old disklabel size, but fixing it is impossible, as
> >we end up with 468 (0x1d4) as first byte past the disklabel.
> >
> >However, at 0x19e we need to fill in the parameter block for uVAX
> boot:
> >.org    0x19e
> >        .byte   0x18            # must be 0x18
> >        .byte   0x00            # must be 0x00 (MBZ)
> >        .byte   0x00            # any value
> >        .byte   0xFF - (0x18 + 0x00 + 0x00)
> >                /* 4th byte holds 1s' complement of sum of previous 3
> >bytes */ ...
> >
> >
> >So, unless there are any tricks I don't see right now, I would suggest
> >to
> >
> > - revert the above mentioned commit
> > - document the incompatiblity (affecting all new installs done after
> that
> >   commit in -current or in netbsd-6)

I'm on the road right now and don't have everything at my fingertips, so I 
can't verify the validity of my suggestion.

That said, the parameter block doesn't have to be exactly at the offset it 
currently is located at.  The bytes at the beginning of the block actually 
point to it, so if there is room otherwise, it could slide around to any 
convenient place.

                +-------+-------+-------+-------+
BB+0:           |     1 |     n |     any value |
                +-------+-------+-------+-------+
                | Low LBN       | High LBN      |
                +-------+-------+-------+-------+

                +-------+-------+-------+-------+
BB+(2*n)+0:     |  Chk  |     k |        18(Hex)|
                +-------+-------+-------+-------+
                | any value, most likely 0      |
                +-------+-------+-------+-------+
BB+(2*n)+8:     | size in blocks of the image   |
                +-------+-------+-------+-------+
BB+(2*n)+12:    | offset to load                |
                +-------+-------+-------+-------+
BB+(2*n)+16:    | offset into image to start    |
                +-------+-------+-------+-------+
BB+(2*n)+20:    | sum of the previous three LW's|
                +-------+-------+-------+-------+

- Mark