Skip to contentSkip to conversation

Whee! Dino is recognized.

parisc-linux Alex deVries 8 participants 13 messages Jul 7, 1999 – Jul 9, 1999

lore
Share & tools
lore

Alex deVries

author
#0 lore raw

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

Signature · 3 lines
Alex deVries
Vice President of Engineering
The Puffin Group
#1 lore raw

[parisc-linux] vmlinux in C360

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

#2 lore raw

Re: [parisc-linux] vmlinux in C360

Quoted 3 lines · Hannu Martikka

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.

Signature · 4 lines
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
#3 lore raw

Re: [parisc-linux] vmlinux in C360

Quoted 7 lines
Quoted 1 line

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.

#4 lore raw

Re: [parisc-linux] vmlinux in C360

Quoted 11 lines · Philipp Rumpf
Quoted 7 lines
Quoted 1 line

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?

Signature · 7 lines
"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
#5 lore raw

RE: [parisc-linux] vmlinux in C360

Quoted 4 lines

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

#6 lore raw

Re: [parisc-linux] vmlinux in C360

Quoted 9 lines · Jim Hull
Quoted 4 lines

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"

Quoted 1 line

-- Jim

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

author
#7 lore raw

Re: [parisc-linux] vmlinux in C360

In reply to Hannu Martikka
Quoted 2 lines · Hannu Martikka

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

...

Quoted 5 lines

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

Signature · 3 lines
Alex deVries
Vice President of Engineering
The Puffin Group
#8 lore raw

Re: [parisc-linux] vmlinux in C360

In reply to Hannu Martikka

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.

Quoted 19 lines · 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"?

Quoted 7 lines

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

---------------------------------------------------------------------------
To unsubscribe: send e-mail to [email protected] with `unsubscribe' as the subject.

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

author
#9 lore raw

Re: [parisc-linux] vmlinux in C360

Quoted 9 lines · 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.....

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

- A

Signature · 3 lines
Alex deVries
Vice President of Engineering
The Puffin Group
#10 lore raw
In reply to Alex deVries
Quoted 3 lines · 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.

Congrats!
This is a good step forward.

A few more notes below.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 1 line

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

Quoted 2 lines

- Alex

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

author
#11 lore raw
Quoted 10 lines · Grant Grundler
Quoted 2 lines · Alex deVries

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.

Quoted 3 lines

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.

Quoted 2 lines

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

Quoted 9 lines
Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 1 line

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?

Quoted 1 line

hope this helps,

It definitely does... thanks!

- alex

Signature · 3 lines
Alex deVries
Vice President of Engineering
The Puffin Group
#12 lore raw
Quoted 6 lines
Quoted 3 lines

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.

Quoted 2 lines

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