little-endian byte-order. This should work out to be a no-op
for LE systems, and allows BE systems to use the board.
Tested on PPC, reviewed by Dante.
NOTE: The board/microcode does have a BIG_ENDIAN mode of operation,
but it's not well-documented. That might be interesting to investigate
at some point in the future, though.
omagic/nmagic/zmagic binaries from guest account on
Lord Isildur's tahoe system (thanks). enabled if both
COMPAT_43 and COMPAT_VAX1K are defined.
basically rewrote exec_vax1k_prep_anymagic() to handle more
file formats. we remove vax1k_subr.c because we now use the
standard vmcmd_readvn function.
XXX: suspect the code for MID_VAX1K NMAGIC binaries is wrong,
need a binary to confirm this... the old code did not pad the
end of the text segment to a page boundary, and that seems wrong.
you definitely need to pad it on a 4.3BSD NMAGIC binary and i
don't see why MID_VAX1K should be different?
bus (and optionally maps expansion ROMs), and an optional second
pass to disable expansion ROMs that are mapped. This would allow
MD code to possibly execute the expansion ROMs (possibly in an x86
emulator) to configure a device (e.g. a VGA card, which pretty much
needs to be configured by its ROM).
the expansion ROMs on cards, since address decoders may be shared between
the ROM and PCI memory space on some cards (i.e. "only map the ROM if you're
going to use it, and then unmap it when you're done" is the intended
usage).
in the ARMADA config. On the M700 at least, the SMBus host controller lies
it 0x4000 (the beginning of the range allocated by default to rbus), and
stomping all over it causes bad things to happen.
driver uses direct DMA to mbufs (like other PCI network drivers,
and unlike the old "le at pci" driver), and also supports communication
with the MII-connected PHYs on the 10/100 boards.
