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

Nathan Rossi nathan.rossi at xilinx.com
Tue Jul 8 00:03:01 PDT 2014


> -----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


More information about the meta-xilinx mailing list