[meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to u-boot for Zynq

Nathan Rossi nathan at nathanrossi.com
Thu Apr 27 07:11:28 PDT 2017


On 27 April 2017 at 08:21, Manjukumar Harthikote Matha
<manjukumar.harthikote-matha at xilinx.com> wrote:
>
>
>> -----Original Message-----
>> From: Philip Balister [mailto:philip at balister.org]
>> Sent: Wednesday, April 26, 2017 12:38 PM
>> To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>; Nathan Rossi
>> <nathan at nathanrossi.com>
>> Cc: meta-xilinx at 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:nathan at nathanrossi.com]
>> >> Sent: Wednesday, April 26, 2017 10:54 AM
>> >> To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>
>> >> Cc: meta-xilinx at 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- matha at xilinx.com> wrote:
>> >>>
>> >>>
>> >>>> -----Original Message-----
>> >>>> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
>> >>>> bounces at yoctoproject.org] On Behalf Of Nathan Rossi
>> >>>> Sent: Wednesday, April 26, 2017 4:57 AM
>> >>>> To: meta-xilinx at 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 <nathan at 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. 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.

Regards,
Nathan



More information about the meta-xilinx mailing list