headers
Josh Tolbert | 3 Aug 2003 12:40

Motorola Powerstack DT-41200?

Hello,

A friend of mine (former MOT employee, naturally) moved out of town
and had this Powerstack up for grabs. I claimed it, but now I'm not
exactly sure what to do with it. Hardware information seems to be
extremely sparse. I'm guessing that any PCI video cards or SCSI
cards that play nice with OFW will work in the machine, so hopefully
I can find an old Mac video card kicking around and at least get
the thing running. Does anyone have any good links to manuals or
technical documentation for this buzzard? Google was not very
helpful.

Is there a NetBSD port for this machine? I've done some searching
on the lists and there's been posts about Powerstacks on several
of the powerpc-related mailing lists, but nothing really concrete.
I'd like to see a *BSD running on this thing.

Thanks,
Josh
Permalink | Reply | 0 comments |
headers
Dave Huang | 3 Aug 2003 19:11
Gravatar

Can't build -current kernel

> Module Name:	src
> Committed By:	matt
> Date:		Sat Aug  2 19:40:40 UTC 2003
> 
> Modified Files:
> 	src/sys/arch/powerpc/include: asm.h
> 
> Log Message:
> Nuke stmreg/ldmreg.  PPC64 doesn't have a lmd/stmd so make sure lmw/stmw
> don't invoke valid instructions on PPC64.

But just a few days ago, you changed sys/arch/powerpc/powerpc/setfault.S
to use stmreg instead of stmw :) I can't compile setfault.S on macppc
anymore...
Permalink | Reply | 0 comments |
headers
Matt Thomas | 4 Aug 2003 03:38

Significant cleanup of common PowerPC assembly code

I've committed new versions of locore_subr.S and the OEA trap_subr.S 
which have no functional changes.  PowerPC64 doesn't have the lmw/stmw 
(load/store multiple word) equivalents (e.g no lmd/stmd).  Thus the 
continued use of those instructions will make code portability between 
PPC32 and PPC64 difficult.  The easy way to avoid those difficult is to 
just stop using them.

The other significant change is that those files no longer use stw/lwz 
directly.
Instead pseudo-instructions ldint/stint, ldreg/streg, ldlong/stlong, 
ldptr/stptr, and their update variants have been added.  Assembly (that 
may be run on PPC64) should use them.  Those pseudo-instructions will 
emit the appropriate width load/store instruction for the PPC variant 
that is being targeted.

I'll will be converting much of the existing .S files for PowerPC to be 
using those instructions.
--

-- 
Matt Thomas                     email: matt <at> 3am-software.com
3am Software Foundry              www: 
http://3am-software.com/bio/matt/ Cupertino, CA              
disclaimer: I avow all knowledge of this message.
Permalink | Reply | 1 comment |
headers
Nathan J. Williams | 4 Aug 2003 03:44

Re: Significant cleanup of common PowerPC assembly code

Matt Thomas <matt <at> 3am-software.com> writes:

> I've committed new versions of locore_subr.S and the OEA trap_subr.S
> which have no functional changes.  PowerPC64 doesn't have the lmw/stmw
> (load/store multiple word) equivalents (e.g no lmd/stmd).  Thus the
> continued use of those instructions will make code portability between
> PPC32 and PPC64 difficult.  The easy way to avoid those difficult is
> to just stop using them.

This is also generally a performance benefit on modern PowerPC CPUs.

        - Nathan
Permalink | Reply | 0 comments |
headers
Matt Thomas | 4 Aug 2003 18:16

Re: stmw/lmw [Was: CVS commit: src/sys/arch/powerpc/powerpc]


On Monday, August 4, 2003, at 07:51 AM, Jason Thorpe wrote:

>
> On Sunday, August 3, 2003, at 06:31  PM, Simon Burge wrote:
>
>> Does this have any measurable impact on trap response and context 
>> switch
>> times (simply because of more instruction fetches)?  It's also larger
>> code, so we have greater I$ pollution...
>
> It might be worth #ifdef'ing the use of those insns, using 
> __OPTIMIZE_SIZE__ to use the load/store-multiple insns on non-PPC64.

I thought of that.  But use of stmw/lmw are usually buried inside other 
macros and makes even more messy.  The amount of instructions is 
relatively minor
and is (IMO) not worth the effort.

> It's worth noting, however, that individual load/store insns are 
> probably going to be faster than the load/store-multiple on most 
> modern PPCs (like, probably everything since the 601).

That has been my experience.
--

-- 
Matt Thomas                     email: matt <at> 3am-software.com
3am Software Foundry              www: 
http://3am-software.com/bio/matt/ Cupertino, CA              
disclaimer: I avow all knowledge of this message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 9 Aug 2003 19:09
Picon

