- reduce maxusers from 32 to 8 as other m68k ports
- make NFS_BOOT_DHCP default rather than NFS_BOOT_BOOTP
(and move these options in "Networking options" block)
- use 8x16 font instead of 12x22 for machines with small screen like HP362
with "-O2":
text data bss dec hex filename
3717740 86092 152864 3956696 3c5fd8 netbsd
with "-O2 -fno-reorder-blocks":
text data bss dec hex filename
3304404 86092 152864 3543360 361140 netbsd
These options were specified in the INSTALL kernel for 4MB machines,
but nowadays even the INSTALL kernel would not boot on such machines
and the RAMDISK kernel assumes the target machine has more memories.
Furthermore, these options makes extracting binary sets much slower
and also could cause "wapbl_register_deallocation: out of resources"
panic during extracting binaries into a 32GB SSD with 4KB fragments.
Should be pulled up to netbsd-6* branches.
On NetBSD/hp300, hilkbd(4) is probed in config_interrupts(9)
so it's always attached after wsdisplay(4). In that case,
wskbd can't be used as a console input device without wsmux(4).
(i.e. keyboard didn't work on installer using screen console)
Should be pulled up to all netbsd-6* branches.
The cnattach functions for sti(4) and service switch check method
for 425e in com_frodo.c are taken from OpenBSD.
The strategy how to choose the console device in hp300_cninit() is
quite diverged from 4.4BSD and OpenBSD so it's tweaked by me.
Also put several changes in sti_sgc.c to reduce diffs from OpenBSD/hp300.
Tested on 425e and 362 (which still uses gendiofb(4), not sti(4)).
XXX: sti(4) requires uvm_km_alloc(9) and uvm_map_protect(9)
to copy and call ROM functions on the executable memory region, so
it can be called before UVM and related initializations are complete.
Probably it's time to consider about MI "deferred consinit()" API
in init_main.c (or elsewhere) for modern complicated VM system...
Also put several cleanup:
- make local functions and variables static
- use proper variable types
- some KNF
Note it turns out that extreme slowness of netboot on hp300 is
caused by the too slow access of the traditional RTC chip at intio
(i.e. netboot on 425e is so much faster than others). Oh well.
As the OpenBSD/hp300 page says 425e doesn't have the traditional
RTC at intio (as it also lacks DCA 16550 serial at intio?),
but after a few hour investigation it turns out that
425e uses mc146818 compatible calendar clock in
the Apollo "frodo" utility chip and the frodo chip on
425e actually has the 32kHz OSC and is actually backed up
by the onboard lithium battery.
Tested on HP425e (with mcclock) and HP362 (with old rtc).
Taken from OpenBSD/hp300. See the following comment for details:
>> * Check the service switch. On the 425e, this is a physical
>> * switch, unlike other frodo-based machines, so we can use it
>> * as a serial vs internal video selector, since the PROM can not
>> * be configured for serial console.
I.e. fix apci device address per FRODO_BASE macro change
in frodoreg.h rev 1.2. Now bootloader works with serial console
on HP425e (which has only com at frodo).
Thanks to miod@openbsd for providing his 425e.
designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
It's amiga and atari specific and copied from amiga/locore.s
to mac68k/locore.s in rev 1.80, then pasted into other ports.
Note this is harmless because all these ports don't have 68060 variants
(i.e. it's inside #if defined(M68060) block) and mvme68k (which has 68060)
has removed it since the initial import.
WSDISPLAY_COMPAT_USL using the following rules:
- If WSEMUL_ is commented out, add commented out out WSDISPLAY_COMPAT_USL
- If INSTALL or obviously memory constrained, add WSDISPLAY_DEFAULTSCREENS=1
and commented out WSDISPLAY_COMPAT_USL
- Otherwise add WSDISPLAY_COMPAT_USL
Some of the INSTALL configs for larger memory machines are probably suitable
for adding WSDISPLAY_COMPAT_USL.
Now wsconscfg(8) should be able to switch VTs when expected.
Implemented after no objection from tech-kern to the following:
On 5 June 2012 09:47, David Brownlee <abs@absd.org> wrote:
> wsconscfg(8) requires WSDISPLAY_COMPAT_USL in order to switch virtual
> terminals.
>
> Except when in an exceptionally memory or space constrained
> environment (INSTALL being the obvious case), is there any reason why
> all GENERIC and GENERIC-like kernels which have wscons enabled
> shouldn't also have WSDISPLAY_COMPAT_USL?
