Re: weird HAL2

Re: weird HAL2

[Ulf Carlsson]

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

Re: weird HAL2

[Alistair Lambie]

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

Re: weird HAL2

[Ulf Carlsson]

> 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

Re: weird HAL2

[Alistair Lambie]

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

Re: weird HAL2

[Alan Cox]

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

Re: weird HAL2

[Alan Cox]

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

Re: weird HAL2

[Thomas Bogendoerfer]

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]

weird HAL2

[Thomas Bogendoerfer]

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]

Re: weird HAL2

[Ulf Carlsson]

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