This mailing list is listed as an official support channel in beagleboard FAQ,
so I'm posting here as a customer now.
Could anybody from the beagleboard support team tell me which revisions of
beagleboard have a workaround for Cortex-A8 erratum #687067 applied? I'm
particularly interested to know whether beagleboard rev C2 is affected.
The fix is supposed to be applied from the secure mode, which implies that it
has to be somewhere in ROM code (unless there is some other way to initialize
L1 System Array Debug Register).
This mailing list is listed as an official support channel in
beagleboard FAQ, so I'm posting here as a customer now.
Could anybody from the beagleboard support team tell me which
revisions of beagleboard have a workaround for Cortex-A8 erratum #687067 applied? I'm particularly interested to know whether
beagleboard rev C2 is affected.
687067 is present on all Cortex-A8 revisions through r3p2 and thus
affects all Beagle boards produced to date.
The fix is supposed to be applied from the secure mode, which
implies that it has to be somewhere in ROM code (unless there is
some other way to initialize L1 System Array Debug Register).
The erratum only applies if you set the IBE bit in aux control
register; it is not set at reset. If you did that, you know how to
clear it as well. For the record, the aux control register can be
written with a ROM monitor call by means of the SMC instruction.
Details of this are in the OMAP35xx TRM.
But you should understand yourself that clearing IBE bit is not the best
solution. Mostly because it makes any practical use of thumb/thumb2 code
totally impossible on Cortex-A8 r1p3.
Additionally, please take a look at this IRC chat log:
# [20:56:59] <koen> "430973?"
# [20:57:11] <koen> "you need that even for non-thumb with gcc 4.5.x"
# [20:58:05] <rcn-ee> "yeap.. 430973... really i didn't know that.."
# [20:58:48] <koen> "XorA|gone found that out by trial and error"
# [20:59:14] <koen> "we're testing a toolchain upgrade for angstrom and were
seeing that issue"
It's quite likely that XorA and koen just screwed up something when testing
gcc 4.5.x as I could not confirm this problem myself. But the possibility of
the need to have IBE bit set even without using thumb can't be totally ruled
out yet.
Don't you think that it may be a good idea to escalate the problem to whoever
is responsible for the ROM code for beagleboards to workaround erratum #687067 properly (via L1 System Array Debug Register)? So that at least the
problem gets solved for the new batches of beagleboards.
Siarhei Siamashka <siarhei.siamashka@gmail.com> writes:
> Hello,
>
> This mailing list is listed as an official support channel in
> beagleboard FAQ, so I'm posting here as a customer now.
>
> Could anybody from the beagleboard support team tell me which
> revisions of beagleboard have a workaround for Cortex-A8 erratum
> #687067 applied? I'm particularly interested to know whether
> beagleboard rev C2 is affected.
687067 is present on all Cortex-A8 revisions through r3p2 and thus
affects all Beagle boards produced to date.
> The fix is supposed to be applied from the secure mode, which
> implies that it has to be somewhere in ROM code (unless there is
> some other way to initialize L1 System Array Debug Register).
The erratum only applies if you set the IBE bit in aux control
register; it is not set at reset. If you did that, you know how to
clear it as well. For the record, the aux control register can be
written with a ROM monitor call by means of the SMC instruction.
Details of this are in the OMAP35xx TRM.
Thanks for the fast reply.
But you should understand yourself that clearing IBE bit is not the best
solution. Mostly because it makes any practical use of thumb/thumb2 code
totally impossible on Cortex-A8 r1p3.
Don't use thumb then. It doesn't really gain much anyway.
Additionally, please take a look at this IRC chat log:
# [20:56:59] <koen> "430973?"
# [20:57:11] <koen> "you need that even for non-thumb with gcc 4.5.x"
# [20:58:05] <rcn-ee> "yeap.. 430973... really i didn't know that.."
# [20:58:48] <koen> "XorA|gone found that out by trial and error"
# [20:59:14] <koen> "we're testing a toolchain upgrade for angstrom and were
seeing that issue"
It's quite likely that XorA and koen just screwed up something when testing
gcc 4.5.x as I could not confirm this problem myself. But the possibility of
the need to have IBE bit set even without using thumb can't be totally ruled
out yet.
I don't see anything in those errata descriptions that would impact
pure ARM code execution. I've also been running FFmpeg tests with gcc
4.5.0 for quite some time without any issue.
Don't you think that it may be a good idea to escalate the problem
to whoever is responsible for the ROM code for beagleboards to
workaround erratum #687067 properly (via L1 System Array Debug
Register)? So that at least the problem gets solved for the new
batches of beagleboards.
Unless the TRM is incomplete, and there is in fact a way to write the
L1 System Array Debug registers, that would require a new mask ROM,
which is not something TI will do lightly. Previous inquiries into
the details of this ROM code have only been met with total silence.