Port-ofppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Pegasos PCI-bus scan works



Hi!

Based on the great work of Tim Rightnour in the last days, I modified the
pegasospci.c module to use "indirect access method" with the registers I
came to know. The result is a perfect PCI bus scan, of both PCI nodes in the
Pegasos2:

---8<---
NetBSD 4.99.34 (PEGASOS) #6: Sat Oct 27 20:21:48 CEST 2007
       
xxxx%xxx.hasenbraten.de@localhost:/home/frank/NetBSD_current/src/sys/arch/ofppc/co
mpile/obj/PEGASOS
total memory = 256 MB
avail memory = 234 MB
bootpath 
mainbus0 (root)
cpu0 at mainbus0: 750 (Revision 1.1), ID 0 (primary)
cpu0: HID0 8090c0ac<EMCP,DOZE,DPM,ICE,DCE,SGE,BTIC,ABE,BHT>, powersave: 1
cpu0: 600.00 MHz L2 cache present but not enabled 
pegasospci0 at mainbus0
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
       <key>ofw-pci-intrmap</key>
       <dict>
      <key>devfunc-0</key>
      <dict>
     <key>pin-B</key>
     <integer>0</integer>
      </dict>
      <key>devfunc-100</key>
      <dict>
     <key>pin-B</key>
     <integer>0</integer>
      </dict>
      <key>devfunc-101</key>
      <dict>
     <key>pin-D</key>
     <integer>9</integer>
      </dict>
      <key>devfunc-102</key>
      <dict>
     <key>pin-D</key>
     <integer>9</integer>
      </dict>
      <key>devfunc-104</key>
      <dict>
     <key>pin-B</key>
     <integer>9</integer>
      </dict>
      <key>devfunc-8</key>
      <dict>
     <key>pin-B</key>
     <integer>9</integer>
      </dict>
      <key>devfunc-96</key>
      <dict>
     <key>pin-B</key>
     <integer>0</integer>
      </dict>
      <key>devfunc-97</key>
      <dict>
     <key>pin-B</key>
     <integer>14</integer>
      </dict>
      <key>devfunc-98</key>
      <dict>
     <key>pin-E</key>
     <integer>9</integer>
      </dict>
      <key>devfunc-99</key>
      <dict>
     <key>pin-E</key>
     <integer>9</integer>
      </dict>
       </dict>
</dict>
</plist>

pci0 at pegasospci0 bus 0: indirect configuration space access
pci0: i/o space, memory space enabled
pchb0 at pci0 dev 0 function 0
pchb0: Marvell MV6436x System Controller (rev. 0x03)
VIA Technologies VT6306 IEEE 1394 Host Controller (Firewire serial bus, 
interface 0x10, revision 0x46) at pci0 dev 1 function 0 not configured
pcib0 at pci0 dev 12 function 0: VIA Technologies VT8231 PCI-ISA Bridge (rev. 
0x10)
VIA Technologies VT82C586A IDE Controller (IDE mass storage, interface 0x8f, 
revision 0x06) at pci0 dev 12 function 1 not configured
VIA Technologies VT83C572 USB Controller (USB serial bus, revision 0x1e) at 
pci0 dev 12 function 2 not configured
VIA Technologies VT83C572 USB Controller (USB serial bus, revision 0x1e) at 
pci0 dev 12 function 3 not configured
VIA Technologies VT8231 Power Management Controller (miscellaneous bridge, 
revision 0x10) at pci0 dev 12 function 4 not configured
VIA Technologies VT82C686A AC-97 Audio Controller (audio multimedia, revision 
0x40) at pci0 dev 12 function 5 not configured
VIA Technologies VT82C686A MC-97 Modem Controller (miscellaneous 
communications, revision 0x20) at pci0 dev 12 function 6 not configured
VIA Technologies VT6102 (Rhine II) 10/100 Ethernet (ethernet network, revision 
0x51) at pci0 dev 13 function 0 not configured
isa0 at pcib0
pegasospci1 at mainbus0
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
       <key>ofw-pci-intrmap</key>
       <dict>
      <key>devfunc-0</key>
      <dict>
     <key>pin-B</key>
     <integer>0</integer>
      </dict>
      <key>devfunc-64</key>
      <dict>
     <key>pin-B</key>
     <integer>9</integer>
      </dict>
       </dict>
</dict>
</plist>

pci1 at pegasospci1 bus 0: indirect configuration space access
pci1: i/o space, memory space enabled
pchb1 at pci1 dev 0 function 0
pchb1: Marvell MV6436x System Controller (rev. 0x03)
ofb0 at pci1 dev 8 function 0: ATI Technologies Radeon 9200SE 5964
---8<---


I have to mention that this only worked after a small hack. I had to make
sure that the 0xf0000000-region is loaded into a BAT-register, otherwise the
system freezes when initializing the 8259-PIC.

The freeze on attaching ofb0 is certainly the same problem, which has to be
resolved next.

The whole day I was looking for the reason why 0xf0000000 is not loaded into
BAT2 or BAT3 when encountering a DSI exception, although it definitely is in
the battable.

I will provide some more details of my search here, because it may be
interesting for other newbies likes me. :)

The kernel correctly loaded the 256M-regions 0x0, 0x8, 0x9 and
0xa into the BATs. 0xb, 0xc, 0xd and 0xf are waiting in the battable, and
will replace BAT2 or BAT3 when needed. But it doesn't work! I only got total
system-freezes when accessing a region which was not initially in a BAT.

When I made the kernel drop into DDB to inspect memory I found the reason:
the exception vectors are not initialized! The whole memory from 0x0 to
0x100000 is zero! Another prove of this fact: executing single-step trace in
DDB freezes the system as well.

Then I had to make sure if oea_init() is called at all. But it definitely
is! The exception handlers are written to memory.

I started to write patterns to memory at different times to find out at
which point the region from 0 to 0x1000 became writable. It was after
pmap_bootstrap(), when the new MMU-tables had been installed.

Unfortunately oea_init() is run just before pmap_bootstrap(), and it relies
on the MMU-setting the system had before. Now I remembered that SmartFirmware
boots the kernel with translation enabled, and I didn't find code which
disables it.

So my assumption is that the BAT-settings are ignored and SmartFirmware
redirects the installation of the exception handlers to another memory
region. :P

Hmm... which means translation has to be disabled somewhere. But does OFW
still work then? At least it still works with the MMU-tables of the kernel.
Maybe only disable it during oea_init()?

A hint from the experts?

-- 
    _  Frank Wille (frank%phoenix.owl.de@localhost)
 _ //  http://sun.hasenbraten.de/~frank/
 \X/   Phx @ #AmigaGer




Home | Main Index | Thread Index | Old Index