headers
Rafal Boni | 3 Jan 2003 11:18
Picon

Adding R5k/Rm5200 L2 cache enable bit to CP0_CONFIG

Folks:
	To get the R5k/Rm5200 with L2 cache working, one first needs to
	enable the L2 cache in software; I've got changes to do that,
	which I'll send under separate cover, but right now I'd like
	to add enough code to have the MIPS cache code deal with the
	situation where the L2 cache is present but disabled.

	To do this, I've added a MIPS3_CONFIG_SC_ENABLE bit to the
	MIPS cpuregs.h header file; this name is bad for several
	reaons:
		* That bit isn't present in generic MIPS3 CPUs; it's
		  specific to R5k/Rm52xx/Rm7k and maybe some others.
		  On the Rm7k, it in fact controls L3 cache, not L2.
		* I believe the bit is called `SE' in the R5k docs
		  and/or the Rm52xx docs.

	Do folks out there have a suggested name for this bit which
	would fit both the above constraints, or should I leave it
	as MIPS3_CONFIG_SC_ENABLE or change it to MIPS3_CONFIG_SE
	so it at least matches the docs? (I prefer the latter of 
	the two names).

	As you can see this patch is a bit of a WIP (I've got more
	changes in comments than actual code 8-); I plan on cleaning
	up the comments before I commit...

	Diff attached below.  Thanks to Chris Sekiya for the initial
	version of all the R5k cache code which propelled this in the
	right direction 8-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafal Boni | 6 Jan 2003 08:07
Picon

Changes for R5k secondary caches, please review!

Folks:
	Attached are the current set of changes I've got to handle the R5k
	secondary caches as found on the SGI O2 (both in R5k and Rm5200
	flavors).  Some cleanup still needs to be done (see also my last
	mail on naming the CP0_CONFIG bits 8-), but this should be close
	to the intended effect in form and function.

	Besides these changes, one needs the pmap hacks I posted a while
	back, as the hardware does not do virtual coherency detection.
	I would like feedback on this stuff independently of the needed
	pmap changes, as I'd like to get all the small issues sorted out
	before I go attack the pmap code.

	I'm also considering for the short term (before I get the pmap 
	issues sorted out) the pmap a `no virtual coherency detection'
	hint which would cause to behave much as it does not when there
	is no secondary cache.  Is anyone deeply grossed out by this as
	a short-term band-aid?

	I've broken out the R5k (and R4600, since AFAICT the two are more
	alike than the R4k and R4600) declarations into a separate header
	file, "cache_r5k.h", but the code still depends on the cache ops
	declared in "cache_r4k.h"; should I have the former include the
	latter, or is having the dependency implicit (as I do in these
	patches) OK?

	Changes attached, please let me know what you all think!  Giving
	credit where credit is due, almost all of this code was originally
	written by Chris Sekiya -- all bugs and butcheries after the fact
	are most likely my doing, as are some of the small improvements..
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Mattes | 16 Jan 2003 18:45
Picon
Picon
Favicon

compiling help (config.sub cobalt-unknown-netbsd1.6 failed)

Dear Cobalt netBSD user,

i need a package called "pstoedit" to chance ps files into files for xfig. 
The package is not available as binary so I tried
cd /usr/pksrc/graphics/pstoedit
and
make

I have all the dependencies, but the compiling process stops strait with

dynload.cpp:83: #error "system unsupported so far"
dynload.cpp:159: parse error
dynload.cpp:372: #error "system unsupported so far"
*** Error code 1

Stop.
make: stopped in /home/users/frank/tmp/pstoedit-3.33/src
*** Error code 1

Stop.
make: stopped in /home/users/frank/tmp/pstoedit-3.33

It looks that config.sub does not know the cobalt, but I suppose compiling 
for any mipsel machine would do. Does anybody know how to get pstoedit 
compiled ?

I appreciate any help
Frank
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher SEKIYA | 20 Jan 2003 11:26

