previous behaviour of storing them with SR.BL clear was in breach
of the SH5 documentation.
Make an effort to catch PANIC traps and dump machine state to the console.
pcb contains valid state before copying it to p2's pcb.
Previously, we just lazy-sync the fpu state. This wasn't quite good
enough if p1 had not previously slept.
way for bus_space(9) to efficiently map device memory. (Although at
the moment, it doesn't quite work as efficiently as it will down
the line ...)
Fix a pool_init() botch.
Add a debug aid: dump_kipt(). This can be called from ddb(4) in order
to (partially) dump the contents of the kernel IPT.
- Clear SR.FD to enable the FPU. Seems like it starts up disabled. If the
core has no FPU, this is a nop.
- Preserve the debug bits (step/watch) in an attempt to appease the debugger.
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.
through the net the first time around. Here's the relevant snippet
of the original commit message:
Rename cdev_systrace_init() to cdev_clonemisc_init(), so it can
be properly used by any misc. cloning device.
simple config file option.
Also, don't hard code the endian setting in a header file. Rely instead
on the compiler defining __LITTLE_ENDIAN__ and DTRT as appropriate.
SH-5, meet NetBSD.
Let's hope this is the start of a long and fruitful relationship. :-)
This code, funded by Wasabi Systems, adds initial support for the
Hitachi SuperH(tm) SH-5 cpu architecture to NetBSD.
At the present time, NetBSD/evbsh5 only runs on a SH-5 core simulator
which has no simulated devices other than a simple console. However, it
is good enough to get to the "root device: " prompt.
Device driver support for Real SH-5 Hardware is in place, particularly for
supporting the up-coming Cayman evaluation board, and should be quite
easy to get running when the hardware is available.
There is no in-tree toolchain for this port at this time. Gcc-current has
rudimentary SH-5 support but it is known to be buggy. A working toolchain
was obtained from SuperH to facilitate this port. Gcc-current will be
fixed in due course.
The SH-5 architecture is fully 64-bit capable, although NetBSD/evbsh5 has
currently only been tested in 32-bit mode. It is bi-endian, via a boot-
time option and it also has an "SHcompact" mode in which it will execute
SH-[34] user-land instructions.
For more information on the SH-5, see www.superh.com. Suffice to say it
is *not* just another respin of the SH-[34].
scw