[parisc-linux] Dino developments...

[parisc-linux] Dino developments...

[Alex deVries]

I've fixed up a couple of things in the kernel:

- PCI bus walking happens in the *right place*, pci_init().

- I've fixed the inventory code to handle hversion_rev and sversion_rev

- Multiple Dinos are detected properly now

- Card Mode Dino now seems to work for bus walking, the MMIO is a whole
different story.

As a test, I packed in:
- a Symbios SCSI controller PCI card
- a GSC gigabit ethernet card (which uses a dino)
- another GSC gigabit ethernet card (which uses a dino)

(and if you're curious as to how I can pack three cards in an A class,
you'll have to visit Ottawa to see)

The output I get is:
Dino version 3.1 (bridge mode) found at
0xfff80000                              
Dino version 3.0/3.1 (card mode) found at
0xfff84000                            
Found a PCI device, and the vendor is 0x107e, device
0x3                        
Dino version 3.0/3.1 (card mode) found at
0xfff88000                            
Found a PCI device, and the vendor is 0x12ae, device
0x1                        
PCI: Probing PCI
hardware                                                       
Found a PCI device, and the vendor is 0x104b, device
0x8130                     
Found a PCI device, and the vendor is 0x1011, device
0x19                       

So the first PCI device found is an "Interphase" gigE thing that's not
in the PCI database, the second is an Alteon Acenic gigE, the third is
the Symbios SCSI card, and the last is the onboard DEC tulip.

- Alex


-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] Dino developments...

[Grant Grundler]

Alex - this is really cool.

Alex deVries wrote:
> 
> 
> I've fixed up a couple of things in the kernel:
> 
> - PCI bus walking happens in the *right place*, pci_init().

Ok. Were you able to salvage what I had submitted then?
I was under the impression pci_init() wouldn't work. Registration of
the pci_bus_ops for each Dino looked like a problem.

Oh. I think I got it.  Each dino registers pci_bus_ops when it's
"discovered" and pci_init() is called later...is that right?
(I'll be looking at the code anyway...may not have to answer)

> - I've fixed the inventory code to handle hversion_rev and sversion_rev
> - Multiple Dinos are detected properly now
> - Card Mode Dino now seems to work for bus walking, the MMIO is a whole
> different story.

I'll start reviewing card-mode Dino initialization and see what we can
do for MMIO. I have to understand more about what the "right" thing for
linux is WRT I/O address management. This has to take place sometime
between when card-mode Dino is "discovered" and when PCI bus walk completes.
(So we know how much space is needed.)

What about interrupts?
Is alloc_irq() handing virtual IRQ's back to the PCI drivers for the
respective dino irq_region?
I'm curios if/how it is supposed to work and might take a peek at this
as well. Once this works, the box should be able to send mail - that's
a key milestone for HP folks..

cheers,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] Dino developments...

[Grant Grundler]

Alex,
First cut review notes on the v1.17 dino.c:

o card-mode is only supported by dino 3.x.
  Only need to look for card-mode which is 3.0 or better.
  Look for DINO_MEM_DATA in the Dino ERS.
  I know for a fact none were shipped and no HP-UX drivers
  were shipped to support it either.

o "struct hp_driver" is not named very well. Needed more beer? :^)
  I'd like to suggest "struct pa_iodc_driver" or something like that.

o I'm not sure any systems were shipped with 2.0 built-in dino.
  Anybody know? What about 2.1's?
  I don't expect numbers to be posted here - just the existence.

o I see my long-ass comment about broken dino versions has been removed.
  Was it intentionally removed?
  (It's ok...I wrote it because I thought it was either useful or
  interesting depending on why anyone bothers reading the code).

o "struct dino_version_mapping" doesn't appear to be used.
  Can this go?

o FYI: "ifdef USE_PCI_INTR_OPS" stuff is mine.
  I want to save it for some experiments on interrupt path latency.
  May be able to run those by the end of this month at this pace.

o I'd like to move the card-mode initialization into a seperate
  routine. Makes the common initialization easier to read.
  I can already see some stuff is missing too.

