confused about HID1 bits and G5

confused about HID1 bits and G5

[Chris Friesen]

I'm looking at 2.6.5, in the setup for the G5, specifically the HID1 register.

According to the docs for the chip, the default setting is all zeros, and the preferred setting is
0xFD3C200000000000.

The only place I see HID1 being set is in __power4_cpu_preinit, and it executes the following:


	mfspr	r0,SPRN_HID1
	li	r11,0x1200		/* enable i-fetch cacheability */
	sldi	r11,r11,44		/* and prefetch */
	or	r0,r0,r11
	mtspr	SPRN_HID1,r0
	mtspr	SPRN_HID1,r0
	isync

It appears that we're relying on the firmware to set up a lot of the bits in this register--is there
any reason we aren't forcing particular values?

Chris


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: confused about HID1 bits and G5

[Benjamin Herrenschmidt]

> It appears that we're relying on the firmware to set up a lot of the bits in this register--is there
> any reason we aren't forcing particular values?

Forcing values in HIDs is BAD. The firmware may set/clear bits to work
around specific CPU or north bridge bugs for example. That's why I need
to change the code that force-clear HID4/5 one of these days too and
instead just clear the bits I want to be cleared.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: confused about HID1 bits and G5

[Chris Friesen]

Benjamin Herrenschmidt wrote:
>>It appears that we're relying on the firmware to set up a lot of the bits in this register--is there
>>any reason we aren't forcing particular values?
>
>
> Forcing values in HIDs is BAD. The firmware may set/clear bits to work
> around specific CPU or north bridge bugs for example. That's why I need
> to change the code that force-clear HID4/5 one of these days too and
> instead just clear the bits I want to be cleared.

I'm just thinking of stuff that should really be set, like enabling the icache or the branch history
table.  Do we really want to rely on firmware to do that? [1]

Currently there are a bunch of bits in HID1 that are not specifically set in the linux code.  I
think they should be set, but I have no way of actually checking the value since I'm running in
32-bit mode. [2]

Chris




1. We've seen at least one firmware that didn't do this for some 74xx hardware.  Drove us nuts
trying to figure out why performance wasn't meeting projections.

2. I'm trying to get a 64-bit toolchain built, but the gcc doesn't build when I follow the
instructions on linuxppc64.org.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: confused about HID1 bits and G5

[Greg Watson]

As a firmware designed (LinuxBIOS), I would support this. Obviously
there are some things that the firmware has to do, like enable memory,
but the less reliance the o/s has on magic behavior the better. It
makes firmware design simpler and more reliable.

Greg

On 29/04/2004, at 7:54 AM, Chris Friesen wrote:

>
> Benjamin Herrenschmidt wrote:
>>> It appears that we're relying on the firmware to set up a lot of the
>>> bits in this register--is there
>>> any reason we aren't forcing particular values?
>>
>>
>> Forcing values in HIDs is BAD. The firmware may set/clear bits to work
>> around specific CPU or north bridge bugs for example. That's why I
>> need
>> to change the code that force-clear HID4/5 one of these days too and
>> instead just clear the bits I want to be cleared.
>
> I'm just thinking of stuff that should really be set, like enabling
> the icache or the branch history
> table.  Do we really want to rely on firmware to do that? [1]
>
> Currently there are a bunch of bits in HID1 that are not specifically
> set in the linux code.  I
> think they should be set, but I have no way of actually checking the
> value since I'm running in
> 32-bit mode. [2]
>
> Chris
>
>
>
>
> 1. We've seen at least one firmware that didn't do this for some 74xx
> hardware.  Drove us nuts
> trying to figure out why performance wasn't meeting projections.
>
> 2. I'm trying to get a 64-bit toolchain built, but the gcc doesn't
> build when I follow the
> instructions on linuxppc64.org.
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: confused about HID1 bits and G5

[Benjamin Herrenschmidt]

On Thu, 2004-04-29 at 23:54, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>It appears that we're relying on the firmware to set up a lot of the bits in this register--is there
> >>any reason we aren't forcing particular values?
> >
> >
> > Forcing values in HIDs is BAD. The firmware may set/clear bits to work
> > around specific CPU or north bridge bugs for example. That's why I need
> > to change the code that force-clear HID4/5 one of these days too and
> > instead just clear the bits I want to be cleared.
>
> I'm just thinking of stuff that should really be set, like enabling the icache or the branch history
> table.  Do we really want to rely on firmware to do that? [1]

Well, so far, on the HW we had to deal with, the firmware did it
properly, but yes, it may make sense to set them, though not in the
preinit but in the later "setup" code.

> Currently there are a bunch of bits in HID1 that are not specifically set in the linux code.  I
> think they should be set, but I have no way of actually checking the value since I'm running in
> 32-bit mode. [2]
>
> Chris
>
>
>
>
> 1. We've seen at least one firmware that didn't do this for some 74xx hardware.  Drove us nuts
> trying to figure out why performance wasn't meeting projections.
>
> 2. I'm trying to get a 64-bit toolchain built, but the gcc doesn't build when I follow the
> instructions on linuxppc64.org.

I suggest you join #ppc64 on irc.freenode.net. Toolchain build can be
fairly nasty, at least to get the initial one built. Once you get it,
it's easier to rebuild new versions.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: confused about HID1 bits and G5

[Benjamin Herrenschmidt]

On Fri, 2004-04-30 at 01:05, Greg Watson wrote:
> As a firmware designed (LinuxBIOS), I would support this. Obviously
> there are some things that the firmware has to do, like enable memory,
> but the less reliance the o/s has on magic behavior the better. It
> makes firmware design simpler and more reliable.

There is nothing like "magic behaviour" here. There is a set of
features that should normally be enabled on the CPU, this set is
clearly defined in the spec, the firmware should enabled them.

As I wrote, I prefer not touching most of this from the kernel since
some specific CPU rev. errata may involve disabling some of those,
and that is typically done by the firmware, at least on pmacs. Now,
it's possible that I decide to force more of these bits myself based
on experience with broken firmwares, but so far, this has not been
necessary :)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: confused about HID1 bits and G5

[Greg Watson]

On 29/04/2004, at 3:49 PM, Benjamin Herrenschmidt wrote:

> On Fri, 2004-04-30 at 01:05, Greg Watson wrote:
>> As a firmware designed (LinuxBIOS), I would support this. Obviously
>> there are some things that the firmware has to do, like enable memory,
>> but the less reliance the o/s has on magic behavior the better. It
>> makes firmware design simpler and more reliable.
>
> There is nothing like "magic behaviour" here. There is a set of
> features that should normally be enabled on the CPU, this set is
> clearly defined in the spec, the firmware should enabled them.
>
> As I wrote, I prefer not touching most of this from the kernel since
> some specific CPU rev. errata may involve disabling some of those,
> and that is typically done by the firmware, at least on pmacs. Now,
> it's possible that I decide to force more of these bits myself based
> on experience with broken firmwares, but so far, this has not been
> necessary :)

Well the good thing about LinuxBIOS is you can fix the firmware. :-)

Greg


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/