Izumi Tsutsui | 1 Oct 2006 09:13
Picon
Gravatar

sun3 bus_space(9) support added

In article <060606082156.M0114425 <at> mirage.ceres.dti.ne.jp>
I wrote:

> IIUC, the abuse is in sun3/sun3/vme.c. It uses cf_unit to specify
> VME bus types. Of cource sun3 should switch to the MI vme driver,
> but we have to implement bus_space(9) for sun3 first.
> It should be trivial (see sun68k/sun68k/bus.c), but...

As seen on source-changes, finally I've committed changes which
add bus_space(9) support on sun3 port with existing sun68k/bus.c.

http://mail-index.netbsd.org/source-changes/2006/10/01/0003.html

There is no device drivers which have been changed to use these
bus_space(9) API yet, but this is the (late) first step to switch
sun3 port to more MI drivers like sys/dev/sun and sys/dev/vme etc.
MD bus_dma(9) backends are not implemented yet, but it should be trivial..

I'll switch homegrown todclock functions (clock and oclock) to
MI intersil7170(4) and mk48txx(4) first.
(is there anyone who can test it on 3/4xx? ;-)
---
Izumi Tsutsui

Izumi Tsutsui | 1 Oct 2006 10:58
Picon
Gravatar

intersil7170(4) cleanup

Hi,

I'd like to commit the following changes against the intersil7170(4)
TOD clock driver used on old sun3/sun4 machines:

- make intersil7170_softc more generic and allocate it during autoconf(9)
  (rather than MALLOC(9) in attachment)
- put todr_chip_handle_t, year0 value, and the century adjustment flag
  into the intersil7170_softc
- change the attachment function to just take the softc like mk48txx(4)
- split sys/dev/ic/intersil7170.h into intersil7170reg.h and intersil7170var.h
- cleanup some macro

I'll also change sun3 port to use these MI todr drivers.

Any comments (or reports on such ancient machines) are appricated.
(only tested on TME which emulates sun3/120)
---
Izumi Tsutsui

Index: share/man/man4/intersil7170.4
===================================================================
RCS file: /cvsroot/src/share/man/man4/intersil7170.4,v
retrieving revision 1.9
diff -u -r1.9 intersil7170.4
--- share/man/man4/intersil7170.4	27 Jun 2003 18:32:02 -0000	1.9
+++ share/man/man4/intersil7170.4	1 Oct 2006 06:11:44 -0000
 <at>  <at>  -34,22 +34,23  <at>  <at> 
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 .\" POSSIBILITY OF SUCH DAMAGE.
(Continue reading)

Nathan J. Williams | 1 Oct 2006 14:53

Re: sun3 bus_space(9) support added

Izumi Tsutsui <tsutsui <at> ceres.dti.ne.jp> writes:

> I'll switch homegrown todclock functions (clock and oclock) to
> MI intersil7170(4) and mk48txx(4) first.
> (is there anyone who can test it on 3/4xx? ;-)

sigh. of course this comes up about a month after I trashed my last
VME-card-cage system.....

        - Nathan

Izumi Tsutsui | 5 Oct 2006 13:50
Picon
Gravatar

Re: intersil7170(4) cleanup

I wrote:

> I'd like to commit the following changes against the intersil7170(4)
> TOD clock driver used on old sun3/sun4 machines:
 :
> I'll also change sun3 port to use these MI todr drivers.

Committed.

If you see any problem, please report here of via send-pr(1).
---
Izumi Tsutsui

SigmFSK | 16 Oct 2006 22:05
Picon
Favicon

stack limit for sun3/sun3x

I'm running NetBSD 3.0 on a real sun3/80 (sun3x with 16Mb) , and also have  
NetBSD 3.0 running inside TME (emulated sun3/160 with 32Mb). 

On the real  sun3x, the following gcc-3.3.3 testsuite program 
(gcc.dg/20020425-1.c) compiles,  whereas it fails to compile inside TME with a segmentation 
violation. 

I  tracked down the cause: sun3 inside TME has a 2Mb stack limit, whereas the 
 real sun3x has an 8Mb stack limit (TME produces seg fault in NetBSD when  
attempting to push anything on the stack below SP = 0xdf80000).  Maybe the  2Mb 
stack limit is correct for a sun3 (vs. sun3x)?

Does someone know the  NetBSD 3.0 stack limits for sun3/sun3x? 
Or can someone attempt to compile  the following (under NetBSD 3.0 / 
gcc-3.3.3) on a real sun3 (vs. sun3x) and see  if the compile passes? 

If no - then TME is fine - it is correctly emulating a real sun3.
If yes - then I probably won't fix TME; I'd hate to break the MMU emulation  
code since I rarely put 2Mb on the stack, but I'll at least modify it to  
print out a warning when the 2Mb limit is reached.

thanks, 
arthur 

/* PR c/2161: parser stack overflow.   */ 
/* { dg-do compile } */ 