o Before generic PCI  bus walk occurs card-mode dino support must
  program PCI_INTERRUPT_LINE of each PCI device below it.
  Firmware does this for PCI devices below built-in Dino.
  For now, this can be a simple none-recursive bus walk since
  very few people will have the card-mode expansion chassis (which
  uses PCI-PCI bridges).
  
  I'll take care of it this week but just wanted it noted in case
  anyone wonders why card-mode interrupts don't work now.

o is_buildtin_dino(). Typo and it's not needed right now.

o 0x05d. Need the workaround to eventually support J2240 firmware bug.
  This was included in the macros I had posted previously.
  Can just add another HPHW_BRIDGE entry instead.


That's enough for now....time to get some sleep.

later,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] Dino developments...

[Alex deVries]

Grant Grundler wrote:
> Alex deVries wrote:
> > I've fixed up a couple of things in the kernel:
> > - PCI bus walking happens in the *right place*, pci_init().
> 
> Ok. Were you able to salvage what I had submitted then?
> I was under the impression pci_init() wouldn't work. Registration of
> the pci_bus_ops for each Dino looked like a problem.

Yeah, I definitely re-used a lot of existing work. I got pci_init() to
work properly.

> Oh. I think I got it.  Each dino registers pci_bus_ops when it's
> "discovered" and pci_init() is called later...is that right?

Yeah, although if I understand the kernel code properly, the first PCI
bus scan is done from within pci_init().  All the others are called when
the others are detected.  Right now the dino_init() call is in the wrong
place.

> I'll start reviewing card-mode Dino initialization and see what we can
> do for MMIO. I have to understand more about what the "right" thing for
> linux is WRT I/O address management. This has to take place sometime
> between when card-mode Dino is "discovered" and when PCI bus walk completes.
> (So we know how much space is needed.)

Can we gather a memory IO map based on what we find in the inventory
code with the mem_map() PDC calls?

> What about interrupts?
> Is alloc_irq() handing virtual IRQ's back to the PCI drivers for the
> respective dino irq_region?
> I'm curios if/how it is supposed to work and might take a peek at this
> as well. Once this works, the box should be able to send mail - that's
> a key milestone for HP folks..

I really havent' looked at interrupts at all yet in PCI, so please, have
a look at it.

About sending mail: that'd require actually running a userland program
(unless you want to embed something like elm or emacs into the kernel),
and I'm not sure how close we are to that.

- Alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] Dino developments...

[Alex deVries]

Grant Grundler wrote:
> First cut review notes on the v1.17 dino.c:
> 
> o card-mode is only supported by dino 3.x.
>   Only need to look for card-mode which is 3.0 or better.
>   Look for DINO_MEM_DATA in the Dino ERS.
>   I know for a fact none were shipped and no HP-UX drivers
>   were shipped to support it either.

Ah, okay.  This is info that's not in the docs. 

> o "struct hp_driver" is not named very well. Needed more beer? :^)
>   I'd like to suggest "struct pa_iodc_driver" or something like that.

I agree.

> o I'm not sure any systems were shipped with 2.0 built-in dino.
>   Anybody know? What about 2.1's?
>   I don't expect numbers to be posted here - just the existence.

I'd say just leave those config lines in for now.

> o I see my long-ass comment about broken dino versions has been removed.
>   Was it intentionally removed?
>   (It's ok...I wrote it because I thought it was either useful or
>   interesting depending on why anyone bothers reading the code).

That's now been moved to README.dino

> 
> o "struct dino_version_mapping" doesn't appear to be used.
>   Can this go?

Yes!

> o FYI: "ifdef USE_PCI_INTR_OPS" stuff is mine.
>   I want to save it for some experiments on interrupt path latency.
>   May be able to run those by the end of this month at this pace.

Sounds good.

> o I'd like to move the card-mode initialization into a seperate
>   routine. Makes the common initialization easier to read.
>   I can already see some stuff is missing too.

That's a good plan.  I simply stole the config stuff out of the Dino
docs' example, and it worked, I never actually figured out what it
should be. I'm still stunned that it worked.

