CPU15 errata workaround for 8xx by WD
Wolfgang Denk
wd at denx.de
Mon Jan 3 07:54:24 EST 2005
Dear Joakim,
in message <BCEFJBPJCGFCNMMMIDBHOEPBCJAA.Joakim.Tjernlund at lumentis.se> you wrote:
>
> Had a look at your CPU15 errata workaround for 8xx and I have a comment
> or two:
>
> 1) I think you should make the sysctl support a compile time option
> as the overhead for sysctl support in the TLB handler is 6 instr. when
> the fix itself is only 4 instr.
You are right. For a permanent patch that would be better - in our
case it was important to be able to turn on and off this workaround
dynamically with exactly the same kernel binary. We wanted to have
real proof that the effects we saw were caused by CPU15 erratum, and
that the workaround fixes these problems.
> 2) You placed the workaround in the middle of the CPU6 workaround which will
> disable the CPU6 workaround(I think). Move it before the #ifdef CONFIG_8xx_CPU6
> and you should be fine.
I think you are right.
> 3) Your test program uses the dcbst and dcbi instr. and these are buggy as they do not
> update the DAR register in the TLB exceptions. I guess you made sure that such errors
> will not happen?
Ummm... I think so.
> 4) The CPU15 bug has been around for years I think, what made it show up now? New toolchains?
No, this is not a toolchain issue. It's a processor problem.
I have to admit that I didn't believe our customer when he reported
that he has problems that were caused by the CPU15 bug - I never saw
this on any other 8xx processor before, and as you say it has been
mentioned in all errata sheets I can remember. As far as I can tell
it is only the MPC870/885 duet family of processors where this CPU15
bug actually hits. I have no idea why.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Brain: an apparatus with which we think we think. - Ambrose Bierce
More information about the Linuxppc-embedded
mailing list