#define  ONE        else if (0) { } 
#define  TEN        ONE ONE ONE ONE ONE ONE ONE ONE  ONE ONE 
#define HUN        TEN TEN TEN  TEN TEN TEN TEN TEN TEN TEN 
(Continue reading)

Jeremy Cooper | 17 Oct 2006 02:48
Picon

Re: stack limit for sun3/sun3x


On Mon, 16 Oct 2006 SigmFSK <at> aol.com wrote:

> Does someone know the  NetBSD 3.0 stack limits for sun3/sun3x?
> Or can someone attempt to compile  the following (under NetBSD 3.0 /
> gcc-3.3.3) on a real sun3 (vs. sun3x) and see  if the compile passes?

Arthur, the stack limit on the sun3x is determined from the file

sys/arch/sun3/include/vmparam3x.h

The relevant part is this snippet:

#ifndef	MAXSSIZ
#define	MAXSSIZ		(32*1024*1024)		/* max stack size */
#endif

So the answer to your question is 32 megabytes.

You can view the file via cvsweb at

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sun3/include/vmparam3x.h

-J

SigmFSK | 17 Oct 2006 04:52
Picon
Favicon

Re: stack limit for sun3/sun3x

In a message dated 10/16/2006 8:48:28 P.M.  Eastern Standard Time, 
jeremy <at> netbsd.org writes:

Arthur, the stack limit  on the sun3x is determined from the  file

sys/arch/sun3/include/vmparam3x.h

The relevant part is this  snippet:

#ifndef    MAXSSIZ
#define     MAXSSIZ         (32*1024*1024)        /* max stack size  */
#endif

So the answer to your question is 32 megabytes.  

----

Hi Jeremy:  That does seem clear, but it seems I can't use nearly that  much 
on a real sun3x.

On a real sun3/80, running NetBSD 3.0, I run the following  program that is 
designed to quickly use up stack space:

#include <stdio.h>

int val(int myval)
{
if (myval == 0) {
return 0;
} else {
(Continue reading)

SigmFSK | 17 Oct 2006 19:00
Picon
Favicon

Re: stack limit for sun3/sun3x

I believe I've found a problem with NetBSD 3.0 for Sun3/Sun3x leaving the  
maximum stack size at the initial stack size DFLSSIZ in vmparam3/vmparam3x  and 
not increasing it to the maximum MAXSSIZ.

On a real sun3x running NetBSD 3.0, the maximum stack limit is 2Mb  (DFLSSIZ 
in vmparam3x.h instead of the 32Mb MAXSSIZ). This is from examining the  SP 
via GDB at the beginning of main, and when the stack overflows, generating a  
seg fault (f7ffee20 - f7dffffc).  (test runs to 130786 recursive  calls).

On a TME emulated sun3 running NetBSD 3.0, the maximum stack limit is 512Kb  
(DFLSSIZ in vmparam3.h instead of the 32Mb MAXSSIZ).  Same gdb/sp  examine 
(dffedb0 - df7fffc).  (test runs to 32475 recursive calls).

It looks like TME is working, at least mostly well.  Running SunOS  4.1.1 
stack limit test inside TME has almost the same results as on a real sun3  and 
sun3x: approx 2Mb.  Inside TME, the SP check can run to 131051  recursive calls 
before blowing up.  On a real sun3/sun3x, the SP check runs  to 131026.

/arthur

SigmFSK | 18 Oct 2006 19:33
Picon
Favicon

TME sun3 emulator status & getting ethernet working

I've been doing lots of testing of Matt Fredette's sun3 emulator,  TME.

I'm constantly amazed and impressed with TME.  It does so much,  so well.  

I found and fixed the following M68K emulation  bugs:
incorrect calculation of Effective Address for immediate-mode  instructions 
with program counter indirect 16-bit displacement addressing  (problem 34538)
cmp2/chk2 instructions not emulated correctly (problem  33969)
movel sp,-(sp) pushes wrong value on stack (problem  34690)
fcmp doesn't consider positive infinity/negative infinity equal  to itself 
(problem 34571)
fneg of 0.0 is not -0.0 (problem 34616)

Now, other than a few floating point tests (problem 34691), all the  below 
testsuites operate identically inside TME as on a real  sun3:
NetBSD 3.0, gcc-3.3.3-testsuite
SunOS 4.1.1,  gcc-3.2.3-testsuite
and the complete Ada Compiler Validation Capability  as compiled under 
Telesoft under SunOS 4.1.1, running under NetBSD 3.0, NetBSD  1.5.3, and SunOS 4.1.1

Floating point emulation isn't perfect inside  TME, but it is better than 
turning off TME's mc68881 emulation and allowing  NetBSD running inside TME to do 
the emulation.  And its also better than  using a custom NetBSD 
kernel/userland with -mksoftfloat (problem  34553).

The emulated tape drive sometimes truncates files (problem  34536), and I 
wasn't able to login via an emulated serial line (problem 34835),  but these are 
minor complaints, being that ethernet works so well...for running  NetBSD 
inside TME.

(Continue reading)


Gmane