deal with the 64bit bridge mode. pmap changes by Matt Thomas, rest by myself.
Change pmap.c to work similar to exec_elf.c to allow us to compile in
multiple pmaps to a single kernel. This allows the pmap for bridge64 to
co-exist with the 32bit pmap.
Yank __HAVE_PMAP_PHYSSEG from all the oea code.
Add a new global, "oeacpufeat", which is used early in locore to determine
certain cpu features. This allows us to conditionalize code early in the boot
for certain CPUs that have special needs.
Yank most of the ifdef PPC_OEA_BRIDGE64 code from almost every file it was
found in. Some of it seemed incorrect, and my 7044 booted just fine
without it. It would appear that the bridge cpus treat BAT instructions
as nops, so they seem to be safe.
In ofppc, check the oeacpufeat, and if we are on a 64bit proc, clear
MSR[SF], and ASR[V].
With all of these changes, a kernel with both PPC_OEA and PPC_OEA_BRIDGE64
will boot on the POWERIII-2 cpu. However, it will not yet boot on a 32bit
cpu, because of CACHELINESIZE. Work remains to be done there to fix that.
during boot and ddb.
This is done by routing all requests for changes to the screen into one
function. The function can then determine if interrupts are enabled or
disabled, and either flush them to screen immediately or set them up for
the next flyback irq.
Also if we have nothing to do, disable the flyback irq, and re-enable when
we have something to do. This avoids taking an interrupt for every vsync,
IE 50-75Hz, just to do nothing.
This makes ddb usable and the boot dmesg visable with an SA.
lmbench now reports that the A7000+ has a 14Mhz CPU, rather than 4Mhz
(it's actually 48Mhz)
Tested on SA Risc-PC and A7000+
- add a comment to explain why:
+ * We start with 1, because 0 doesn't work with linux, which
+ * considers timestamp 0 in a SYN packet as a bug and disables
+ * timestamps.
revision 1.230
date: 2005/06/30 02:58:28; author: christos; state: Exp; lines: +20 -4
Normalize our PAWS code with Free and Open, as mentioned in tech-security.
reviewed by christos@ and matt@.
A rather excessive amount of 'appending 64' to names seems to have happened
when linux won support for files > 4G.
technically the linux32_sys_fcntl() function should error the 64bit file
locking requests - but life is too short.
