[meta-xilinx] microblazev8 tune problems

[William Mills]

On 04/29/2017 10:22 AM, Nathan Rossi wrote:
> On 29 April 2017 at 07:14, Mills, William <wmills at ti.com> wrote:
>> Hello,
>>
>> I have been looking at microblaze as an example of how to add a new architecture to OE-core.
>> Right now I am on master for bitbake, oe-core, and meta-xilinx.
>>
>> I have tried multiple MACHINEs but right now I am working with MACHINE=ml605-qemu-microblazeel
>> In this combination and others, I could not get the below code to work.
> 
> You mean you couldn't trigger it? or it was causing errors?
> 

bitbake fails during the conf/recipe parsing phase.
I think even before it actually gets to recipes.
I did see in the in-progress YP 2.3 Docs that the old bb.data.getVar()
syntax was deleted.  This python fragment uses that so I would not
expect it to work in master branch.

However, this does not explain why I could not get it to work when I was
on morty or krogoth.  I think I need to retry that.

I am not at the machine I was using for this.  I will post a detailed
error message when I get back to that machine.

>>
>> At first I thought it was because it used the older syntax but I tried changing w/o luck.
>> I then explored switching the 3 git repos to morty (bitbake 1.32) or krogoth (bitbake 1.30) and I could not
>> find a winning combination.
>>
>> As shown below I worked around it by just disabling this python fragment as it is not important to what I am doing.
>> (And the existing "tune"'s enable both options anyway).
>>
>> I would be interested to understand what I was doing wrong anyway.
>>
>> BTW: The comment above the code does not match what the code does IMHO.
> 
> So the code is essentially forcing the enabling of 'pattern-compare'
> when using the 'reorder' feature but only for cpu version v8.30. There
> is no way to make a tune feature depend on another tune feature
> (although they can conflict), so this is the reason for the anonymous
> function. There are a number of other ways to handle this, ideally it
> should generate an error but its quite hard to make it a sanity error
> like TUNECONFLICTS.

Yes, I agree that is what the code does.

The comment says it also does the converse.  The comment would lead you
to believe that it adds the reorder feature if it is not present and the
pattern-compare feature is.  I don't think it does that.

"""
# Check if either one exists alone and if so, add the other
"""

> 
> Normally with OE you would solve this issue by not providing a TUNE
> that has the set of invalid features. However for MicroBlaze there are
> quite a few tune features, which would require the definition of an
> absurd number of AVAILTUNES (~10 features and ~15 versions, expanding
> to >1000 possible tunes). So for MicroBlaze the machine must define
> its TUNE_FEATURES by overriding the default
> TUNE_FEATURES_tune-microblaze value.
> 

Yes, it is a pretty slick system.