"Fast Data Access MMU Miss" is being printed by the
PROM. It happens in early bootstrapping before the virtual
memory system has been brought up when the kernel or
bootloader access unmapped memory.

This usually happens due to a mismatch between the
kernel and ofwboot. It's usually best to have both
the latest kernel and latest ofwboot.

The main differences between versions involve how
ofwboot
allocates memory for text and data segments. Originally, it
allocated whatever memory was available and the segments
could end up with any alignment. The kernel needs both text
and data segments both physically and virtually aligned to
a 4MB boundary, and the data segment must be extended to a
4MB boundary so they can be mapped in with 4MB pages. The
kernel has code to relocate itself, if necessary, but some
PROMs are buggy and relocation does not work, especially on
newer machines.

Versions 1.2 and 1.3 makes sure that any segment's
physical alignment is the lesser of its virtual alignment
or 4MB. This means the kernel does not need to relocate the
text segment, but sometimes there is something in the way
of extending the data segment to 4MB

Version 1.4 is buggy and always extends all segments
to exactly 4MB. This is a problem if segments happen to be
greater than 4MB, in which case they are truncated.

Version 1.5 extends the data+BSS segment to the next
4MB boundary. This, in conjunction with a recent kernel
means that the kernel never needs to be relocated. It is
required for new machines where kernel relocation or data
segment extension simply fails. However, since it does
extend the data segment, older kernels will not detect this
and think that something else is in the way, forcing them
to relocate the data segment.

In short, although different combinations may work,
it is best to have
ofwboot
match the kernel.

Some standard PCI cards "just work" in
NetBSD/sparc64, such as network cards, IDE cards, etc.
However, for these cards to be recognised by the PROM, you
need to update the SUNW,builtin-drivers FCode package to
force the device into native PCI mode.

Lloyd Parkes has provided the nvram commands to have
a "standard" IDE controller recognised correctly by the
PROM.

The sparc64 architecture requires special handling for PCI memory.
The /dev/mem device driver can not easily get the MMU and external
cache handling coherent without collaborating with all PCI device
drivers. So in a better-safe-than-sorry policy /dev/mem restricts
access to known-safe areas - which basically means main memory.
See this
message for details.

If you want to access PCI memory space you need to go through some
sort of PCI device driver that maps it correctly.

When booting from hard disk, the disk needs to be partitioned
using a "sunlabel" compatible disklabel. Sparc64 machines
can not boot from GPT partitioned disks. The root file system
can be in a RAID-1 (raidframe) set and all FFS formats as
well as LFS are supported.

Of course GPT partitioned disks can be used for additional
partitions.

Usually you will not need one. The X server is
able to figure out the hardware automatically
at startup. If you want to differ in certain aspects,
just create a /etc/xorg.conf file with the sections
that should be changed from the default values.

If you see this, install the
sysutils/afbinit package, which can download the missing
firmware to the board, and get afb.ucode (the firmware image) from
SUN. Thanks to
Alan Coopersmith for making
it available.

As part of the NetBSD 7.0 development process, checks for accessing
memory were tightened, closing some security holes that could allow
priviledge escalation. Unfortunately, this stops the X server from
being able to map all of the necessary parts of the framebuffer or
registers and X reports error 22 (EINVAL).

To fix this a kernel that has securelevel set to -1 must be used.
In order to do that options INSECURE should be set in the
kernel configuration file (by default it is commented out in GENERIC)
and a new kernel should be recompiled.
Please see
How to build a kernel for further information.