Whee! Dino is recognized.

I fixed up dino.c a little to setup it's HPA properly. Understanding the docs took a bit of time, so this is a personal victory.

Now the kernel boots up and prints:

Dino device driver, by Alan Cox and Alex deVries
dino0: version 3.1 at 0xFF000000, IRQ 0, 1.

Now we just need to configure the PCI bus properly, connect the interrupts, and we should be close to being able to talk to a network. The A-classes have tulips hanging off the PCI bus, so that should be pretty simple.

There's some small changes so that the GSC irqs are handled by a pool handler.

People with 712s differ at this point, you'll have to muck with Lasi's built in ethernet port, which will be slightly difficult because you may interrupt the serial console in doing so. If you use the graphics, you should be okay.

There's some initial code to handle multiple dinos, and it may in fact work, but I really haven't tried (and can't until I have one of those GSC ethernet cards that Thomas and Philipp have).

What other HPs have Dino onboard?

- Alex

Alex deVries
Vice President of Engineering
The Puffin Group

Hi!

I have problems with Linux on C360. Here is what I tried:

1) Get latest kernel src from CVS + egcs from binaries/depot.
2) Compilation works fine (done on hpux11/D-series):
make config; make dep;make clean ; make vmlinux ; make Image

3) copy vmlinux to /stand/vmlinux in C360
4) reboot with IPL
5) hpux /stand/vmlinux

	boot:(0.0......)/stand/vmlinux

This is the last message. Here it hangs. On frontpanel the leds 1-3 are on (no 4 is off).

Should it work better in C-series? or is C-series "unsupported"?

- Goodi
"The linuX Files -- The Source is Out There." ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

According to http://www.hp.com/unixwork/hpc360/page6.htm, the C360 has a PA-8500 CPU which is PA-RISC version 2.0. This port is currently only targetting the PA-RISC 1.1 family of processors since this is where most of the demand is. In time, I'm sure we will support the PA-RISC 2.0 series of processors, but we don't right now.

Matthew Wilcox <[email protected]>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Still, I _think_ we should be able to run the kernel on PA2.0 in narrow mode.

As soon as I can get my hands on a PA2.0 box, I can test that.

I think you're right for the moment. The TLB instructions are different between the two variants though; maybe there's some other stuff?

I guess the bootloader needs to force the W bit to 0? I note that on an interruption, the W bit is set to the value of the default width bit, but how to set the default width bit is implementation defined. Anyone care to hint at how to set the default width bit too?

"A `puffin shuttle' also runs in the summer when the cute, meaty birds
are abundant on nearby cliffs."

Matthew Wilcox <[email protected]>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

You use PDC_PSW to set the default width and default endian bits. See page 2-59 in:

http://dtf.external.hp.com/dtf/swdev/pdf/pdc.pdf

-- Jim

There seems to be some problems with that url... "Connection was refused by te server dtf.external.hp.com"

- Goodi
"The linuX Files -- The Source is Out There." ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°°º¤ø,¸¸,ø¤º°°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

...

Matt is likely right, it is something to do with that being a 2.0 CPU.

I'm a bit surprised that you never see anything, though. It could be that our PDC calls or CPU setup code is CPU specific, but I'd thought it was pretty generic.

Just to eliminate the possibility of it being a build time bug, could you try booting that c360 with a precompiled kernel at ftp://puffin.external.hp.com/pub/parisc/binaries/kernels/ ?

- Alex

Alex deVries
Vice President of Engineering
The Puffin Group

Hi !

Only a little idea, but you could try to set the Boot-Offset for the loaded Image in the
arch/parisc/Makefile from 0x10000 to 0x12000 or higher....
It could be, that we overwrite the PDC & IO-Structures from the BIOS... I think I read something about that in the other parisc-ports.....

Helge.

--
---------------------------------------
Mailto:[email protected]
ICQ# 2046114
---------------------------------------

Is there any reason not to bump that up to 0x12000 ?

- A

Alex deVries
Vice President of Engineering
The Puffin Group

Congrats!
This is a good step forward.

A few more notes below.

Did you plan on using both IAR0 and IAR1?

You don't need to. It doesn't help on single processor systems and only adds complexity in the IRQ management.

The PCI bus walk and IRQ management is pretty straight forward. At least if one has done it once before. :^)

Don't forget about U2/Uturn DMA services on C/J-class. It can probably be ignored for now.
They help performance if the OS can determine DMA is coherent with processor caches. Then the PCI device drivers don't need to flush processor caches before/after DMA operations. It also allows 32-bit PCI devices to access more than 4GB of mem directly.

Notes:
1) The "card-mode" Dino's report different IODC data. See description of IODC_DATA_0 register in the ERS. The GSC 100BT cards using DEC 100BT LAN chip are "card-mode".

2) Firmware will NOT touch card-mode Dino devices. ie Dino and PCI devices below it must be programmed by the OS from scratch. Due to all the platform variations where card-mode Dino are supported, HP-UX does NOT map PCI MMIO space into processor I/O address space.

2) On J-class, the second GSCtoPCI IODC data is reported incorrectly by firmware. I forgot what it reports but recall we had to kludge the test in HP-UX.

All A, B, C, and J class workstations.
And the "industrial" rack mount 743 family.
C and J have two built-in (aka Bridge-Mode) GSCtoPCI bus converters. J-class is "SMP" (2 processors).

hope this helps,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Oh, that wasn't quite clear in the dino docs. I'll just ignore IAR1 then.

The kernel already has generic PCI bus walking code, so this shouldn't be too difficult
to sort out. Philipp's doing very well with the interruption stuff, we just need interrupts to work to be able to link them in.

But we can walk the bus without interrupts, so that's what I'm doing next.

It will be ignored for now because:
- I don't have a C or J class
- I've never heard of U2/Uturn before :)

Yeah, I have detection for card mode.

That makes sense, and once you know if it's a card mode Dino, then you can decide if you need to setup the entire device from scratch.

Exactly what setup is required here? I know on the second page into Chapter 5 of the Dino docs they describe an example setup.

Ah, excellent.

What HPs have Lasi?

It definitely does... thanks!

- alex

Alex deVries
Vice President of Engineering
The Puffin Group

Right now the code treats the IRQ off IAR0 and IAR1 as the same - so you register an IRQ and SMP folks can load balance it later.

It assumes the bus has been configured. If not then Russ King has a set of nastiness for configuring the PCI bus on his ebsa285 we can half inch