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

[Philip Balister]

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

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)

Philip


> 
> Thanks
> Manju
> 
> 
>> Regards,
>> 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.
>