[meta-xilinx] microblazev8 tune problems

[Nathan Rossi]

On 3 May 2017 at 03:19, Mills, William <wmills at ti.com> wrote:
> Nathan,
>
> Actually, I rechecked my original machine.  (Below I used a 2nd machine with a cleaner environment.)
>
> There are 13 new patches on meta-xilink master that were not there when I cloned for the first machine several days ago.
> I pulled again and now see your microblaze tune rework (commit dated 2017-01-14)

Yes those changes had been sitting around for a while.

> Did you just push these to github master a couple of days ago or is something funny going on in my clones?

I did push those changes last week though. So you might have missed them.

>
> Thanks,
> Bill
>
> -----Original Message-----
> From: Mills, William
> Sent: Tuesday, May 2, 2017 1:00 PM
> To: Mills, William; Nathan Rossi
> Cc: meta-xilinx at yoctoproject.org
> Subject: RE: [meta-xilinx] microblazev8 tune problems
>
>>> On 04/29/2017 10:22 AM, Nathan Rossi wrote:
>>> You mean you couldn't trigger it? or it was causing errors?
>
> Yesterday I wrote:
>>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.
>
> Sorry, this must have just been me messing up.
> Retesting with oe-core & meta-xilinx on morty branch and bitbake at v3.2 it works fine.
> It also works fine with all 3 at master.
>
> Somehow I must have been using morty branch of meta-xilinx with master bitbake etc.
> The microblaze conf in master is totally reworked.
> The anon python fragment is still present and updated for the new syntax.
> What's more the comment has been updated to reflect exactly what the code does.

Yep, I was going to point you to that. Since it was only recently
changed on master.

However you bringing up this topic has made me re-look into why that
python code is there in the first place, as such I think it is a bad
practice to add features without them being specified manually and
instead fall back to ensuring correct ABI compatibility by ignoring
features like reorder (by not enabling it in TUNE_CCARGS) if a
dependent feature is not enabled.

The plan is to add these microblaze arch/tune includes into OE-Core,
so it is worth fixing up these obscurities.

Thanks,
Nathan