405EX Rev D mis-identification?

405EX Rev D mis-identification?

[Marc Chidester]

It looks like the Rev D version of the 405EX chip without security
will be identified as a 405EXr, based on the values in the cpu_specs
table.  For 405EX/405EXr the pvr_mask is  0xffff0004 with the
pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
Rev D PVR value for the 405EX without security is 0x12911473, which
would mask out to the EXr value.

Is there an algorithm update needed or am I missing something?

Re: 405EX Rev D mis-identification?

[Lee Nipper]

On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrot=
e:
> It looks like the Rev D version of the 405EX chip without security
> will be identified as a 405EXr, based on the values in the cpu_specs
> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
> Rev D PVR value for the 405EX without security is 0x12911473, which
> would mask out to the EXr value.
>
> Is there an algorithm update needed or am I missing something?

With 405EX Rev D, we have noticed that we must reset our board
one time after the initial powerup to make the PVR read correctly.

See this post:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html

Re: 405EX Rev D mis-identification?

[Lee Nipper]

On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
> It looks like the Rev D version of the 405EX chip without security
> will be identified as a 405EXr, based on the values in the cpu_specs
> table.

Yes, that is the case.
The 405EX Rev D without security PVR matches an old 405EXr A/B with security,
and hence the cpu_spec entries' pvr_mask values are no longer correct.

> Is there an algorithm update needed or am I missing something?

Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
pvr_mask = 0xffff000f  ?

Re: 405EX Rev D mis-identification?

[Josh Boyer]

On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote:
>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
>> It looks like the Rev D version of the 405EX chip without security
>> will be identified as a 405EXr, based on the values in the cpu_specs
>> table.
>
>Yes, that is the case.
>The 405EX Rev D without security PVR matches an old 405EXr A/B with security,
>and hence the cpu_spec entries' pvr_mask values are no longer correct.
>
>> Is there an algorithm update needed or am I missing something?
>
>Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
>pvr_mask = 0xffff000f  ?

Have you tried that in a locally modified kernel?  If so, did it work?  If so,
care to submit a patch? :)

josh

Re: 405EX Rev D mis-identification?

[Josh Boyer]

On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wrote:
>> It looks like the Rev D version of the 405EX chip without security
>> will be identified as a 405EXr, based on the values in the cpu_specs
>> table.  For 405EX/405EXr the pvr_mask is  0xffff0004 with the
>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>> Rev D PVR value for the 405EX without security is 0x12911473, which
>> would mask out to the EXr value.
>>
>> Is there an algorithm update needed or am I missing something?
>
>With 405EX Rev D, we have noticed that we must reset our board
>one time after the initial powerup to make the PVR read correctly.
>
>See this post:
>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html

That is very very weird.  Have you seen that behavior on multiple Rev D CPUs
or just one board or?

The PVR value should never change, so if you have odd behavior I wonder if the
are silicon bugs in that revision.  Did you happen to ask AMCC about it?

josh

Re: 405EX Rev D mis-identification?

[Lee Nipper]

On Thu, Jul 8, 2010 at 13:24, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote=
:
> On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>> It looks like the Rev D version of the 405EX chip without security
>>> will be identified as a 405EXr, based on the values in the cpu_specs
>>> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
>>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>>> Rev D PVR value for the 405EX without security is 0x12911473, which
>>> would mask out to the EXr value.
>>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>With 405EX Rev D, we have noticed that we must reset our board
>>one time after the initial powerup to make the PVR read correctly.
>>
>>See this post:
>>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
>
> That is very very weird. =A0Have you seen that behavior on multiple Rev D=
 CPUs
> or just one board or?
>

Multiple Rev D CPUs.  In fact, ALL of the samples we obtained behave this w=
ay.

> The PVR value should never change, so if you have odd behavior I wonder i=
f the
> are silicon bugs in that revision. =A0Did you happen to ask AMCC about it=
?
>

Yes, I did.
AMCC suggested doing an early one-time s/w reset to make the PVR read
"correctly" afterwards.
Since we only support one specific 405EX variety, we could do that.

However, on a generic u-boot, there is no way to know if a "correct"
PVR is read,
so that approach is not a solution.

I'm wondering if our power on reset circuitry is not entirely correct,
and it showed up with the Rev D part.  I received no comments on my
original post
from other users of the 405EX, so I'm thinking it is a possible explanation=
.

Does anyone have a board with a 405EX Rev D ?
If so, does the PVR value match your processor chip after power up ?

Lee

Re: 405EX Rev D mis-identification?

[Lee Nipper]

On Thu, Jul 8, 2010 at 13:22, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote=
:
> On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>Perhaps add more cpu_spec table entries for the 405EX & 405EXr with
>>pvr_mask =3D 0xffff000f =A0?
>
> Have you tried that in a locally modified kernel? =A0If so, did it work? =
=A0If so,
> care to submit a patch? :)
>

I have not yet.  I will prepare a patch.

Lee

Re: 405EX Rev D mis-identification?

[Marc Chidester]

On Thu, Jul 8, 2010 at 2:24 PM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wro=
te:
> On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote:
>>On Thu, Jul 8, 2010 at 10:06, Marc Chidester <marcchidester@gmail.com> wr=
ote:
>>> It looks like the Rev D version of the 405EX chip without security
>>> will be identified as a 405EXr, based on the values in the cpu_specs
>>> table. =A0For 405EX/405EXr the pvr_mask is =A00xffff0004 with the
>>> pvr_value's as 0x12910004 and 0x12910000 respectively. I see that the
>>> Rev D PVR value for the 405EX without security is 0x12911473, which
>>> would mask out to the EXr value.
>>>
>>> Is there an algorithm update needed or am I missing something?
>>
>>With 405EX Rev D, we have noticed that we must reset our board
>>one time after the initial powerup to make the PVR read correctly.
>>
>>See this post:
>>http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html
>
> That is very very weird. =A0Have you seen that behavior on multiple Rev D=
 CPUs
> or just one board or?
>
> The PVR value should never change, so if you have odd behavior I wonder i=
f the
> are silicon bugs in that revision. =A0Did you happen to ask AMCC about it=
?
>
> josh
>

Check the recent Errata for the chip on this issue.