2008-11-26 21:46:41     About uClinux running on different blackfin chip version

Document created by Aaronwu Employee on Aug 9, 2013
Version 1Show Document
  • View in full screen mode

2008-11-26 21:46:41     About uClinux running on different blackfin chip version

DAVID ZHOU (CHINA)

Message: 65869   

 

Hi All,

 

Can uClinux compiled for  bf536 0.2 version running on bf536 0.3 version fully compatible ?

 

and

 

Can uClinux compiled for bf536 0.3 version runnning on bf536 0.2 version fully compatible?

 

Thanks in advance!

QuoteReplyEditDelete

 

 

2008-11-26 21:50:48     Re: About uClinux running on different blackfin chip version

Mike Frysinger (UNITED STATES)

Message: 65871   

 

the revision you select is the oldest that will work.  so if you compile for bf536-0.2, then it should work on 0.2 and newer.  if you compile for bf536-0.3, it will probably not work for 0.2 and that is by design.

 

QuoteReplyEditDelete

 

 

2008-11-26 21:57:50     Re: About uClinux running on different blackfin chip version

DAVID ZHOU (CHINA)

Message: 65873   

 

Thanks Mike!   my uclinux version is 2008release 1 and have you fully tested with it  ? We should make sure it .

QuoteReplyEditDelete

 

 

2008-11-26 22:01:46     Re: About uClinux running on different blackfin chip version

Mike Frysinger (UNITED STATES)

Message: 65874   

 

please be exact in what you're asking.  fully tested what ?

 

QuoteReplyEditDelete

 

 

2008-11-26 22:31:33     Re: About uClinux running on different blackfin chip version

DAVID ZHOU (CHINA)

Message: 65878   

 

I mean that your surely have strict test with 0.2 version uClinux running on 0.3 version chip and it works fine.:)

QuoteReplyEditDelete

 

 

2008-11-26 23:39:04     Re: About uClinux running on different blackfin chip version

Mike Frysinger (UNITED STATES)

Message: 65881   

 

we havent done strict tests, but we code things in mind and no one has complained ...

QuoteReplyEditDelete

 

 

2008-11-28 07:14:23     Re: About uClinux running on different blackfin chip version

Michael McTernan (UNITED KINGDOM)

Message: 65957   

 

Is this really true?  Later revisions have new anomalies which don't seem to be retrospectively applied e.g.  from mach-bf533/anomaly.h on 2008R1.5:

 

/* PPI Does Not Start Properly In Specific Mode */

#define ANOMALY_05000400 (__SILICON_REVISION__ == 5)

 

So surely something built for 0.2 wouldn't apply the needed workarounds for a 0.5 part.

 

Should the == be a <=?  Or is this for a new PPI mode added in 0.5 silicon (the anomaly lists doesn't mention this though)?

 

 

 

 

QuoteReplyEditDelete

 

 

2008-11-28 20:54:00     Re: About uClinux running on different blackfin chip version

Robin Getz (UNITED STATES)

Message: 65995   

 

Michael:

 

When we make a release (like 2008R1.5) it is tested against specific versions of silicon/anomaly lists which are current at that time. We normally test multiple versions of the same silicon (bf533 0.3 and 0.5 for example - to make sure we didn't break anything - where anomalies which are known either are new/exist/disappear/change the logic of the part, we attempt to code for it, and test for it (compile for 0.3, test on 0.5).

 

When a new anomaly is discovered after the release is made - we sometimes (most times, but not always) update the svn branch where the release was build from. When a new revision is released - we never try it on the release branch. It is expected that it may fail, as functionality / anomaly descriptions change. This is unfortunate, but unavoidable. (When the release is made - we can't test what we don't have; and we would never make new releases if we re-tested old releases on newer versions of parts).

 

Does that make sense?

QuoteReplyEditDelete

 

 

2008-11-30 12:58:09     Re: About uClinux running on different blackfin chip version

Michael McTernan (UNITED KINGDOM)

Message: 66044   

 

Makes perfect sense and I sympathise that your test matrix must be *huge*.  But it still seems slightly different to Mike's statement that "the revision you select is the oldest that will work".  Plus, as I already pointed out, some anomalies such as 05000400 are only enabled when a later specific silicon revision is selected even within a code branch.

 

So right now I'm of the opinion that if the factory changes the chip revision on our boards, the safest thing to do is make a new software load with matching revision target and of course redo all our testing.  I think this is unavoidable though, and certainly no fault of uClinux - if anything, the way the anomalies are handled and laid out in the code is very consistent and well organised and it's also unrealistic to expect every combination of revisions to be tested in anycase.

QuoteReplyEditDelete

 

 

2008-12-01 13:55:53     Re: About uClinux running on different blackfin chip version

Robin Getz (UNITED STATES)

Message: 66105   

 

Michael:

 

Yeah - that is a good point about 05000400 - (or any anomaly that is **introduced** on new silicon). The anomaly.h definition currently is something like:

 

#define ANOMALY_05000400 (__SILICON_REVISION__ > 4)

 

Since __SILICON_REVISION__ is a constant, that will get optimized to a true/false at compile time. (meaning if you compile it for 0.2, and run it on 0.5 - it will not include the anomaly workaround). It should be something like:

 

#define ANOMALY_05000400 (__SILICON_REVISION__ < 5 && bfin_revid() > 4)

 

That way - if it is 6 or above - it goes to a constant (and is compiled out). If it is compiled for something less than that - it is a run time check...

 

I think that would cover things?

 

-Robin

QuoteReplyEditDelete

 

 

2008-12-02 10:39:37     Re: About uClinux running on different blackfin chip version

Michael McTernan (UNITED KINGDOM)

Message: 66171   

 

> #define ANOMALY_05000400 (__SILICON_REVISION__ < 5 && bfin_revid() > 4)

 

Yes - that would match Mike's statement and enable a single build to handle multiple silicon revisions.  But I guess it may come at a slight cost of a run time check for all future anomalies, and would also require changing each macro.

 

Would it be simpler to use the 'any' selection for cpu target?  Gcc, when passed -mcpu=bf533-any already sets __SILICON_REVISION to 0xffff, so we could use this as follows:

 

#if __SILICON_REVISION__ == 0xffff

#define BUILD_SI_REV bfin_revid()

#else

#define BUILD_SI_REV __SILICON_REVISION__

#endif

 

#define ANOMALY_05000400 (BUILD_SI_REV == 5)

 

This then gives the choice of something lean for a targeted build, or something slightly bigger and slower but more generic.  I recon that these are reasonable options to support, and it would reduce the test matrix to either needing a matching Si rev and build, or a build for any and some target.

 

I guess bfin_revid() may also need a conditional def for __ASSEMBLY__ too, if not done already.

QuoteReplyEditDelete

 

 

2008-12-02 15:44:18     Re: About uClinux running on different blackfin chip version

Robin Getz (UNITED STATES)

Message: 66182   

 

Michael:

 

Yeah - this is something I will follow up on (or someone will) for the next release. (2009R1) - but not apply back to the 2008 branch

 

It is likely that all the anomaly.h files will get updated, and we will fix things up then.

 

-Robin

QuoteReplyEditDelete

 

 

2008-12-05 11:23:50     Re: About uClinux running on different blackfin chip version

Michael McTernan (UNITED KINGDOM)

Message: 66417   

 

Excellent - many thanks Robin & Mike.

 

I'm looking forward to 09R1 :-)

Attachments

    Outcomes