headers
Fraser Douglas | 12 Apr 2004 19:50

ev64260, softnet


I pulled from CVS last night (4/11/2004). Configured and compiled
sys/arch/evbppc/conf/EV64260
At completion, it failed to link, unknown symbol 'softnet'.

I cut the definition of softnet from sys/arch/powerpc/oea/oea_machdep.c and
pasted it
to the end of sys/arch/evbppc/ev64260/machdep.c

The resulting image linked and booted.
(just thought you should know....)

Doug Fraser

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================
Permalink | Reply | 0 comments |
headers
dwfraser | 12 Apr 2004 20:31
Favicon

RE: ev64260, softnet


Sorry about the disclaimer in the sig, that gets pasted by our
server AFTER I send...

I'll post from here from now on.

--

-- 
Doug
Permalink | Reply | 0 comments |
headers
Doug Fraser | 13 Apr 2004 15:17
Favicon

ev64260 PCI location / boot monitor


When the boot monitor runs (PMON) it configures the
PCI busses on the Discovery bridge. They were set to
address space 0xC0000000, 0xD0000000, and IO space 0xE0000000.

That caused a conflict which I could address by adding definitions
to the config for USER_SR, KERNEL_SR and KERNEL2_SR.

I changed the monitor to locate the PCI space at 4, 5, and 6
so that the default USER, KERNEL, KERNEL2 spaces (12, 13, 14)
would then work. We will have a maximum of 1GB of SDRAM, so
that requires battable space for 0, 1, 2, and 3. Now that I am
no longer setting my own USER (etc.) space, I could shove the
PCI up at 9, 10, and 11.

Is there information available for the powerpc port that discusses
recomended IO and memory mapping locations for devices?
Obviously having SDRAM at 0 and FLASH way up at 0xfff00000
works fine, but I am looking for guidance on where the other
non-PCI bus devices should be located. My first impulse is to
stick them all in BAT 15 (along with the flash and the Discovery).

Any thoughts on this from others with more experience in
these matters would be appreciated.

thanks

--

-- 
Doug Fraser
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matt Thomas | 14 Apr 2004 01:44

Re: ev64260 PCI location / boot monitor

At 06:17 AM 4/13/2004, Doug Fraser wrote:

>When the boot monitor runs (PMON) it configures the
>PCI busses on the Discovery bridge. They were set to
>address space 0xC0000000, 0xD0000000, and IO space 0xE0000000.

because pmon is stupid.  Unless you are have video cards, 256MB
per PCI is overkill.  Don't forget the CSn regions.

>That caused a conflict which I could address by adding definitions
>to the config for USER_SR, KERNEL_SR and KERNEL2_SR.
>
>I changed the monitor to locate the PCI space at 4, 5, and 6
>so that the default USER, KERNEL, KERNEL2 spaces (12, 13, 14)
>would then work. We will have a maximum of 1GB of SDRAM, so
>that requires battable space for 0, 1, 2, and 3. Now that I am
>no longer setting my own USER (etc.) space, I could shove the
>PCI up at 9, 10, and 11.

You can do better.

>Is there information available for the powerpc port that discusses
>recomended IO and memory mapping locations for devices?
>Obviously having SDRAM at 0 and FLASH way up at 0xfff00000
>works fine, but I am looking for guidance on where the other
>non-PCI bus devices should be located. My first impulse is to
>stick them all in BAT 15 (along with the flash and the Discovery).

Shove everything as high as you can go.  1MB for the Discovery, 64MB
for each PCI, xx MB for each of the CS (including BootCS) should easily
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Fraser | 14 Apr 2004 03:15
Favicon

RE: Re: ev64260 PCI location / boot monitor

Matt,

Thanks for the reply.

I agree pmon is stupid, but it is what I was blessed with.
The real world being what the real world is, my job is to
live with it. (pmon as well as the real world....)

I'll shove everything up into that final page.
I am also only going to enable the single PCI that we are
using.

Doug Fraser

-----Original Message-----
From:     Matt Thomas <matt <at> 3am-software.com>
Sent:     Tue, 13 Apr 2004 16:44:50 -0700
To:       "Doug Fraser" <dwfraser <at> onebox.com>
Cc:       port-powerpc <at> netbsd.org
Subject:  Re: ev64260 PCI location / boot monitor

At 06:17 AM 4/13/2004, Doug Fraser wrote:

>When the boot monitor runs (PMON) it configures the
>PCI busses on the Discovery bridge. They were set to
>address space 0xC0000000, 0xD0000000, and IO space 0xE0000000.

because pmon is stupid.  Unless you are have video cards, 256MB
per PCI is overkill.  Don't forget the CSn regions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aymeric Vincent | 14 Apr 2004 13:01
Picon

SRR1 bits in signal trampolines


Hi,

when I run "startx", the X server immediately dies as soon as it gets a 
SIGALRM, which is as soon as it gets started.

    248 XFree86  PSIG  SIGALRM caught handler=0x18ae57c mask=())
    248 XFree86  CALL  compat_16___sigreturn14(0xffffe7e0)
    248 XFree86  RET   compat_16___sigreturn14 -1 errno 22 Invalid 