signal.h context lossage, diff attached

Hello,

Looks like a critical bit for arch/mips/include/signal.h didn't survive the
nathanw-sa merge.  The attached diff seems to do the right thing ... at least,
the compile doesn't choke anymore ...

-- Chris
	GPG key FEB9DE7F (91AF 4534 4529 4BCC 31A5  938E 023E EEFB FEB9 DE7F)

Index: sys/arch/mips/include/signal.h
===================================================================
RCS file: /cvsroot/src/sys/arch/mips/include/signal.h,v
retrieving revision 1.17
diff -u -r1.17 signal.h
--- sys/arch/mips/include/signal.h	2003/01/18 13:03:17	1.17
+++ sys/arch/mips/include/signal.h	2003/01/20 10:23:07
 <at>  <at>  -104,9 +104,9  <at>  <at> 
 	(sc)->mulhi = (uc)->uc_mcontext.__gregs[_REG_MDHI];		\
 									\
 	if ((uc)->uc_flags & _UC_FPU) {					\
-		memcpy((sc)->sc_fpregs,					\
-		    (uc)->uc_mcontext.__fpregs.__fp_r.__fpregs32,	\
-		    sizeof((uc)->uc_mcontext.__fpregs.__fp_r.__fpregs32)); \
+		memcpy(&(sc)->sc_fpregs,					\
+		    &(uc)->uc_mcontext.__fpregs.__fp_r.__fp_regs32,	\
+		    sizeof((uc)->uc_mcontext.__fpregs.__fp_r.__fp_regs32)); \
 		(sc)->sc_fpregs[32] =					\
 		    (uc)->uc_mcontext.__fpregs.__fp_csr;		\
 		(sc)->sc_fpc_eir = 0;	/* XXX */			\
 <at>  <at>  -124,9 +124,9  <at>  <at>
(Continue reading)

Permalink | Reply | 1 comment |
headers
cancermail-request | 20 Jan 2003 16:10
Picon

CancerMail Request Unknown

                               !!! NOTICE !!!

*******************************************************************************
***     CancerMail service has been discontinued as of 6 December 2002.     ***
*******************************************************************************

NCI has updated its cancer information delivery services.

Please use these other ways to get cancer information from the NCI . . .

Internet:  Go to the NCI's Cancer.gov Web site at http://cancer.gov to get all
           the latest information from the National Cancer Institute including 
           updated PDQ® summaries, our clinical trials database, details about 
           NCI research programs, and grants and funding opportunities in 
           easy-to-use Web format.  LiveHelp instant messaging is available 
           9:00 a.m. to 10:00 p.m., Eastern time,to help users locate 
           information.

Telephone: Call the Cancer Information Service at 1-800-4-CANCER 
           (1-800-422-6237) Monday through Friday between 9:00 a.m. and 
           4:30 p.m., local time, to speak with a Cancer Information 
           Specialist. 
           Deaf and hard of hearing callers with TTY equipment may call 
           1-800-332-8615. 
           Specialists are able to provide paper copies of PDQ® cancer 
           information by mail upon request. Recorded information about cancer 
           is also available at this number 24 hours a day, 7 days a week.  

If you have questions or comments about these services, contact us. 
By e-mail at: cancer.gov_staff <at> mail.nih.gov
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 20 Jan 2003 17:28

Re: signal.h context lossage, diff attached

On Mon, Jan 20, 2003 at 07:26:48PM +0900, Christopher SEKIYA wrote:

 > Looks like a critical bit for arch/mips/include/signal.h didn't survive the
 > nathanw-sa merge.  The attached diff seems to do the right thing ... at least,
 > the compile doesn't choke anymore ...

I've checked it in, thanks :-)

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
Emmanuel Dreyfus | 28 Jan 2003 23:38
Picon

unknown patch

Hi all

While fixing COMPAT_IRIX, I discovered I still havd this local patch:

===================================================================
RCS file: /cvsroot/src/sys/arch/mips/mips/mipsX_subr.S,v
retrieving revision 1.11
diff -r1.11 mipsX_subr.S
739a740,754
> #ifndef IPL_ICU_MASK
> /*
>  * Allow any pending soft interrupts to run. This is needed in the case
>  * of an exception occurring immediately after the return from exception
>  * which would prevent the soft interrupt triggering.
>  */
>       mfc0    t2, MIPS_COP_0_STATUS
>       REG_L   t0, CALLFRAME_SIZ + FRAME_SR(sp)
>       and     t0, t0, MIPS_INT_MASK
>       DYNAMIC_STATUS_MASK_TOUSER(t0, t1)      # machine dependent masking
>       or      t0, t0, t2
>       mtc0    t0, MIPS_COP_0_STATUS
>       COP0_SYNC
> #endif
> 

Anyone want to do something with that? I beleive it is related to the
following mips only problem (there is a PR about this, but I can't find
it anymore)

#include <stdio.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Swift Griggs | 29 Jan 2003 11:13

Technical docs for O2 / Indy video hardware


Is there a good source for programmer documentation for:

1. Using the dmedia API for use with the analog video capture hardware on
   the Indy and O2 (under IRIX)?
2. The hardware itself (ie.. specs on the chips that could be used to
   write drivers for NetBSD)?

I'm new to port-mips so could someone in the know give a blurb about the
current state of supporting the video display and capture hardware for O2
and Indy workstations?

many thanks,
 swift
Permalink | Reply | 2 comments |
headers
Antti Kantee | 29 Jan 2003 13:28
Picon
Picon

Re: Technical docs for O2 / Indy video hardware

On Wed Jan 29 2003 at 03:13:47 -0700, Swift Griggs wrote:
> 
> Is there a good source for programmer documentation for:
> 
> 1. Using the dmedia API for use with the analog video capture hardware on
>    the Indy and O2 (under IRIX)?

IIRC they're documented at least in the insightbooks. And I do think
there's a fair number of example programs, and I remember that the manual
pages are ok also.

> 2. The hardware itself (ie.. specs on the chips that could be used to
>    write drivers for NetBSD)?

Hmm, it might be that there is a lot less documentation for this ;)

