[meta-xilinx] [PATCH 5/7] Update recipes for Xilinx v2017.3 release

[Nathan Rossi]

On 13 October 2017 at 03:59, Manjukumar Harthikote Matha
<MANJUKUM at xilinx.com> wrote:
>
>
>> -----Original Message-----
>> From: Nathan Rossi [mailto:nathan at nathanrossi.com]
>> Sent: Tuesday, October 10, 2017 11:51 PM
>> To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>
>> Cc: Alistair Francis <alistair23 at gmail.com>; meta-xilinx at yoctoproject.org
>> Subject: Re: [meta-xilinx] [PATCH 5/7] Update recipes for Xilinx v2017.3 release
>>
>> On 11 October 2017 at 09:05, Manjukumar Harthikote Matha
>> <MANJUKUM at xilinx.com> wrote:
>> > Hi Nathan,
>> >
>> >> -----Original Message-----
>> >> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
>> >> bounces at yoctoproject.org] On Behalf Of Alistair Francis
>> >> Sent: Tuesday, October 10, 2017 3:13 PM
>> >> To: Nathan Rossi <nathan at nathanrossi.com>
>> >> Cc: meta-xilinx at yoctoproject.org
>> >> Subject: Re: [meta-xilinx] [PATCH 5/7] Update recipes for Xilinx
>> >> v2017.3 release
>> >>
>> >> On Sat, Oct 7, 2017 at 2:57 AM, Nathan Rossi <nathan at nathanrossi.com> wrote:
>> >> > Update the arm-trusted-firmware, pmu-firmware, u-boot-xlnx,
>> >> > linux-xlnx, qemu-xilinx and qemu-devicetrees recipes for to the 'xilinx-v2017.3'
>> >> > release tags.
>> >> >
>> >> > Drop/update existing patches where applicable.
>> >> >
>> >> > Signed-off-by: Nathan Rossi <nathan at nathanrossi.com>
>> >>
>> >> Reviewed-by: Alistair Francis <alistair.francis at xilinx.com>
>> >>
>> >> Thanks,
>> >> Alistair
>> >>
>> >> > ---
>> >
>> > <.....>
>> >
>> >> > diff --git
>> >> > a/recipes-bsp/u-boot/u-boot-xlnx/v2017.1/arm-zynqmp-xilinx_zynqmp.h
>> >> > -Au
>> >> > to-boot-in-JTAG-if-imag.patch
>> >> > b/recipes-bsp/u-boot/u-boot-xlnx/v2017.3/arm-zynqmp-xilinx_zynqmp.h
>> >> > -Au
>> >> > to-boot-in-JTAG-if-imag.patch
>> >> > similarity index 100%
>> >> > rename from
>> >> > recipes-bsp/u-boot/u-boot-xlnx/v2017.1/arm-zynqmp-xilinx_zynqmp.h-A
>> >> > uto -boot-in-JTAG-if-imag.patch rename to
>> >> > recipes-bsp/u-boot/u-boot-xlnx/v2017.3/arm-zynqmp-xilinx_zynqmp.h-A
>> >> > uto -boot-in-JTAG-if-imag.patch diff --git
>> >
>> > meta-xilinx should not be a holding ground for non upstreamable patches.
>> > Implementation has to be from kernel-fitimage.bbclass inclusion.
>> > Please don't add this in meta-xilinx
>> >
>>
>> This is not adding it, just moving the existing patch to apply to the newer u-boot
>> recipe.
>>
>
> Agreed, we are porting a non-upstreamable patch regardless.
>> It does however need to go though.
>
> I completely disagree, it's not an option to proceed. I cannot accept this path.

I'm not sure what you mean exactly, there are a few non-upstreamable
patches in meta-xilinx. Some of them were contributed by you.

This patch even though it is primarily just a BSP/runqemu config patch
is also an outlier in that it has an implementation that was generic
enough to be considered for upstream inclusion.

If it is just a case of having the Upstream-Status field updated to
represent this from Denied to "Inappropriate [runqemu bsp config]", I
can update the patch.

>
> But I have not had a chance to sort that out yet,
>> the biggest problem with using fit is that it would need to embed the rootfs (which is
>> passed at runqemu time). Which  means that using a disk interface is a better way to
>> go, but since qemu boots u-boot instead of a kernel directly it is not so straight
>> forward to pass the root= param to the kernel.
>>
>
> We could also look into kernel-fitimage.bbclass to introduce the fit to resolve.

For reference simply changing to fitimage only moves the goal post,
since a patch would still need to be made to u-boot, and there is no
guarantee that it would be accepted upstream.

I had been looking at setting it up so that for zcu102 runqemu boots
from a full disk image, which was essentially the same as a image that
would be booted on the board itself. This would avoid any qemu/runqemu
specific changes and would help validate board boot flows with
runqemu. However I have not looked into the details, so there might be
issues with that approach too.

Regards,
Nathan