Hi,
It seems that all three ARM errata workarounds done in omap3 board-init
(#454179 #430973 #621766) are solved/not longer needed e.g. in the
AM/DM37xx chips. Other people have noticed this:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/254742.aspx
When still applying them (especcially #430973), lots of segmentations
faults and other strange stuff begin to appear.
I read your link the other way round. If the #430973 errata fix is _not_
applied to r3p2 it gives a lot of segfaults. Unfortunately the thread
has noc more information on that.
I dont know what bootloader the guy used, but he states that he needs to
enable the errata fix in the kernel for the segfaults to disappear. I
found exactly the same: Initially I had no errata fixes configured for
the kernel, only when I added them the segfaults disappeared.
However they also disappear if I remove the workarounds from kernel as
well as u-boot, hence this patch.
So as a simple solution I propose adding a config option to remove these
workarounds for boards/silicon that dont need them. Is this sensible or
should there be more automatism?
regards,
Andreas
PS. Does anybody have the "ARM Core Cortex-A8 (AT400/AT401) errata"
document to make sure my assumption above holds true?
I have rev 20.0 from 13-Apr-10. The three mentioned errata should be
fixed in r2p1.
<snip>
Two remarks:
1. I would prefer the option to be the other way around, i.e. forcing
the inclusion of the workaround when defined rather than when not
defined; e.g. CONFIG_SYS_CORTEXA8_WORK_AROUND_ERRATA
If we do that, lots of board configs have to be adapted. People who have
custom configs probably wont notice and loose their apropriate errata
handling.
2. (if applicable) I would prefer erratum-specific options, e.g.
CONFIG_SYS_CORTEXA8_WORK_AROUND_ERRATUM_430973 -- ok, "ERRATA" will be
fine too; what I want is easing the search for errata by number.
I join Albert's suggestion. Another solution could be to read the
silicon revision and enable erratum workarounds on that information. It
would be a step towards single binary.
So I'd rather do that, but can we map the ARM revision e.g. r2p1 to the
TI die versions ES1.0, 1.1 and so on? Or can the ARM revision be read
directly?
cheers,
Andreas
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
