[#6997] Wrong handling of silicon anomalies when "Silicon Rev" == "any"(2012)

[#6997] Wrong handling of silicon anomalies when "Silicon Rev" == "any"

Submitted By: Mike Sinkovsky

Open Date

2012-03-12 08:33:19    

Priority:

Low     Assignee:

Nobody

Status:

Open     Fixed In Release:

N/A

Found In Release:

N/A     Release:

all

Category:

Architecture     Board:

N/A

Processor:

ALL     Silicon Revision:

any

Is this bug repeatable?:

Yes     Resolution:

Assigned (Not Start)

Uboot version or rev.:

all     Toolchain version or rev.:

all

App binary format:

N/A     

Summary: Wrong handling of silicon anomalies when "Silicon Rev" == "any"

Details:

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

#else

#define __SILICON_ANY__ 0

#endif

.....

/* Data CPLBs Should Prevent False Hardware Errors */

#define ANOMALY_05000246 (__SILICON_ANY__ || __SILICON_REVISION__ < 5)

/* Incorrect Bit Shift of Data Word in Multichannel (TDM) Mode in Certain Conditions */

#define ANOMALY_05000250 (__SILICON_ANY__ || __SILICON_REVISION__ == 4)

/* Maximum External Clock Speed for Timers */

#define ANOMALY_05000253 (__SILICON_ANY__ || __SILICON_REVISION__ < 5)

/* Incorrect Timer Pulse Width in Single-Shot PWM_OUT Mode with External Clock */

#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.

Follow-ups

--- 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

u-boot).

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.

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

File Name     File Type     File Size     Posted By

No Files Were Found