Re: GPT BIOS boot

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 30 May 2019 03:16:12 +0200
    From:        manu%netbsd.org@localhost (Emmanuel Dreyfus)
    Message-ID:  <1o8dbps.15mvtt61mh7wskM%manu%netbsd.org@localhost>

  | Then the secondary bootstrap launches, which is an improvement.
  | Unfortunately it seems unable to see files in the RAID volume.

It probably needs to be taught to assume a raid it sees is raid1, and
to simply assume that is a FFS, with an offset to the super block, and
continue that way.   It is unlikely that full raid support will ever
appear in the boot code (it would need lots of it to work at all for
any other raid format) so that's about the best that can be done, and
matches MBR/disklabel raid booting.

  | +
  | +       /* 
  | +        * Try to skip a GPT at the beginning of a raid set.
  | +        * The layout is as below, with 34 sectors to skip:
  | +        *     start         size  index  contents
  | +        *         0            1         PMBR (active)
  | +        *         1            1         Pri GPT header
  | +        *         2           32         Pri GPT table
  | +         *        34      .......         GPT part - NetBSD FFSv1/FFSv2
  | +        */
  | +       #define GPT_PROTECTED_SECTORS 34

But that's just plain insane ... if that matches your setup, you should
start again.  For raid it is even more important than with normal FFS
that the blocks be sensibly aligned, and while 34 is (marginally) better
than 63, that's all it is.   64 would be better (it is at least a power of
2, if a small one).   The ideal number depends upon the underlying raidframe
configuration.  512 or 1024 as the FFS starting offset in the raidframe
partition would handle most normal configs I expect (though the FFS params
also ought to be set correctly to get good performance.)

This is one place though where building in a magic number is not the right
way - it is OK for the raidframe offset, as that one never changes, but
this one depends upon user filesystem layout preferences - usually governed
by issues like the actual space available.   We really need the boot code
to read the GPT tables, find the right FFS/raid partition, and get the offset
that way - reading GPT isn't hard, recognising FFS/raid is easy, and testing
the "bootable" flag is trivial, so (unlike actually dealing correctly with
raid in all its possible forms) this would be entirely reasonable to add
to boot.

kre