Re: macppc kernel make -j4 fail

[ moved to port-powerpc ]

On Sun, Aug 10, 2003 at 02:03:43AM +0900, Izumi Tsutsui wrote:
> Well, IIRC bzero.S was temporarily(?) disabled about 1.5 years ago
> because it uses cachelinesize which should be determined
> at runtime (and it might cause problem on stand alone programs etc).
> http://mail-index.netbsd.org/port-powerpc/2001/12/
> 
> I don't know if there is any conclusion about this.

I'd say remove it. It can be cvs add'ed back later if needed.
Nothing in the kernel uses bzero anymore, so I don't think it's worth
trying to optimise it.
I guess gcc will inline the memset() calls.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer <at> lip6.fr
     NetBSD: 24 ans d'experience feront toujours la difference
--
Permalink | Reply | 1 comment |
headers
Izumi Tsutsui | 10 Aug 2003 05:39
Picon
Gravatar

Re: macppc kernel make -j4 fail

In article <20030809170953.GA17009 <at> antioche.lip6.fr>
bouyer <at> antioche.lip6.fr wrote:

> I'd say remove it. It can be cvs add'ed back later if needed.
> Nothing in the kernel uses bzero anymore, so I don't think it's worth
> trying to optimise it.
> I guess gcc will inline the memset() calls.

I agree with you, but I'd punt it to powerpc (or toolchain) guys.
---
Izumi Tsutsui
tsutsui <at> ceres.dti.ne.jp
Permalink | Reply | 0 comments |
headers
Matt Thomas | 13 Aug 2003 01:50

Important bug fix: powerpc/powerpc/locore_subr.S

http://mail-index.netbsd.org/source-changes/2003/08/12/0034.html

contains a significant fix which could cause random crashes of PowerPC 
based NetBSD systems.  The cpu_switch code was incorrectly lowering SPL 
which was
leading random panics in remrunqueue and other places.  I have not 
looked to see if NetBSD-1.6 contains the same problem(s).
--

-- 
Matt Thomas                     email: matt <at> 3am-software.com
3am Software Foundry              www: 
http://3am-software.com/bio/matt/ Cupertino, CA              
disclaimer: I avow all knowledge of this message.
Permalink | Reply | 0 comments |
headers
Simon Burge | 18 Aug 2003 08:06

Re: CVS commit: src/sys/arch/evbppc/walnut

Hi Eduardo,

On Sun, Aug 03, 2003 at 11:28:46PM +0000, Eduardo Horvath wrote:

> Module Name:	src
> Committed By:	eeh
> Date:		Sun Aug  3 23:28:46 UTC 2003
> 
> Modified Files:
> 
> 	src/sys/arch/evbppc/walnut: walnut_start.S
> 
> Log Message:
> 
> The firmware actually passes the info block pointer in the link register.

With this change, the info block pointer is set to 0xfffe2960, which is
near the end of the ROM "invalidate_dcache" function.  The board info
now looks like:

	Board config data:
	  usr_config_ver = L
	  rom_sw_ver = 8
	  mem_size = 1619296256
	  mac_address_local = 7c:93:03:86:38:80
	  mac_address_pci = 00:11:7c:92:03:86
	  processor_speed = 1015022209
	  plb_speed = 1619285120
	  pci_speed = 2090009478
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eduardo Horvath | 19 Aug 2003 01:23
Picon

Re: CVS commit: src/sys/arch/evbppc/walnut

On Mon, Aug 18, 2003 at 04:06:18PM +1000, Simon Burge wrote:
> Hi Eduardo,
> 
> On Sun, Aug 03, 2003 at 11:28:46PM +0000, Eduardo Horvath wrote:
> 
> > Module Name:	src
> > Committed By:	eeh
> > Date:		Sun Aug  3 23:28:46 UTC 2003
> > 
> > Modified Files:
> > 
> > 	src/sys/arch/evbppc/walnut: walnut_start.S
> > 
> > Log Message:
> > 
> > The firmware actually passes the info block pointer in the link register.
> 
> With this change, the info block pointer is set to 0xfffe2960, which is
> near the end of the ROM "invalidate_dcache" function.  The board info
> now looks like:
> 
> 	Board config data:
> 	  usr_config_ver = L
> 	  rom_sw_ver = 8
> 	  mem_size = 1619296256
> 	  mac_address_local = 7c:93:03:86:38:80
> 	  mac_address_pci = 00:11:7c:92:03:86
> 	  processor_speed = 1015022209
> 	  plb_speed = 1619285120
> 	  pci_speed = 2090009478
(Continue reading)

Permalink | Reply | 0 comments |

Gmane