major code cleanup esp. types used. Also cleanup up a major BUG that for
some odd reason worked :-/ makes me puzzled. It signifies that there might
be copies around in physical space of the DRAM ??? and thus its function
was motherboard dependent? It must have been old cruft from before the
cleanup of the relocation engine.
/*
* The size of the code/data to be moved is not `end - rmbase' but
* `__bss_start__ - rmbase' for the module is loaded into RISC OS
* based on the filesize where as NetBSD doesn't have to include all
* the bss space into the file itself. In some odd cases the
* relocatable module area can be smaller than the module + bss and
* thus bomb out.
*/
cd ${KERNSRCDIR}/${KERNARCHDIR}/compile && ${PRINTOBJDIR}
This is far simpler than the previous system, and more robust with
objdirs built via BSDOBJDIR.
The previous method of finding KERNOBJDIR when using BSDOBJDIR by
referencing _SRC_TOP_OBJ_ from another directory was extremely
fragile due to the depth first tree walk by <bsd.subdir.mk>, and
the caching of _SRC_TOP_OBJ_ (with MAKEOVERRIDES) which would be
empty on the *first* pass to create fresh objdirs.
This change requires adding sys/arch/*/compile/Makefile to create
the objdir in that directory, and descending into arch/*/compile
from arch/*/Makefile. Remove the now-unnecessary .keep_me files
whilst here.
Per lengthy discussion with Andrew Brown.
got wrong when no VRAM was there.
Placing the video DRAM in front of the kernel is OK when its 1Mb since the
kernel wants to be on a Mb boundary. Placing the video DRAM in the last
SIMM bank at the front is also OK unless there is just one SIMM and just one
bank; then it got in the way again!
Solution is to put the DRAM at the end of the SIMM instead of the beginning!
This however can result in the non 16 kb alignment of the top of physical
RAM where the temporary L1 page tables are situated. If its not 16 kb aligned
then move the L1 page table address down and down until it is 16 kb aligned.
This memory will be reused later on anyway.
What to do when we really support changing screensizes... see it as a max?
or use a different sceme alltogether? It might not even be a bootloader
problem then allthough its memory is not showing up in the DRAM/VRAM
block counts wich needs to be fixed one day.
platform. It features far better support for newer architectures and is
fully rewritten in C and compile-able under NetBSD.
Since it shares code with `boot26' for Acorn26 merging the common parts is
likely to be next on the list.
- disk_unbusy() gets a new parameter to tell the IO direction.
- struct disk_sysctl gets 4 new members for read/write bytes/transfers.
when processing hw.diskstats, add the read&write bytes/transfers for
the old combined stats to attempt to keep backwards compatibility.
unfortunately, due to multiple bugs, this will cause new kernels and old
vmstat/iostat/systat programs to fail. however, the next time this is
change it will not fail again.
this is just the kernel portion.
kqueue provides a stateful and efficient event notification framework
currently supported events include socket, file, directory, fifo,
pipe, tty and device changes, and monitoring of processes and signals
kqueue is supported by all writable filesystems in NetBSD tree
(with exception of Coda) and all device drivers supporting poll(2)
based on work done by Jonathan Lemon for FreeBSD
initial NetBSD port done by Luke Mewburn and Jason Thorpe
in question, whereas the ARM code was using it to hold the model
identification. To fix this, rename:
ci_cpuid -> ci_arm_cpuid
ci_cputype -> ci_arm_cputype (for consistency)
ci_cpurev -> ci_arm_cpurev (ditto)
ci_cpunum -> ci_cpuid
This makes top(1) give correct CPU numbers in its "STATE" column (all 0 for
now).
invalidation after every lock to ensure that changes made by other CPUs are
visible. This has nasty performance implications, but it does allow my
Hydrated Risc PC to run printf() on all its CPUs at once without corrupting
the message buffer.
and boot multi-user on a single-processor machine. Many of these changes
are wildly inappropriate for actual multi-processor operation, and correcting
this will be my next task.
based systems. Untested on shark, but is the right thing to do. I suspect
the original arm32 intr.h had the bug, and when the ports split we just took
the bug.
at run time. This simplifies the code and avoids problems with uninitialised
variables, and if it's good enough for pciide(4), it's good enough for me.
Also normalise the prefix for channel-specific messages.
necessary to allow the card to be detected afterwards. In theory, this
shouldn't be necessary, since we don't touch the page latch yet, but I'm not
going to argue.
This merge changes the device switch tables from static array to
dynamically generated by config(8).
- All device switches is defined as a constant structure in device drivers.
- The new grammer ``device-major'' is introduced to ``files''.
device-major <prefix> char <num> [block <num>] [<rules>]
- All device major numbers must be listed up in port dependent majors.<arch>
by using this grammer.
- Added the new naming convention.
The name of the device switch must be <prefix>_[bc]devsw for auto-generation
of device switch tables.
- The backward compatibility of loading block/character device
switch by LKM framework is broken. This is necessary to convert
from block/character device major to device name in runtime and vice versa.
- The restriction to assign device major by LKM is completely removed.
We don't need to reserve LKM entries for dynamic loading of device switch.
- In compile time, device major numbers list is packed into the kernel and
the LKM framework will refer it to assign device major number dynamically.
Seems that we assume that the dram blocks are sorted, and that the first/lowest address is also where the kernel is.
If the above is not true, then we're on a kinetic (probably should make a better way to indicate this) So search for all dram blocks < with starting addr lower than the first block and remove them.
Currently there's minimal performance gain (which is odd as the SDRAM is meant to be faster, I'm wondering if we need to prod some hidden registers to set timing information.
Note that I still get 16MB/s compared with 7MB/s on RiscStation and 93MB/s on my cats. I'm thinking that something else is seriously nasty on acorn32.
to do uncached memory access during VM operations (which can be
quite expensive on some CPUs).
We currently write-back PTEs as soon as they're modified; there is
some room for optimization (to write them back in larger chunks).
For PTEs in the APTE space (i.e. PTEs for pmaps that describe another
process's address space), PTEs must also be evicted from the cache
complete (PTEs in PTE space will be evicted durint a context switch).
counters. These counters do not exist on all CPUs, but where they
do exist, can be used for counting events such as dcache misses that
would otherwise be difficult or impossible to instrument by code
inspection or hardware simulation.
pmc(9) is meant to be a general interface. Initially, the Intel XScale
counters are the only ones supported.
SCSIPI_ADAPT_POLL_ONLY to tell the MI scsipi layer to do it for us. This,
plus G/Cing some debugging code, removes the card-specific scsi_request
wrappers.
into platform-specific initialization code, giving platform-specific
code control over which free list a given chunk of memory gets put
onto.
Changes are essentially mechanical. Test compiled for all ARM
platforms, test booted on Intel IQ80321 and Shark.
Discussed some time ago on port-arm.
be properly used by any misc. cloning device. While here, correct
a comment to indicate that "open" is the only entry point and that
everything else is handled with fileops.
MALLOC_NOINLINE, and VNODE_OP_NOINLINE. The exceptions are when they
include another config files that already defines the options, or if
they are for an embedded board, just define a few extra options, and
do not already define PIPE_SOCKETPAIR.
ragge