I think the O2 video capture engine is supported in linux, so you could
probably glance at their code.

> I'm new to port-mips so could someone in the know give a blurb about the
> current state of supporting the video display and capture hardware for O2
> and Indy workstations?

non-existent, contributions welcome ;).

ps. the correct list for this is port-sgimips, not port-mips

  - antti

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toru Nishimura | 30 Jan 2003 06:16
Picon

Re: unknown patch

manu <at> netbsd.org (Emmanuel Dreyfus) said;

> While fixing COMPAT_IRIX, I discovered I still havd this local patch:
> ...
> ...restoring CP0 SR value...
> ...
> Anyone want to do something with that? I believe it is related to the
> following mips only problem (there is a PR about this, but I can't find
> it anymore)

Your code looks reasonable (somehow) to me, however, I have severals to
say;
- the small program you provided is running very long time on stock i386
1.6-RELEASE eating CPU cycle, so your asserting is in doubt.
- there is "instruction hazard issue" immediately after load instruction.
This is a processor design issue peculiar to MIPS.  The processor(s) you use
may not make any trouble for the instruction sequence in particular, but
neglecting
load delay issue sets fires to the entire MIPS integrality.  You're warned.
- Please, don't be quick to fix/change/improve the suspicious code segments
before grasping what the matter really is.  The code we have now is known
bogus/dirty/hacky, and fortunately working.  It must be made clean to go
further, with large efforts to avoid spoiling NetBSD/mips.  Ask before any
change when something looks wrong.

Toru Nishimura/ALKYL Technology
Permalink | Reply | 1 comment |

Gmane