Merge the projects/clang-sparc64 branch back to head. This brings in
several updates from the llvm and clang trunks to make the sparc64
backend fully functional.
Apart from one patch to sys/sparc64/include/pcpu.h which is still under
discussion, this makes it possible to let clang fully build world and
kernel for sparc64.
Any assistance with testing this on actual sparc64 hardware is greatly
appreciated, as there will unavoidably be bugs left.
Many thanks go to Roman Divacky for his upstream work on getting the
sparc64 backend into shape.
MFC r262985:
Repair a few minor mismerges from r262261 in the clang-sparc64 project
branch. This is also to minimize differences with upstream.
I was considering committing all these patches one by one, but as
discussed with brooks@, there is no need to do this. If we ever
need/want to merge these changes back, it is still possible to do this
per application.
use it, only those with FCode. Add references to dc(4), gem(4) and hme(4)
for obtaining further information about such devices presently supported
by FreeBSD.
- Correct the HISTORY section. There was an eeprom(8) utility in 4.4BSD and
early versions of FreeBSD 2.x.
- Add an AUTHORS section.
stored in EEPROM or NVRAM. It's inspired by the NetBSD eeprom(8) and
the SunOS/Solaris eeprom(1M) utilities. Currently, this eeprom(8)
only supports systems equipped with Open Firmware and is only tested
on Sun machines but should work on any platform using Open Firmware.
A bit more specific, eeprom(8) can be used on these systems to do the
same under FreeBSD as can be done using the printenv and setenv
commandos in the boot monitor. One thing that only hardly can be done
using the boot monitor but easily with eeprom(8) is to write a logo
to the "oem-logo" property. eeprom(8) may also be useful to recover
the boot monitor password (in the default configuration only as root,
of course), i.e. when the boot monitor allows you to boot but you
can't alter the configuration because the password is unknown. The
man page may also be a useful reference of the various configuration
variables.
The idea of eeprom(8) is that handlers can be written to add support
for any firmware that stores such configuration in EEPROM or NVRAM;
sort of e.g. eeprom(1M) on Solaris/x86 is used to turn PAE-support
on and off (stored in a file then, not hardware). In FreeBSD, a
candidate for this would be a handler for the EFI boot environment
for FreeBSD/ia64.
eeprom(8) uses some code from NetBSD (eeprom.c and the base for
eeprom.8), the handler for the Open Firmware /options node
(ofw_options.[c,h]) was written using ofw_util.[c,h] from ofwdump(8).
Reviewed by: ru (slightly earlier version of the man page)
