> -----Original Message----- > From: Nathan Rossi [mailto:nat...@nathanrossi.com] > Sent: Thursday, May 04, 2017 7:30 AM > To: Manjukumar Harthikote Matha <manju...@xilinx.com> > Cc: Philip Balister <phi...@balister.org>; meta-xil...@lists.yoctoproject.org > Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to > u-boot for > Zynq > > On 2 May 2017 at 07:52, Manjukumar Harthikote Matha > <manjukumar.harthikote-ma...@xilinx.com> wrote: > > > > > >> -----Original Message----- > >> From: Nathan Rossi [mailto:nat...@nathanrossi.com] > >> Sent: Thursday, April 27, 2017 9:44 AM > >> To: Manjukumar Harthikote Matha <manju...@xilinx.com> > >> Cc: Philip Balister <phi...@balister.org>; > >> meta-xil...@lists.yoctoproject.org > >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to > >> u-boot > for > >> Zynq > >> > >> On 28 April 2017 at 01:36, Manjukumar Harthikote Matha > <manjukumar.harthikote- > >> ma...@xilinx.com> wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Nathan Rossi [mailto:nat...@nathanrossi.com] > >> >> Sent: Thursday, April 27, 2017 7:11 AM > >> >> To: Manjukumar Harthikote Matha <manju...@xilinx.com> > >> >> Cc: Philip Balister <phi...@balister.org>; > >> >> meta-xil...@lists.yoctoproject.org > >> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: > >> >> Default to u-boot for Zynq > >> >> > >> >> On 27 April 2017 at 08:21, Manjukumar Harthikote Matha > >> >> <manjukumar.harthikote-ma...@xilinx.com> wrote: > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Philip Balister [mailto:phi...@balister.org] > >> >> >> Sent: Wednesday, April 26, 2017 12:38 PM > >> >> >> To: Manjukumar Harthikote Matha <manju...@xilinx.com>; Nathan > >> >> >> Rossi <nat...@nathanrossi.com> > >> >> >> Cc: meta-xil...@lists.yoctoproject.org > >> >> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: > >> >> >> Default to u-boot > >> >> for > >> >> >> Zynq > >> >> >> > >> >> >> On 04/26/2017 03:06 PM, Manjukumar Harthikote Matha wrote: > >> >> >> > > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: Nathan Rossi [mailto:nat...@nathanrossi.com] > >> >> >> >> Sent: Wednesday, April 26, 2017 10:54 AM > >> >> >> >> To: Manjukumar Harthikote Matha <manju...@xilinx.com> > >> >> >> >> Cc: meta-xil...@lists.yoctoproject.org > >> >> >> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: > >> >> >> >> Default to u-boot for Zynq > >> >> >> >> > >> >> >> >> On 27 April 2017 at 02:41, Manjukumar Harthikote Matha > >> >> >> >> <manjukumar.harthikote- ma...@xilinx.com> wrote: > >> >> >> >>> > >> >> >> >>> > >> >> >> >>>> -----Original Message----- > >> >> >> >>>> From: meta-xilinx-boun...@yoctoproject.org > >> >> >> >>>> [mailto:meta-xilinx- boun...@yoctoproject.org] On Behalf Of > >> >> >> >>>> Nathan Rossi > >> >> >> >>>> Sent: Wednesday, April 26, 2017 4:57 AM > >> >> >> >>>> To: meta-xil...@lists.yoctoproject.org > >> >> >> >>>> Subject: [meta-xilinx] [PATCH] machine-xilinx-default.inc: > >> >> >> >>>> Default to u-boot for Zynq > >> >> >> >>>> > >> >> >> >>>> Upstream U-Boot provides an almost complete environment for > >> >> >> >>>> the majority of Zynq targets and specifically covers all the > >> >> >> >>>> boot functionality required for the boards in the meta-xilinx > >> >> >> >>>> layer. As such default to > >> >> >> >> the mainline version of U-Boot. > >> >> >> >>>> > >> >> >> >>>> For users that require or prefer to use u-boot-xlnx this can > >> >> >> >>>> be selected on a per- machine basis using: > >> >> >> >>>> > >> >> >> >>>> PREFERRED_PROVIDER_virtual/bootloader = "u-boot-xlnx" > >> >> >> >>>> > >> >> >> >>>> Signed-off-by: Nathan Rossi <nat...@nathanrossi.com> > >> >> >> >>>> --- > >> >> >> >>>> conf/machine/include/machine-xilinx-default.inc | 1 + > >> >> >> >>>> 1 file changed, 1 insertion(+) > >> >> >> >>>> > >> >> >> >>>> diff --git a/conf/machine/include/machine-xilinx-default.inc > >> >> >> >>>> b/conf/machine/include/machine-xilinx-default.inc > >> >> >> >>>> index 13e4df5746..f9e7e3a33f 100644 > >> >> >> >>>> --- a/conf/machine/include/machine-xilinx-default.inc > >> >> >> >>>> +++ b/conf/machine/include/machine-xilinx-default.inc > >> >> >> >>>> @@ -19,6 +19,7 @@ PREFERRED_VERSION_linux-xlnx ?= > >> >> >> >>>> "4.6-xilinx- > >> >> v2016.4%" > >> >> >> >>>> > >> >> >> >>>> # U-Boot Configuration > >> >> >> >>>> XILINX_DEFAULT_UBOOT := "u-boot-xlnx" > >> >> >> >>>> +XILINX_DEFAULT_UBOOT_zynq := "u-boot" > >> >> >> >>>> XILINX_DEFAULT_UBOOT_zynqmp := "u-boot" > >> >> >> >>> > >> >> >> >>> Why have any preferred_provider? Distro can provide these > >> >> >> >>> settings. > >> >> >> >>> For ex: meta-petalinux can provide u-boot-xlnx, oe-core can > >> >> >> >>> provide u-boot > >> >> >> >>> > >> >> >> >>> Any thoughts? > >> >> >> >> > >> >> >> >> Unfortunately not picking a provider for "virtual/bootloader" > >> >> >> >> will result in bitbake attempting to build all providers (since > >> >> >> >> EXTRA_IMAGEDEPENDS is depending on virtual/bootloader), as > >> >> >> >> bitbake has no idea which one is desired (and they are all > >> >> >> >> compatible). > >> >> >> >> > >> >> >> >> -- > >> >> >> >> NOTE: multiple providers are available for virtual/bootloader > >> >> >> >> (u-boot-xlnx, u-boot- xlnx-dev, u-boot) > >> >> >> >> NOTE: consider defining a PREFERRED_PROVIDER entry to match > >> >> >> >> virtual/bootloader ... > >> >> >> >> ERROR: Multiple .bb files are due to be built which each > >> >> >> >> provide virtual/bootloader ... > >> >> >> >> <various failures due to overlapping files/etc.> > >> >> >> >> -- > >> >> >> >> > >> >> >> >> Also note, meta-petalinux or other layers should already be > >> >> >> >> able to override this default (by setting with ??=) either in a > >> >> >> >> distro conf or in a machine conf e.g. zynq- generic (for > >> >> >> >> meta-petalinux). > >> >> >> >> > >> >> >> > If this is the case then why meta-xilinx should peg to upstream > >> >> >> > u-boot by > >> >> default? > >> >> >> It should peg to u-boot-xlnx or linux-xlnx by default. We know > >> >> >> that there are patches/drivers which are not upstreamed yet, and > >> >> >> only available in Xilinx specific tree. This layer is specific to > >> >> >> Xilinx updates and should stick to defaults supported > >> >> by > >> >> >> Xilinx. Other distros or layer stack which use meta-xilinx should > >> >> >> override > >> >> depending > >> >> >> on their requirements not the other way round. > >> >> > >> >> It should be noted that Xilinx does work with upstream U-Boot, since > >> >> Xilinx has an active maintainer (and active contributors). I would > >> >> call that support, but that is open to your own interpretation. > >> >> > >> >> >> > PREFERRED_PROVIDER_virtual/bootloader = "u-boot" should be > >> >> >> > specific to > >> >> boards > >> >> >> other than the Xilinx eval boards, for example in zybo/microzed. > >> >> >> > >> >> >> I'd be happiest if meta-xilinx used upstream u-boot and a bbappend > >> >> >> to add > >> >> patches > >> >> >> that are not upstream yet. This way we (the consumers) know > >> >> >> exactly what the > >> >> delta > >> >> >> is to upstream. > >> >> >> > >> >> > Yes agreed on the methodology, that it would be the best if we > >> >> > maintained > >> >> patchset on top upstream master for u-boot or kernel. > >> >> > But currently we don't have this model, and pinning down > >> >> > meta-xilinx to upstream > >> >> u-boot by default and not fetching Xilinx specific trees is not the > >> >> right answer > as > >> well. > >> >> > meta-xilinx should ideally point to Xilinx trees, we have an option > >> >> > either via distro > >> >> or local.conf to change it to upstream at any given point. > >> >> > We also can point certain evaluation boards (zybo/microzed/picozed > >> >> > etc) to > >> >> upstream u-boot or kernel. > >> >> > > >> >> >> In this day and age, using non-mainline u-boot and kernel leads to > >> >> >> future > pain. > >> >> (Yes, I > >> >> >> have some old pain from using linux-xlnx) > >> >> > I agree, but certain drivers are not up-streamed and we are doing > >> >> > our best to get > >> >> them up-streamed. > >> >> > >> >> So the reason I have posted this patch for discussion is for this > >> >> exact reason. Since u-boot v2017.01 (mainline), the majority of > >> >> features and drivers are upstream (for zynq). > >> >> > >> >> The delta between xilinx/master > >> >> (92e3dd638b50ad22dd90072673c80d8730903e95) and u-boot v2017.01 > (which > >> >> is the version in oe-core, as well as the base of the current > >> >> xilinx/master) is very small for zynq. > >> >> > >> >> Looking at the differences, ignoring the obvious zynqmp/microblaze > >> >> changes there are only a few features that are available in > >> >> u-boot-xlnx that are not in mainline: > >> >> * partial bitstream loading support > >> >> * secure/encrypted bitstream loading support > >> >> * support for rsa verification of images > >> >> * board configs/devicetrees for various Xilinx internal boards > >> >> > >> >> Given that these features have very specific requirements, and that > >> >> they rely on external Xilinx tools and software it is very unlikely > >> >> that users are interested in these features by default when using > >> >> meta-xilinx. > >> > > >> > This is totally debatable correct? > >> > >> Yes, that is the point of this discussion. > >> > >> Remember this patch is about changing the default for the machines in meta- > xilinx. > >> However if someone uses meta-xilinx and creates a custom machine the > >> features > >> might be desired, however in this case that machine (or distro) can set to > >> use u- > boot- > >> xlnx. > >> > > I believe using meta-xilinx with custom machine/evaluation boards is common > practice now, specially give that PetaLinux tools have adopted to Yocto flow. > Hence > the requirement to peg to u-boot-xlnx not mainline u-boot. If the features > are not > desired and not required for any reason then the switch should happen at > local.conf > or distro or machine settings to mainline. The point of having defaults to > vendor tree > or patchset can be done only with vendor specific meta-layers, a standard > practice > across border in Yocto > > So you would be agreeable with the individual machines in meta-xilinx > using mainline by default? Yes that’s good with me.
Your issue is just with the common include > selecting the default u-boot provider as mainline? > The default providers should be Xilinx trees in meta-xilinx > If so, other than zc706 and zc702 would the other Zynq boards in your > opinion be ok to be defaulted to mainline? > I can agree with it, the boards other than Xilinx evaluation boards can point to mainline. I hope they get validated by the community. > > > >> > When a feature is introduced there must have been a requirement from some > set > >> of customers for it be implemented. > >> > >> Maybe, though that may not necessarily be the case. Also that does not > >> mean it > was > >> because all users wanted/needed said feature. > > This is again your take of how things might be used. As this layer is > > specific to Xilinx > and support for its hardware, related drivers, .. we should peg to Xilinx > specific trees. > > > >>Is the logic that because these > >> features exist it means that meta-xilinx machines should be using the > >> vendor tree > >> despite not needing/using them? > >> Essentially throwing away all the benefits of using the mainline source > >> for no > >> reason? > > The whole point of using meta-xilinx layer is to enable the customers/users > > with > drivers which are not upstreamed yet. "Mainline benefits" can be enabled by > local.conf, that’s the beauty of Yocto isn’t it? > > That is not the "whole point" of the meta-xilinx layer, by I digress > and that is not the purpose of this threads discussion. > > > > >> > >> > > >> > The fact that the delta is almost gone for Zynq suggests > >> >> that Xilinx has almost achieved that goal of fully upstreaming Zynq > >> >> support. > >> >> > >> >> In my opinion at least, I think that the benefits of using mainline > >> >> u-boot now greatly out weigh the benefits of u-boot-xlnx. As such I > >> >> think now is the best time to make this switch. > >> >> > >> > > >> > I disagree, meta-xilinx should not switch to mainline till delta is > >> > completely zero. > >> > >> It would be great if you could provide some more information as to why you > >> disagree, it seems there is something I am missing? > >> > >> Whilst it will be great to see zynq support reach a zero delta with > >> upstream, that > >> might take years due to bug fixes and development for zynq still occurring > >> on u- > >> boot-xlnx before upstream. And that is ignoring the delta due to > zynqmp/microblaze > >> and driver overlap. Also it can be argued that Xilinx might not have the > >> incentive > to > >> get to a almost zero delta since not enough users/customers are using > >> mainline, > of > >> which making this change could help provide a nudge for completing it. > >> > > The efforts of upstreaming and work is always planned so that every driver > > is up > streamed, and we are doing our best effort to get this done ASAP. > > So to make your position clearer, what you are saying is that you > would accept that when the features mention in this thread (or any > other features missed that are specifically related to Zynq) which are > not yet mainline get merged to mainline you would consider this 'zero > delta' for Zynq? > Yes I would consider it zero delta when everything is upstreamed by Xilinx. Thanks Manju > Thanks, > Nathan This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
