Dear Joakim,
in message [off-list ref] 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@denx.de
Brain: an apparatus with which we think we think. - Ambrose Bierce
Dear Joakim,
in message [off-list ref] you wrote:
quoted
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.
Have you done any performance measurements with with/without the CPU15
patch? To always invalidate the previous and the next TLB(plus the extra code in the
TLB handler) seems expensive.
quoted
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.
quoted
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.
Me too, but I only had a quick look.
quoted
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.
That explains why I never seen this before, thanks.
A better fix would be to make the toolchain insert an extra NOP if
the last instr. in a page is a branch, but that will take some time.
Any GCC people on this list?
Regards
Joakim
Best regards,
Wolfgang Denk