On 3 May 2017 at 03:19, Mills, William <[email protected]> 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: [email protected] > 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 -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
