| Age | Commit message (Collapse) | Author |
|---|
|
$ADORABLE_FELINE.
ok deraadt@ matthew@
|
|
"feel free!" deraadt
|
|
|
|
for both structs, the new members are 'bps' and 'msb', which
describe the number of bytes per sample and data alignment in the
sample, respectively. drivers must properly set these fields in
the 'query_encoding', 'set_parameters' and 'get_default_params'
hardware interface methods.
discussed with ratchov, deraadt
|
|
|
|
sun4c, as it has a sun4c OpenPROM but a sun4 8KB pagesize. VME devices are
not supported yet.
ok deraadt@
|
|
|
|
is stupid, since the bits in the interrupt enable register are completely
different between 4/4c and 4m.
Instead, provide distinct, explicit function names to handle the interrupt
enable register.
|
|
CPUTYP_xxx defines.
|
|
|
|
General huzzahs.
"go for it" deraadt@
|
|
|
|
|
|
ok deraadt matthew millert
|
|
|
|
sparsely populated buses.
ok dlg@, krw@
|
|
pv_changepte4m() since DVMA addresses are never loaded in the SRMMU; this
chunk was forgotten in the previous `don't steal DVMA out of kernel_map on 4m'
commit.
|
|
memory, but instead gather memory layout information and work with the MMU
(or the PROM) to make sure we can actually load the kernel image in a proper
contiguous physical memory area.
In order to do this, we look at the kernel image twice; during the first pass,
the kernel footprint is computed, and then after making sure it can be
loaded, the second pass loads the actual image.
Since such a logic doesn't work on media which can not seek backwards, such
as tapes, we check for the boot device being a tape and, in that case, assume
a fixed (generous) image size and don't load the kernel symbol table (to
avoid seeking backwards); since tape boot is supposed to be only used to
boot bsd.rd, this is something we can live with.
While there, lower the address the boot blocks are loaded in memory, because
the last crank did not work with some early sun4c OpenPROM, which only
map about 3.5MB of memory.
Memory games logic from NetBSD, tape handling by me.
|
|
low physical memory, but instead figure out where it has been loaded from
the current MMU setup.
From NetBSD.
|
|
space on SRMMU systems (i.e. sun4m), so don't do it anymore and update
misleading comments.
|
|
NetBSD; tested on SM100.
|
|
step in elminating 'struct scsi_device' entirely.
Spotted and initial diff from matthew@.
ok matthew@ dlg@ deraadt@ marco@ miod@
|
|
max-baud-rate hint. Adjust TTYHOG (the nearly full logic) to this new
situation. The larger buffers are required by the very high speed
KDDI devices in Japan (CF com, or USB ucom) so those are the only two
drivers which currently ask for a larger buffer size.
ok yasuoka miod
|
|
|
|
ok kettenis@
|
|
doing thread-local storage and fix a typo in one that was already defined.
ok kettenis@ drahn@
|
|
which contains the constraints for DMA/memory allocation for each
architecture, and dma_constraints which contains the range of addresses
that are dma accessable by the system.
This is based on ariane@'s physcontig diff, with lots of bugfixes and
additions the following additions by my self:
Introduce a new function pool_set_constraints() which sets the address
range for which we allocate pages for the pool from, this is now used
for the mbuf/mbuf cluster pools to keep them dma accessible.
The !direct archs no longer stuff pages into the kernel object in
uvm_km_getpage_pla but rather do a pmap_extract() in uvm_km_putpages.
Tested heavily by my self on i386, amd64 and sparc64. Some tests on
alpha and SGI.
"commit it" beck, art, oga, deraadt
"i like the diff" deraadt
|
|
it defines. In some cases, this means pulling in uvm.h or pcb.h
instead, but most of the inclusions were just noise. Tested on
alpha, amd64, armish, hppa, i386, macpcc, sgi, sparc64, and vax,
mostly by krw and naddy.
ok krw@
|
|
pmap_enter(), according to the XXX comment right above.
Removes another un-CANFAILed pmap_enter.
ok miod@
|
|
keyboard is connected but a framebuffer exists in the machine; the current
kernel console code will complain and switch to full serial, but later on
the framebuffer would incorrectly take over the console.
Correctly detect this situation and reset the `fbnode' variable. This is
an improvement of the fix which went in rev 1.54 of this file.
|
|
|
|
|
|
|
|
ok deraadt@
|
|
|
|
28 bit address bus) by reusing the regular sun4 configuration stanzas (with
the upper four bits set in the device addresses), and clearing them when
searching for a PROM mapping.
This makes the obio autoconf code simpler, and all knowledge of the 4/110
specifics is now contained in a single file (dev/obio.c).
ok todd@ deraadt@
|
|
bogus) `cache enabled' line in dmesg on 4/110.
ok todd@ deraadt@
|
|
|
|
|
|
prefer binutils-compatible options in STRIPFLAGS (now that our non-binutils
strip(1) can handle them too)
ok drahn; miod kettenis (for parts)
|
|
a fat kernel (GERERIC or GENERIC.MP) into a temporary dir, then extract some
variables using make -V, and after some more singing and dancing use this
full and (more) correct list of files with ctags. Don't read this code.
ok guenther
|
|
to genassym.sh
ok deraadt
|
|
the differences between these files. You will need a newer config(8) binary
to be able to build kernels.
ok kettenis miod
|
|
result: kernels built without 'make depend'-provided information
(ie. the .depend file) are more likely to have their *.[Ss] file
compilations track changes to *.h files.
The "*.o: assym.h" dependencies listed are gotten from reading the
.depend output --- from the biggest kernel possible (ie. GENERIC.MP).
When an architecture changes in a substantial way (new .[sS] files),
the list should be updated in the prettiest way possible.
This is not encouraging people to skip 'make depend'; other issues are
not resolved and may be solved later with a change guenther is working
on. You can still screwed really easily, so continue running make
depend as config tells you.
Idea from a discussion with drahn
ok drahn, kettenis likes the idea too
|
|
idea that came out of discussion with drahn
|
|
delete the archaic links: target which is easily misused
handle special .[sS] files in a portable way
|
|
ok various people, tested by fewer people, tested by me on 15.
|
|
|
|
requested by deraadt@ who was rightly disparaging of my grep skillz.
|
|
in 1.36.
|