argument
    248 XFree86  CALL  exit(0x16)

The problem is with the following test in 
powerpc/powerpc/compat_16_machdep.c:compat_16_sys___sigreturn14():

   if ((sc.sc_frame.srr1 & PSL_USERSTATIC) != (tf->srr1 &PSL_USERSTATIC))
     return (EINVAL);

and/or with this definition in powerpc/include/psl.h:

/*
  * A user is not allowed to change any MSR bits except the following:
  */
#define PSL_USERSTATIC 
(~(PSL_VEC|PSL_FP|PSL_FE0|PSL_FE1|PSL_LE|PSL_SE|PSL_BE))

SRR1 can have bits 1-4 and 10-15 modified depending on the exception 
taken. In my case, a printf() shows that bit 2 (0x40000000) gets set in 
sc.sc_frame.srr1. I don't know why it does now and why it didn't 
before, but the fact is that it does, and the documentation says we
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Seefried | 15 Apr 2004 04:56

Synergy VGMD


Does anyone have any information (i.e. anything from a technical manual to 
the pinout of the serial port) for the Synergy VGMD?  This is a PPC G3 (750) 
VME64 card with a Tundra Universe PCI controller (2 x PMC connectors), 
53C885 SCSI, some kind of ethernet (Level One LXT970 MAC, FWIW), 256MB SDRAM 
& Unknown Flash. 

Synergy has proven excellent at not responding to their tech support request 
form. 

Thanks... 

Ken
Permalink | Reply | 2 comments |
headers
Matt Thomas | 15 Apr 2004 06:03

Re: Synergy VGMD


On Apr 14, 2004, at 7:56 PM, Ken Seefried wrote:

>
> Does anyone have any information (i.e. anything from a technical 
> manual to the pinout of the serial port) for the Synergy VGMD?  This 
> is a PPC G3 (750) VME64 card with a Tundra Universe PCI controller (2 
> x PMC connectors), 53C885 SCSI, some kind of ethernet (Level One 
> LXT970 MAC, FWIW), 256MB SDRAM & Unknown Flash.

The 53c885 is the ethernet.  the lxt970 is the phy.  Alas, NetBSD 
doesn't
have a driver for the 53c885.
--

-- 
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
Matt Thomas | 17 Apr 2004 07:59

First experience with PegasosPPC

[Here is the first non-spam posting to port-ofppc for 2004!]

I received my PegasosPPC system yesterday.  Currently I have plugged 
into
a terminal server (8N1 <at> 115200) to see what I can see.  The good news is
that ofppc's ofwboot works just fine.  The bad news is a GENERIC ofppc
kernel (not unsurprisingly) goes off into never never land.

PegasosII Boot Strap (c) 2002-2003 bplan GmbH
Running on CPU PVR:80020101
Enable L1 ICache...                                                    
Done.
Clean/Flush Block enabled
Reading W83194 : 5CFFFFFFFFFFFF00                                      
Done.
Setting Front Side Bus to 133MHz...                                    
Done.
Configuring DDR...                                                     
Done.
Configuring PCI0...                                                    
Done.
Configuring PCI1...                                                    
Done.
Configuring ETH...                                                     
Done.
Releasing IDE reset ...                                                
Done.
Configuring Legacy Devices
Initializing KBD...00000032                                            
FAILED.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jochen Kunz | 17 Apr 2004 10:10
Picon

Re: First experience with PegasosPPC

On Fri, 16 Apr 2004 22:59:19 -0700
Matt Thomas <matt <at> 3am-software.com> wrote:

> The good news is that ofppc's ofwboot works just fine. 
I found a bug (to small stack size) in it about 1.5 years ago when I
started to play with port-ofppc...

> The bad news is a GENERIC ofppc kernel (not unsurprisingly) goes off
> into never never land.
[...]
> root addr=192.168.7.52 path=/clients/pegasos/root
> 2281616+329408 [121472+107554]=0x2b58d0
>   start=0x100000
Maybe this is the same bug that I noticed about 1.5 years back. There
where some modifications to the pmap and ofw interface code short after
the 1.6 release. port-ofppc is broken since then. I traced this with the
good, old debug printf metod and the kernel hangs in pmap_init(). Can
you try a plain, old 1.6 kernel?

> The amount of information in the OFW tree compared to other systems
> I've seen is extremely limited.  However, there is CHRP RTAS support
> (RTAS is the IBM defined run-time-abstraction-services) and it would
> make life much easier for ofppc systems if NetBSD could use it.
Well, RTAS would be fine. But I would prefere to get real PCI/ISA
attachments first. I extended the existing firepower code for the
Motorola PowerStack II and the IBM RS/6000 B50 so that I can use the
generic NetBSD PCI and ISA drivers. But there is some strange problem
with PCI in the PowerStack II. It seems to be related to PCI memory
space access. I have the PowerStack II runing single user with a kernel
attached ram disk. - Only to notice yet an other problem: non-working
(Continue reading)

Permalink | Reply | 0 comments |

Gmane