* Re: HAL2 support.
[not found] ` <Pine.LNX.3.96.990125122018.21345K-100000@lager.engsoc.carleton.ca>
@ 1999-01-28 18:50 ` Ulf Carlsson
1999-01-25 19:27 ` Alex deVries
0 siblings, 1 reply; 6+ messages in thread
From: Ulf Carlsson @ 1999-01-28 18:50 UTC (permalink / raw)
To: Alex deVries; +Cc: Linux SGI
> First, many thanks for the files.
>
> Do you mind if I cvs upload them to the SGI kernel mailing list?
CVS upload them to the mailing list, I don't get your point here. I have CVS
access so I may upload them if I want to, and I can post it to the mailing list
if you want me to. But it feels like too much people would laugh at me if I
posted it at the moment.. I'll atleast get it through the compiler once again.
> Do you mind if we hold this discussion on the SGI list once I do that?
Sure, I actually forgot to group reply, that's why this discussion isn't
(wasn't) on the list :-)
> Next, I was hoping you could explain this bit of code to me, I don't quite
> see how it's right from the docs. I'm looking at page 13 of the HAL2
> docs.
Does something else bother you than the incorrect type? I can't see anything
else being wrong here.
[snip]
> typedef volatile unsigned long hpcreg;
How stupid! I thought I had checked that it was unsigned short.. ;)
My spacing depends on that..
> Next, your spacing isn't quite right I don't think. I think it needs to
> be:
>
> typedef volatile __u16 hal_reg;
>
> struct hal2_ctrl_regs {
> hal_reg _unused0[8];
> hal_reg isr; /* 0x10 Status Register */
> hal_reg _unused1[7];
> hal_reg rev; /* 0x20 Revision Register */
> hal_reg _unused2[7];
> hal_reg iar; /* 0x30 Indirect Address Register */
> hal_reg _unused3[7];
> hal_reg idr0; /* 0x40 Indirect Data Register 0 */
> hal_reg _unused4[7];
> hal_reg idr1; /* 0x50 Indirect Data Register 1 */
> hal_reg _unused5[7];
> hal_reg idr2; /* 0x60 Indirect Data Register 2 */
> hal_reg _unused6[7];
> hal_reg idr3; /* 0x70 Indirect Data Register 3 */
> } *h2_ctrl = (hal2_ctrl_regs *) H2_CTRL_PIO;
And this line should actually be:
} *h2_ctrl = (hal2_ctrl_regs *) KSEG1ADDR(H2_CTRL_PIO);
> Does that make sense, or otherwise, what was your thought on this?
It probably does, I have found two bugs so far.
- Ulf
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: HAL2 support.
1999-01-28 18:50 ` HAL2 support Ulf Carlsson
@ 1999-01-25 19:27 ` Alex deVries
1999-01-28 20:32 ` Ulf Carlsson
0 siblings, 1 reply; 6+ messages in thread
From: Alex deVries @ 1999-01-25 19:27 UTC (permalink / raw)
To: Ulf Carlsson; +Cc: Linux SGI
On Thu, 28 Jan 1999, Ulf Carlsson wrote:
> > Do you mind if I cvs upload them to the SGI kernel mailing list?
> CVS upload them to the mailing list, I don't get your point here. I have CVS
> access so I may upload them if I want to, and I can post it to the mailing list
> if you want me to. But it feels like too much people would laugh at me if I
> posted it at the moment.. I'll atleast get it through the compiler once again.
I'll merge them with a modern kernel and make sure that it all builds
properly. That should be done in the next 30 hours. Woo! Finally! Kernel
work!
> Does something else bother you than the incorrect type? I can't see anything
> else being wrong here.
No, but I just scanned the code quickly.
> And this line should actually be:
> } *h2_ctrl = (hal2_ctrl_regs *) KSEG1ADDR(H2_CTRL_PIO);
Okay. Why's that?
Anyway, I'll get this code into the kernel so we have a way to debug it in
a distributed fashion. It's clear there'll be problems with it; we'll get
through that over time.
- Alex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HAL2 support.
1999-01-25 19:27 ` Alex deVries
@ 1999-01-28 20:32 ` Ulf Carlsson
0 siblings, 0 replies; 6+ messages in thread
From: Ulf Carlsson @ 1999-01-28 20:32 UTC (permalink / raw)
To: Alex deVries; +Cc: Linux SGI
> I'll merge them with a modern kernel and make sure that it all builds
> properly. That should be done in the next 30 hours. Woo! Finally! Kernel
> work!
As you wish. I have actually merged it before, I can send you an old patch so
you can see what it should look like.
> > And this line should actually be:
> > } *h2_ctrl = (hal2_ctrl_regs *) KSEG1ADDR(H2_CTRL_PIO);
>
> Okay. Why's that?
Because it has to be in the virtual address space.
> Anyway, I'll get this code into the kernel so we have a way to debug it in
> a distributed fashion. It's clear there'll be problems with it; we'll get
> through that over time.
Great..
- Ulf
^ permalink raw reply [flat|nested] 6+ messages in thread
* HAL2 support.
@ 1999-01-24 21:01 Alex deVries
1999-01-25 4:06 ` Dave Olson
0 siblings, 1 reply; 6+ messages in thread
From: Alex deVries @ 1999-01-24 21:01 UTC (permalink / raw)
To: SGI Linux
There's a rumour going around that Ulf has had some luck with getting HAL2
support working. If there's any truth to this,a dn so that we don't
reinvent the wheel, does anyone know where this source might be?
Also, am I right in saying that there's no devices written for HPC3 that
use the pbus? Looks like the first step to writing a HAL driver is to be
able to write to the pbus.
What else is actually on the pbus on the Indy? From this HPC
documentation, looks
like:
- fdc (I thought Indy floppies were SCSI though)
- rtc
- prom
- scsi (although not the 33c93)
- int2 (what's this?)
- hal2
- pi1 (what's this?)
- Alex
--
Alex deVries, puffin on LinuxNet.
I know exactly what I want in life.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HAL2 support.
@ 1999-01-25 4:06 ` Dave Olson
0 siblings, 0 replies; 6+ messages in thread
From: Dave Olson @ 1999-01-25 4:06 UTC (permalink / raw)
To: Alex deVries; +Cc: linux
Alex deVries wrote:
| Also, am I right in saying that there's no devices written for HPC3 that
| use the pbus? Looks like the first step to writing a HAL driver is to be
| able to write to the pbus.
The pbus interface itself is a pretty simple interface.
| What else is actually on the pbus on the Indy? From this HPC
| documentation, looks
| like:
| - fdc (I thought Indy floppies were SCSI though)
There was talk of doing floppy this way, but it never was actually done.
| - rtc
| - prom
| - scsi (although not the 33c93)
scsi is off the hpc3, but it's only the control path (pio to registers)
that uses the pbus interface. The datapath is a different bus.
| - int2 (what's this?)
interrupt control.
| - hal2
| - pi1 (what's this?)
parallel port.
Dave Olson, Silicon Graphics
http://reality.sgi.com/olson olson@sgi.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HAL2 support.
@ 1999-01-25 4:06 ` Dave Olson
0 siblings, 0 replies; 6+ messages in thread
From: Dave Olson @ 1999-01-25 4:06 UTC (permalink / raw)
To: Alex deVries; +Cc: linux
Alex deVries wrote:
| Also, am I right in saying that there's no devices written for HPC3 that
| use the pbus? Looks like the first step to writing a HAL driver is to be
| able to write to the pbus.
The pbus interface itself is a pretty simple interface.
| What else is actually on the pbus on the Indy? From this HPC
| documentation, looks
| like:
| - fdc (I thought Indy floppies were SCSI though)
There was talk of doing floppy this way, but it never was actually done.
| - rtc
| - prom
| - scsi (although not the 33c93)
scsi is off the hpc3, but it's only the control path (pio to registers)
that uses the pbus interface. The datapath is a different bus.
| - int2 (what's this?)
interrupt control.
| - hal2
| - pi1 (what's this?)
parallel port.
Dave Olson, Silicon Graphics
http://reality.sgi.com/olson olson@sgi.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-01-25 20:32 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <19990128004527.A1266@bun.falkenberg.se>
[not found] ` <Pine.LNX.3.96.990125122018.21345K-100000@lager.engsoc.carleton.ca>
1999-01-28 18:50 ` HAL2 support Ulf Carlsson
1999-01-25 19:27 ` Alex deVries
1999-01-28 20:32 ` Ulf Carlsson
1999-01-24 21:01 Alex deVries
1999-01-25 4:06 ` Dave Olson
1999-01-25 4:06 ` Dave Olson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.