[#6997] Wrong handling of silicon anomalies when "Silicon Rev" == "any"
Submitted By: Mike Sinkovsky
Open Fixed In Release:
Found In Release:
ALL Silicon Revision:
Is this bug repeatable?:
Assigned (Not Start)
Uboot version or rev.:
all Toolchain version or rev.:
App binary format:
Summary: Wrong handling of silicon anomalies when "Silicon Rev" == "any"
When in menu "Silicon Rev" I select "any" (CONFIG_BF_REV_ANY=y), __SILICON_REVISION__ is defined as 0xffff.
But in file mach/anomaly.h I see something like this:
/* Data CPLBs Should Prevent False Hardware Errors */
#define ANOMALY_05000246 (__SILICON_REVISION__ < 5)
/* Incorrect Bit Shift of Data Word in Multichannel (TDM) Mode in Certain Conditions */
#define ANOMALY_05000250 (__SILICON_REVISION__ == 4)
/* Maximum External Clock Speed for Timers */
#define ANOMALY_05000253 (__SILICON_REVISION__ < 5)
/* Incorrect Timer Pulse Width in Single-Shot PWM_OUT Mode with External Clock */
#define ANOMALY_05000254 (__SILICON_REVISION__ > 4)
ANOMALY_05000253 is not handled, because (0xffff < 5) == false.
But I think in this case all anomalies in all supported revisions should be handled?
I think here should be something like this:
#if __SILICON_REVISION__ == 0xffff
#define __SILICON_ANY__ 1
#define __SILICON_ANY__ 0
#define ANOMALY_05000246 (__SILICON_ANY__ || __SILICON_REVISION__ < 5)
#define ANOMALY_05000250 (__SILICON_ANY__ || __SILICON_REVISION__ == 4)
#define ANOMALY_05000253 (__SILICON_ANY__ || __SILICON_REVISION__ < 5)
#define ANOMALY_05000254 (__SILICON_ANY__ || __SILICON_REVISION__ > 4)
As I can see, this issue always was in all versions of Blackfin kernel and u-boot, but somehow should be fixed or explicitly documented.
--- Mike Frysinger 2012-03-12 11:11:31
the anomaly handling is known to be not that great. your proposal unfortunately
would make things worse. most anomaly workarounds operate on the assumption
that when they're enabled, they're needed, and some of those cause problems when
executed on newer parts.
the ideal would probably to implement runtime code patching like the
alt-instruction stuff that x86 does for uniprocessor/smp. build in all
workarounds and then at runtime during kernel init, patch out all the
workarounds that don't make sense for the active silicon rev.
--- Mike Sinkovsky 2012-03-13 02:37:25
> the ideal would probably to implement runtime code patching
As general solution - yes, it would be ideal, at least for RAM-based kernels
(don't know if it's possible at all for NOR-flash based kernels and for
I'm not familiar with that runtime patching infrastructure to say how easy it
would be to port it to Blackfin kernel (and u-boot too?)
As for my simple solution - maybe it's possible to sort out cases when handling
workarounds for newer silicons will break execution on older? I think anyway
here is very small fraction of that cases, and maybe it could be fixed
explicitly doing if/else in code...
--- Mike Frysinger 2012-03-13 10:57:15
yes, runtime patching would not work for XIP kernels. but i think the mechanism
that would be in place to mark off the sections would be able to transparently
be replaced with sirev checking.
i'm not sure about your proposed solution ... it prob wouldn't make the
sirev-any behavior worse. but since it'd require work to verify, i'd rather put
it into implementing a proper solution.
other examples that have known to come up: anomalies that only affect newer or
specific versions. your code quote provides an example: ANOMALY_05000254. if
sirev is set to 2, then that anomaly won't kick in.
File Name File Type File Size Posted By
No Files Were Found