[meta-xilinx] confused about linux-zynqmp-mainline_3.19.bb

[Nathan Rossi]

> -----Original Message-----
> From: Robert P. J. Day [mailto:rpjday at crashcourse.ca]
> Sent: Thursday, 5 March 2015 5:50 PM
> To: Nathan Rossi
> Cc: meta-xilinx at yoctoproject.org
> Subject: RE: [meta-xilinx] confused about linux-zynqmp-mainline_3.19.bb
> 
> On Thu, 5 Mar 2015, Nathan Rossi wrote:
> 
> > > -----Original Message-----
> > > From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
> > > bounces at yoctoproject.org] On Behalf Of Robert P. J. Day
> > > Sent: Thursday, 5 March 2015 5:21 AM
> > > To: meta-xilinx at yoctoproject.org
> > > Subject: [meta-xilinx] confused about linux-zynqmp-mainline_3.19.bb
> 
>   ... snip ...
> 
> > >   however, immediately next, we have:
> > >
> > > include linux-xlnx.inc
> > >
> > > which then overrides some values, and sets SRC_URI to xilinx's github
> > > repo:
> > >
> > > # Sources
> > > KBRANCH ?= "master"
> > > FILESEXTRAPATHS_prepend := "${THISDIR}/linux-xlnx:"
> > > SRC_URI = " \
> > >
> > > git://github.com/Xilinx/linux-
> xlnx.git;protocol=https;branch=${KBRANCH} \
> > >                 file://xilinx-base;type=kmeta;destsuffix=xilinx-base \
> > >                 "
> > >
> > > but, weirdly, once that file is included, things pick up again back in
> > > linux-zynqmp-mainline_3.19.bb, which reassigns SRC_URI:
> > >
> > > FILESEXTRAPATHS_prepend := "${THISDIR}/linux-zynqmp-mainline:"
> > > SRC_URI = " \
> > >
> > >
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=
> > > https;branch=${KBRANCH} \
> > > ... snip ...
> > >
> > >   this is just confusing ... is there a reason it's being done this
> > > way?
> >
> > Quickness of getting it going. I put together the recipes for these
> > components relatively quickly, as I knew they would be short lived
> > recipes and serve mainly as a day one release sort of thing. All of
> > the patches are intended on going upstream, and once that has been
> > achieved the goal is to remove these "zynqmp-mainline" recipes as
> > oe-core/linux-yocto picks up the newer releases.
> >
> > For this specific case it was easiest to just use the linux-xlnx
> > recipe include, and override the source uri and srcrev. So that the
> > build flow matched that of the linux-xlnx kernels. There are some
> > undesirable changes that come from including it, but nothing that is
> > particularly important from a functional build use case.
> 
>   not sure if you caught my question on the YP mailing list, but i was
> asking about the above very usage of "type=kmeta" as part of the
> SRC_URI in linux-xlnx.inc, and wondering why you did it this way (if
> this was just the "getting it working and out the door" thing, that's
> fine).
> 
>   but i'm curious as to whether you made a conscious decision to use
> that feature, as bruce ashfield suggested that that's not a normal
> developer feature, but i'd definitely be interested in whether you
> picked that technique specifically for what you were doing, or whether
> that's just a quick stopgap until, as you say, all this stuff is
> upstreamed.

I saw that thread.

So it was a conscious decision. Essentially the idea is to enable the linux-yocto kernel (and also use it in the linux-xlnx kernel for consistency reasons), unfortunately some of the Xilinx drivers are not in mainline yet so there is some churn on configs, adding and removing. But I wanted it to work exactly the same as the linux-yocto config cache so that users would not really notice any major differences when using linux-yocto. So that hopefully in the future if accepted the config fragments can be merged into the linux-yocto tree.

Just to be clear "file://xilinx-base;type=kmeta;destsuffix=xilinx-base" in the zynqmp-mainline recipe is copied from the linux-xlnx.inc src_uri, needed due to how the SRC_URI is set in linux-xlnx.inc.

I actually find this method of adding the config fragments cleaner and easier to use then the manual addition of .scc files to the SRC_URI, it is particularly useful when you are adding more than just one or two .scc/.cfg files. Or if you have a bunch of config fragments and you want to set it up so that KERNEL_FEATURES selects which ones are used. So I imagine it is worth documenting to some degree.

If you are interested in reading the discussion that lead to the meta-xilinx working this way have a look at this archived thread here: https://lists.yoctoproject.org/pipermail/meta-xilinx/2014-June/000684.html.

Regards,
Nathan