Over the last few days, I've tracked down a rather nasty little problem
with the SPARC bootblocks - or more precisely, with the ROM routines
used by them to read the disk.

I have a "SPARCstation 1+", "ROM Rev. 1.3" (according to the banner
printed on reset).  I recently tried to set it up to boot from a 2G
disk that I previously had on a Sun-3/260.  After going around in
circles for a while and doing lots of tests, I eventually determined
that the ROM routines used by the first-stage bootblocks simply refuse
to read past the first 1G of the disk!  It appears something is
throwing away everything but the low 21 bits of the block number at
some point - and worse, this applies to the absolute block number, not
the partition-relative block number.  (This means that in some
circumstances you may end up reading a block that's outside the
partition you thought you were using.)  This machine presents a V0
monitor interface (pv_romvec_vers is 0).

I have no idea what other ROM versions the bug may apply to.  But if
you're getting mysterious first-level boot failures, it may be wise to
check the block numbers printed by installboot, especially if you have
rev 1.3 ROMs, and/or try again with a small root partition near the
beginning of the disk.

(There is another bug, this time in the NetBSD code, that means that
root partitions >4G may break similarly on machines with V2 monitor
interfaces, but that one appears fixable - when calling
promvec->pv_v2devops.v2_seek in obp_strategy() [promdev.c], the high
half of the offset is hardcoded as zero.  pk pointed this out to me
when discussing the other problem, but it turned out to be irrelevant
to my particular trouble.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B