| Age | Commit message (Collapse) | Author |
|
|
|
|
|
This excludes atari, sgimips, evbmips, evbppc, evbsh3, and hpcarm
all of which have somewhat specific kernel config file layouts
|
|
|
|
Fix boot failure on my ancient Seagate ST52160N drive.
It looks some of such old drives can't respond to SCSI
test-unit-ready command without proper wait after SCSI bus reset.
Bump version again to denote a fix.
XXX we should re-evaluate cpuspeed counts for DELAY() in bootloaders
(where cache is disabled) on other m68k ports, hp300 and luna68k etc.
|
|
Also fix inconsistent sdopen() and sdstrategy() args and
remove useless #if 0'ed out code.
No functional change.
|
|
No sysinst(8) yet, but useful on bootstrap and rescue ops.
|
|
|
|
All these fixes should be pulled up to netbsd-10 and netbsd-9.
|
|
Also enable files-system MSDOS for file exchange via removable media.
|
|
|
|
|
|
It's useful for installation especially on emulators.
|
|
Info from Andreas Grabher on port-next68k@.
|
|
Info from Andreas Grabher on port-next68k@.
|
|
Info from Andreas Grabher on port-next68k@:
https://mail-index.netbsd.org/port-next68k/2023/02/06/msg000052.html
Also refactor bus_space_map(9) and fix (unused) bus_space_mmap(9).
|
|
|
|
Some drives don't respond larger requested size for newer
SCSI3 devices and not all drivers can handle short xfers.
We should fix drivers to handle such short xfers properly,
but we need only SCSI device type here (and the 36 bytes are
enough even if we want vendor and product names on a bootloader).
The problem is reported from Andreas Grabher (a maintainer of NeXT
Computer Emulator)a on port-next68k@:
https://mail-index.netbsd.org/port-next68k/2023/02/thread1.html
|
|
|
|
It looks booting from SCSI disks on next68k have been broken
since NetBSD 1.6 days, but now it works.
Should be pulled up to netbsd-10 and netbsd-9.
|
|
|
|
Whilehere, also remove VM definitions for obsolete COMPAT_HPUX stuff.
All hp300 machines has RAMs at a region from the highest address
i.e. 0xFFFFFFFF to smaller address (as HP claims "it's the MSB first"),
so kernels have to prepare PA==KVA mappings as the "last PT page" to
guarantee the running kernel works both before and after the MMU is
turned on. For such a special mapping, we have to set up necessary
segment table and page table during early startup, in pmap_bootstrap()
invoked from locore.s.
On the other hand, NeXT machines have RAMs at a region from 0x40000000
to below (i.e. to larger address) so we still need a PA==KVA mapping.
However currently NetBSD/next68k just uses the transparent translation
registers to achieve the PA==KVA mapping, so unlike hp300 we don't have
to prepare special segment table and page table for it.
Note many other m68k ports (like luna68k, news68k, x68k etc.) have
RAMs at a region from 0x00000000 so usually we can assume PA==KVA
and don't have to bother to prepare such speicial mappings.
No user visible changes (except now freed wasted pages for the tables).
Tested on my NeXTstation slab.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- use C99 designated initializer
- misc KNF
- TAB/space cleanup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
next68k bootloader cannot load a kernel larger than ~3.8 MB.
|
|
next68k esp(4) driver requires nextdma(4) interrupts at ipl 6
during ncr53c9x_intr() for esp(4) at ipl 3. It worked on netbsd-5
and prior, but on netbsd-5 splbio() was changed from ipl 3 to 6
for SMP support and on netbsd-6 ncr53c9x driver was changed to
use mutex(9) instead of simple_lock(9), so nextdma interrupts
were no longer raised during ncr53c9x interrupt handler.
For now, just call mutex_exit(9) and mutex_enter(9) during
waiting nextdma(4) interrupts in MD esp_dma_intr() handler.
This could be wrong and the interrupt handler for nextdma should
be reorganized, but it just works.
Should be pulled up to netbsd-10 and netbsd-9.
|
|
These functions write the read data into memory at a specified pointer,
but without the "memory" constraint gcc could optimize out these ops
if the memory is allocated on local stack.
With this fix nextkbd(4) works again.
Should be pulled up to netbsd-10 and netbsd-9.
|
|
|
|
Written by Hiroshi Noguchi, of which an updated version was posted to
port-mac68k in 2001.
Attachments were added to kernel configs for platforms that already had
the Cabletron (se.4) driver added, although other platorms may benefit.
Reviewed on tech-net by Izumi Tsutsui.
|
|
any case.)
|
|
- Enable UFS_DIRHASH if the architecture or kernel model specific config
file can use 128MB of RAM or more.
- Remove experimental tag from UFS_DIRHASH; it's been with RUMP kernel
and by a number of NetBSD developers for years.
- Add LFS_DIRHASH if LFS was enabled.
- Be somewhat consistent with FS options order.
|
|
|
|
|
|
way".
|
|
|
|
|
|
Currently most ports do nothing in cnpollc(9), but this is required to
handle wskbd(9) .set_leds op in cngetc(9) properly, at least on luna68k.
|
|
Affects only inside #ifdef DEBUG part on "trap during panic" in trap.c
derived from hp300.
|