> o Before generic PCI  bus walk occurs card-mode dino support must
>   program PCI_INTERRUPT_LINE of each PCI device below it.
>   Firmware does this for PCI devices below built-in Dino.
>   For now, this can be a simple none-recursive bus walk since
>   very few people will have the card-mode expansion chassis (which
>   uses PCI-PCI bridges).
>   I'll take care of it this week but just wanted it noted in case
>   anyone wonders why card-mode interrupts don't work now.

Sounds good.

> o is_buildtin_dino(). Typo and it's not needed right now.

That should probably be removed then.

> o 0x05d. Need the workaround to eventually support J2240 firmware bug.
>   This was included in the macros I had posted previously.
>   Can just add another HPHW_BRIDGE entry instead.

That's a good idea.

Grant, I'll leave it to you to commit these changes.

- Alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] Dino developments...

[Grant Grundler]

Hi all,
I've committed changes to the following files:

  linux/arch/parisc/kernel/drivers.c
  linux/arch/parisc/kernel/inventory.c
  linux/arch/parisc/kernel/pci.c
  linux/drivers/gecko/dino.c
  linux/drivers/gecko/gecko.c
  linux/include/asm-parisc/pci.h
  linux/init/main.c

Both Card-mode and Built-in now get walked and devices are discovered.

outb/inb stuff probably isn't working because it doesn't call
dino_in/out functions yet. I've made changes to dino_in/out
functions and that's the *only* way a PCI driver can talk to a PCI
device for card-mode implementations. But Alex is eager to
get the built-in 100BT working and will hack at this some more...


> o Before generic PCI  bus walk occurs card-mode dino support must
>   program PCI_INTERRUPT_LINE of each PCI device below it.
>   Firmware does this for PCI devices below built-in Dino.
>   For now, this can be a simple none-recursive bus walk since
>   very few people will have the card-mode expansion chassis (which
>   uses PCI-PCI bridges).
>   I'll take care of it this week but just wanted it noted in case
>   anyone wonders why card-mode interrupts don't work now.

This issue is still outstanding too.

Requires code be added to pcibios_fixup_bus() and applies to both
built-in and card-mode Dino busses. So PCI line interrupts won't work
until this is fixed or the driver is temporarily kluged to hardcode
the virtual IRQ number.

Where is the tree now?

The kernel is data page faulting on both 715 and A-class with:

...
VFS: Mounted root (ext2 filesystem).
Warning: unable to open an initial console.
It's for the PA-RISC!
It's executable!
It has an appropriate version!
The checksum checks out!
Well, it *smells* like a valid SOM executable
interrupted with code 15, regs c00749ec
 IAOQ: c003fa10 c003fa14
 ior 20000028

PSW  : 0006ff0b  GR 1 : c010a800  GR 2 : c003ff50  GR 3 : 20000000  
GR 4 : 00000002  GR 5 : 00000005  GR 6 : 20000024  GR 7 : 20000018  
GR 8 : 20000000  GR 9 : c00747c0  GR10 : c00746c0  GR11 : 0000000a  
GR12 : ffffffff  GR13 : fdffffff  GR14 : 000000fd  GR15 : f0100000  
GR16 : f00008e8  GR17 : f000009c  GR18 : 00000020  GR19 : 00000018  
GR20 : 0000000c  GR21 : c0074000  GR22 : 20100000  GR23 : c0074000  
GR24 : c0074740  GR25 : c01810e0  GR26 : c0074488  GR27 : c0070000  
GR28 : 20000000  GR29 : 000000f5  GR30 : c0074b40  GR31 : c0024320  
SR0  : 00000000  SR1  : 00000000  SR2  : 00000000  SR3  : 00000000  
SR4  : 00000000  SR5  : 00000000  SR6  : 00000000  SR7  : 00000000  
IAOQ : c003fa10 c003fa14
SHR 1: 50000800  SHR 8: 00000008  SHR 9: c00d0000  SHR16: c00749ec  
SHR17: f000009c  SHR24: ffffffff  SHR25: 00000001  
d_p_f c00749ec 0000000f 20000028
returning c00749ec
...


IAOQ:
0xc003fa10?i
create_som_tables+60:           STWS,MB         r8,4(r6)

GR2:
0xc003ff50?i
load_som_binary+240:            STW             r28,256(r7)


grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253