maps standard boot flags to corresponding RB_* values
use BOOT_FLAG() in port's MD code as appropriate
as discussed on tech-kern, add new boot flags -v, -q for booting
verbosely or quietly, and corresponding AB_VERBOSE/AB_QUIET
boot flags; also add FreeBSD-compatible bootverbose macro and
NetBSD-specific bootquiet macro
for hpcmips, use new bootverbose instead of it's own hpcmips_verbose
Tested on i386, and to limited extend (compile of affected files) also for
mvme68k, hp300, luna68k, sun3.
backend.
The VME2chip can use this to translate a VMEbus irq to a cpu irq.
The VMEchip (on mvme147) can't deal with the VMEbus irq and cpu irq
being different so we just panic in that case for now.
routine. Works similarly fto pmap_prefer(), but allows callers
to specify a minimum power-of-two alignment of the region.
How we ever got along without this for so long is beyond me.
Currently, the major onboard devices are supported (disk, network,
rs232 and VMEbus). However, work is still need to support the remaining
devices (eg. IndustryPack sites).
These boards are available with a dazzling array of build options. At
this time, the following options are *required*:
o Real floating point hardware (the 68LC040 model isn't tested),
o The VMEchip2 must be present,
o If offboard VMEbus RAM is not present, at least 8MB of onboard
RAM is required.
o Even if offboard VMEbus RAM *is* present, at least 4MB of onboard
RAM is required. (Boards with 1 or 2MB onboard RAM *can* be
supported with offboard RAM, but not without some funky values in
the VMEbus Master mapping registers.)
There is no support for boards other than those in the -LX 200/300 series.
treated as just another available VMEbus slave image as far as
bus_dma(9) is concerned.
To preserve faster onboard memory, mvmebus_dmamem_alloc() will
allocate first from the offboard VMEbus RAM slave image if present,
and assuming its address modifier matches the caller's constraints.
This can be overidden by specifying the BUS_DMA_ONBOARD_RAM flag.
deal with dynamic address modifier generation based on the CPU's
function code pins.
Also implement VMEbus slave mode for mvme147. (Not yet 100% working.)
in the non-MULTIPROCESSOR case (LOCKDEBUG requires it). Scheduler
lock is held upon entry to mi_switch() and cpu_switch(), and
cpu_switch() releases the lock before returning.
Largely from Bill Sommerfeld, with some minor bug fixes and
machine-dependent code hacking from me.
vme_dmamem*.
This is still a work in progress, but seems to DTRT on mvme167 so far.
TODO:
. Get VMEbus slave mode going on mvme147. This should be easy.
. Fix up the A16 slave mappings.
. Bounce buffer support. (Messy, but pretty much a `must have'.)
. Figure out how to deal with `location monitor' interrupts
within the framework. (Useful for Busnet, among other things.)
. It would be nice to make use of the VMEchip2's DMA facilities...
Debugger(). Use db_printf() instead.
This fixes a problem whereby it was impossible to enter the debugger
if the CPU was spinning in lockmgr() for the proclist lock, because
printf() calls logwakeup(), which eventually calls proclist_lock_read(),
which then spins in lockmgr() yet again...
[Note: This change was prematurely committed to the 1.5 branch by
mistake. Since it would've been pulled up anyway, I won't
be sending a pullup request.]
stuff
make this all compile with -Wall -Wno-main -Wmissing-prototypes
-Wstrict-prototypes -Werror , also compilable on 1.4.1
label itself as NetBSD/mvme68k instead of "BSD" in bootblock message
move bugcrt.c to libbug, remove bugcrt directory (bugcrt is still built
and used separately to rest of libbug)
convert sboot to use ordinary mvme68 libsa, instead of copying needed
stuff in libc_sa.c
convert to use version info generated by sys/conf/newvers_stand.sh
instead of previous version.c files, add necessary 'version' files
put chiptotime() to separate libsa file (used also by sboot/clock.c)
Thanks to Steve Woodford for help with this. Note that -current build
might be hosed by this change, will be addressed by Steve shortly.
itohy