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