[parisc-linux] Whee! Dino is recognized.

[parisc-linux] Whee! Dino is recognized.

[Alex deVries]

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

[parisc-linux] vmlinux in C360

[Hannu Martikka]

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."
ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°

Re: [parisc-linux] vmlinux in C360

[Matthew Wilcox]

On Wed, Jul 07, 1999 at 01:05:35PM +0300, Hannu Martikka wrote:
> Hi!
> 
> I have problems with Linux on C360. Here is what I tried:

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 <willy@bofh.ai>
"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

Re: [parisc-linux] vmlinux in C360

[Philipp Rumpf]

> > I have problems with Linux on C360. Here is what I tried:
> 
> 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.

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.

Re: [parisc-linux] vmlinux in C360

[Matthew Wilcox]

On Wed, Jul 07, 1999 at 05:23:38PM +0200, Philipp Rumpf wrote:
> > > I have problems with Linux on C360. Here is what I tried:
> > 
> > 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.
> 
> 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 <willy@bofh.ai>
"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

RE: [parisc-linux] vmlinux in C360

[Jim Hull]

> 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?

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

Re: [parisc-linux] vmlinux in C360

[Hannu Martikka]

On Thu, 8 Jul 1999, Jim Hull wrote:

> > 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?
> 
> 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
There seems to be some problems with that url...
"Connection was refused by te server dtf.external.hp.com"

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

Re: [parisc-linux] vmlinux in C360

[Alex deVries]

Hannu Martikka wrote:
> I have problems with Linux on C360. Here is what I tried:
> 
...
> 
> 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"?

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

Re: [parisc-linux] vmlinux in C360

[Helge Deller]

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.

Hannu Martikka schrieb:

> 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."
> ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°
>
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.

--
---------------------------------------
 Mailto:deller@gmx.de
 ICQ# 2046114
---------------------------------------

Re: [parisc-linux] vmlinux in C360

[Alex deVries]

Helge Deller wrote:
> 
> 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.....
> 

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

- A

-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] Whee! Dino is recognized.

[Grant Grundler]

Alex deVries wrote:
> 
> 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.

Congrats!
This is a good step forward.

A few more notes below.

> 
> 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.

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.

> 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.

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.

> 
> 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).

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.

> What other HPs have Dino onboard?

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

> 
> - Alex

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux] Whee! Dino is recognized.

[Alex deVries]

Grant Grundler wrote:
> Alex deVries wrote:

> > Dino device driver, by Alan Cox and Alex deVries
> > dino0: version 3.1 at 0xFF000000, IRQ 0, 1.
> 
> 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.
>

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

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

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.

> Don't forget about U2/Uturn DMA services on C/J-class.
> It can probably be ignored for now.

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

> >
> > 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).
> 
> 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".

Yeah, I have detection for 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.

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.

> 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.
> > What other HPs have Dino onboard?
> 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).

Ah, excellent.

What HPs have Lasi?

> hope this helps,

It definitely does... thanks!

- alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group

Re: [parisc-linux] Whee! Dino is recognized.

[Alan Cox]

> > You don't need to. It doesn't help on single processor systems
> > and only adds complexity in the IRQ management.
> >
> 
> Oh, that wasn't quite clear in the dino docs.  I'll just ignore IAR1
> then.

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.

> The kernel already has generic PCI bus walking code, so this shouldn't
> be too difficult

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