Currently "machine" symlink points sys/arch/sun68k/include,
but this means some <machine/foo.h> files are taken from
sys/arch/sun68k/include but others (i.e. files not in sun68k/include)
are taken from ${DESTDIR}/usr/include/machine.
Instead, make "machine" symlink point sys/arch/${MACHINE}/include,
make "sun68k" symlink point sys/arch/sun68k/include (not sys/arch/sun68k),
add sys/arch to include path, and move some files where appropriate.
to override settings in /etc/mk.conf, so that build won't fail
in sun68k which contains both sun2 and sun3 sources.
Suggested by thorpej, and closes PR toolchain/34528.
Tested on most m68k ports. Still there is no report of
atari, cesfic, luna68k, and mvme68k on real machines,
but at least builds for these ports should work.
on (some) OpenFirmware 2.x machines.
Current macppccd.iso image doesn't boot on Openfirmware 2.x
(and probably 1.0.5) machines because it uses pre-compiled binary
which is based on old (and customized) bootxx.
It causes version mismatch against newer ofwboot whose load address
has been changed from 0x600000 to 0xe00000, as mentioned in the
following post:
http://mail-index.netbsd.org/port-macppc/2004/12/14/0020.html
There was also an raw binary which was passed to mkisofs as -boot-hfs-file.
To fix these issue, prepare a simple mkhfsboot program which creates
a boothfs file with the Apple partition map info for mkisofs,
and modify macppc_installboot to search the secondary ofwboot from isofs
and to put and modify the primary bootxx accordingly.
See PR toolchain/30245 for more details.
There are still some machines which don't boot from an iso image created
by this method (G3 machines with OF 2.0f1 etc.), but it's still better
than to keep ugly and obsolete hacks.
Ok'ed by macallan, and there is no other particular comment about this PR.
__HAVE_GENERIC_TODR. Compile tested only, as I have no idea how to track
down actual hardware, and the ports previous port master is no longer a
TNF member.
Fleming.
This one has some nice options -- for example, an admin can run right
after installing a system:
fpgen -D
and it will fingerprint a set of "common" system directories to the
default loaction. See the man-page for more stuff.
Performance-wise, here are results for both fpgen.sh (old) and this
new tool:
474.599u 574.335s 13:53.05 125.9% 0+0k 0+307io 0pf+0w
0.424u 0.131s 0:00.56 98.2% 0+0k 0+2io 0pf+0w
...guess which is which? (that's ~1500 times *faster*)
was taken from OpenBSD, and their hostname.if(5) format is different from
that of ifconfig.if(5) on NetBSD.
Noted & patch sent by Nino Dehne <ndehne@gmail.com>
Uvm changes over 17 months ago resulted in the 68040/060 segment table
page being entered with pmap_kenter(), which does not record the mapping
in the pv table. Attempting to inhibit caching of that page as required
by the 68060 hardware no longer changes the PTE and caused varying degrees
of multiple faulting, sometimes resulting in an unusable system. Apparently
very few people attempted to run a 68060 based system since that change.
Fix to to change the caching bits directly rather than using pmap_changebit().
Tested and verified on my Amiga (yes, I'm hoping to switch amiga to using
the common pmp_motorola.c).
Uvm changes over 17 months ago resulted in the 68040/060 segment table
page being entered with pmap_kenter(), which does not record the mapping
in the pv table. Attempting to inhibit caching of that page as required
by the 68060 hardware no longer changes the PTE and caused varying degrees
of multiple faulting, sometimes resulting in an unusable system. Apparently
very few people attempted to run a 68060 based system since that change.
Fix to to change the caching bits directly rather than using pmap_changebit().
uwe