* weird HAL2
@ 1999-02-01 22:10 Thomas Bogendoerfer
1999-02-01 23:09 ` Ulf Carlsson
0 siblings, 1 reply; 9+ messages in thread
From: Thomas Bogendoerfer @ 1999-02-01 22:10 UTC (permalink / raw
To: linux
Hi,
I've looked at the HAL2 driver, and everything is looking strange hardware-
wise. The driver first resets the hardware by clearing the isr register and
setting the appropriate bits afterwards. But reading back isr indicates, that
the hardware is still in reset state. I've removed clearing of the isr, so the
driver just writes the same value as was before. This still leads to a HAL2
in reset state. Even removing the reset code completly the HAL2 acts very
strange. Doing the first indirect register access, causes as set busy bit
in isr, that's all. Any ideas ?
Thomas.
--
This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
[Martin `MJ' Mares on linux-kernel]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
1999-02-01 22:10 Thomas Bogendoerfer
@ 1999-02-01 23:09 ` Ulf Carlsson
0 siblings, 0 replies; 9+ messages in thread
From: Ulf Carlsson @ 1999-02-01 23:09 UTC (permalink / raw
To: Thomas Bogendoerfer
Hi Thomas,
> I've looked at the HAL2 driver,
Cool :)
> and everything is looking strange hardware- wise.
I was actually thinking exactly the same thought.
> The driver first resets the hardware by clearing the isr register and setting
> the appropriate bits afterwards.
I was looking at the sgiseeq.c, and I've actually stolen some ideas from it. For
example are we doing the reset (trying to do?) in about the same way.
> But reading back isr indicates, that the hardware is still in reset state.
> I've removed clearing of the isr, so the driver just writes the same value as
> was before. This still leads to a HAL2 in reset state. Even removing the reset
> code completly the HAL2 acts very strange. Doing the first indirect register
> access, causes as set busy bit in isr, that's all. Any ideas
Hm, I haven't been able to set the busy bit, how did you manage to do that?
It looks to me like some volatile bug, causing the driver not to read back the
values directly from the card. But everything seems to be ok.
By the way, did you notice that isr is 0x0018 before you reset the card? This is
one of the strange things. Maybe it's because Alex didn't reboot his computer
after reinserting the driver again. If this is the case, why doesn't the card
enter active mode again before the driver has failed to activate it?
- Ulf
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
@ 1999-02-02 16:17 Ulf Carlsson
1999-02-02 19:36 ` Alistair Lambie
0 siblings, 1 reply; 9+ messages in thread
From: Ulf Carlsson @ 1999-02-02 16:17 UTC (permalink / raw
To: Linux SGI
On Tue, Feb 02, 1999 at 04:23:39PM +0100, Thomas Bogendoerfer wrote:
> On Tue, Feb 02, 1999 at 05:14:44PM +0100, Ulf Carlsson wrote:
> > Is it possible to download the BIOS and disassemble it to check how to do it
> > correctly?
>
> should be doable, but I guess disassembling the IRIX driver might be easier.
> I've hoped someone at SGI could help us out.
I think we should ask them kindly then:
Does anyone at SGI know how the HAL2 works?
We can't get it working correctly, it doesn't come back to normal state after
the reset. Even if we write 0x0018 to isr, to enable the chip, it still shows
0x0000. It's certainly off because we can't write to the indirect registers in
this state
If we don't reset the HAL2, leaving it the way it is when after playing the boot
sound, we can't write to the indirect registers. The busy bit doesn't go off.
The only thing which works correctly is reading the version register.
- Ulf
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
1999-02-02 16:17 weird HAL2 Ulf Carlsson
@ 1999-02-02 19:36 ` Alistair Lambie
1999-02-02 19:53 ` Ulf Carlsson
0 siblings, 1 reply; 9+ messages in thread
From: Alistair Lambie @ 1999-02-02 19:36 UTC (permalink / raw
To: Ulf Carlsson; +Cc: Linux SGI
Ulf Carlsson wrote:
>
> On Tue, Feb 02, 1999 at 04:23:39PM +0100, Thomas Bogendoerfer wrote:
> > On Tue, Feb 02, 1999 at 05:14:44PM +0100, Ulf Carlsson wrote:
> > > Is it possible to download the BIOS and disassemble it to check how to do it
> > > correctly?
> >
> > should be doable, but I guess disassembling the IRIX driver might be easier.
> > I've hoped someone at SGI could help us out.
>
> I think we should ask them kindly then:
>
> Does anyone at SGI know how the HAL2 works?
>
> We can't get it working correctly, it doesn't come back to normal state after
> the reset. Even if we write 0x0018 to isr, to enable the chip, it still shows
> 0x0000. It's certainly off because we can't write to the indirect registers in
> this state
>
I don't know anything about the HAL2, but looking in hal2.h it says
0=reset, so from what I can see you write 0x0018 to it and then it
should read 0x0000 when it is reset. Maybe this part is working ok for
you and the problem is further along?
There are other people who would know this better though!
Cheers, Alistair
> If we don't reset the HAL2, leaving it the way it is when after playing the boot
> sound, we can't write to the indirect registers. The busy bit doesn't go off.
>
> The only thing which works correctly is reading the version register.
>
> - Ulf
--
Alistair Lambie alambie@csd.sgi.com
SGI Global Product Support SGI Voicemail/VNET: 234-1455
Level 5, Cigna House, M/S: INZ-3780
PO Box 24 093, Ph: +64-4-494 6325
40 Mercer St, Wellington, Fax: +64-4-494 6321
New Zealand Mobile: +64-21-635 262
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
1999-02-02 19:36 ` Alistair Lambie
@ 1999-02-02 19:53 ` Ulf Carlsson
1999-02-02 20:25 ` Alistair Lambie
1999-02-02 21:11 ` Alan Cox
0 siblings, 2 replies; 9+ messages in thread
From: Ulf Carlsson @ 1999-02-02 19:53 UTC (permalink / raw
To: Alistair Lambie; +Cc: Linux SGI
> I don't know anything about the HAL2, but looking in hal2.h it says
> 0=reset, so from what I can see you write 0x0018 to it and then it
> should read 0x0000 when it is reset.
The spec says:
Bit 3, Global reset R/W:
Assertion of hardware reset i.e. RESET_N, set this to zero. Software brings the
HAL2 out of reset by setting this bit and may reset the HAL2 by clearing it.
Please note: this bit must be set before any other internal register access
occurs.
RESET = 0;
ACTIVE = 1;
Bit 4, Codec reset R/W:
Value reflected to CODEC_RESET_N pin. To reset external codecs and other
external devices.
RESET = 0; ACTIVE = 1;
This is exactly what I'm trying to do by first writing 0x0000 to isr, waiting
some us, and then writing 0x0018. Then the card should be active and isr should
IMHO contain 0x0018.
> Maybe this part is working ok for you and the problem is further along?
Nope.
- Ulf
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
1999-02-02 19:53 ` Ulf Carlsson
@ 1999-02-02 20:25 ` Alistair Lambie
1999-02-02 21:11 ` Alan Cox
1 sibling, 0 replies; 9+ messages in thread
From: Alistair Lambie @ 1999-02-02 20:25 UTC (permalink / raw
To: Ulf Carlsson; +Cc: Alistair Lambie, Linux SGI
Ulf Carlsson wrote:
>
> > I don't know anything about the HAL2, but looking in hal2.h it says
> > 0=reset, so from what I can see you write 0x0018 to it and then it
> > should read 0x0000 when it is reset.
>
write 0x0
wait 50us
write 0x18
write to indirect data reg
write to indirect addr reg
spin until idirect status reg transaction status reg clears
.....
> The spec says:
>
> Bit 3, Global reset R/W:
> Assertion of hardware reset i.e. RESET_N, set this to zero. Software brings the
> HAL2 out of reset by setting this bit and may reset the HAL2 by clearing it.
> Please note: this bit must be set before any other internal register access
> occurs.
> RESET = 0;
> ACTIVE = 1;
>
> Bit 4, Codec reset R/W:
> Value reflected to CODEC_RESET_N pin. To reset external codecs and other
> external devices.
> RESET = 0; ACTIVE = 1;
>
> This is exactly what I'm trying to do by first writing 0x0000 to isr, waiting
> some us, and then writing 0x0018. Then the card should be active and isr should
> IMHO contain 0x0018.
>
> > Maybe this part is working ok for you and the problem is further along?
>
> Nope.
>
> - Ulf
--
Alistair Lambie alambie@csd.sgi.com
SGI Global Product Support SGI Voicemail/VNET: 234-1455
Level 5, Cigna House, M/S: INZ-3780
PO Box 24 093, Ph: +64-4-494 6325
40 Mercer St, Wellington, Fax: +64-4-494 6321
New Zealand Mobile: +64-21-635 262
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
@ 1999-02-02 21:11 ` Alan Cox
0 siblings, 0 replies; 9+ messages in thread
From: Alan Cox @ 1999-02-02 21:11 UTC (permalink / raw
To: Ulf Carlsson; +Cc: alambie, linux
> This is exactly what I'm trying to do by first writing 0x0000 to isr, waiting
> some us, and then writing 0x0018. Then the card should be active and isr should
> IMHO contain 0x0018.
Stupid question but does
write 0x0010
wait 10uS
write 0x0018
work ?
(ie do you have to bring them out of reset card, then codec ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
@ 1999-02-02 21:11 ` Alan Cox
0 siblings, 0 replies; 9+ messages in thread
From: Alan Cox @ 1999-02-02 21:11 UTC (permalink / raw
To: Ulf Carlsson; +Cc: alambie, linux
> This is exactly what I'm trying to do by first writing 0x0000 to isr, waiting
> some us, and then writing 0x0018. Then the card should be active and isr should
> IMHO contain 0x0018.
Stupid question but does
write 0x0010
wait 10uS
write 0x0018
work ?
(ie do you have to bring them out of reset card, then codec ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: weird HAL2
1999-02-02 21:11 ` Alan Cox
(?)
@ 1999-02-02 21:26 ` Thomas Bogendoerfer
-1 siblings, 0 replies; 9+ messages in thread
From: Thomas Bogendoerfer @ 1999-02-02 21:26 UTC (permalink / raw
To: Alan Cox, Ulf Carlsson; +Cc: alambie, linux
On Tue, Feb 02, 1999 at 09:11:04PM +0000, Alan Cox wrote:
>
> write 0x0010
> wait 10uS
> write 0x0018
>
> work ?
not for me.
Thomas.
--
This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
[Martin `MJ' Mares on linux-kernel]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1999-02-02 22:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-02-02 16:17 weird HAL2 Ulf Carlsson
1999-02-02 19:36 ` Alistair Lambie
1999-02-02 19:53 ` Ulf Carlsson
1999-02-02 20:25 ` Alistair Lambie
1999-02-02 21:11 ` Alan Cox
1999-02-02 21:11 ` Alan Cox
1999-02-02 21:26 ` Thomas Bogendoerfer
-- strict thread matches above, loose matches on Subject: below --
1999-02-01 22:10 Thomas Bogendoerfer
1999-02-01 23:09 ` Ulf Carlsson
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.