[meta-xilinx] linux-xlnx: Config Fragments and Device Trees

Sun Sep 28 23:01:41 PDT 2014

> -----Original Message-----
> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
> bounces at yoctoproject.org] On Behalf Of Nathan Rossi
> Sent: Tuesday, July 08, 2014 5:03 PM
> To: meta-xilinx Mailing List (meta-xilinx at yoctoproject.org)
> Subject: Re: [meta-xilinx] linux-xlnx: Config Fragments and Device Trees
> 
> > -----Original Message-----
> > From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
> > Sent: Tuesday, June 17, 2014 5:20 AM
> > To: Nathan Rossi
> > Cc: meta-xilinx Mailing List (meta-xilinx at yoctoproject.org); Philip
> > Balister
> > Subject: Re: linux-xlnx: Config Fragments and Device Trees
> >
> > On Mon, Jun 16, 2014 at 3:02 AM, Nathan Rossi <nathan.rossi at xilinx.com>
> > wrote:
> > >> -----Original Message-----
> > >> From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
> > >> Sent: Friday, June 13, 2014 12:04 AM
> > >> To: Nathan Rossi
> > >> Cc: meta-xilinx Mailing List (meta-xilinx at yoctoproject.org); Philip
> > >> Balister
> > >> Subject: Re: linux-xlnx: Config Fragments and Device Trees
> > >>
> > >> Hi Nathan,
> > >>
> > >> Also let me start by saying .. that I wasn't looking to cause any
> > >> controversy or
> > >> trouble on your end .. just looking to see if I can help drive
> > consistency
> > >> where
> > >> possible. I'm fully aware that nothing is perfect, and we can change
> > >> things
> > >> were required .. or completely change our minds if we run into
> > >> something horrible!
> > >
> > > Don't worry no controversy was caused, I had intended to bring this
> > topic up sooner or later :).
> > >
> > >>
> > >> ok .. onto the technical part.
> > >>
> > >> On Thu, Jun 12, 2014 at 2:42 AM, Nathan Rossi
> <nathan.rossi at xilinx.com>
> > >> wrote:
> > >> > Hi All,
> > >> >
> > >> > So I decided to split off this thread from the one being discussed.
> > >> >
> > >> > Firstly to answer Bruce's question regarding why linux-xlnx does
> not
> > use
> > >> the linux-yocto.inc. This was primarily because at the time the
> linux-
> > >> yocto kernel had removed support for external device trees in the
> > kernel,
> > >> this presented issues in recipe and so we decided to step away from
> the
> > >> linux-yocto include and just have the small linux-dtb.inc in our
> layer
> > do
> > >> the device tree work. This was prior to having the config fragment
> > stuff
> > >> that we now have, which evolved from having microblaze systems use a
> > small
> > >> fragment to add to the defconfig. This then evolved into the now
> > relative
> > >> duplication of functionality. So there is no opposition to the use
> the
> > of
> > >> the linux-yocto/yocto-kernel-tools specifically.
> > >>
> > >> Sounds good on this point.
> > >>
> > >> We could consider restoring the external tree device tree support. I
> > know
> > >> that
> > >> I've leveraged it in the past, but working with largely integrated
> > >> device trees over
> > >> the past year to year and a half, I haven't run into any significant
> > pain.
> > >
> > > So restoring the external device tree support would probably be
> > beneficial, especially if you are able to apply the kernel device tree
> > build flow (which differs to just dtc). This might be a matter of using
> > the KERNEL_DEVICETREE to look in both the ${WORKDIR} and the
> > ${S}/arch/arm/...
> > >
> > > The in kernel device tree building has some requirements around
> > location/path of dts. And there are some details around dtsi's and the
> > include path requirements. Which is why we decided to go back to
> straight
> > dtc.
> >
> > Agreed. I do think the flexibility to do both is needed, the out of tree
> > usecase
> > simply wasn't front and centre when the modifications happened.
> >
> > What do you think about capturing the use case and build requirements in
> > the Yocto bugzilla ? That way we can work on it for 1.7 and not forget
> > details.
> >
> > >
> > >>
> > >> And just so I'm clear, are you talking about the oe-core change that
> > >> switched
> > >> to using the kernel's build system to generate dtb's, or some other
> > >> changes.
> > >> I just want to make sure I'm looking at the right thing.
> > >
> > > Yes, the oe-core change is the change I was referring to, specifically
> > this commit: http://git.openembedded.org/openembedded-
> > core/commit/?id=72980d5bb465f0640ed451d1ebb9c5d2a210ad0c
> >
> > Good. That's the one that I thought it was. Thanks for confirming.
> >
> > >
> > >>
> > >>
> > >> >
> > >> > Zynq support in the mainline kernel has come a long way, and the
> > linux-
> > >> yocto 3.14 kernel has a decent amount of the Zynq PS support. And
> > >> hopefully this will continue to improve and eventually the need for
> the
> > >> linux-xlnx kernel will diminish so that people can rely on the
> mainline
> > >> kernel for Zynq and MicroBlaze. Which will hopefully get people to
> use
> > the
> > >> linux-yocto kernel with meta-xilinx/Yocto.
> > >> >
> > >>
> > >> This would also be a great thing, and my congrats and thanks for the
> > hard
> > >> working pushing changes upstream.
> > >>
> > >> I'll add a minor point here, that we can do a hybrid that uses the
> > common
> > >> build steps/infrastructure and not jump all the way to the full
> linux-
> > >> yocto
> > >> tree. That could be an intermediate step, or a semi-permanent one ..
> > time
> > >> would tell the story.
> > >>
> > >> >
> > >> >
> > >> > Now for the main discussion topic. There are 3 main things to talk
> > about
> > >> here, starting with device trees. Currently linux-yocto does not
> > support
> > >> out of the kernel device trees (it was dropped), for the majority of
> > >> Xilinx BSPs putting the device tree in the kernel is not the easiest
> or
> > >> best way to handle the device tree building. Currently we rely on the
> > >> linux-dtb.inc recipe steps to do this job, but it still ties the
> device
> > >> tree to the kernel. There are some annoyances with tying the device
> > tree
> > >> to the kernel recipe, notably that in order to rebuild the device
> tree
> > the
> > >> kernel needs to redo a number of recipe steps which are time
> consuming.
> > >> >
> > >> > The idea I have here is to move the building of the device tree's
> > into a
> > >> separate bsp recipe, keeping in mind that the device trees we build
> (in
> > >> meta-xilinx) are kernel independent (and the intention is to keep it
> > that
> > >> way, at least for the kernels compatible in the meta-xilinx layer).
> The
> > >> recipe would also be responsible for deploying the device tree into
> the
> > >> images directory.
> > >> >
> > >> > Please let me know what you think about this idea.
> > >>
> > >> This sounds reasonable to me, as does trying to come up with a way to
> > >> restore flexibility in building the trees not using the kernel's
> build
> > >> system.
> > >>
> > >> Being able to re-build the dtb's quickly, without needing to depend
> on
> > the
> > >> kernel is a valid development workflow .. and a real timesaver if
> just
> > >> updating
> > >> a dts :)
> > >>
> > >> >
> > >> >
> > >> >
> > >> > The second topic is kernel configs, I think is has been made clear
> > that
> > >> the hacked solution we have in the linux-xlnx recipe needs to be
> fixed.
> > >> And it seems a majority of you would prefer to see it use the
> > >> functionality used in the linux-yocto recipes (I would also like to
> see
> > it
> > >> done this way). There are some questions around that though,
> > specifically
> > >> in regards to how we manage and control the fragments that are used
> to
> > >> configure the Zynq and MicroBlaze specific portions of the kconfig.
> > >> >
> > >> > Is it possible to maintain these in the layer itself? Or is it
> > required
> > >> that they become part of the kernel-cache/meta branch stuff in order
> to
> > be
> > >> used? The idea here would be to have the Zynq and MicroBlaze specific
> > >> fragments and kmachine definitions in the meta-xilinx layer (e.g. in
> > >> recipes-kernel/linux/files/* or something), and then depend on the
> rest
> > of
> > >> the standard linux-yocto kernel-cache for the rest of the
> > configuration.
> > >> This would save us the effort of maintaining a full duplicate of the
> > >> kernel-cache and also give us the freedom to modify it without
> needing
> > to
> > >> submit it to the linux-yocto kernel-cache directly.
> > >> >
> > >>
> > >> You can maintain and manage your fragments in your layer, including
> > >> machine
> > >> definitions, features, etc. So the flexibility is there to have your
> > >> own layer to
> > >> re-use, extend, override or clobber the built in ones.
> > >>
> > >> If there's value in factoring options into common fragments, they can
> > be
> > >> looked at and merged as time permits.
> > >
> > > Sounds good, I will have to play around with this and see what we can
> > come up with.
> > >
> > > In regards to 'KERNEL_FEATURES', this is the expected way of adding
> > configs fragments on a per machine basis?
> > > Or is it preferred to use KERNEL_FEATURES within the kernel recipe
> > itself?
> >
> > The use case varies. Distro features, machine features and other global
> > features
> > can trigger a new KERNEL_FEATURE. I'm not an expert at sstate and the
> > dependencies
> > that get triggered, but by using a KERNEL_FEATURE you are doing a
> > machine specific
> > thing, so anything that uses the variable also becomes machine specific.
> >
> > Bruce
> >
> > >
> > >>
> > >> >
> > >> >
> > >> > The last topic is the MACHINE_DEVICETREE and MACHINE_KCONFIG
> > variables
> > >> that we have in the linux-xlnx includes, and additionally the
> > >> conf/machine/boards/* sub directory structure.
> > >> >
> > >> > Firstly the sub directory structure can easily be disseminated into
> > the
> > >> 3 recipe components, kernel, device tree and u-boot. And with the
> > device
> > >> tree recipe idea I mentioned above, this would be much easier for
> > adding
> > >> boards and similar in effort to support boards across kernels.
> > >> >
> > >> > The other question is whether people use the MACHINE_DEVICETREE and
> > >> MACHINE_KCONFIG variables, and whether or not they should be removed?
> > >>
> > >> I'll see if anyone else has a strong opinion here, but I'll throw a
> > >> random comment in ..
> > >> we could likely have a class or python snippet that maps these to use
> > >> new techniques
> > >> under the covers. It would provide a migration path that was
> > >> transparent to existing
> > >> users.
> > >>
> > >> That being said, I'm only now just looking at how you are currently
> > >> using them, so I
> > >> may be completely off base :)
> > >>
> > >> Cheers,
> > >>
> > >> Bruce
> > >>
> > >> >
> > >> > Regards,
> > >> > Nathan
> > >>
> > >>
> > >>
> > >> --
> > >> "Thou shalt not follow the NULL pointer, for chaos and madness await
> > >> thee at its end"
> > >
> > > Regards,
> > > Nathan
> >
> >
> >
> > --
> > "Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end"
> 
> Hi all,
> 
> So an update on this config fragment stuff using linux-yocto cache and the
> device-tree recipe.
> 
> I have thrown together some of it, and wanted to get some feedback. I have
> pushed some commits to the nrossi/kconfig-fragment branch on my github.
> See: https://github.com/nathanrossi/meta-xilinx/tree/nrossi/kconfig-
> fragments.
> 
> Currently I have only got the config fragments for Zynq going (3.14 kernel
> specific), and have the kernel recipes only going for the linux-yocto_3.14
> kernel. The device-tree recipe should work for all machines though.
> 
> Thanks,
> Nathan
> --
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx

Just pinging this one, was hoping to get some feedback.

The 1.7 BSP window is coming around so it would be a good time to do some of these changes for 1.7.

Regards,
Nathan