On 28 April 2017 at 01:36, Manjukumar Harthikote Matha <[email protected]> wrote: > > >> -----Original Message----- >> From: Nathan Rossi [mailto:[email protected]] >> Sent: Thursday, April 27, 2017 7:11 AM >> To: Manjukumar Harthikote Matha <[email protected]> >> Cc: Philip Balister <[email protected]>; [email protected] >> 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 >> <[email protected]> wrote: >> > >> > >> >> -----Original Message----- >> >> From: Philip Balister [mailto:[email protected]] >> >> Sent: Wednesday, April 26, 2017 12:38 PM >> >> To: Manjukumar Harthikote Matha <[email protected]>; Nathan Rossi >> >> <[email protected]> >> >> Cc: [email protected] >> >> 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:[email protected]] >> >> >> Sent: Wednesday, April 26, 2017 10:54 AM >> >> >> To: Manjukumar Harthikote Matha <[email protected]> >> >> >> Cc: [email protected] >> >> >> 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- [email protected]> wrote: >> >> >>> >> >> >>> >> >> >>>> -----Original Message----- >> >> >>>> From: [email protected] [mailto:meta-xilinx- >> >> >>>> [email protected]] On Behalf Of Nathan Rossi >> >> >>>> Sent: Wednesday, April 26, 2017 4:57 AM >> >> >>>> To: [email protected] >> >> >>>> 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 <[email protected]> >> >> >>>> --- >> >> >>>> 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. > 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. 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 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 option to switch to mainline is available either through distro or > local.conf. Sure, but the same is also true of the reverse. Regards, Nathan -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
