On 2/9/21 3:29 PM, Peter Smith wrote: > Useful information in there. I noticed that the stuff on master has both > dunfell > and gatesgarth in the layer compats and in fact I have tested meta-xilinx > master > with poky dunfell with some success. Is it planned to maintain the layer > compat > as it is today?
We suspect that gatesgarth will work with dunsfell, but we've not tested it. Master on the other hand, we know doesn't work with gatesgarth anymore (but the community has not yet moved the layer compat forward on master. Once they do, I'll adjust all of the conf/layer.conf files in master) The reason I suspect it doesn't work in gatesgarth anymore is a nunber of .bbappends around the toolchain have changed pretty dramatically. If someone runs into an issue w/ the gatesgarth that shows it doesn't work with dunsfell, then I'll remove the dunsfell from the compat as well... but I don't have any information either way. --Mark > On Tue, 9 Feb 2021 at 20:35, Mark Hatle <[email protected] > <mailto:[email protected]>> wrote: > > > > On 2/9/21 6:51 AM, Adrian Fiergolski wrote: > > Has anyone ported meta-xilinx to dunfell? > > Xilinx has not ported to the dunfell version, nor do we have plans to do > so. If > someone wants to take over this work we will help where possible, and we > would > suggest backporting from gatesgarth or master. (All current work is > being done > on gatesgarth and master, in parallel. Obviously we have stuff we're not > yet > allowed to release, but everything public has been put in those branches > and is > being updated regularly.) > > > Is there any way to use meta-xilinx with newer release than 'zeus'? Is > 'master' > > (according to conf it supports 'dunfell' and 'gatesgarth') stable and > could be used? > > We have only worked with gatesgarth and master. It is unlikely master > will work > with dunfell, due to a number of changes in master. However, the > gatesgarth > version MIGHT work, but this is not what we are targeting. > > > The latest Xilinx releases (v2020.1 and v2020.2) are based on 'zeus' > which is > > more than one year old. There were upgrades in other layers (e.g. Qt) > fixing > > affecting bugs over last year, but they were not backported to 'zeus'. > It's > > surprising and disappointing that the latest Xilinx release v2020 was > not > based > > on the latest Yocto release. Why is that? > > Zeus was released as stable fall of 2019. Fall of 2019 is when work for > the > 2020.* versions of PetaLinux began. It would not have been possible for > us to > do Dunfell or Gatesgarth due to release cycles. > > > According to this video [1] yocto is one of the official Xilinx flow. > However, > > your development milestones are not clear to me. Why don't you keep > meta-xilinx > > aligned with yocto releases? Is Xilinx committed to supporting the > Yocto flow? > > Everything is subject to change, but historically Xilinx has taken the > Fall > stable release, then upgraded meta-xilinx, meta-petalinux (and other > components) > to work with it. Then released X.1. Later, as updates are necessary for > new > features, .2, .3, etc versions are released, but the base Yocto Project > does not > change. > > So I would expect 2020.X to be based on Fall 2019. 2019.x to be based on > Fall > 2018, etc. > > The work-in-progress is currently based on Gatesgarth, which is why we're > targeting that work. > > --Mark > > > Regards, > > > > Adrian > > > > [1] > > > > https://www.xilinx.com/video/software/xilinx-embedded-linux-build-flows-yocto-project.html > > <https://www.xilinx.com/video/software/xilinx-embedded-linux-build-flows-yocto-project.html> > > > > On 22.10.2020 19:26, Mark Hatle wrote: > >> Most of the work I've been doing has been on master branch. (But it's > been over > >> a week since the last major build I've run.) > >> > >> The majority of the work has been using MACHINE=zynqmp-generic, with a > DISTRO=poky. > >> > >> As mentioned before, the baremetal and some of the microblaze stuff is > not > >> working properly yet. Still trying to figure out how to resolve those > issues, > >> but unfortunately I probably won't get back to it until early November. > >> > >> --Mark > >> > >> On 10/22/20 9:02 AM, Philip Balister wrote: > >>> Is there any combination of layers that actually work for zynqmp? I > >>> constantly run into build failures, bad docs etc. > >>> > >>> Philip > >>> > >>> On 10/14/20 3:33 PM, Mark Hatle wrote: > >>>> On 10/8/20 8:50 AM, Scott Ellis wrote: > >>>>> I don't see any commits to *meta-xilinx* *[master]* since Aug 14. > >>>>> > >>>>> Since *[dunfell]* is a Yocto LTS release we would really like to use > this version. > >>>> We've replied to this in the past. We don't have any intention of > supporting > >>>> dunfell in meta-xilinx. > >>>> > >>>> Our last release was on Zeus, (Fall 2019) and our next major release > will be on > >>>> Fall 2020 (unless things change..) > >>>> > >>>> This is how we've been operating for many years, supporting every > other > release. > >>>> > >>>> What HAS changed recently is that we're actively working on master. > So > instead > >>>> of waiting until spring for gatesgarth to work, it will be "mostly" > working and > >>>> continued development/maintenance through at least spring. > >>>> > >>>>> Right now the *libgloss* and *newlib* bbappends are still > referencing > version > >>>>> 3.1, the versions that *Poky* *[zeus]* uses. > >>>> This work for _master_ is in progress. > >>>> > >>>> Look at the top three commits: > >>>> > >>>> https://github.com/Xilinx/meta-xilinx/tree/mgh/master-next > <https://github.com/Xilinx/meta-xilinx/tree/mgh/master-next> > >>>> > >>>> Note, the reason this hasn't been merged yet is that it DOES NOT YET > WORK! > >>>> Building a baremetal toolchain results in numerous compiliation and > installation > >>>> failures. > >>>> > >>>> Again, if you or anyone else can help resolve these we'll happily > accept patches > >>>> -- but until then the work is on-hold until other more pressing > issues are > >>>> resolved. (We're constantly juggling both internal and external > priorities.) > >>>> > >>>>> So they can't work with *Poky* *[dunfell]*'s 3.2 versions. > >>>> We started developing master _after_ dunfell was released. It would > divide our > >>>> resources to backport the master work to dunfell, and this would > limit our > >>>> abilities to manage master and do other new development tasks that > we have. > >>>> > >>>> As stated a few months ago when this was asked. If someone wants to > manage a > >>>> dunfell branch, let us know. We're happy to work with you, but we > just > don't > >>>> have resources to spare managing a dead end when master and future > development > >>>> is far more important. > >>>> > >>>>> This makes the *pmu-firmware* unbuildable which is an issue for > *zynqmp* boards. > >>>>> > >>>>> >From *[dunfell]* branch of *Poky* > >>>>> > >>>>> > >>>>> ~/poky-dunfell$ ls -l meta/recipes-core/newlib/ > >>>>> total 16 > >>>>> drwxrwxr-x 2 scott scott 4096 Apr 23 07:09 libgloss > >>>>> -rw-rw-r-- 1 scott scott 858 May 1 14:24 libgloss_3.2.0.bb > <http://libgloss_3.2.0.bb> > >>>>> -rw-rw-r-- 1 scott scott 571 May 1 14:24 newlib_3.2.0.bb > <http://newlib_3.2.0.bb> > >>>>> -rw-rw-r-- 1 scott scott 1995 May 1 14:24 newlib.inc > >>>>> > >>>>> >From *[master]* branch of *meta-xilinx* > >>>>> > >>>>> > >>>>> ~/poky-dunfell$ ls -l > meta-xilinx/meta-xilinx-standalone/recipes-core/newlib/ > >>>>> total 8 > >>>>> -rw-rw-r-- 1 scott scott 405 Aug 26 15:39 > libgloss_3.1.0.bbappend > >>>>> -rw-rw-r-- 1 scott scott 584 Aug 26 15:39 newlib_3.1.0.bbappend > >>>>> > >>>>> > >>>>> But also in the new *meta-xilinx/meta-microblaze* layer *newlib* and > *libgloss* > >>>>> reference the 3.3 version. > >>>>> > >>>>> But 3.3 is from *Poky* *[master]*, what will be the branch that > follows *[dunfell]*. > >>>>> > >>>>> >From *[master]* branch of *meta-xilinx* > >>>>> > >>>>> > >>>>> $ ls -l meta-xilinx/meta-microblaze/recipes-core/newlib/ > >>>>> total 16 > >>>>> drwxrwxr-x 2 scott scott 4096 Aug 15 19:13 files > >>>>> -rw-rw-r-- 1 scott scott 229 Aug 15 19:13 > libgloss_3.3.%.bbappend > >>>>> -rw-rw-r-- 1 scott scott 965 Aug 15 19:13 microblaze-newlib.inc > >>>>> -rw-rw-r-- 1 scott scott 230 Aug 15 19:13 newlib_3.3.%.bbappend > >>>>> > >>>>> >From *[master]* branch of *Poky* > >>>>> > >>>>> > >>>>> ~/poky-master$ ls -l meta/recipes-core/newlib/ > >>>>> total 16 > >>>>> drwxrwxr-x 2 scott scott 4096 Feb 1 2020 libgloss > >>>>> -rw-rw-r-- 1 scott scott 858 Jun 5 16:12 libgloss_3.3.0.bb > <http://libgloss_3.3.0.bb> > >>>>> -rw-rw-r-- 1 scott scott 571 Jun 5 16:12 newlib_3.3.0.bb > <http://newlib_3.3.0.bb> > >>>>> -rw-rw-r-- 1 scott scott 1942 Jun 5 16:12 newlib.inc > >>>>> > >>>>> > >>>>> So is Xilinx even working on a *[dunfell]* branch or are they just > skipping over > >>>>> this release? > >>>> No we are NOT working on dunfell, nor do we have plans to do so. > >>>> > >>>> If someone else wants to backport master work to Dunfell and handle > help > >>>> requests, we are more then happy to work with you and facilitate > this. > But we > >>>> simply don't have the resources to do this ourselves. In future > releases, we > >>>> hope to enable it, but we started doing this work AFTER Dunfell was > already > >>>> obsolete (from a development perspective). > >>>> > >>>> --Mark > >>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > > > > -- > Best Regards > Peter
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4853): https://lists.yoctoproject.org/g/meta-xilinx/message/4853 Mute This Topic: https://lists.yoctoproject.org/mt/77383753/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
