Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 04/14] libmali-xlnx.bb: ABIs are made consistent for all backends

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Jean-Francois Dagenais
> Sent: Monday, November 18, 2019 6:07 PM
> To: Chandana Kalluri 
> Cc: Madhurkiran Harikrishnan ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 04/14] libmali-xlnx.bb: 
> ABIs
> are made consistent for all backends
> 
> 
> 
> > On Nov 15, 2019, at 22:00, Sai Hari Chandana Kalluri
>  wrote:
> >
> > From: Madhurkiran Harikrishnan 
> >
> > Application binary interface are made consistent for all backends. GBM
> > API support is now available for any libMali monolithic library.
> >
> > Signed-off-by: Madhurkiran Harikrishnan
> > 
> > Signed-off-by: Sai Hari Chandana Kalluri 
> > Signed-off-by: Manjukumar Matha
> > 
> > ---
> > meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> > b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> > index d3c7646..ba0cb6c 100644
> > --- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> > +++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> > @@ -17,7 +17,6 @@ FILESEXTRAPATHS_append := " \ REPO ?=
> > "git://github.com/Xilinx/mali-userspace-binaries.git;protocol=https"
> > BRANCH ?= "rel-v2019.2"
> > SRCREV ?= "90ea8555cddaa7979019fd7eeaeb01a9f1b26ac7"
> > -
> 
> Is it just me or this patch is only removing a blank line (just above this) 
> and thus
> doesn't fit the commit message...
> 

Nope you are correct, some commit squash went incorrect here


> > BRANCHARG = "${@['nobranch=1', 'branch=${BRANCH}'][d.getVar('BRANCH',
> True) != '']}"
> >
> > PV = "r8p0-01rel0"
> > --
> > 2.7.4
> >
> > --
> > ___
> > meta-xilinx mailing list
> > meta-xilinx@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] Add me to the maintainers list

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Sai Hari Chandana Kalluri
> Sent: Monday, November 18, 2019 1:51 PM
> To: meta-xilinx@yoctoproject.org
> Cc: Chandana Kalluri 
> Subject: [meta-xilinx] [PATCH] Add me to the maintainers list
> 
> Signed-off-by: Sai Hari Chandana Kalluri 

Thanks Chandana for helping out

> ---
>  meta-xilinx-bsp/README.md| 1 +
>  meta-xilinx-contrib/README.md| 1 +
>  meta-xilinx-standalone/README.md | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/meta-xilinx-bsp/README.md b/meta-xilinx-bsp/README.md index
> 13ef6b6..ae268f4 100644
> --- a/meta-xilinx-bsp/README.md
> +++ b/meta-xilinx-bsp/README.md
> @@ -47,6 +47,7 @@ the [meta-xilinx mailing
> list](https://lists.yoctoproject.org/listinfo/meta-xili
>  Maintainers:
> 
>   Manjukumar Harthikote Matha  ma...@xilinx.com>
> + Sai Hari Chandana Kalluri 
> 
>  Dependencies
>  
> diff --git a/meta-xilinx-contrib/README.md b/meta-xilinx-contrib/README.md
> index 55c9853..f2629f8 100644
> --- a/meta-xilinx-contrib/README.md
> +++ b/meta-xilinx-contrib/README.md
> @@ -26,6 +26,7 @@ https://lists.yoctoproject.org/listinfo/meta-xilinx
>  Maintainers:
> 
>   Manjukumar Harthikote Matha  ma...@xilinx.com>
> + Sai Hari Chandana Kalluri 
> 
>  Dependencies
>  
> diff --git a/meta-xilinx-standalone/README.md b/meta-xilinx-
> standalone/README.md
> index b800f37..96ddd98 100644
> --- a/meta-xilinx-standalone/README.md
> +++ b/meta-xilinx-standalone/README.md
> @@ -16,6 +16,7 @@ Maintainers:
> 
>   Alejandro Enedino Hernandez Samaniego 
>   Manjukumar Harthikote Matha  ma...@xilinx.com>
> + Sai Hari Chandana Kalluri 
> 
>  Dependencies
>  
> --
> 2.7.4
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] Add me to the maintainers list

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Mark Hatle
> Sent: Monday, November 18, 2019 11:31 AM
> To: meta-xil...@lists.yoctoproject.org
> Subject: [meta-xilinx] [PATCH] Add me to the maintainers list
> 
> From: Mark Hatle 
> 

Thanks Mark

> Signed-off-by: Mark Hatle 
> ---
>  meta-xilinx-bsp/README.md| 1 +
>  meta-xilinx-contrib/README.md| 1 +
>  meta-xilinx-standalone/README.md | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/meta-xilinx-bsp/README.md b/meta-xilinx-bsp/README.md index
> 13ef6b6..d8248c8 100644
> --- a/meta-xilinx-bsp/README.md
> +++ b/meta-xilinx-bsp/README.md
> @@ -47,6 +47,7 @@ the [meta-xilinx mailing
> list](https://lists.yoctoproject.org/listinfo/meta-xili
>  Maintainers:
> 
>   Manjukumar Harthikote Matha  ma...@xilinx.com>
> + Mark Hatle 
> 
>  Dependencies
>  
> diff --git a/meta-xilinx-contrib/README.md b/meta-xilinx-contrib/README.md
> index 55c9853..5fc9493 100644
> --- a/meta-xilinx-contrib/README.md
> +++ b/meta-xilinx-contrib/README.md
> @@ -26,6 +26,7 @@ https://lists.yoctoproject.org/listinfo/meta-xilinx
>  Maintainers:
> 
>   Manjukumar Harthikote Matha  ma...@xilinx.com>
> + Mark Hatle 
> 
>  Dependencies
>  
> diff --git a/meta-xilinx-standalone/README.md b/meta-xilinx-
> standalone/README.md
> index b800f37..46ba24f 100644
> --- a/meta-xilinx-standalone/README.md
> +++ b/meta-xilinx-standalone/README.md
> @@ -16,6 +16,7 @@ Maintainers:
> 
>   Alejandro Enedino Hernandez Samaniego 
>   Manjukumar Harthikote Matha  ma...@xilinx.com>
> + Mark Hatle 
> 
>  Dependencies
>  
> --
> 2.17.1
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Setting HDMI for Zedboard

[Manjukumar Harthikote Matha]

Hi,

AFAIK hdmi is a IP and needs kernel module etc to support it. Please check in 
Xilinx forum on IP design etc.  If you use displayport, it will not need any IP

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
 On Behalf Of Jek F.
Sent: Thursday, November 14, 2019 5:24 AM
To: meta-xil...@lists.yoctoproject.org
Subject: [meta-xilinx] Setting HDMI for Zedboard

Hi everyone,

i'm still a novice and autodidact and i'm tring to set up the Zedboard's hdmi. 
I'm currently using the "thud (2.6.2)" version of poky.

This is what i've done so far:

- I used the Vivado project from here: 
https://github.com/analogdevicesinc/hdl/tree/master/projects/adv7511/zed and 
with SDK i generated the device-tree. I created a layer and i inserted the 
ps7_init_gpl.c/h, the device-tree and the bitstream inside my project.

- This is my bblayer.conf:

BBLAYERS ?= " \
/home/jksandek/poky/meta \
/home/jksandek/poky/meta-poky \
/home/jksandek/poky/meta-yocto-bsp \
/home/jksandek/poky/meta-openembedded/meta-oe \
/home/jksandek/poky/meta-openembedded/meta-python \
/home/jksandek/poky/meta-openembedded/meta-networking \
/home/jksandek/poky/meta-openembedded/meta-multimedia \
/home/jksandek/poky/meta-xilinx/meta-xilinx-bsp \
/home/jksandek/poky/meta-xilinx-tools \
/home/jksandek/poky/meta-petalinux \
"

and this is my local.conf:

MACHINE ??= "zedboard-zynq7"
IMAGE_INSTALL_append = " rsync busybox tmux nano i2c-tools devmem2 python3 
python3-pip dropbear"
LICENSE_FLAGS_WHITELIST += " commercial commercial_faad2 
commercial_gstreamer1.0-plugins-ugly "
ENABLE_I2C = "1"

- At the end i did "bitbake core-image-sato" and compiled without errors, but 
when i start up, the Zedboard cannot find the screen connected to the hdmi.

What should i do?
This is the right mailing list to ask this?

Thanks for your help.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Failed to init entropy source hwrng

[Manjukumar Harthikote Matha]

Hi Arno,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Arno Steffens
> Sent: Wednesday, October 30, 2019 6:48 AM
> To: meta xilinx 
> Subject: [meta-xilinx] Failed to init entropy source hwrng
> 
> Build a rootfs with Yocto 2.5 and 3.0 (Zeus). Got both working, but booting 
> in 3.0
> is terrible slow.
> The reasons seems to be that random numbers are not generated for ssh. I
> found that there is a new startup script:
> /etc/init.d/rng-tools
> that needs around 14s. But if I comment it out, it ssh needs even 86s!
> 
> Please help, what can I do to get same fast timing as in 2.5? I would rather 
> go
> lower security than waiting for 14 seconds.
> I am running a 4.19 vanilla kernel with some xilinx patches. Do I miss one?
> 
> Output in boot-log>:
> ...
> run-parts: /etc/network/if-pre-up.d/nfsroot: exit status 1 Starting random
> number generator daemon Initializing available sources
> 
> Failed to init entropy source hwrng
> 
> Initializing AES buffer
> 
> Enabling JITTER rng support
> 
> Initializing entropy source jitter
> 
> .

We used haveged recipe to overcome this issue


> random: crng init done
> Starting OpenBSD Secure Shell server: sshd
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] merging linux-stable tags into linux-xlnx tracking branch

[Manjukumar Harthikote Matha]

Hi Jean-Francois,


> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Jean-Francois Dagenais
> Sent: Thursday, October 24, 2019 10:16 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] merging linux-stable tags into linux-xlnx tracking 
> branch
> 
> Hi guys,
> 
> We track linux-xlnx master trunk, which tracks linus' main trunk. (i.e. Xilinx
> merges actual linux mainline tags into their master)
> 
> This is great since it allows us to put our work on our master, and then be
> compatible with future linux versions by simple merge of Xilinx's tree. Good 
> job
> Xilinx!
> 
> Now, problem is, when one wants to release in the field, he should apply the
> latest stable fixes to his tree. Otherwise, as Greg insistently points out:
> https://youtu.be/HeeoTE9jLjM?t=1350 "you are running an insecure system."
> 
> Right now, I am on 2019.1 which means kernel 4.19. I went ahead and created a
> mymaster-4.19 which will contain merges of mymaster and stable/linux-4.19.y
> from Greg's tree (as of today: v4.19.80).
> 
> This should work without much conflicts, but of course, I'm not getting a 
> freebie
> today either. I get tons of conflicts which are Xilinx changes which conflict 
> with
> 4.19.y stable fixes.
> 
> Some are trivial, some truely aren't. And then I think, hey, why am I the 
> "first" to
> be doing this... we should all be in this situation right?
> 
> So is there a repo out there, where kind souls have exposed the conflict
> resolution work done?

We also provide a rebase tree, this will help to see what patches we hold 
on-top of a released version from mainline
https://github.com/Xilinx/linux-xlnx/tree/xlnx_rebase_v4.19

The above rebase tree will be easier to use for your work rather than using 
merge tree from linux-xlnx.

Thanks,
Manju

<...>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] kernel-simpleimage.bbclass: Fix do_prep_simpleimage `[[: not found`

[Manjukumar Harthikote Matha]

Hi Michael,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Monaghan, Michael L. (GSFC-5870)
> Sent: Tuesday, July 30, 2019 4:43 PM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] [PATCH] kernel-simpleimage.bbclass: Fix
> do_prep_simpleimage `[[: not found`
> 
> While developing a custom MicroBlaze machine configuration with meta-xilinx-
> bsp, the linux-xlnx recipe would fail when configured to use the
> “simpleImage.devicetree-name” kernel image type.
> 
> Though the do_prep_simpleimage task does not fail, messages were left in the
> log indicating the “[[“ bash extension could not be found.
> 

We haven’t run into this issue.

>   DEBUG: Executing shell function do_prep_simpleimage
>   /yocto/builds/microblaze/tmp/work/kcu102_microblazeel-poky-
> linux/linux-xlnx/4.14-xilinx-v2018.3+gitAUTOINC+eeab73d120-
> r0/temp/run.do_prep_simpleimage.66740: 112:
>   /yocto/builds/microblaze/tmp/work/kcu102_microblazeel-poky-
> linux/linux-xlnx/4.14-xilinx-v2018.3+gitAUTOINC+eeab73d120-
> r0/temp/run.do_prep_simpleimage.66740: [[: not found
>   /yocto/builds/microblaze/tmp/work/kcu102_microblazeel-poky-
> linux/linux-xlnx/4.14-xilinx-v2018.3+gitAUTOINC+eeab73d120-
> r0/temp/run.do_prep_simpleimage.66740: 112:
>   /yocto/builds/microblaze/tmp/work/kcu102_microblazeel-poky-
> linux/linux-xlnx/4.14-xilinx-v2018.3+gitAUTOINC+eeab73d120-
> r0/temp/run.do_prep_simpleimage.66740: [[: not found
>   DEBUG: Shell function do_prep_simpleimage finished
> 
> The two offending lines are in kernel-simpleimage.bbclass. Here's one of them
> for reference.
> 
>   if [[ "${type}" =~ "simpleImage" ]] && [ ${ARCH} = "microblaze" ]; then
> 
> The problem is that “[[“ will return -1 since the extension is not found and 
> the if
> statement will simply interpret the error as false causing the task to 
> continue,
> even if the image type was "simpleImage"!
> 

Bash programming supports "[[", not sure why you are seeing the error

> Testing was done using the official crops/poky docker image. The crops/poky
> system shell was confirmed to include the “[[“ extension however, it appears
> that the extension is disabled within the recipe shell scripts. In addition, 
> "[[" does
> not appear to be used by any openembedded-core recipes so I made this patch
> to convert the two instances of "[[" to "[". The patch was created for master,
> but the problem appears to exist on all branches of meta-xilinx.
> 

I am ok with the patch since it essentially does the same.

> Signed-off-by: Michael Monaghan 
> ---
>  meta-xilinx-bsp/classes/kernel-simpleimage.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta-xilinx-bsp/classes/kernel-simpleimage.bbclass b/meta-xilinx-
> bsp/classes/kernel-simpleimage.bbclass
> index 348d0a7..6da28f3 100644
> --- a/meta-xilinx-bsp/classes/kernel-simpleimage.bbclass
> +++ b/meta-xilinx-bsp/classes/kernel-simpleimage.bbclass
> @@ -13,7 +13,7 @@ do_prep_simpleimage[dirs] += "${B}"
>  do_prep_simpleimage () {
>  install -d ${B}/arch/${ARCH}/boot/dts
>  for type in ${KERNEL_IMAGETYPES} ; do
> -if [[ "${type}" =~ "simpleImage" ]] && [ ${ARCH} = "microblaze" ]; 
> then
> +if [ -z "${type##*simpleImage*}" ] && [ ${ARCH} = "microblaze"
> + ]; then
>  ext="${type##*.}"
>  # Microblaze simpleImage only works with dts file
>  cp ${RECIPE_SYSROOT}/boot/devicetree/${ext}.dts
> ${B}/arch/${ARCH}/boot/dts/ @@ -23,7 +23,7 @@ do_prep_simpleimage () {
> 
>  do_deploy_append () {
>  for type in ${KERNEL_IMAGETYPES} ; do
> -if [[ "${type}" =~ "simpleImage" ]] && [ ${ARCH} = "microblaze" ]; 
> then
> +if [ -z "${type##*simpleImage*}" ] && [ ${ARCH} = "microblaze"
> + ]; then
>  base_name=${imageType}-${KERNEL_IMAGE_NAME}
>  install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.strip
> $deployDir/${base_name}.strip
>  install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.unstrip
> $deployDir/${base_name}.unstrip
> --
> 2.20.1 (Apple Git-117)
> 

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Ultra96 V2 Support

[Manjukumar Harthikote Matha]

Hi Simon,

You should check :
https://github.com/Avnet/Ultra96-PYNQ for how the layers and recipes are done 
for V2 board.



You would need patchset for v2 board or add bbappend in 2018.2/2018.3 release 
to make it work.



Thanks,

Manju


From: meta-xilinx-boun...@yoctoproject.org 
 On Behalf Of Simon Goda
Sent: Wednesday, July 24, 2019 3:55 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Ultra96 V2 Support

We have just received an Ultra96V2 board and need to rebase on this as the V1 
is no longer available.
Is this device supported in meta-xilinx?
Can we just build as for the V1 i.e. MACHINE = "ultra96-zynqmp"?
Do we need to a specific version number (been using v2018.2 thus far)?

Thanks & regards
Simon Goda
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] warrior branch

[Manjukumar Harthikote Matha]

Hi Oleg,

We are little behind on the warrior branch.
See https://github.com/Xilinx/meta-xilinx/commits/master-next this in the 
branch which will be merged to master to cut the warrior branch

We are targeting to get this done by July 17th

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
 On Behalf Of Oleg K Dzhimiev
Sent: Tuesday, July 9, 2019 10:52 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] warrior branch

Hello,

What branch of meta-xilinx is currently compatible with the poky's warrior 
branch? If none what's the schedule?

meta-xilinx, master-next: some layer.confs:
LAYERSERIES_COMPAT_xilinx = "sumo thud"

Thanks

Best regards,
Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783  x124
Elphel, Inc.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-tools][RFC][patch 3/3] xilinx-bootbin: add multiple images support

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: Jean-Francois Dagenais 
> Sent: Tuesday, July 9, 2019 8:45 AM
> To: meta-xilinx@yoctoproject.org; git 
> Cc: Jean-Francois Dagenais 
> Subject: [meta-xilinx-tools][RFC][patch 3/3] xilinx-bootbin: add multiple 
> images
> support
> 
> In certain scenarios, it might be desirable to produce multiple boot.bin 
> files. For
> example, a boot.bin which bundles kernel and dts, and another which loads u-
> boot.
> 
> The default behaviour is kept and the produced image, named boot-default.bin,
> will get the symlink named just "boot.bin".
> 

This is a good patch for generating multiple boot.bin .
I think we needed something like this for fpga-manager flow

> Signed-off-by: Jean-Francois Dagenais 
> ---
>  recipes-bsp/bootbin/xilinx-bootbin_1.0.bb | 78 ++--
> ---
>  1 file changed, 55 insertions(+), 23 deletions(-)
> 
> diff --git a/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb b/recipes-
> bsp/bootbin/xilinx-bootbin_1.0.bb
> index 41e5f1e..f4dca7f 100644
> --- a/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> +++ b/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> @@ -5,12 +5,16 @@ the image."
> 
>  LICENSE = "BSD"
> 
> +PR = "r2"
> +

We should never set PR in recipes, this is best maintained by a PR server

>  include machine-xilinx-${SOC_FAMILY}.inc
> 
>  inherit deploy
> 
>  PROVIDES = "virtual/boot-bin"
> 
> +B = "${WORKDIR}/build"
> +
>  do_configure[depends] += "${@get_bootbin_depends(d)}"
> 
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
> @@ -21,15 +25,24 @@ BOOTGEN_EXTRA_ARGS ?= ""
> 
>  BIF_PARTITIONS_zynqmp = "${@'fsbl pmu atf u-boot' if
> d.getVar('FPGA_MNGR_RECONFIG_ENABLE') == '1' else 'fsbl bitstream pmu atf
> u-boot'}"
> 
> +XILINX_BOOTBIN_IMAGES ??= "default"
> +
>  inherit nopackages
>  deltask do_fetch
>  deltask do_patch
>  deltask do_unpack
>  deltask do_install
> 
> +python () {
> +if not d.getVar("BIF_PARTITIONS_default"):
> +d.setVar("BIF_PARTITIONS_default", d.getVar("BIF_PARTITIONS"))
> +}
> +
>  def get_bootbin_depends(d):
>  bootbindeps = ""
> -bifpartitions = (d.getVar("BIF_PARTITIONS", True) or "").split()
> +bifpartitions = set()
> +for image in d.getVar("XILINX_BOOTBIN_IMAGES").split():
> +bifpartitions |= set((d.getVar("BIF_PARTITIONS_%s" % image) or
> + "").split())
>  attrdepends = d.getVarFlags("BIF_PARTITION_DEPENDS") or {}
>  for partition in bifpartitions:
>  if partition in attrdepends:
> @@ -37,7 +50,7 @@ def get_bootbin_depends(d):
> 
>  return bootbindeps
> 
> -def create_bif(config, attrflags, attrimage, common_attr, biffd, d):
> +def create_bif_partitions(config, attrflags, attrimage, common_attr, biffd, 
> d):
>  import re, os
>  for cfg in config:
>  if cfg not in attrflags and common_attr:
> @@ -64,9 +77,7 @@ def create_bif(config, attrflags, attrimage, common_attr,
> biffd, d):
> 
>  return
> 
> -python do_configure() {
> -
> -fp = d.getVar("BIF_FILE_PATH", True)
> +def create_bif_file(d, fp, bifpartitions):
>  biffd = open(fp, 'w')
>  biffd.write("the_ROM_image:\n")
>  biffd.write("{\n")
> @@ -74,32 +85,47 @@ python do_configure() {
>  bifattr = (d.getVar("BIF_COMMON_ATTR", True) or "").split()
>  if bifattr:
>  attrflags = d.getVarFlags("BIF_COMMON_ATTR") or {}
> -create_bif(bifattr, attrflags,'', 1, biffd, d)
> +create_bif_partitions(bifattr, attrflags,'', 1, biffd, d)
> 
> -bifpartition = (d.getVar("BIF_PARTITIONS", True) or "").split()
> -if bifpartition:
> -attrflags = d.getVarFlags("BIF_PARTITION_ATTR") or {}
> -attrimage = d.getVarFlags("BIF_PARTITION_IMAGE") or {}
> -create_bif(bifpartition, attrflags, attrimage, 0, biffd, d)
> +attrflags = d.getVarFlags("BIF_PARTITION_ATTR") or {}
> +attrimage = d.getVarFlags("BIF_PARTITION_IMAGE") or {}
> +create_bif_partitions(bifpartitions, attrflags, attrimage, 0,
> + biffd, d)
> 
>  biffd.write("}")
>  biffd.close()
> -}
> 
> -do_configure[vardeps] += "BIF_PARTITIONS BIF_PARTITION_ATTR
> BIF_PARTITION_IMAGE BIF_COMMON_ATTR"
> +python do_configure() {
> +for image in d.getVar("XILINX_BOOTBIN_IMAGES").split():
> +bifpartitions = d.getVar("BIF_PARTITIONS_" + image)
> +if not bifpartitions:
> +continue
> +create_bif_file(d, "bootgen-%s.bif" % image,
> +bifpartitions.split()) } do_configure[vardeps] += "\
> +XILINX_BOOTBIN_IMAGES \
> +BIF_PARTITIONS \
> +BIF_PARTITION_ATTR \
> +BIF_PARTITION_IMAGE \
> +BIF_COMMON_ATTR \
> +"
> 
>  do_compile() {
> -cd ${WORKDIR}
> -rm -f ${B}/BOOT.bin
> -bootgen -image ${BIF_FILE_PATH} -arch ${SOC_FAMILY}
> ${BOOTGEN_EXTRA_ARGS} -w -o ${B}/BOOT.bin
> -if [ ! -e ${B}/BOOT.bin ]; then
> -bbfatal "bootgen failed. See log"
> -fi
> +pwd
> +ls -la
> +rm -f boot*.bin BOOT.bin
> +for image in ${XILINX_BOOTBIN_IMAGES}
> +do
> +bootbin=boot-${image}.bin
> +

Re: [meta-xilinx] [meta-xilinx-tools][RFC][patch 1/3] xilinx-bootbin: rename BIF_PARTITION_ATTR to BIF_PARTITIONS for clarity

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: Jean-Francois Dagenais 
> Sent: Tuesday, July 9, 2019 8:45 AM
> To: meta-xilinx@yoctoproject.org; git 
> Cc: Jean-Francois Dagenais 
> Subject: [meta-xilinx-tools][RFC][patch 1/3] xilinx-bootbin: rename
> BIF_PARTITION_ATTR to BIF_PARTITIONS for clarity
> 
> Using BIF_PARTITION_ATTR main variable as the list of partitions is a
> reuse of the variable which makes the definition and code much harder to
> read and understand. Simply renaming the list of partitions as
> BIF_PARTITIONS alleviates this completely.
> 
> Signed-off-by: Jean-Francois Dagenais 
> ---
>  README.md |  2 +-
>  recipes-bsp/bootbin/machine-xilinx-versal.inc |  2 +-
>  recipes-bsp/bootbin/machine-xilinx-zynq.inc   |  4 ++--
>  recipes-bsp/bootbin/machine-xilinx-zynqmp.inc |  4 ++--
>  recipes-bsp/bootbin/xilinx-bootbin_1.0.bb | 14 +++---
>  5 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/README.md b/README.md
> index 65f6623..e4091e5 100644
> --- a/README.md
> +++ b/README.md
> @@ -83,7 +83,7 @@ Examples for adding dependencies
> 
>  See https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-
> bsp/bootbin/machine-xilinx-zynq.inc
> 
> -BIF_PARTITION_ATTR= "fsbl u-boot"
> +BIF_PARTITIONS= "fsbl u-boot"
> 

The reason to keep the variable name as "BIF partition attributes" is to match 
with the user guide of bootgen.
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug1283-bootgen-user-guide.pdf

>  BIF_PARTITION_ATTR[fsbl]="bootloader"
> 
> diff --git a/recipes-bsp/bootbin/machine-xilinx-versal.inc b/recipes-
> bsp/bootbin/machine-xilinx-versal.inc
> index 2cdaee7..8304448 100644
> --- a/recipes-bsp/bootbin/machine-xilinx-versal.inc
> +++ b/recipes-bsp/bootbin/machine-xilinx-versal.inc
> @@ -8,7 +8,7 @@ DEPENDS += "virtual/cdo"
>  BIF_COMMON_ATTR ?= ""
> 
>  # specify BIF partition attributes required for BOOT.bin
> -BIF_PARTITION_ATTR ?= "pmc_cdo plm psm dtb u-boot atf"
> +BIF_PARTITIONS ?= "pmc_cdo plm psm dtb u-boot atf"
> 
>  # specify BIF partition attributes for pmc_cdo
>  BIF_PARTITION_ATTR[pmc_cdo] ?= "pmcdata,load=0xF200"
> diff --git a/recipes-bsp/bootbin/machine-xilinx-zynq.inc b/recipes-
> bsp/bootbin/machine-xilinx-zynq.inc
> index b8d75c4..6ced4c3 100644
> --- a/recipes-bsp/bootbin/machine-xilinx-zynq.inc
> +++ b/recipes-bsp/bootbin/machine-xilinx-zynq.inc
> @@ -1,5 +1,5 @@
>  #specify BIF partition attributes required for BOOT.bin
> -BIF_PARTITION_ATTR ?= "fsbl bitstream u-boot"
> +BIF_PARTITIONS ?= "fsbl bitstream u-boot"
> 
>  #specify BIF partition attributes for FSBL
>  #bootloader is FSBL. Location where FSBL binary is present and dependency to
> build FSBL
> @@ -12,6 +12,6 @@ BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl:do_deploy"
>  BIF_PARTITION_IMAGE[u-boot] ?= "${DEPLOY_DIR_IMAGE}/u-boot-
> ${MACHINE}.elf"
>  BIF_PARTITION_DEPENDS[u-boot] ?= "virtual/bootloader:do_deploy"
> 
> -# enable bitstream-Note this is not enabled by default (missing in
> BIF_PARTITION_ATTR)
> +# enable bitstream-Note this is not enabled by default (missing in
> BIF_PARTITIONS)
>  BIF_PARTITION_IMAGE[bitstream] ?= "${DEPLOY_DIR_IMAGE}/download-
> ${MACHINE}.bit"
>  BIF_PARTITION_DEPENDS[bitstream] ?= "virtual/bitstream:do_deploy"
> diff --git a/recipes-bsp/bootbin/machine-xilinx-zynqmp.inc b/recipes-
> bsp/bootbin/machine-xilinx-zynqmp.inc
> index 3cc2f8b..4d70590 100644
> --- a/recipes-bsp/bootbin/machine-xilinx-zynqmp.inc
> +++ b/recipes-bsp/bootbin/machine-xilinx-zynqmp.inc
> @@ -2,7 +2,7 @@
>  BIF_COMMON_ATTR ?= ""
> 
>  # specify BIF partition attributes required for BOOT.bin
> -BIF_PARTITION_ATTR ?= "fsbl pmu atf u-boot"
> +BIF_PARTITIONS ?= "fsbl pmu atf u-boot"
> 
>  # specify BIF partition attributes for FSBL
>  # bootloader is FSBL. Location where FSBL binary is present and dependency to
> build FSBL
> @@ -28,7 +28,7 @@ BIF_PARTITION_ATTR[u-boot] ?= "destination_cpu=a53-
> 0,exception_level=el-2"
>  BIF_PARTITION_IMAGE[u-boot] ?= "${DEPLOY_DIR_IMAGE}/u-boot-
> ${MACHINE}.elf"
>  BIF_PARTITION_DEPENDS[u-boot] ?= "virtual/bootloader:do_deploy"
> 
> -# enable bitstream-Note this is not enabled by default (missing in
> BIF_PARTITION_ATTR)
> +# enable bitstream-Note this is not enabled by default (missing in
> BIF_PARTITIONS)
>  BIF_PARTITION_ATTR[bitstream] ?= "destination_device=pl"
>  BIF_PARTITION_IMAGE[bitstream] ?= "${DEPLOY_DIR_IMAGE}/download-
> ${MACHINE}.bit"
>  BIF_PARTITION_DEPENDS[bitstream] ?= "virtual/bitstream:do_deploy"
> diff --git a/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb b/recipes-
> bsp/bootbin/xilinx-bootbin_1.0.bb
> index 1fb8d99..979c737 100644
> --- a/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> +++ b/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> @@ -19,7 +19,7 @@ BIF_FILE_PATH ?= "${B}/bootgen.bif"
> 
>  BOOTGEN_EXTRA_ARGS ?= ""
> 
> -BIF_PARTITION_ATTR_zynqmp = "${@'fsbl pmu atf u-boot' if
> d.getVar('FPGA_MNGR_RECONFIG_ENABLE') == '1' else 'fsbl bitstream pmu atf
> 

Re: [meta-xilinx] [meta-xilinx-tools][RFC][patch 2/3] xilinx-bootbin: cleanup unecessary steps

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: Jean-Francois Dagenais 
> Sent: Tuesday, July 9, 2019 8:45 AM
> To: meta-xilinx@yoctoproject.org; git 
> Cc: Jean-Francois Dagenais 
> Subject: [meta-xilinx-tools][RFC][patch 2/3] xilinx-bootbin: cleanup 
> unecessary
> steps
> 
> Signed-off-by: Jean-Francois Dagenais 
> ---
>  recipes-bsp/bootbin/xilinx-bootbin_1.0.bb | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb b/recipes-
> bsp/bootbin/xilinx-bootbin_1.0.bb
> index 979c737..41e5f1e 100644
> --- a/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> +++ b/recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> @@ -21,9 +21,11 @@ BOOTGEN_EXTRA_ARGS ?= ""
> 
>  BIF_PARTITIONS_zynqmp = "${@'fsbl pmu atf u-boot' if
> d.getVar('FPGA_MNGR_RECONFIG_ENABLE') == '1' else 'fsbl bitstream pmu atf
> u-boot'}"
> 
> -do_fetch[noexec] = "1"
> -do_unpack[noexec] = "1"
> -do_patch[noexec] = "1"
> +inherit nopackages
> +deltask do_fetch
> +deltask do_patch
> +deltask do_unpack
> +deltask do_install
> 
>  def get_bootbin_depends(d):
>  bootbindeps = ""
> @@ -101,10 +103,6 @@ do_compile_append_versal() {
>  dd if=${DEPLOY_DIR_IMAGE}/boot.scr of=${B}/QEMU_qspi.bin bs=1
> seek=66584576 conv=notrunc  }
> 
> -do_install() {
> - :
> -}
> -

We are working on mechanism which enables boot.bin upgrade mechanism using RPM 
packages.
To do this, we would need do_install task and packaging tasks

Thanks,
Manju

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-tools] 2019.1 XPAR_MICROBLAZE_DDR_RESERVE_SA not defined in BSP

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Jean-Francois Dagenais
> Sent: Wednesday, July 3, 2019 8:59 AM
> To: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] [meta-xilinx-tools] 2019.1
> XPAR_MICROBLAZE_DDR_RESERVE_SA not defined in BSP
> 
> Poke!
> 
> Anyone at Xilinx get a chance to look into this? Am I the only one getting 
> this
> problem? Anyone using meta-xilinx-tools 2019.1 on a custom board?
> 

I was looking at our evaluation board zcu102, and see that 
./pmu-firmware/zynqmp_pmufw_bsp/psu_pmu_0/include/xparameters.h has a 
definition 
#define XPAR_MICROBLAZE_DDR_RESERVE_EA 0x7FFF
#define XPAR_MICROBLAZE_DDR_RESERVE_SA 0x7FF0

Can you share your hdf ? we can open a bug case to see why it is set to 0

Thanks,
Manju

> > On Jun 25, 2019, at 12:50, Jean-Francois Dagenais 
> wrote:
> >
> > So, this is following my previous misadventure with booting without u-boot.
> FYI, we have our own board with a zynqmp on it. So not using the pre-defined
> boards.
> >
> > The culprit being that the PMU firmware was overwriting my kernel because of
> this:
> >
> > 2019.1+gitAUTOINC+26c14d9861-r0/build/pmu-
> firmware/zynqmp_pmufw_bsp/psu_pmu_0/include/xparameters.h:#define
> XPAR_MICROBLAZE_DDR_RESERVE_SA 0
> >
> > This is a BSP auto-created from xsctbase.bbclass (I believe) using the 
> > handoff
> file as reference. As you can see, 0 is wrong here as it then means
> >
> > #define FSBL_STORE_ADDR
>   (XPAR_MICROBLAZE_DDR_RESERVE_SA + 0x8U)
> >
> > from xpfw_restart.h means the FSBL is copied over the kernel's default 
> > loading
> address.
> >
> > I have aligned my handoff with meta-xilinx-tools. 2019.1 everywhere, still,
> XPAR_MICROBLAZE_DDR_RESERVE_SA is zero.
> >
> > This means I will most likely not be the only one with this problem.
> >
> > Am I missing something? Should one edit xparameters.h? If so, how? Because I
> gathered it was auto-generated, correct?
> >
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-tools][2019.1][patch 2/2] layer.conf: add fpga-manager as an IMAGE_FEATURE

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: Jean-Francois Dagenais 
> Sent: Wednesday, June 26, 2019 5:09 AM
> To: Manjukumar Harthikote Matha 
> Cc: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx-tools][2019.1][patch 2/2] layer.conf: add fpga-
> manager as an IMAGE_FEATURE
> 
> Hi Manju!
> 
> > On Jun 25, 2019, at 23:40, Manjukumar Harthikote Matha
>  wrote:
> >
> > We don't plan to use image-features going forward with fpga-manager.
> > The best way is to just enable using FPGA_MNGR_RECONFIG_ENABLE.
> > Setting the variable to "1" allow you to use the script and utility
> 
> Hmmm... this line
> FPGA_MNGR_RECONFIG_ENABLE ?= "${@bb.utils.contains('IMAGE_FEATURES',
> 'fpga-manager', '1', '0', d)}"
> 

We kept it this way for allowing backward compatibility with meta-petalinux.
Ideally we want to have FPGA_MNGR_RECONFIG_ENABLE ?=1 by default

> enable FPGA_MNGR_RECONFIG_ENABLE through 'fpga-manager' in
> IMAGE_FEATURES. The problem is that this is not a recognized IMAGE_FEATURE
> so it fails with bb.parse.SkipRecipe("'%s' in IMAGE_FEATURES is not a valid
> image feature... from image.bbclass
> 
> So do you recommend I add something like this to mymachine.conf?
> 
> FPGA_MNGR_RECONFIG_ENABLE = "1"
> MACHINE_ESSENTIAL_EXTRA_DEPENDS += "fpga-manager-util"
> EXTRA_HDF = "${DEPLOY_DIR_IMAGE}"
> 
> 
> Is this how it is meant to be used? (without petalinux)

If you are using FPGA manager then it is easier to set that variable to "1" 
instead of image feature.

> 
> Thanks!
> P.S.: Did you look into my other patch?

Yes, checking why it worked for us and did not see the error

Thanks,
Manju

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-tools][2019.1][patch 2/2] layer.conf: add fpga-manager as an IMAGE_FEATURE

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: Jean-Francois Dagenais 
> Sent: Tuesday, June 25, 2019 1:41 PM
> To: meta-xilinx@yoctoproject.org; git 
> Cc: Jean-Francois Dagenais 
> Subject: [meta-xilinx-tools][2019.1][patch 2/2] layer.conf: add fpga-manager 
> as
> an IMAGE_FEATURE
> 
> Since fpga-manager things were migrated from meta-petalinux to this layer,
> remove the dependency towards this other layer so this one can work on it's
> own.
> 
> Signed-off-by: Jean-Francois Dagenais 
> ---
>  conf/layer.conf | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/conf/layer.conf b/conf/layer.conf index f647f81..7218a7b 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -21,3 +21,7 @@ SDK_LOCAL_CONF_WHITELIST_append = "
> XILINX_SDK_TOOLCHAIN XILINX_VER_MAIN"
>  HOSTTOOLS += "ps"
>  INHERIT += "xsct-tc"
>  LAYERSERIES_COMPAT_xilinx-tools = "sumo thud"
> +
> +IMAGE_FEATURES[validitems] += "fpga-manager"
> +FEATURE_PACKAGES_fpga-manager ?= "fpga-manager-script fpga-manager-
> util"
> +FEATURE_PACKAGES_fpga-manager[optional] ?= "1"

We don't plan to use image-features going forward with fpga-manager. The best 
way is to just enable using FPGA_MNGR_RECONFIG_ENABLE. Setting the variable to 
"1" allow you to use the script and utility

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] externalxsctsrc.bbclass deletes the source dir! :(

[Manjukumar Harthikote Matha]

Hi JD,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Jean-Francois Dagenais
> Sent: Friday, June 21, 2019 11:31 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] externalxsctsrc.bbclass deletes the source dir! :(
> 
> I have a fsbl_git.bbappend which adds the following:
> 
> XSCTH_BUILD_DEBUG = "1"
> inherit externalxsctsrc
> EXTERNALXSCTSRC = "/home/dagenaisj/devel/xlnx-embeddedsw"
> EXTERNALXSCTSRC_BUILD = "/builds/fsbl/ws"
> 

Are you on 2018.3 or 2019.1 release?

Thanks,
Manju

<..>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Build and boot zcu106 image

[Manjukumar Harthikote Matha]

Hi Mike,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Mike Looijmans
> Sent: Tuesday, June 4, 2019 6:09 AM
> To: Luca Ceresoli ; Manjukumar Harthikote Matha
> ; meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] Build and boot zcu106 image
> 
> On 04-06-19 14:58, Luca Ceresoli wrote:
> > Hi Mike,
> >
> > On 04/06/19 07:41, Mike Looijmans wrote:
> >> On 03-06-19 16:25, Manjukumar Harthikote Matha wrote:
> >>> Hi Mike,
> >>>
> >>>> -Original Message-
> >>>> From: meta-xilinx-boun...@yoctoproject.org  >>>> boun...@yoctoproject.org> On Behalf Of Mike Looijmans
> >>>> Sent: Monday, June 3, 2019 7:01 AM
> >>>> To: meta-xilinx@yoctoproject.org
> >>>> Subject: [meta-xilinx] Build and boot zcu106 image
> >>>>
> >>>> Got a zcu106 board here to experiment with. With pre-built stuff,
> >>>> the board boots okay.
> >>>>
> >>>> I cloned OpenEmbedded and meta-xilinx "thud" branches, made no
> changes.
> >>>>
> >>>> Built the PMU firmware and core-image-minimal for machine zcu106-
> zynqmp.
> >>>>
> >>>
> >>> I had similar issue! I think the PMU default config objects in SPL
> >>> flow does not work.
> >>> Luca had config object which worked for him.
> >>
> >>
> >> And what is the solution?
> >>
> >>
> >> There's nothing "machine" dependent in the PMU recipe, so all ZynqMP
> >> machines will build the exact same binary. Right?
> >>

I am not sure about this, because Ultra96 needed different PMU cfg to work.
I will check once I am back from vacay

> >> My first attempt was actually to use my "standard" PMU stuff (patched
> >> PMU with built-in config object) for the image, but that also
> >> delivered the same error.
> >
> > My SPL patch is just moving the cfg loading in a different place. It
> > would not solve your problem.
> >
> > Just guessing, are you using the pm_cfg_obj.c produced by XDSK for
> > your FPGA design or an "enable-all" config?
> >

The pmu configs generated from XSDK works, meaning I don’t see the issue while 
using meta-xilinx-tools

> 
> I tried to use the "enable all" config I also use on our custom boards. In 
> theory,
> that should work on any board, right?
> 
> I also tried "whatever meta-xilinx delivers by default".
> 
> As for "pm_cfg_obj.c produced by XDSK", I have no clue as to how to do that,
> but I'm guessing Google can help me out with that. Do you think it'd make a
> difference?

meta-xilinx-tools can help generate that file, maybe comparing that with SPL 
generated flow might provide some insights why it is breaking


Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Warrior release 06/30

[Manjukumar Harthikote Matha]

Hi All,

We plan to release warrior by end of month. 
We also want to see if we can backport patches of u-boot from Luca to enable 
cleaner SPL flow for PMU config objects.
If we cannot do it by 6/30, we want to make sure we can add it after the 
release branch is cut.
Please see: 
https://lucaceresoli.net/zynqmp-uboot-spl-pmufw-cfg-load/
or
https://www.linkedin.com/pulse/booting-u-boot-spl-zynqmp-step-forward-luca-ceresoli/


We will start posting the patches to master branch soon which will be a part of 
Warrior (v2.7).

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Build and boot zcu106 image

[Manjukumar Harthikote Matha]

Hi Mike,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org  boun...@yoctoproject.org> On Behalf Of Mike Looijmans
> Sent: Monday, June 3, 2019 7:01 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Build and boot zcu106 image
> 
> Got a zcu106 board here to experiment with. With pre-built stuff, the board
> boots okay.
> 
> I cloned OpenEmbedded and meta-xilinx "thud" branches, made no changes.
> 
> Built the PMU firmware and core-image-minimal for machine zcu106-zynqmp.
> 

I had similar issue! I think the PMU default config objects in SPL flow does 
not work.
Luca had config object which worked for him.

Thanks,
Manju
> Copied the usual files onto an SD card: atf-uboot.ub boot.bin Image system.dtb
> u-boot.bin uEnv.txt zynqmp-zcu106-revA.dtb
> 
> Put the card in the board and switch it on. All I get is this:
> 
>  Debug uart enabled
> "Synchronous Abort" handler, esr 0x9640
> ELR: fffc9e70
> LR:  fffc6c78
> x0 : fdfd00011dfdfe5d x1 : 
> x2 : 0202020201a3 x3 : fdfd00011dfdfe5d
> x4 :  x5 : 
> x6 : 7f20 x7 : 0005
> x8 : 00ad x9 : 0080
> x10: fffd x11: 0064
> x12: fe6a x13: 60f8a90300b080a0
> x14: 8a10070a4265 x15: a5cc22ca484081d9
> x16: 385a360321460003 x17: 9b800c890e560844
> x18: 7e90 x19: 2000
> x20:  x21: fdfd00011dfdfe5d
> x22:  x23: 0001
> x24: 7f20 x25: fffdae68
> x26: fffdae68 x27: fffdb000
> x28:  x29: 7c10
> 
> Resetting CPU ...
> 
> ### ERROR ### Please RESET the board ###
> 
> 
> What does one have to do to actually boot that board with meta-xilinx?
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Xilinx DNNDK Layer

[Manjukumar Harthikote Matha]

Hi Emily,

Yes definitely, if you have recipes we can add under recipes-examples/dnndk in 
meta-xilinx-bsp.

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Emily S
Sent: Wednesday, May 8, 2019 1:40 PM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Xilinx DNNDK Layer

Hi all -

Xilinx recently released the source code for their Deep Neural Network 
Development Kit (DNNDK) in the last month or so. They have the code written 
nicely in recipes (perhaps meant for petalinux) but it doesn't appear to be an 
actual layer: 
https://github.com/Xilinx/Edge-AI-Platform-Tutorials/tree/master/docs/DPU-Integration/reference-files/files
 . Is there a possibility of creating a layer for it inside meta-xilinx? I 
could also probably get it into the form of a layer, but this would be nicely 
centralized.

Or if anyone has additional options on how to incorporate this code, 
suggestions are appreciated!
Thanks for the help!
Emily
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] u-boot fpga command silently fails on zcu102 SD boot

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Wednesday, April 24, 2019 8:53 AM
> To: Monaghan, Michael L. (GSFC-5870) ;
> meta-xilinx@yoctoproject.org
> Cc: Andreas Galauner ; Manjukumar Harthikote Matha
> ; Mounika Akula 
> Subject: Re: [meta-xilinx] u-boot fpga command silently fails on zcu102 SD 
> boot
> 
> Hi Michael,
> 
> On 24/04/19 01:51, Monaghan, Michael L. (GSFC-5870) wrote:
> > Hello all,
> >
> > When booting from SD on the zcu102, the u-boot `fpga` command appears
> silently fails to configure the PL. The done led does not illuminate and the
> command returns 1.
> 
> PMUFW version? 2018.3?
> 
> Since 2018.3, the build instructions for pmu firmware are broken. The
> copy_bsp.sh script does not copy the FPGA loading files, which results is a
> successful build of a PMUFW *without* the FPGA loading feature.
> 
> Andreas reported the problem and sent a patch to fix it:
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004184.html
> 
> The patch is in meta-xilinx master, but has not been backported to thud, so 
> you
> should try that.
> 

I have backported to thud 

> Additionally, a patch has been merged in U-Boot 2019.04 to always print an
> error message when FPGA loading fails, you might want that one as well:
> https://git.denx.de/?p=u-
> boot.git;a=commit;h=8df324a20b45f3a15a166797a2d5a5d447337891
> 
> Hope it helps.
> 
> 
> Manjukumar, Mounika, this issue is still hurting people. I'd like to renew my
> appeal to really fix 
> it:https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-
> January/004190.html
> 

Will follow up and keep you posted

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] meta-xilinx-tools shell function parsed as python function

[Manjukumar Harthikote Matha]

Hi Michael,

You are on master and meta-xilinx-tools 2018.3 release. They don’t work 
together.
You can apply this RFC patch on meta-xilinx-tools to get going:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-February/004250.html

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Monaghan, Michael L. 
(GSFC-5870)
Sent: Tuesday, April 16, 2019 12:58 PM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] meta-xilinx-tools shell function parsed as python 
function

Hello all,

Thank you in advance for your time. I’m new to the Yocto Project and 
OpenEmbedded.

I am trying to add the meta-xilinx-tools layer to a working Yocto/OE build for 
the zcu102 board, but bitbake subsequently fails to parse 
meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb. Here are 
some snippets from the console.

WARNING: 
/yocto/projects/yocto-zcu102/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb:
 Error during finalise of 
/yocto/projects/yocto-zcu102/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
…
ERROR: Unable to parse 
/yocto/projects/yocto-zcu102/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb:20:23
Traceback (most recent call last):
…
File "/yocto/projects/yocto-zcu102/bitbake/lib/bb/codeparser.py", line 327, in 
PythonParser.parse_python(node="\n\t[ -e ${DTS_FILES_PATH}/system.dts ] && rm 
${DTS_FILES_PATH}/system.dts\nbb.build.exec_func('devicetree_do_compile', 
d)\n", lineno=1, filename='autogenerated'):
 code = compile(check_indent(str(node)), filename, "exec",
>   ast.PyCF_ONLY_AST)

  File "autogenerated", line 2
[ -e ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts
 ^
SyntaxError: invalid syntax


Summary: There were 10 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

I found the offending function at 
meta-xilinx-tools/recipes-bsp/device-tree/device-tree.bbappend:71

do_compile_prepend() {
[ -e ${DTS_FILES_PATH}/system.dts ] && rm 
${DTS_FILES_PATH}/system.dts
}

And it appears to ultimately override this python function at 
openembedded-core/meta/classes/devicetree.bbclass:119

python devicetree_do_compile() {
  …
}

devicetree.bbappend:do_compile_prepend() is clearly a shell script, but the 
“SyntaxError: invalid syntax” message indicates that it is being parsed as a 
python function! It looks like this could be a problem with bitbake or yocto/oe 
but I thought I would reach out to the community here first. Has anyone here 
encountered this?

I’m using the rel-v2018.3 branch for meta-xilinx-tools and the thud branch for 
everything else. I have tried using version 1.40 and the master branch of 
bitbake.

Thanks,
Michael Monaghan
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] pre-built SD card image for zedboard to verify board actually works?

[Manjukumar Harthikote Matha]

Hi Rob,

Try from pre-built images from here:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/57639129/Zynq+2018.3+Release

Thanks,
Manju

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
> Sent: Sunday, April 14, 2019 2:10 PM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] pre-built SD card image for zedboard to verify board
> actually works?
> 
> 
>   i was just gifted with an avnet zedboard with no SD card and, before i 
> launch
> into trying to build my own boot images with YP, i'd like to copy some minimal
> pre-built files to an SD card and just make sure the board works. i've been 
> trying
> that for the last couple hours and have had absolutely no luck, in the sense 
> that,
> other than the power LED coming on, i've seen no sign that anything is
> happening with this board.
> 
>   i don't even want to boot to linux -- i'm really just looking to get to 
> u-boot --
> with as little fuss as possible. i've connected my fedora box to the serial 
> debug
> UART port, i've verified all the jumper settings, i've populated an SD card 
> with
> the files extracted from zedboard_oob_design.zip as described here:
> 
> http://zedboard.org/content/zedboard-out-box-sd-card-image-and-source
> 
> i've fired up both minicom and picocom to connect to /dev/ttyACM0 ...
> no luck.
> 
>   i've run out of ideas, and i've tried all sorts of variations i've found 
> all over the
> net. thoughts? getting to u-boot is all i'm after to confirm that this board
> actually functions. any suggestions?
> 
> rday
> 
> --
> 
> =
> ===
> Robert P. J. Day Ottawa, Ontario, CANADA
>  http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> =
> ===
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][RFC] kernel-module-mali: Fix errors associated with kernel upgrade to 4.19

[Manjukumar Harthikote Matha]

Hi JFD,

> -Original Message-
> From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com]
> Sent: Monday, April 1, 2019 1:45 PM
> To: Manjukumar Harthikote Matha 
> Cc: meta-xilinx@yoctoproject.org; Madhurkiran Harikrishnan
> 
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][RFC] kernel-module-mali: Fix
> errors associated with kernel upgrade to 4.19
> 
> 
> 
> > On Apr 1, 2019, at 16:36, Jean-Francois Dagenais
>  wrote:
> >
> >> We don't see the issue with above tree and the RFC patches.
> >>
> >
> > Any idea where to start? Could it be related to our handoff file?
> >
> 
> Or something missing in my defconfig? Is ./configs/xilinx_zynqmp_defconfig
> kept up to date in the kernel tree?

This is up to date 

> 
> For example, comparing zynqmp_defconfig changes from 4.14 to master, I
> see I am missing ZYNQMP_RESET_CONTROLLER.
> 
> I will check for more discrepancies, but any pointers from this community will
> help a lot.


Were you able to solve this? I am not seeing this issue in our builds.

> 
> Thanks again.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][RFC] kernel-module-mali: Fix errors associated with kernel upgrade to 4.19

[Manjukumar Harthikote Matha]

Hi JFD,

> -Original Message-
> From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com]
> Sent: Monday, April 01, 2019 12:52 PM
> To: Manjukumar Harthikote Matha 
> Cc: meta-xilinx@yoctoproject.org; Madhurkiran Harikrishnan
> 
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][RFC] kernel-module-mali: Fix 
> errors
> associated with kernel upgrade to 4.19
> 
> Hi Manju, guys,
> 
> I need to move up to 4.19 early for the kernel. I just tried this patchset 
> (only after
> having made my own... I had forgotten about yours here).
> 
> I am aligned with 2018.3, using meta-xilinx-tools, but am not using 
> meta-petalinux.
> We have our own kernel recipe which
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
> 

Can you try with linux-xlnx master? https://github.com/Xilinx/linux-xlnx

> So using either my patches on kernel-module-mali, or yours, I get this:

We don't see the issue with above tree and the RFC patches. 

Thanks,
Manju

> 
> [  641.029489] SError Interrupt on CPU2, code 0xbf02 -- SError
> [  641.029492] CPU: 2 PID: 5232 Comm: insmod Tainted: GW  O  
> 4.19.0-jfd #1
> [  641.029493] Hardware name: dublin (DT)
> [  641.029495] pstate: 8005 (Nzcv daif -PAN -UAO)
> [  641.029497] pc : _mali_osk_mem_iowrite32+0x10/0x20 [mali]
> [  641.029498] lr : mali_pp_reset_async+0x50/0x1b0 [mali]
> [  641.029500] sp : ff8011ad38c0
> [  641.029501] x29: ff8011ad38d0 x28: ff80123bd000
> [  641.029504] x27: 0100 x26: ff80009052d0
> [  641.029508] x25: ff8000905280 x24: 
> [  641.029511] x23: 0001 x22: ffc036d0d600
> [  641.029514] x21: ff8011ad3968 x20: ff8000904000
> [  641.029518] x19: ffc035266b80 x18: fff0
> [  641.029521] x17:  x16: 
> [  641.029524] x15: ff8008a78ad8 x14: ff8008ad8d10
> [  641.029527] x13:  x12: 
> [  641.029531] x11: 0001 x10: ff800886ae50
> [  641.029534] x9 : ff8008a6e000 x8 : 
> [  641.029537] x7 : 0041 x6 : 
> [  641.029540] x5 : 0001 x4 : ff804936
> [  641.029544] x3 : 00e80f07 x2 : 1fff
> [  641.029547] x1 : 1020 x0 : ff800936
> [  641.029551] Kernel panic - not syncing: Asynchronous SError Interrupt
> [  641.029553] CPU: 2 PID: 5232 Comm: insmod Tainted: GW  O  
> 4.19.0-jfd #1
> [  641.029555] Hardware name: dublin (DT)
> [  641.029556] Call trace:
> [  641.029557]  dump_backtrace+0x0/0x180
> [  641.029558]  show_stack+0x14/0x20
> [  641.029560]  dump_stack+0x9c/0xbc
> [  641.029561]  panic+0x130/0x278
> [  641.029562]  nmi_panic+0x6c/0x70
> [  641.029563]  arm64_serror_panic+0x74/0x80
> [  641.029565]  is_valid_bugaddr+0x0/0x8
> [  641.029566]  el1_error+0x7c/0xdc
> [  641.029568]  _mali_osk_mem_iowrite32+0x10/0x20 [mali]
> [  641.029569]  mali_pp_create+0x7c/0x350 [mali]
> [  641.029571]  mali_initialize_subsystems+0x12c/0x5f8 [mali]
> [  641.029572]  mali_probe+0xf0/0x358 [mali]
> [  641.029574]  platform_drv_probe+0x50/0xa0
> [  641.029575]  really_probe+0x1e0/0x298
> [  641.029577]  driver_probe_device+0x54/0xe8
> [  641.029578]  __driver_attach+0xe4/0xe8
> [  641.029579]  bus_for_each_dev+0x70/0xc0
> [  641.029581]  driver_attach+0x20/0x28
> [  641.029582]  bus_add_driver+0x1dc/0x208
> [  641.029583]  driver_register+0x60/0x110
> [  641.029585]  __platform_driver_register+0x44/0x50
> [  641.029586]  init_module+0x30/0x140 [mali]
> [  641.029588]  do_one_initcall+0x74/0x178
> [  641.029589]  do_init_module+0x54/0x1c0
> [  641.029591]  load_module+0x1ae4/0x2108
> [  641.029592]  __se_sys_finit_module+0xb8/0xc8
> [  641.029594]  __arm64_sys_finit_module+0x18/0x20
> [  641.029595]  el0_svc_common+0x84/0xd8
> [  641.029596]  el0_svc_handler+0x6c/0x88
> [  641.029598]  el0_svc+0x8/0xc
> [  641.029625] SMP: stopping secondary CPUs
> [  641.029626] Kernel Offset: disabled
> [  641.029628] CPU features: 0x0,20802004
> [  641.029629] Memory Limit: none
> [  641.295015] ---[ end Kernel panic - not syncing: Asynchronous SError 
> Interrupt ]---
> 
> 
> Any clues?
> 
> 
> > On Mar 13, 2019, at 14:23, Manjukumar Matha  ma...@xilinx.com> wrote:
> >
> > From: Madhurkiran Harikrishnan 
> >
> > These patches fixes errors caused by removal of ancient init_timer API.
> > Also, addresses the removal of hot/cold cache pages in the kernel.
> >
> > Signed-off-by: Madhurkiran Harikrishnan 
> > 
> > Signed-off-by: Manjukumar Matha 
> > ---
> > .../recipes-graphics/mali/kernel-module-mali.bb|   3 +
> > ...ux-mali_

Re: [meta-xilinx] Really bad SD/eMMC performance after upgrading 2018.1 to 2018.3

[Manjukumar Harthikote Matha]

Hi Mike and all,

Are there any specific configurations? PMU/Linux ?

We are not able to replicate this issue, we tested it on zcu102 board

Thanks,
Manju

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> Sent: Thursday, March 21, 2019 10:09 AM
> To: Peter Smith 
> Cc: meta-xil...@lists.yoctoproject.org
> Subject: Re: [meta-xilinx] Really bad SD/eMMC performance after upgrading 
> 2018.1
> to 2018.3
> 
> Have only tried the MPSoC.
> 
> I haven't tried the 7k yet with 2018.3, may get to that tomorrow. I
> suspect it's something with the PMU interface and/or clock dividers.
> 
> 
> On 21-03-19 17:54, Peter Smith wrote:
> > Mike, although I have not made any measurements I have noticed in the
> > last few days (coincidentally I have been doing a lot of work with a
> > ZCU102) that the SD interface seemed a bit slow. Are you seeing this on
> > Zynq 7K or US+ MPSoC?
> > Best Regards
> > Peter
> >
> >
> > On Thu, 21 Mar 2019 at 16:38, Mike Looijmans  > > wrote:
> >
> > The SD and eMMC controller has become terribly slow in 2018.3:
> >
> > # echo 3 > /proc/sys/vm/drop_caches
> >
> > # dd if=/dev/mmcblk0 of=/dev/null bs=1M count=20
> > 20+0 records in
> > 20+0 records out
> > 20971520 bytes (20.0MB) copied, 4.972666 seconds, 4.0MB/s
> >
> > # dd if=/dev/mmcblk1 of=/dev/null bs=1M count=20
> > 20+0 records in
> > 20+0 records out
> > 20971520 bytes (20.0MB) copied, 38.899436 seconds, 526.5KB/s
> >
> >
> > This used to be over 160MB/s for the eMMC (mmcblk0) and over 20 MB/s
> > for the
> > SD card (mmcblk0) with the 2018.1 kernel and bootloader.
> >
> > This is only in Linux, the bootloader still reads at about 10MB/s
> > from the SD
> > card. So apparently the clocks are set up okay.
> >
> > According to the kernel, the clocks and interface are running at
> > full speed:
> >
> > # cat /sys/kernel/debug/mmc0/ios
> > clock:          2 Hz
> > actual clock:   2 Hz
> > vdd:            21 (3.3 ~ 3.4 V)
> > bus mode:       2 (push-pull)
> > chip select:    0 (don't care)
> > power mode:     2 (on)
> > bus width:      3 (8 bits)
> > timing spec:    9 (mmc HS200)
> > signal voltage: 1 (1.80 V)
> > driver type:    0 (driver type B)
> >
> > # cat /sys/kernel/debug/mmc1/ios
> > clock:          5000 Hz
> > actual clock:   5000 Hz
> > vdd:            21 (3.3 ~ 3.4 V)
> > bus mode:       2 (push-pull)
> > chip select:    0 (don't care)
> > power mode:     2 (on)
> > bus width:      2 (4 bits)
> > timing spec:    2 (sd high-speed)
> > signal voltage: 0 (3.30 V)
> > driver type:    0 (driver type B)
> >
> >
> > Any insights?
> > --
> > ___
> > meta-xilinx mailing list
> > meta-xilinx@yoctoproject.org 
> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> >
> 
> 
> --
> Mike Looijmans
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [xilinx-tools] Why does it require Rocko?

[Manjukumar Harthikote Matha]

Hi Geoff,

Historically this layer has worked regardless of Yocto upstream changes, the 
reason is that it is dependent on Xilinx tools rather than Yocto OE-core 
changes. One of the recent changes that happened in Thud was 
device-tree.bbclass, which impacts the device tree generation. We have not seen 
any other issue wrt Thud other than devicetree

Thanks,
Manju

From: Geoff Gillett [mailto:ggill...@qvil.ca]
Sent: Wednesday, March 20, 2019 9:21 AM
To: Manjukumar Harthikote Matha ; 
meta-xilinx@yoctoproject.org
Subject: Re: [xilinx-tools] Why does it require Rocko?


Hi Manju,



Thank you for the quick useful response.

I have not tried to upgrade my basic build system yet but will give the patch a 
try and get back to the list if any problems arise. This would fix our current 
problems by allowing us to use  Python3.7 which is good news.



I guess the patch may give me some clues as to why xilinx-tools does not follow 
Yocto releases, but can you enlighten me as to why? I am not asking why 
xilinx-tools does not follow every Yocto release, but why every xilinx-tools 
release does not use the latest Yocto at the time. Wasn't Sumo available at the 
time of the 2018.3 release? (I know that this would not have helped our Python 
problem).



Cheers,

Geoff.


From: Manjukumar Harthikote Matha 
mailto:manju...@xilinx.com>>
Sent: March 20, 2019 1:02:10 PM
To: Geoff Gillett; 
meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: RE: [xilinx-tools] Why does it require Rocko?

Hi Geoff,

The only needed patch for Thud is the devicetree patch, which we had sent as 
RFC. Meta-xilinx-tools currently does not follow Yocto releases at this point 
of time, it is following Vivado release hence it is approx. 4months behind 
Yocto release.

RFC patch is here:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-February/004250.html

Are you witnessing any issue other than device-tree?

Thanks,
Manju

From: 
meta-xilinx-boun...@yoctoproject.org<mailto:meta-xilinx-boun...@yoctoproject.org>
 [mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Geoff Gillett
Sent: Wednesday, March 20, 2019 8:53 AM
To: meta-xilinx@yoctoproject.org<mailto:meta-xilinx@yoctoproject.org>
Subject: [meta-xilinx] [xilinx-tools] Why does it require Rocko?


Hi,



We are a new applied science lab using Zynq's to embed our data acquisition and 
control systems. We find the ability to use the xilinx-tools layer very useful 
as it allows non HDL experts to configure hardware through the Vivado block 
diagram, then Yocto builds the custom OS for our embedded nodes. This would 
enable our science teams  to create not only the science package but the 
embedded instrumentation and control without detailed expertise in embedded 
Linux or HDL.



Our issue is we would like to track the Python releases, Yocto appears to have 
fixed the issues it had with Python tracking in the Thud release, but 
xilinx-tools appears to be stuck at Rocko.



We wonder what underlying problems are causing this?  We would like to 
investigate fixing it, first we would need to know what the issues are.



My understanding is:

  *   Yocto is a build system based on layers of recipes that construct 
components.
  *   xilinx-tools is a layer of recipes for building the device-tree and other 
BSP components using Xilinx's proprietary tools.
What I don't understand is why the recipes in xilinx-tools can't be handled by 
more recent versions of Yocto.

Does xilinx-tools work with more recent Yocto versions than Rocko?
I have a basic version of a build system working based on the 2018.3 Xilinx 
releases but have not tried upgrading Yocto/openembedded versions.

Cheers,
Geoff Gillett.
Senior Scientist, Quantum Valley Ideas Laboratories.


-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Loading FPGA firmware broken in 2018.3

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Mike Looijmans [mailto:mike.looijm...@topic.nl]
> Sent: Thursday, March 21, 2019 5:55 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@lists.yoctoproject.org
> Subject: Re: Loading FPGA firmware broken in 2018.3
> 
> On 21-03-19 07:33, Mike Looijmans wrote:
> > On 20-03-19 18:46, Manjukumar Harthikote Matha wrote:
> >> Hi Mike,
> >>
> >> We tested by loading  both the vivado generated and bootgen generated
> >> bitstreams using 2018.3 and it worked fine, we are able to see Done
> >> and leds glowing as per our design.
> >>
> >> Is it a custom board or zcu102?
> >
> > Custom board (the Xilinx Drone Platform actually)
> >
> >> Do you need this patch on thud?
> >>
> >> https://github.com/Xilinx/meta-xilinx/commit/2c98fa11ccf33b6d9a550beb
> >> f50d2a2a876f9afb
> >
> > Might be, from the description it sounds like "the FPGA configuration
> > code is non-functional" is what I'm experiencing here.
> 
> Built the PMU with the above patch, and now programming the PL works.

Thanks, will backport to thud

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Loading FPGA firmware broken in 2018.3

[Manjukumar Harthikote Matha]

Hi Mike,



We tested by loading  both the vivado generated and bootgen generated 
bitstreams using 2018.3 and it worked fine, we are able to see Done and leds 
glowing as per our design.

Is it a custom board or zcu102?



Do you need this patch on thud?

https://github.com/Xilinx/meta-xilinx/commit/2c98fa11ccf33b6d9a550bebf50d2a2a876f9afb



Thanks,

Manju





> -Original Message-

> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-

> boun...@yoctoproject.org] On Behalf Of Mike Looijmans

> Sent: Wednesday, March 13, 2019 6:10 AM

> To: meta-xil...@lists.yoctoproject.org

> Subject: [meta-xilinx] Loading FPGA firmware broken in 2018.3

>

> With the 2018.1 version of u-boot, atf and pmu this worked okay.

>

> With the "thud" release and 2018.3, loading the FPGA no longer works:

>

> ZynqMP> load mmc $sdbootdev:2 0x10 /lib/firmware/fpga.bin

> 19311092 bytes read in 1900 ms (9.7 MiB/s)

> ZynqMP> fpga load 0 0x10 $filesize

> ZynqMP> md 0x10

> 0010:    

> 00100010:    

> 00100020:    

> 00100030:    

> 00100040: 00bb 11220044  D.".

> 00100050: aa995566 2000 2000 30022001fU. ... . .0

> 00100060:  30020001  30008001...0...0

> 00100070:  2000 30008001 0007... ...0

> 00100080: 2000 2000 30002001 ... ... . .0

> 00100090: 30026001  30012001 38003fe5.`.0. .0.?.8

> 001000a0: 3001c001 0040 30018001 04a5a093
> ...0..@0

> 001000b0: 30008001 0009 2000 3000c001...0... ...0

> 001000c0: 0001 3000a001 0101 3000c001...0...0

> 001000d0:  30030001  2000...0...

> 001000e0: 2000 2000 2000 2000... ... ... ...

> 001000f0: 2000 2000 2000 30002001... ... ... . .0

> ZynqMP>

>

>

> No error is displayed, but the FPGA remains unprogrammed (as indicated by the

> PROG_DONE pin).

>

> Reverting to previous sumo version makes it work again.

> --

> ___

> meta-xilinx mailing list

> meta-xilinx@yoctoproject.org

> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [xilinx-tools] Why does it require Rocko?

[Manjukumar Harthikote Matha]

Hi Geoff,

The only needed patch for Thud is the devicetree patch, which we had sent as 
RFC. Meta-xilinx-tools currently does not follow Yocto releases at this point 
of time, it is following Vivado release hence it is approx. 4months behind 
Yocto release.

RFC patch is here:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-February/004250.html

Are you witnessing any issue other than device-tree?

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Geoff Gillett
Sent: Wednesday, March 20, 2019 8:53 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] [xilinx-tools] Why does it require Rocko?


Hi,



We are a new applied science lab using Zynq's to embed our data acquisition and 
control systems. We find the ability to use the xilinx-tools layer very useful 
as it allows non HDL experts to configure hardware through the Vivado block 
diagram, then Yocto builds the custom OS for our embedded nodes. This would 
enable our science teams  to create not only the science package but the 
embedded instrumentation and control without detailed expertise in embedded 
Linux or HDL.



Our issue is we would like to track the Python releases, Yocto appears to have 
fixed the issues it had with Python tracking in the Thud release, but 
xilinx-tools appears to be stuck at Rocko.



We wonder what underlying problems are causing this?  We would like to 
investigate fixing it, first we would need to know what the issues are.



My understanding is:

  *   Yocto is a build system based on layers of recipes that construct 
components.
  *   xilinx-tools is a layer of recipes for building the device-tree and other 
BSP components using Xilinx's proprietary tools.
What I don't understand is why the recipes in xilinx-tools can't be handled by 
more recent versions of Yocto.

Does xilinx-tools work with more recent Yocto versions than Rocko?
I have a basic version of a build system working based on the 2018.3 Xilinx 
releases but have not tried upgrading Yocto/openembedded versions.

Cheers,
Geoff Gillett.
Senior Scientist, Quantum Valley Ideas Laboratories.


-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Fwd: [OE-core] [thud][PATCH] yocto-uninative: Correct sha256sum for aarch64

[Manjukumar Harthikote Matha]

Hi Philip,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Philip Balister
> Sent: Wednesday, March 13, 2019 7:15 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Fwd: [OE-core] [thud][PATCH] yocto-uninative: Correct
> sha256sum for aarch64
> 
> Mike does this help?
> 

We are using v2.6.1 and don't see the issue. Is this very specific to a Host 
OS/CPU?

Thanks,
Manju

> 
>  Forwarded Message 
> Subject: [OE-core] [thud][PATCH] yocto-uninative: Correct sha256sum for
> aarch64
> Date: Tue, 12 Mar 2019 21:03:44 -0700
> From: Robert Joslyn 
> To: openembedded-c...@lists.openembedded.org
> 
> From: Michael Halstead 
> 
> Avoid uninative checksum warnings when building on aarch64 hardware.
> 
> Signed-off-by: Michael Halstead 
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/distro/include/yocto-uninative.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/distro/include/yocto-uninative.inc
> b/meta/conf/distro/include/yocto-uninative.inc
> index c9d502ba4f..0d484f6c3c 100644
> --- a/meta/conf/distro/include/yocto-uninative.inc
> +++ b/meta/conf/distro/include/yocto-uninative.inc
> @@ -9,7 +9,7 @@
>  UNINATIVE_MAXGLIBCVERSION = "2.28"
>   UNINATIVE_URL ?=
> "http://downloads.yoctoproject.org/releases/uninative/2.3/;
> -UNINATIVE_CHECKSUM[aarch64] ?=
> "b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
> +UNINATIVE_CHECKSUM[aarch64] ?=
> "e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
>  UNINATIVE_CHECKSUM[i686] ?=
> "44253cddbf629082568cea4fff59419106871a0cf81b4845b5d34e7014887b20"
>  UNINATIVE_CHECKSUM[x86_64] ?=
> "c6954563dad3c95608117c6fc328099036c832bbd924ebf5fdccb622fc0a8684"
>  -- 2.19.2
> 
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH v2] kernel-module-mali: add patch to check dma_map_page error

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Hyun Kwon
> Sent: Tuesday, March 12, 2019 11:24 AM
> To: Jean-Francois Dagenais ; meta-
> xil...@lists.yoctoproject.org
> Cc: Madhurkiran Harikrishnan 
> Subject: Re: [meta-xilinx] [PATCH v2] kernel-module-mali: add patch to check
> dma_map_page error
> 
> Hi JFD,
> 
> + Mads
> 
> Thanks for the patch.
> 
> > -Original Message-
> > From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com]
> > Sent: Tuesday, March 12, 2019 11:17 AM
> > To: meta-xil...@lists.yoctoproject.org
> > Cc: Hyun Kwon ; Jean-Francois Dagenais
> > 
> > Subject: [PATCH v2] kernel-module-mali: add patch to check
> > dma_map_page error
> >
> > This fixes an error when using the module in a kernel configured with
> > the CONFIG_DMA_API_DEBUG flag.
> >
> > utgard fd4b.gpu: DMA-API: device driver failed to check map
> > error[device address=0x325b] [size=4096 bytes] [mapped as
> > page] ...
> >  [] check_unmap+0x44c/0x7e8  []
> > debug_dma_unmap_page+0x60/0x68  []
> > mali_mem_os_alloc_pages+0x230/0x498 [mali] ...
> >
> > Acked-by: Hyun Kwon 
> > Signed-off-by: Jean-Francois Dagenais 
> > ---
> >  .../recipes-graphics/mali/kernel-module-mali.bb |  1 +
> >  .../0007-fix-driver-failed-to-check-map-error.patch | 17
> > +
> >  2 files changed, 18 insertions(+)
> >  create mode 100644
> > meta-xilinx-bsp/recipes-graphics/mali/kernel-module-
> > mali/0007-fix-driver-failed-to-check-map-error.patch
> >
> > diff --git
> > a/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb
> > b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb
> > index 0f44d25..5833239 100644
> > --- a/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb
> > +++ b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb
> > @@ -16,6 +16,7 @@ SRC_URI = " \
> > file://0004-staging-mali-r8p0-01rel0-Don-t-include-
> > mali_read_phy.patch \
> > file://0005-linux-mali_kernel_linux.c-Handle-clock-when-probed-
> > a.patch \
> > file://0006-arm.c-global-variable-dma_ops-is-removed-from-the-
> > ke.patch \
> > +   file://0007-fix-driver-failed-to-check-map-error.patch \
> > file://0010-common-mali_pm.c-Add-PM-runtime-barrier-after-
> > removi.patch \
> > file://0011-linux-mali_kernel_linux.c-Enable-disable-clock-for-
> > r.patch\
> > "
> 
> I'm still not sure why this list looks different here, unless I'm missing 
> something:
> 
> https://github.com/Xilinx/meta-xilinx/blob/rel-v2018.3/meta-xilinx-bsp/recipes-
> graphics/mali/kernel-module-mali.bb

This is based on Rocko release

> https://github.com/Xilinx/meta-xilinx/blob/master-next/meta-xilinx-bsp/recipes-
> graphics/mali/kernel-module-mali.bb
> 

master-next is WIP tree, may not be in sync with master.

> If that is the case, it'll probably fail to apply.

The patch should be apply to master tree, if not it will fail

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Booting zcu102-zynqmp machine crashes in SPL

[Manjukumar Harthikote Matha]

Hi Sebastian,

Please see (SPL flow section )
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.building.md

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Sebastian Panceac
Sent: Friday, March 08, 2019 1:16 AM
To: meta-xil...@lists.yoctoproject.org
Subject: [meta-xilinx] Booting zcu102-zynqmp machine crashes in SPL

Hi,

I'm using the `meta-xilinx` layers to build the OS for the Xilinx ZCU102 board: 
https://www.xilinx.com/products/boards-and-kits/ek-u1-zcu102-g.html board.

I compiled for the "zcu102-zynqmp" Yocto machine.

In order for u-boot to build successfully I had to rename the symbolic link 
from "${DEPLOYDIR}/pmu-firmware-${MACHINE}.bin" to  
"${DEPLOYDIR}/pmu-${MACHINE}.bin" in the "do_install" task of 
"pmu-firmware_2017.3.bb recipe".

I used the "rel-v2018.3" branch of meta-xilinx.

I flashed a SD card with the boot files according to: 
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.booting.md#loading-via-sd
 but the boot process hangs in SPL with this stack trace:

 Debug uart enabled
"Synchronous Abort" handler, esr 0x9640
ELR: fffcaa3c
LR:  fffc774c
x0 : fdfd00011dfd0060 x1 : 
x2 : 02020202ffa0 x3 : 2000
x4 : fdfd00011dfd0068 x5 : 
x6 : 00405fffe0405ff4 x7 : 2008
x8 : 00ad x9 : 0080
x10: fffd x11: 0064
x12: fe6a x13: 098100080102
x14: ca99010442042023 x15: 0020890800101045
x16: 0001284017244083 x17: 002011001c040041
x18: 7e90 x19: 2000
x20:  x21: fdfd00011dfd0060
x22:  x23: 0001
x24: 7f20 x25: fffdaca8
x26: fffdb000 x27: fffd977a
x28:  x29: 7c10

Resetting CPU ...

### ERROR ### Please RESET the board ###

Also, is it mandatory to compile also "pmu-rom" for this board to boot?

Please advise! Thanks!



-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-tools][RFC] device-tree.bbappend: Changes needed to use upstream devicetree class

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Wednesday, February 27, 2019 12:04 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org; Jaewon Lee 
> Subject: Re: [meta-xilinx] [meta-xilinx-tools][RFC] device-tree.bbappend: 
> Changes
> needed to use upstream devicetree class
> 
> Hi Manjukumar, Jaewon,
> 
> On 26/02/19 04:07, Manjukumar Matha wrote:
> > From: Jaewon Lee 
> >
> > These are some changes needed to use upstream devicetree class. There
> > are some variable name changes as well as switching some script to
> > python from bash.
> >
> > Signed-off-by: Jaewon Lee 
> > Signed-off-by: Manjukumar Matha 
> > ---
> >  recipes-bsp/device-tree/device-tree.bbappend | 23 +++
> >  1 file changed, 11 insertions(+), 12 deletions(-)
> >
> > diff --git a/recipes-bsp/device-tree/device-tree.bbappend 
> > b/recipes-bsp/device-
> tree/device-tree.bbappend
> > index e077955..118688c 100644
> > --- a/recipes-bsp/device-tree/device-tree.bbappend
> > +++ b/recipes-bsp/device-tree/device-tree.bbappend
> > @@ -44,10 +44,10 @@ YAML_DT_BOARD_FLAGS_zcu104-zynqmp ?= "{BOARD
> zcu104-revc}"
> >  YAML_DT_BOARD_FLAGS_zcu111-zynqmp ?= "{BOARD zcu111-reva}"
> >  YAML_DT_BOARD_FLAGS_zc1275-zynqmp ?= "{BOARD zc1275-revb}"
> >
> > -DTS_FILES_PATH = "${XSCTH_WS}/${XSCTH_PROJ}"
> > -DTS_INCLUDE_append = " ${WORKDIR}"
> > +DT_FILES_PATH = "${XSCTH_WS}/${XSCTH_PROJ}"
> > +DT_INCLUDE_append = " ${WORKDIR}"
> >  DT_PADDING_SIZE = "0x1000"
> > -KERNEL_DTS_INCLUDE_append = " ${STAGING_KERNEL_DIR}/include"
> > +KERNEL_INCLUDE_append = " ${STAGING_KERNEL_DIR}/include"
> >
> >  COMPATIBLE_MACHINE_zynq = ".*"
> >  COMPATIBLE_MACHINE_zynqmp = ".*"
> > @@ -57,21 +57,20 @@ SRC_URI_append_ultra96-zynqmp =
> "${@bb.utils.contains('MACHINE_FEATURES', 'mipi'
> >
> >  do_configure_append_ultra96-zynqmp() {
> >  if [ -e ${WORKDIR}/mipi-support-ultra96.dtsi ]; then
> > -   cp ${WORKDIR}/mipi-support-ultra96.dtsi 
> > ${DTS_FILES_PATH}/mipi-
> support-ultra96.dtsi
> > -   echo '/include/ "mipi-support-ultra96.dtsi"' >>
> ${DTS_FILES_PATH}/system-top.dts
> > +   cp ${WORKDIR}/mipi-support-ultra96.dtsi 
> > ${DT_FILES_PATH}/mipi-
> support-ultra96.dtsi
> > +   echo '/include/ "mipi-support-ultra96.dtsi"' >>
> ${DT_FILES_PATH}/system-top.dts
> >  fi
> >  }
> >
> > -
> > -do_compile_prepend_kc705-microblazeel() {
> > -   cp ${WORKDIR}/system-conf.dtsi ${DTS_FILES_PATH}
> > -   cp ${WORKDIR}/kc705-microblazeel.dts ${DTS_FILES_PATH}
> > -}
> 
> The log message does not explain why this change it is needed. It also
> looks unrelated to the rest of the changes so it might be worth a
> separate commit.
> 

The upstream class moved to python based from bash functions. We cannot move it 
to a different patch, we can explain better in the commit message

> >  do_compile_prepend() {
> > -   [ -e ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts
> > +listpath = d.getVar("DT_FILES_PATH")
> > +try:
> > +os.remove(os.path.join(listpath, "system.dts"))
> > +except OSError:
> > +pass
> 
> Oh dear, Python is usually very concise but there are clearly
> exceptions. Any python expert knows a more concise way to do 'rm -f
> $FILE' in python? Otherwise of course this code is OK.
> 

I think there is a better way than this one, we are looking into it

Thanks for feedback.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZCU102 boot issue

[Manjukumar Harthikote Matha]

Hi Mike,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> Sent: Friday, February 01, 2019 12:19 AM
> To: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] ZCU102 boot issue
> 
> On 30-01-19 14:13, Jean-Francois Dagenais wrote:
> > Hi guys,
> >
> >> On Jan 28, 2019, at 14:39, Manjukumar Harthikote Matha
> >> mailto:manju...@xilinx.com>> wrote:
> >>
> >> Hi Alex,
> >> You need additional patches on pmu-firmware
> >> See:https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January
> >> /004198.html
> >
> > Manju, thanks for your patience and diligence in answering this yet another 
> > time.
> >
> > In my experience, when such an issue is raised again and again, it
> > means it will not go away and it costs a lot in loss of time, money
> > and most importantly, spirit ;)
> >
> > I know it's been discussed before too but if I may add my 2 cents: Am
> > I missing something or without manually patching pmu-firmware, the
> > boards in the meta-xilinx-bsp will not function because of the missing
> > config object? (I still use meta-xilinx-tools so I actually don't
> > know.)  Doesn't this mean Xilinx doesn't fully support the open-source
> > workflow? Or is just the word "support" that should be replaced with
> > "participates"? (In which case it is indeed directly responsible for
> > it)
> >
> > I remember problems with the licensing, but there has to be a
> > solution. Even if not elegant, once automated in yocto recipes, it's
> > better than nothing and a broken board after 5 hours of building!
> >
> > And if this is still not possible, to help people find the very
> > un-obvious source of their issues, perhaps PMU firmware could suffix
> > "(no cfg obj)" to its version? Or anything else printed early which
> > will help people find a xilinx wiki page explaining the problem and the 
> > solutions
> available.
> >
> 
> Simplest solution here would be to just integrate that "default config" patch 
> into the
> standard PMU firmware and then all boards will just boot. It won't prevent 
> the FSBL
> changing the config, so that flow isn't affected negatively.
> 

Please do send a patch if you have for pmu-firmware "default config". We will 
take a look at having them integrated.

> If licensing of my patch is an issue, I'm happy to change the license from 
> GPL into
> whatever Xilinx needs it to be to be able to integrate it.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] xsct-tarball: use fetcher cache

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Jean-Francois Dagenais
> Sent: Thursday, March 07, 2019 8:39 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] [PATCH] xsct-tarball: use fetcher cache
> 
> Without it, whenever a build starts on a fresh tmp directory, the file is 
> actually
> downloaded from http://petalinux.xilinx.com each time. Even though it might 
> be in
> the local download dir or in the SOURCE_MIRROR_URL specified mirror. This
> unnecessarily slows down build bootstrap and puts burden on xilinx.com 
> servers.
> 

Thanks JFD for the patch

> Signed-off-by: Jean-Francois Dagenais 
> ---
>  classes/xsct-tarball.bbclass | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/classes/xsct-tarball.bbclass b/classes/xsct-tarball.bbclass index
> c5a1b74..bc321a9 100644
> --- a/classes/xsct-tarball.bbclass
> +++ b/classes/xsct-tarball.bbclass
> @@ -1,7 +1,7 @@
>  XSCT_LOADER ?= "${XSCT_STAGING_DIR}/SDK/${XILINX_VER_MAIN}/bin/xsct"
> 
> -XSCT_URL ?= "http://petalinux.xilinx.com/sswreleases/rel-v2018.3/xsct-trim/;
> -XSCT_TARBALL ?= "xsct.tar.xz"
> +XSCT_URL ?= "http://petalinux.xilinx.com/sswreleases/rel-v2018.3/xsct-
> trim/xsct.tar.xz"
> +XSCT_TARBALL ?= "xsct_${XILINX_VER_MAIN}.tar.xz"
>  XSCT_DLDIR ?= "${DL_DIR}/xsct/"
>  XSCT_STAGING_DIR ?= "${STAGING_DIR}-xsct"
> 
> @@ -70,9 +70,10 @@ python xsct_event_extract() {
>  localdata = bb.data.createCopy(d)
>  localdata.setVar('FILESPATH', "")
>  localdata.setVar('DL_DIR', xsctdldir)
> -srcuri = d.expand("${XSCT_URL}${XSCT_TARBALL};md5sum=%s" %
> chksum_tar)
> +srcuri = d.expand("${XSCT_URL};md5sum=%s;downloadfilename=%s"
> +   % (chksum_tar, tarballname))
>  bb.note("Fetching xsct binary tarball from %s" % srcuri)
> -fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
> +fetcher = bb.fetch2.Fetch([srcuri], localdata)
>  fetcher.download()
>  localpath = fetcher.localpath(srcuri)
>  if localpath != tarballpath and os.path.exists(localpath) and not
> os.path.exists(tarballpath):
> --
> 2.11.0
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Ultra 96 support

[Manjukumar Harthikote Matha]

Hi Philip,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Philip Balister
> Sent: Monday, March 04, 2019 11:31 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Ultra 96 support
> 
> I've started looking at the Ultra 96 patches from way back and have a few
> comments, all against master:
> 
> 
> The file
> meta-xilinx-bsp/recipes-microblaze/gcc/gcc-source_7.%.bbappend
> b/meta-xilinx-bsp/recipes-microblaze/gcc/gcc-source_7.%.bbappend
> no longer has a file to append.
> 

We will have a RFC ready hopefully end of week on GCC8. It is under regression 
test run.

> A tune file has been renamed:
> 
> -require conf/machine/include/arm/arch-armv8.inc
> +require conf/machine/include/arm/arch-armv8a.inc
> 

This patch is sent on mailing list


> Nothing provides:
> 
> -   virtual/pmu-firmware \
> 
> 
> And U-boot isn't building, not sure why. This seems to be the porblem:
> 
> ake[4]: 'arch/arm/dts/zynqmp-zcu100-revC.dtb' is up to date.
> test -e arch/arm/dts/zynqmp-zcu100-revC.dtb || (
> 
> \
> echo >&2;   \
> echo >&2 "Device Tree Source is not correctly specified.";  \
> echo >&2 "Please define 'CONFIG_DEFAULT_DEVICE_TREE'";  \
> echo >&2 "or build with 'DEVICE_TREE=' argument";  \
> echo >&2;   \
> /bin/false)
> make -f
> /home/balister/opensdr/zynq/ultra96/sdr-build-ultra96/build/tmp-
> glibc/work/ultra96_zynqmp-oe-linux/u-boot-xlnx/v2018.01-xilinx-
> v2018.3+gitAUTOINC+d8fc4b3b70-r0/git/scripts/Makefile.build
> obj=spl/drivers/clk
> make -f
> /home/balister/opensdr/zynq/ultra96/sdr-build-ultra96/build/tmp-
> glibc/work/ultra96_zynqmp-oe-linux/u-boot-xlnx/v2018.01-xilinx-
> v2018.3+gitAUTOINC+d8fc4b3b70-r0/git/scripts/Makefile.build
> obj=spl/drivers/core
> ( cd
> /home/balister/opensdr/zynq/ultra96/sdr-build-ultra96/build/tmp-
> glibc/work/ultra96_zynqmp-oe-linux/u-boot-xlnx/v2018.01-xilinx-
> v2018.3+gitAUTOINC+d8fc4b3b70-r0/git
> && test -r ../../../../../..//.bin ) \
> || ( echo "Cannot read ../../../../../..//.bin" && false ) Cannot read
> ../../../../../..//.bin
> 
> 

Will check on this

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Syntax issue with device-tree using thud

[Manjukumar Harthikote Matha]

Hi Christian,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Christian Dreher
> Sent: Friday, February 22, 2019 11:50 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Syntax issue with device-tree using thud
> 
> Hi,
> 
> I tried to use meta-xilinx on thud branch, and I got some "SyntaxError: 
> invalid syntax"
> on meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> 
> It comes with the changes on meta-xilinx SHA1:
> b6f2540b0ab22dba8b90e68f4151e865483d51d9 "device-tree: Consolidate device-
> tree recipe and append"
> 
> I read in the commit message it depends on openembedded-core/meta, but I fetch
> it, branch thud, from github, which is up-to-date with git.openembedded.org
> 
> If I revert the commit, the recipe parsing passes (but uboot-xlnx fails on 
> some step
> related to device trees), but I don't really understand where to fix the 
> recipe.
> 
> I know I'm a bit ahead of what Xilinx officially supports (rel-v2018.3 is 
> told to be
> based on Rocko), and for know, what I do works on sumo, but I would like to 
> know if
> the issue is on my side, or if it is known and will be fixed later.
> 
> If it works on your computer and you need my setup, I made something near, 
> that
> allows me to reproduce the issue:
> It's based on linaro's Open Embedded Reference Platform Build for 96boards, I 
> just
> added meta-xilinx (thud) and meta-xilinx-tools (2018.3)
> 
> (assuming you're in an empty folder and you've got repo (the android tool) in 
> your
> path) repo init -u https://github.com/dreherch/oe-rpb-manifest -b thud repo 
> sync -
> j16 MACHINE=zcu102-zynqmp DISTRO=rpb source setup-environment bitbake core-
> image-minimal
> 
> you can find the repo manifest it uses directly here:
> https://github.com/dreherch/oe-rpb-manifest/blob/thud/default.xml
> 
> The error log looks as follow:
> ERROR: Unable to parse /home/cdreher/REPO/rpb-github/build-
> rpb/conf/../../layers/meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-
> tree.bb
> Traceback (most recent call last):
>   File "/home/cdreher/REPO/rpb-github/bitbake/lib/bb/siggen.py", line 134, in
> SignatureGeneratorOEBasicHash.finalise(fn='/home/cdreher/REPO/rpb-github/build-
> rpb/conf/../../layers/meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-
> tree.bb', d=, variant=None):
>  try:
> >taskdeps = self._build_data(fn, d)
>  except bb.parse.SkipRecipe:
>   File "/home/cdreher/REPO/rpb-github/bitbake/lib/bb/siggen.py", line 111, in
> SignatureGeneratorOEBasicHash._build_data(fn='/home/cdreher/REPO/rpb-
> github/build-rpb/conf/../../layers/meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-
> tree/device-tree.bb', d=):
>  ignore_mismatch = ((d.getVar("BB_HASH_IGNORE_MISMATCH") or '') 
> == '1')
> >tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)
> 
>   File "/home/cdreher/REPO/rpb-github/bitbake/lib/bb/data.py", line 394, in
> generate_dependencies(d=):
>  for task in tasklist:
> >deps[task], values[task] = build_dependencies(task, keys, 
> shelldeps,
> varflagsexcl, d)
>  newdeps = deps[task]
>   File "/home/cdreher/REPO/rpb-github/bitbake/lib/bb/data.py", line 327, in
> build_dependencies( [Insert 57kB of key/values here]
>  logger.warning("Variable %s contains tabs, please 
> remove these (%s)"
> % (key, d.getVar("FILE")))
> >parser.parse_python(value, 
> filename=varflags.get("filename"),
> lineno=varflags.get("lineno"))
>  deps = deps | parser.references
>   File "/home/cdreher/REPO/rpb-github/bitbake/lib/bb/codeparser.py", line 
> 327, in
> PythonParser.parse_python(node="\n\t[ -e ${DTS_FILES_PATH}/system.dts ] && rm
> ${DTS_FILES_PATH}/system.dts\nbb.build.exec_func('devicetree_do_compile',
> d)\n", lineno=1, filename='autogenerated'):
>  code = compile(check_indent(str(node)), filename, "exec",
> >   ast.PyCF_ONLY_AST)
> 
>   File "autogenerated", line 2
> [ -e ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts
>  ^ (the ^ is under the first $ sign)
> SyntaxError: invalid syntax
> 

We have sent a RFC to mailing list, please have a look

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] kernel-module-mali: check and honour dma_unmap_page exit code

[Manjukumar Harthikote Matha]

Hi JFD,

Please send v2 with correction suggested by Hyun

Thanks,
Manju
From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Jean-Francois 
Dagenais
Sent: Friday, February 22, 2019 5:04 AM
To: Hyun Kwon 
Cc: meta-xil...@lists.yoctoproject.org; Hyun Kwon 
Subject: Re: [meta-xilinx] [PATCH] kernel-module-mali: check and honour 
dma_unmap_page exit code

Hi Hyun,


On Feb 21, 2019, at 17:25, Hyun Kwon 
mailto:hyun.k...@xilinx.com>> wrote:

Hi Jean-Francois,

Thanks for the patch.

On Tue, 2019-02-19 at 09:16:46 -0800, Jean-Francois Dagenais wrote:

Sorry, the subject should be:

kernel-module-mali: check and honour dma_map_page exit code

instead of "dma_UNmap_page"

Why using upper case, 'UN'?

It was just emphasis on what the mistake on the commit headline was... trying 
to remove the subtlety.






On Feb 19, 2019, at 10:39, Jean-Francois Dagenais 
mailto:jeff.dagen...@gmail.com>> wrote:

This fixes an error when using the module in a kernel configured with
the CONFIG_DMA_API_DEBUG flag.

utgard fd4b.gpu: DMA-API: device driver failed to check map error[device 
address=0x325b] [size=4096 bytes] [mapped as page]
...
[] check_unmap+0x44c/0x7e8
[] debug_dma_unmap_page+0x60/0x68
[] mali_mem_os_alloc_pages+0x230/0x498 [mali]
...

Signed-off-by: Jean-Francois Dagenais 
mailto:dagena...@sonatest.com>>

I believe the Yocto patch requires the upstreaming status. Please refer to
other patches. You can mark it as pending. Our team can share this to ARM
internally.

noted.




---
.../recipes-graphics/mali/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fkernel-module-mali.bb=E,1,7H1c4ml0nbgV5Y-a8ex5Nz-45BClZi0HAb8rSq_LVyywEvSS_hmK5Elx6jiQ69wE9_E1QeXVcbkuLM3wVzF94BmsSb6qcaxlV72Yhev6VOpD-Va8ik99UVY,=1
  |  1 +
.../0007-fix-driver-failed-to-check-map-error.patch  | 16 
2 files changed, 17 insertions(+)
create mode 100644 
meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0007-fix-driver-failed-to-check-map-error.patch

diff --git 
a/meta-xilinx-bsp/recipes-graphics/mali/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fkernel-module-mali.bb=E,1,_43jl_v77hUeZ715j6nn3vef5fYyi5F8RndfWf7jFiMkSoYFNOFmaBY-eCWB04sK6Rs2xuAQXQQLPfB3DR-4vTWdAeyhs1FG88HNCPpxRT4IBMFxfpo,=1
 
b/meta-xilinx-bsp/recipes-graphics/mali/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fkernel-module-mali.bb=E,1,JaZ3yJLlmgR_Qe9c3t82B8aU2fH7lMmTxdGS2rEmZdyNWYlZXRBMelmmmJNcH07ltvr8DLau5iRr3aHww_esitrJ74H-z6N3l499VbXohkosRapNSkht=1
index 0f44d25..5833239 100644
--- 
a/meta-xilinx-bsp/recipes-graphics/mali/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fkernel-module-mali.bb=E,1,JqkVEZw5PLC_acDxcaxe3EmRTDzQtpfOF0S4ihWN30-lP3msD4vK_acCQ9sKuS5qgR16izABptBPu3V1ZiG5Asv_MlTX6zV8I0Sis_DkCyxAetfsx3tIR_xQvQ,,=1
+++ 
b/meta-xilinx-bsp/recipes-graphics/mali/https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fkernel-module-mali.bb=E,1,BrH3PiHKnMb_dJfDtP8QdTfn_a_1u4u6-Op5vJEWvlZOpwm8o6Girdnwajqk5AnN4y9nDiNOQlDSJVCmnVqNSjABPOdFOeXlvF-4gujGyfw,=1
@@ -16,6 +16,7 @@ SRC_URI = " \
 
file://0004-staging-mali-r8p0-01rel0-Don-t-include-mali_read_phy.patch
 \
 
file://0005-linux-mali_kernel_linux.c-Handle-clock-when-probed-a.patch
 \
 
file://0006-arm.c-global-variable-dma_ops-is-removed-from-the-ke.patch
 \
+   
file://0007-fix-driver-failed-to-check-map-error.patch
 \

This list is different from what I see in the head. There's no empty index
there. Then this can be 0012. Maybe we are looking at differnt branches. Please
confirm.

You mean meta-xilinx/master? I will check and apply there with proper sequence 
number.




 
file://0010-common-mali_pm.c-Add-PM-runtime-barrier-after-removi.patch
 \
 
file://0011-linux-mali_kernel_linux.c-Enable-disable-clock-for-r.patch\
 "
diff --git 
a/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0007-fix-driver-failed-to-check-map-error.patch
 
b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0007-fix-driver-failed-to-check-map-error.patch

It would be better to make this as a git commit than just diff. I'm not sure if
there's any guideline for that though.

Indeed, however what the kernel-module-mali recipe downloads is not a git repo 
but a tarball (.tgz). If the tar extracted directory structure is the same as 
their git repo's, I can create it as a commit patch and cross my fingers.




new file mode 100644
index 000..f553e58
--- /dev/null
+++ 
b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0007-fix-driver-failed-to-check-map-error.patch
@@ -0,0 +1,16 @@
+Index: mali/linux/mali_memory_os_alloc.c
+===
+--- mali.orig/linux/mali_memory_os_alloc.c
 mali/linux/mali_memory_os_alloc.c
+@@ -239,8 +239,9 @@ int mali_mem_os_alloc_pages(mali_mem_os_
+  /* Ensure page is flushed from CPU caches. */
+  dma_addr 

Re: [meta-xilinx] [PATCH v2] Add support for Z-turn board

[Manjukumar Harthikote Matha]

Hi Anton,

> -Original Message-
> From: tos...@gmail.com [mailto:tos...@gmail.com]
> Sent: Saturday, January 26, 2019 1:48 PM
> To: meta-xil...@lists.yoctoproject.org; Manjukumar Harthikote Matha
> 
> Cc: Anton Gerasimov 
> Subject: [PATCH v2] Add support for Z-turn board
> 
> From: Anton Gerasimov 
> 
> Signed-off-by: Anton Gerasimov 
> ---
>  meta-xilinx-bsp/conf/machine/zturn-zynq7.conf |34 +
>  .../platform-init/platform-init.bb| 1 +
>  .../platform-init/zturn-zynq7/ps7_init_gpl.c  | 13170 
>  .../platform-init/zturn-zynq7/ps7_init_gpl.h  |   137 +
>  ...fig-extend-the-bootstrap-malloc-pool.patch |47 +
>  .../recipes-bsp/u-boot/u-boot_%.bbappend  | 3 +
>  ...ts-zynq-Add-support-for-Z-turn-board.patch |   152 +
>  .../recipes-kernel/linux/linux-xlnx.inc   | 2 +
>  8 files changed, 13546 insertions(+)
>  create mode 100644 meta-xilinx-bsp/conf/machine/zturn-zynq7.conf
>  create mode 100644 
> meta-xilinx-bsp/recipes-bsp/platform-init/platform-init/zturn-
> zynq7/ps7_init_gpl.c
>  create mode 100644 
> meta-xilinx-bsp/recipes-bsp/platform-init/platform-init/zturn-
> zynq7/ps7_init_gpl.h

Can you upstream the psu files to u-boot as well? Ideally we don't want to hold 
the psu files in layers.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] libmali and wayland

[Manjukumar Harthikote Matha]

Hi JFD and all,

Thanks for the feedback.

We introduced rebase tree in linux-xlnx to make it easier for holding or 
migrating patches (custom or development patches).
If there are issues that are found, please do let us know asap via mailing list.
We will try to address/replicate the issue and see if we can post RFC patches 
earlier to fix those issues.

Honestly, I do like pull-request, but github PR still lacks certain features to 
be in sync with YP requirements ( for ex: Maintainer signed-off etc).
I am definitely open to having github issues to fix the bugs (for meta layers).

We will make good effort towards maintaining a master-next to show-case 
upcoming work.

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Jean-Francois 
Dagenais
Sent: Wednesday, February 20, 2019 6:02 AM
To: Mike Looijmans ; meta-xil...@lists.yoctoproject.org
Cc: Luca Ceresoli ; Simon Labarre 
Subject: Re: [meta-xilinx] libmali and wayland




On Feb 20, 2019, at 06:01, Mike Looijmans 
mailto:mike.looijm...@topic.nl>> wrote:

+1 for that!

(and not just on meta-xilinx, but on kernel, u-boot, and other repositories as
well)

These "big blob" changes are impossible to manage.

Indeed. Here's a concrete example:

I had to integrate the audio on our board. Our design called for the xilinx_dma 
driver to come into play. When I started using the cyclic mode with the audio I 
found it was (and still is I believe) completely broken/non-functional. I spent 
a week and a half working on xilinx_dma.c. I meticulously fixed the different 
issues I saw, cleaned up a whole bunch of stuff and carefully created a nice 
series of commits so that it could be discussed and applied.

I was carrying this in our repo awaiting a closely upcoming release. To my 
dismay, xilinx_dma.c had a complete overhaul appear in github's linux-xlnx upon 
the release and to add insult to injury, the commits which were finally 
deposited on the repo pre-dated my work!

I could no longer afford to spend time on this and I ended up copy/renaming the 
xilinx_dma.c file and we are using an un mergeable fork. Basically, the Xilinx 
workflow means it has completely missed the point of open-source and the 
benefits that come with it.

This story has knocked me pretty hard and I can echo all the pains that the 
others on this thread have raised.

I understand that there may be legal issues here. But perhaps there are ways to 
mitigate their constraints. For example, since it's git, xilinx could setup 
different branches or even whole repos with README.md specifying the terms of 
usage of the repo. For example, a whole github space called xilinx-community?

The community repos could be used as open spaces where bleeding edge is worked 
on and discussed collaboratively until deemed sufficiently mature to be merged 
(or applied) back to the official releases repo. Some people, such as we at 
Sonatest, would live on the master most of the development cycle, contributing 
back periodically.

And please, PLEASE, if Xilinx wants more help and freebies, let's use the 
issues and pull request mechanisms instead of the clunky patches! Or 
gitlab.com's merge requests (We're gitlab here). Patch 
management is completely un-natural and discourages MANY developers to get 
involved. Basically, all these companies combing through Xilinx's code are a 
gold mine of contributions and bug fixes. One would think that Xilinx would 
make it SUPER easy for them to report and even fix things. No real changes can 
go in without Xilinx admins going through a full review and adjustment process 
anyway... so what's the obstacle? It's available and free (right?), if not on 
github then on gitlab.



Also adds some benefix for Xilinx, as it prevents that Xilinx's implementation
gets completely thrown out just because some other manufacturer beat them to
the punch.

Well in this case, Sonatest got it efforts thrown out. We here are lucky, my 
employer shares my views on open-source and community but it does have a limit, 
and I suspect this type of experience might chill others which may have been 
hesitant in the first place to invest workforce resources into giving back to 
other parties.

Anyway, I fully appreciate that Xilinx has come a long way with open-source and 
seeing all the love and care Manju, Michal, Kwon, and many other Xilinx 
employees are putting into this I am confident that things will continue to 
improve.

Thanks Xilinx!
Cheers!
/jfd
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] yocto for pynq

[Manjukumar Harthikote Matha]

Hi All,

We are working towards getting PYNQ layer to Yocto. This is targeted for next 
Yocto release in Sept

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Jean-Francois 
Dagenais
Sent: Wednesday, February 13, 2019 8:58 AM
To: Ahmadmunthar Zaklouta 
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] yocto for pynq




On Feb 13, 2019, at 09:39, Ahmadmunthar Zaklouta 
mailto:zaklo...@kth.se>> wrote:

I am new to Yocto and i have been folowing a tutorial on building image for 
zedboard but i only have a pynq board. i checked the recipe for the zedboard 
and the repo for the pynq board in attempt to try to understand and fix a 
recipe but i didn't understand any thing.

is there any one interested in this topic so we can try to make one or can some 
one guide me how and where to start.


Hi,

Yocto is a big beast indeed. Take it one day at a time. Lots of documentation 
on yoctoproject.org and books also, "Learning Embedded 
Linux Using the Yocto Project" is fine.

Look in the meta-xilinx mailing list archive for patches like "Add support for 
xyz board", this should give you clues to add a new board in the layer (or your 
own layer).

I think there has been a discussion on pynq too on the list. Matthew Clark was 
working on pynq I believe last summer.


Good luck!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Using devicetree from devicetree.bbclass with fitimage?

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Philip Balister [mailto:phi...@balister.org]
> Sent: Thursday, January 24, 2019 4:49 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] Using devicetree from devicetree.bbclass with 
> fitimage?
> 
> On 01/23/2019 11:31 PM, Manjukumar Harthikote Matha wrote:
> > Hi Philip,
> >
> >> -Original Message-
> >> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> >> boun...@yoctoproject.org] On Behalf Of Philip Balister
> >> Sent: Wednesday, January 23, 2019 8:10 AM
> >> To: meta-xilinx@yoctoproject.org
> >> Subject: [meta-xilinx] Using devicetree from devicetree.bbclass with 
> >> fitimage?
> >>
> >> Subject pretty much says it all :)
> >>
> >> So the minized uses the devicetree bbclass to build the dtb file. But the 
> >> kernel-
> >> fitimage class expects the KERNEL_DEVICETREE variable to be set.
> >>
> >> How can I use the kernel-fitimage and devicetree bbclasses?
> >>
> >
> > Not straightforward, will send a patch as RFC to OE-core.
> 
> Thanks. Any ETA for that?
> 

Sent to OE-core mailing list, can you ACK if it works for you.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] meta-xilinx-standalone layer compat

[Manjukumar Harthikote Matha]

Hi Peter,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Peter Smith
> Sent: Monday, January 28, 2019 3:15 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] meta-xilinx-standalone layer compat
> 
> Is there any reason why the layer compat for meta-xilinx-standalone cannot be 
> set
> to sumo and thud (like meta-xilinx-bsp is)?
> 

Few things:
1- The layer has not been tested against sumo 
2 - newlib version is different in sumo
3 - meta-xilinx pmu firmware recipe is in meta-xilinx-bsp, whereas in thud it 
was removed to accommodate it in meta-xilinx-standalone

Thanks,
Manju


-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZCU102 boot issue

[Manjukumar Harthikote Matha]

Hi Alex,

You need additional patches on pmu-firmware
See: 
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004198.html

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Alexander Kerner
Sent: Monday, January 28, 2019 10:56 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] ZCU102 boot issue

Hello,

I've got a ZCU102 rev 1.1 board and I'm trying to build yocto using this howto: 
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.building.md

There is following error while booting:

U-Boot SPL 2018.01 (Jan 25 2019 - 21:16:27)
EL Level:   EL3
Trying to boot from MMC1
reading u-boot.bin
reading atf-uboot.ub
reading atf-uboot.ub
NOTICE:  ATF running on XCZU9EG/silicon v4/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x800
NOTICE:  BL31: v1.5(release):xilinx-v2018.3
NOTICE:  BL31: Built : 21:23:57, Jan 25 2019
PMUFW:  v1.1
zynqmp_clk_get_peripheral_rate mio read fail
failed to get rate
zynqmp_clk_get_peripheral_rate mio read fail
failed to get rate

I also tried to boot pre-build petalinux 2018.2 image and it worked fine.

Here is my build configuration:

BB_VERSION   = "1.40.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-poky-linux"
MACHINE  = "zcu102-zynqmp"
DISTRO   = "poky"
DISTRO_VERSION   = "2.6.1"
TUNE_FEATURES= "aarch64"
TARGET_FPU   = ""
meta
meta-poky
meta-yocto-bsp   = "thud:cc73390a75d98b96eb861ae0624283c1ea6ef1bd"
meta-xilinx-bsp
meta-xilinx-standalone
meta-xilinx-contrib  = "thud:c42016e2e6ca13e133fdb877785ec8aa2bd82f16"

Build Configuration:
BB_VERSION   = "1.40.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-poky-linux"
MACHINE  = "zcu102-zynqmp"
DISTRO   = "poky"
DISTRO_VERSION   = "2.6.1"
TUNE_FEATURES= "aarch64"
TARGET_FPU   = ""
meta
meta-poky
meta-yocto-bsp   = "thud:cc73390a75d98b96eb861ae0624283c1ea6ef1bd"
meta-xilinx-bsp
meta-xilinx-standalone
meta-xilinx-contrib  = "thud:c42016e2e6ca13e133fdb877785ec8aa2bd82f16"

Build Configuration:
BB_VERSION   = "1.40.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "microblazeel-xilinx-elf"
MACHINE  = "zynqmp-pmu"
DISTRO   = "xilinx-standalone"
DISTRO_VERSION   = "1.0"
TUNE_FEATURES= "microblaze v9.2 barrel-shift pattern-compare"
TARGET_FPU   = "fpu-soft"
meta
meta-poky
meta-yocto-bsp   = "thud:cc73390a75d98b96eb861ae0624283c1ea6ef1bd"
meta-xilinx-bsp
meta-xilinx-standalone
meta-xilinx-contrib  = "thud:c42016e2e6ca13e133fdb877785ec8aa2bd82f16"

Kind regards
Alex
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Wednesday, January 23, 2019 7:13 AM
> To: Scott Ellis ; Manjukumar Harthikote Matha
> ; meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp 
> boards
> 
> Hi Scott,
> 
> On 23/01/19 11:12, Scott Ellis wrote:
> > Hi Manju,
> >
> > Thanks for answering.
> >
> > I will look at the meta-xilinx-tools layer. I think I finally
> > understand what is required to boot.
> >
> > But I am still not clear on the meta-xilinx multiconfig...
> 
> Just to make sure we are on the same page, there are mainly two workflows with
> respect to booting on ZynqMP: using the Xilinx-specific bootloader (FSBL) and 
> tools
> (meta-xilinx-tools layer), OR using U-Boot SPL and a more standard yocto 
> setup. A
> few more details in section "Booting" here [0].
> 
> I suggest you first choose the workflow that is best for your needs.
> 
> > The meta-xilinx-bsp/README.building.md has no mention that a patch is
> > required to the pmu-firmware which is confusing.
> >
> > Is this just an omission?
> >
> > Is the pmu-firmware recipe useful without the patch?
> 
> Short answer: only with the Xilinx workflow.
> 
> Long answer:
> 
> The pmufw needs a "configuration object" to know what it should do, and it 
> expects
> to receive it at runtime.
> 
> In the Xilinx workflow the FSBL has a file called pm_cfg_obj.c built into 
> itself. It is the
> PMUFW configuration object, and FSBL passes it to PMUFW at runtime.
> 
> With the U-Boot SPL workflow there's no FSBL, and there are two problems:
>  1) passing a cfg obj to pmufw is just not implemented in U-Boot
>  2) the pm_cfg_obj.c file is generated by the Xilinx XSDK and its
> license is not compatible with the GPL license of U-Boot
> 
> Clearly problem 2 prevents from fixing problem 1. :(
> 
> To work around this problem a small patch has been developed so that 
> pm_cfg_obj.c
> is linked into pmufw and loaded directly, without waiting for it from the 
> outside. Find
> the original patch on the meta-topic layer [1] and the patch updated for pmufw
> 2018.x here [2].
> 
> > Excuse the dumb questions.
> 
> As you might guess from the reply, that was clearly not dumb at all! :)
> 
> Hope it helps.
> 
> [0]
> https://archive.fosdem.org/2018/schedule/event/arm64_and_fpga/attachments/sli
> des/2564/export/events/attachments/arm64_and_fpga/slides/2564/zynqmp_linux.p
> df
> 
> [1]
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-
> bsp/pmu-firmware/pmu-firmware_2017.%25.bbappend
> 
> [2]
> https://github.com/lucaceresoli/zynqmp-pmufw-builder/blob/master/0001-Load-
> XPm_ConfigObject-at-boot.patch
> 

Thanks for the information. I will add this to README 

Did you happen to get ZCU106 booting with config object as zcu102?

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Using devicetree from devicetree.bbclass with fitimage?

[Manjukumar Harthikote Matha]

Hi Philip,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Philip Balister
> Sent: Wednesday, January 23, 2019 8:10 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Using devicetree from devicetree.bbclass with fitimage?
> 
> Subject pretty much says it all :)
> 
> So the minized uses the devicetree bbclass to build the dtb file. But the 
> kernel-
> fitimage class expects the KERNEL_DEVICETREE variable to be set.
> 
> How can I use the kernel-fitimage and devicetree bbclasses?
> 

Not straightforward, will send a patch as RFC to OE-core.

We added a dependency on devicetree bbclass as virtual/dtb provider. The below 
patch is based on Rocko,
https://github.com/Xilinx/poky/commit/51fae3661a19b7202c2b12df806dced0948317e2

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards

[Manjukumar Harthikote Matha]

Hi Scott,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Scott Ellis
> Sent: Saturday, January 19, 2019 6:09 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
> 
> Is there a way to use the thud branch meta-xilinx-bsp and 
> meta-xilinx-standalone
> layers to build a bootable zynqmp system without having to use an external 
> patch to
> the pmu-firmware recipe?
> 

If following SPL you will need to patch the PMU firmware
Otherwise you can grab meta-xilinx-tools layer (2018.3) which will build pmu 
firmware using Xilinx tools

Thanks,
Manju

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] bitbake openamp-image-minimal fails to create image

[Manjukumar Harthikote Matha]

+meta-xilinx mailing list

From: Pandey, Kamal [mailto:kamal.pan...@ifm.com]
Sent: Monday, January 07, 2019 8:59 AM
To: yo...@yoctoproject.org; Manjukumar Harthikote Matha 
Subject: RE: bitbake openamp-image-minimal fails to create image

Hi,
I solved the problem by using meta-openamp(branch should be similar to xilinx 
version) layer in my yocto project and enabled "libmetal" and "open-amp" 
packages in my image recipe. It compiled successfully.  I also add 
rpmsg-echo-test,  rpmsg-mat-mul , and rpmsg-proxy-app packages in the image and 
it successfully compiled. I am building Linux Application that uses RPMsg in 
user space.
Now the executable generated from echo-test or mat-mul are in my host linux 
master (a53-core). I have also created an r5-application using XSDK.
What is the next step to have a communication between a53 and r5. How to use 
the generated elf file for r5 processor.
Also I have enabled remoteproc, rpmsg, virtio  in kernel configuration.
But while using the command " $modprobe zynqmp_r5_remoteproc", I get the 
following error:

"modprobe: module zynqmp_r5_remoteproc not found in modules.dep"

How can I boot the r5 processor and where to store the elf file generated.
From: Manjukumar Harthikote Matha 
mailto:manju...@xilinx.com>>
Sent: 07 January 2019 13:53
To: Pandey, Kamal mailto:kamal.pan...@ifm.com>>; 
yo...@yoctoproject.org<mailto:yo...@yoctoproject.org>
Subject: RE: bitbake openamp-image-minimal fails to create image

Hi Kamal,

Seems like the required kernel modules are missing causing the breakage.
Enable them using kernel menuconfig (bitbake virtual/kernel -c menuconfig) and 
then build the image

Thanks,
Manju

From: yocto-boun...@yoctoproject.org<mailto:yocto-boun...@yoctoproject.org> 
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of Pandey, Kamal
Sent: Sunday, January 06, 2019 11:14 PM
To: yo...@yoctoproject.org<mailto:yo...@yoctoproject.org>
Subject: [yocto] bitbake openamp-image-minimal fails to create image

Hello,
I used the meta-openamp layer for r5-a53 communication.
but when I simply ran $bitbake openamp-image-minimal, it gave me the following 
error:

ERROR: openamp-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command 
'/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/dnf
 -y -c 
/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/rootfs/etc/dnf/dnf.conf
 
--setopt=reposdir=/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/rootfs/etc/yum.repos.d
 
--repofrompath=oe-repo,/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/oe-rootfs-repo
 
--installroot=/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/rootfs
 
--setopt=logdir=/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/temp
 --nogpgcheck install kernel-module-virtio-ring kernel-module-virtio-rpmsg-bus 
kernel-module-uio-pdrv-genirq kernel-module-virtio libopen-amp0 
packagegroup-base-extended kernel-image-fitimage-4.14.79-yocto-standard 
run-postinsts libmetal packagegroup-core-boot kernel-module-remoteproc' 
returned 1:
Added oe-repo repo from 
/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/oe-rootfs-repo
Last metadata expiration check: 0:00:00 ago on Fri 04 Jan 2019 01:58:31 PM UTC.
No package kernel-module-virtio-ring available.
No package   available.
No package kernel-module-virtio available.
No package   available.
Error: Unable to find a match

ERROR: openamp-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/media/iepl/iepl1/work/yocto_build/build-open-amp/tmp/work/pdm3_rev_b_zynqmp-pdm3-linux/openamp-image-minimal/1.0-r0/temp/log.do_rootfs.7153
ERROR: Task 
(/home/iepl/work/yocto_build/poky/../meta-openamp/recipes-openamp/images/openamp-image-minimal.bb:do_rootfs)
 failed with exit code '1'


Can someone provide me a solution to this problem.
Thanks
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Thud branch release

[Manjukumar Harthikote Matha]

Hi All,

Happy New Year!

Thud release branch has been created for the 2.6 Yocto/OE. 

We have the following changes:

* meta-xilinx-standalone layer to enable baremetal distro. 
Please see the Readme to understand the multiconfig builds.
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/README.building.md

Alejandro will be the maintainer for this layer. Thanks Alejandro for pitching 
in

*Consolidated device-tree according to upstream device tree class.
Thanks Nathan for the patch upstream.

The layers can be obtained via either of the git repositories at:
 * Yocto Project - http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/
 * Xilinx - https://github.com/Xilinx/meta-xilinx

Thanks everyone who contributed to the Thud branch release.

Thanks,
Manju

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Thursday, December 20, 2018 2:44 AM
> To: Manjukumar Harthikote Matha ; Alejandro Enedino
> Hernandez Samaniego ; meta-xilinx@yoctoproject.org
> Cc: Mike Looijmans 
> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, 
> distro
> and machine to build standalone components
> 
> Hi Manjukumar, Alejandro,
> 
> On 19/12/18 04:28, Manjukumar Harthikote Matha wrote:
> > Hi Luca,
> >
> >> -Original Message-
> >> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> >> Sent: Tuesday, December 18, 2018 7:26 AM
> >> To: Alejandro Enedino Hernandez Samaniego ; meta-
> >> xil...@yoctoproject.org
> >> Cc: Mike Looijmans ; Manjukumar Harthikote Matha
> >> 
> >> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create 
> >> layer,
> distro
> >> and machine to build standalone components
> >>
> >> Hi Alejandro, Manju,
> >>
> >> On 11/12/18 23:16, Alejandro Enedino Hernandez Samaniego wrote:
> >>> Hey Luca,
> >>>
> >>>
> >>> On 12/11/2018 07:41 AM, Luca Ceresoli wrote:
> >>>> Hi Alejandro,
> >>>>
> >>>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> >>>>> This layer is meant to augment Yocto/OE functionality to provide a
> >>>>> toolchain to build standalone components for Xilinx architectures.
> >>>>>
> >>>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
> >>>>> 
> >>>>> Signed-off-by: Manjukumar Matha
> >>>>> 
> >>>>> ---
> >>>>>   meta-xilinx-standalone/README.md   | 56
> >>>>> ++
> >>>>>   .../conf/distro/xilinx-standalone.conf | 12 +
> >>>>>   meta-xilinx-standalone/conf/layer.conf | 14 ++
> >>>>>   .../conf/machine/zynqmp-pmu.conf   | 11 +
> >>>>>   4 files changed, 93 insertions(+)
> >>>>>   create mode 100644 meta-xilinx-standalone/README.md
> >>>>>   create mode 100644
> >>>>> meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
> >>>>>   create mode 100644 meta-xilinx-standalone/conf/layer.conf
> >>>>>   create mode 100644
> >>>>> meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
> >>>>>
> >>>>> diff --git a/meta-xilinx-standalone/README.md
> >>>>> b/meta-xilinx-standalone/README.md
> >>>>> new file mode 100644
> >>>>> index 000..da7f4e1
> >>>>> --- /dev/null
> >>>>> +++ b/meta-xilinx-standalone/README.md
> >>>>> @@ -0,0 +1,56 @@
> >>>>> +meta-xilinx-standalone
> >>>>> +=
> >>>> Nitpick: there should be an extra '='.
> >>>>
> >>>> [...]
> >>>>> +Dependencies
> >>>>> +
> >>>>> +
> >>>>> +This layer depends on:
> >>>>> +
> >>>>> + URI: git://git.yoctoproject.org/poky
> >>>>> +
> >>>>> + URI: git://git.yoctoproject.org/meta-xilinx
> >>>> That's the repo, not the layer. Maybe clarify as:
> >>>>
> >>>>    URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp
> >>>> layer
> >>> True
> >>>
> >>>>
> >>>>> +Usage
> >>>>> +=
> >>>>> +
> >>>>> +1.- Clone this layer along with the specified layers
> >>>>> +
> >>>>> +2.- $ source oe-init-build-env
> >>>>> +
> >>>>> +3.- Add this layer to BBLAYERS on conf/bblayers.conf
> >>>>> +
> >>>>> +4.- Add the following to your conf/local.conf to build for the
> >>>>> microblaze architecture:
> >>>>> +
> >>>>> +DISTRO="xilinx-standalone"
> >>>>> +
> >>>>> +MACHINE="zynqmp-pmu"
> >>>> To the best of my knowledge, to use U-Boot SPL people link the
> >>>> pm_cfg_obj.c file in the pmufw binary and then patch the pmufw code
> >>>> to load that config object i

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] arm-trusted-firmware.inc: Make console a platform override

[Manjukumar Harthikote Matha]

Hi Jean,

> -Original Message-
> From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com]
> Sent: Thursday, December 20, 2018 5:02 AM
> To: Manjukumar Harthikote Matha 
> Cc: meta-xilinx@yoctoproject.org; Jaewon Lee 
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] 
> arm-trusted-firmware.inc:
> Make console a platform override
> 
> 
> 
>   On Dec 19, 2018, at 8:12 PM, Manjukumar Matha  ma...@xilinx.com <mailto:manjukumar.harthikote-ma...@xilinx.com> > wrote:
> 
>   Define ATF_CONSOLE such that it is a platform override. zynqmp by
>   default has cadence as console, set the ATF build depedencies based on
> 
> 
> 
> "dependencies" ... sorry, just stumbled on it.
> 

Will correct it and apply.
I wonder if there is spell error tool :) 

Thanks,
Manju

> 
>   this override. Other architectures might have different value which can
>   be set using local.conf
> 

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 0/7] Setup IMAGE_BOOT_FILES automatically

[Manjukumar Harthikote Matha]

Hi Nathan/Franz,

> -Original Message-
> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
> Sent: Wednesday, January 31, 2018 8:20 AM
> To: meta-xilinx@yoctoproject.org
> Cc: Nathan Rossi ; Franz Forstmayr
> ; Manjukumar Harthikote Matha
> 
> Subject: [PATCH 0/7] Setup IMAGE_BOOT_FILES automatically
> 
> This series changes how the IMAGE_BOOT_FILES variable is set as well as how 
> the
> values in it are used by various parts of the meta-xilinx-bsp layer. The
> IMAGE_BOOT_FILES value is now default populated in machine-xilinx-default.inc 
> to
> cover all machines in the meta-xilinx-bsp layer.
> 
> The files populated in this variable now include all device-trees built by 
> device-
> tree.bb (if used) as well as all KERNEL_DEVICETREES defined by the 
> machine.conf. In
> order to get this working some changes were needed to have u-boot-zynq-uenv
> capable of picking up the file names.
> 
> In order to achieve the automatic selection of device trees without 
> collecting all dtb
> files from the deploy directory (e.g.  undesired duplicates of kernel built 
> device
> trees), the device-tree recipe is changed such that it deploys it's dtbs into 
> a
> 'devicetree' subdirectory.
> 
> The default value of QB_DTB is also changed as it is now only populated from
> IMAGE_BOOT_FILES.
> 
> Additionally this series removes machine-xilinx-board.inc, this is due to it 
> being
> reduced to a single EXTRA_IMAGEDEPENDS value.
> 
> Franz Forstmayr (1):
>   get_dtb_list function which formats the dtb files properly before
> adding to IMAGE_BOOT_FILES
> 
> Nathan Rossi (6):
>   machine-xilinx-default.inc: Default IMAGE_BOOT_FILES using function
>   device-tree.bb: Deploy the device tree blobs into subdirectory
>   machine-xilinx-default.inc: Add dtb files for IMAGE_BOOT_FILES
>   machine-xilinx-qemu.inc: Remove KERNEL_DEVICETREE parsing
>   u-boot-zynq-uenv.bb: Handle IMAGE_BOOT_FILES wildcard patterns
>   machine-xilinx-board.inc: Remove include
> 
>  meta-xilinx-bsp/classes/image-wic-utils.bbclass| 51 
>  .../conf/machine/include/machine-xilinx-board.inc  |  6 ---
>  .../machine/include/machine-xilinx-default.inc | 28 +++
>  .../conf/machine/include/machine-xilinx-qemu.inc   |  6 +--
>  .../conf/machine/kc705-microblazeel.conf   |  6 ++-
>  meta-xilinx-bsp/conf/machine/microzed-zynq7.conf   |  3 +-
>  meta-xilinx-bsp/conf/machine/picozed-zynq7.conf|  3 +-
>  meta-xilinx-bsp/conf/machine/qemu-zynq7.conf   |  1 -
>  meta-xilinx-bsp/conf/machine/zc702-zynq7.conf  |  7 ++-
>  meta-xilinx-bsp/conf/machine/zc706-zynq7.conf  |  3 +-
>  meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf|  7 ++-
>  meta-xilinx-bsp/conf/machine/zedboard-zynq7.conf   |  7 ++-
>  .../conf/machine/zybo-linux-bd-zynq7.conf  |  3 +-
>  meta-xilinx-bsp/conf/machine/zybo-zynq7.conf   |  3 +-
>  .../recipes-bsp/device-tree/device-tree.bb |  2 +-
>  .../recipes-bsp/u-boot/u-boot-zynq-uenv.bb | 55 
> --
>  16 files changed, 125 insertions(+), 66 deletions(-)  create mode 100644 
> meta-xilinx-
> bsp/classes/image-wic-utils.bbclass
>  delete mode 100644 meta-xilinx-bsp/conf/machine/include/machine-xilinx-
> board.inc
> 


This series is staged in master-next with additional changes and will be applied

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Tuesday, December 18, 2018 7:26 AM
> To: Alejandro Enedino Hernandez Samaniego ; meta-
> xil...@yoctoproject.org
> Cc: Mike Looijmans ; Manjukumar Harthikote Matha
> 
> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, 
> distro
> and machine to build standalone components
> 
> Hi Alejandro, Manju,
> 
> On 11/12/18 23:16, Alejandro Enedino Hernandez Samaniego wrote:
> > Hey Luca,
> >
> >
> > On 12/11/2018 07:41 AM, Luca Ceresoli wrote:
> >> Hi Alejandro,
> >>
> >> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> >>> This layer is meant to augment Yocto/OE functionality to provide a
> >>> toolchain to build standalone components for Xilinx architectures.
> >>>
> >>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
> >>> 
> >>> Signed-off-by: Manjukumar Matha
> >>> 
> >>> ---
> >>>   meta-xilinx-standalone/README.md   | 56
> >>> ++
> >>>   .../conf/distro/xilinx-standalone.conf | 12 +
> >>>   meta-xilinx-standalone/conf/layer.conf | 14 ++
> >>>   .../conf/machine/zynqmp-pmu.conf   | 11 +
> >>>   4 files changed, 93 insertions(+)
> >>>   create mode 100644 meta-xilinx-standalone/README.md
> >>>   create mode 100644
> >>> meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
> >>>   create mode 100644 meta-xilinx-standalone/conf/layer.conf
> >>>   create mode 100644
> >>> meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
> >>>
> >>> diff --git a/meta-xilinx-standalone/README.md
> >>> b/meta-xilinx-standalone/README.md
> >>> new file mode 100644
> >>> index 000..da7f4e1
> >>> --- /dev/null
> >>> +++ b/meta-xilinx-standalone/README.md
> >>> @@ -0,0 +1,56 @@
> >>> +meta-xilinx-standalone
> >>> +=
> >> Nitpick: there should be an extra '='.
> >>
> >> [...]
> >>> +Dependencies
> >>> +
> >>> +
> >>> +This layer depends on:
> >>> +
> >>> + URI: git://git.yoctoproject.org/poky
> >>> +
> >>> + URI: git://git.yoctoproject.org/meta-xilinx
> >> That's the repo, not the layer. Maybe clarify as:
> >>
> >>    URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp
> >> layer
> > True
> >
> >>
> >>> +Usage
> >>> +=
> >>> +
> >>> +1.- Clone this layer along with the specified layers
> >>> +
> >>> +2.- $ source oe-init-build-env
> >>> +
> >>> +3.- Add this layer to BBLAYERS on conf/bblayers.conf
> >>> +
> >>> +4.- Add the following to your conf/local.conf to build for the
> >>> microblaze architecture:
> >>> +
> >>> +DISTRO="xilinx-standalone"
> >>> +
> >>> +MACHINE="zynqmp-pmu"
> >> To the best of my knowledge, to use U-Boot SPL people link the
> >> pm_cfg_obj.c file in the pmufw binary and then patch the pmufw code
> >> to load that config object instead of getting it via smc calls [0].
> >> This makes pmufw binary machine-specfic.
> >>
> >> How do you think the same goal should be obtained with the new
> >> "zynqmp-pmu" machine?
> > Unless I'm not understanding this correctly, using MACHINEOVERRIDES
> > should do it
> 
> I don't think this can be done with MACHINEOVERRIDES. Let me explain better 
> what
> I mean.
> 
> In my current rocko setup, there are multiple machines defined in my layer. 
> Let's call
> then "foo" and "bar":
> 
>   $ ls meta-mylayer/conf/machine/
>   foo-zynqmp.conf
>   bar-zynqmp.conf
>   $
> 
> Then there is a recipe (say my-hdl.bb) that copies pm_cfg_obj.c in the 
> sysroot. The
> copied file is different file for each MACHINE. This recipe has PACKAGE_ARCH =
> "${MACHINE_ARCH}", so different cfg objects go in different directories.
> 
> Finally I have a pmu-firmware_%.bbappend that is similar to Mike's [0], with 
> the
> difference that it takes the pm_cfg_obj.c file from staging where my-hdl.bb 
> has
> copied it:
> 
>   do_configure[depends] = "my-hdl:do_populate_sysroot"
>   do_co

Re: [meta-xilinx] rel-v2018.03: qt5/qtwebkit_git.bb:do_compile failed with exit code '1'

[Manjukumar Harthikote Matha]

Hi William,

That’s weird, can you rebuild ?
We built the qtwebkit and did not have any issue, I am assuming you have all 
the required layers.
Can you also try MACHINE as ultra96-zynqmp

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of William A. Mills
Sent: Sunday, December 16, 2018 10:32 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] rel-v2018.03: qt5/qtwebkit_git.bb:do_compile failed with 
exit code '1'

Hello,

I am trying to build images for my Ultra96 board.
I am following the instructions at:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841862/How+to+build+images+through+yocto

I tried rel-v2017.3 first as this is what the board came with and also is the 
version associated with the latest image found on the 
96boards.org site.  This fails to build 
petalinux-image-minimal due to needing xsct [device tree something]).  (I am 
trying not to install SDKs etc at this point.  The instructions don't say they 
are needed.)

Next I tried rel-v2018.03 and this builds petalinux-image-minimal OK.  (It now 
fetches an xsct bundle on its own.  Cool & Thanks.)

I tried petalinux-image-full (with -k) and after adding 32GB of swap space to 
my 16GB of DDR I get most of the way though.  (3.5 hours on chromium 
do_compile.  Quad core gen3 i7 i7-3770 CPU @ 3.40GHz).

(FYI: This machine is Ubuntu 16.04 64 bit.)

It still fails on qtwebkit.  Here is the retry:
$  MACHINE=zcu100-zynqmp bitbake petalinux-image-full

bill@rocky:~/w/proj/ultra-96/oe-v2018.3/build/tmp/log/cooker/zcu100-zynqmp$
 cat console-latest.log
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.36.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-xilinx-linux"
MACHINE  = "zcu100-zynqmp"
DISTRO   = "petalinux"
DISTRO_VERSION   = "2018.3"
TUNE_FEATURES= "aarch64"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:3be15ed93e52d797250ad90467760eb1fd7eca56"
meta-perl
meta-python
meta-filesystems
meta-gnome
meta-multimedia
meta-networking
meta-webserver
meta-xfce
meta-initramfs
meta-oe  = "HEAD:83fbd5d5d605de13f47263fab680d910375e1f95"
meta-browser = "HEAD:c5ff301787ef76eec57ca500ec9d1ccf0f74b488"
meta-qt5 = "HEAD:f7e16aeeaa58cd7cc166f16d8537a8b3627e0397"
meta-xilinx-bsp
meta-xilinx-contrib  = "HEAD:7922f16dfa5308fb5419a80f513bb07c0384f95e"
meta-xilinx-tools= "HEAD:b286943d7d468e9ff10b9f9662767e8c71f104d1"
meta-petalinux   = "HEAD:254edec8368c3d30676135365734abe06e596881"
meta-virtualization  = "HEAD:df7b7937b9c91eeea05665c0b69ddcf435cddbcb"
meta-openamp = "HEAD:fb5fbc77fa5595ed291b886abe9555a91e67d241"

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 3753 of 11148 
(/home/bill/w/proj/ultra-96/oe-v2018.3/sources/core/../meta-qt5/recipes-qt/qt5/qtwebkit_git.bb:do_compile)
NOTE: recipe qtwebkit-5.9.6+gitAUTOINC+bd0657f98a-r0: task do_compile: Started
ERROR: qtwebkit-5.9.6+gitAUTOINC+bd0657f98a-r0 do_compile: oe_runmake failed
ERROR: qtwebkit-5.9.6+gitAUTOINC+bd0657f98a-r0 do_compile: Function failed: 
do_compile (log file is located at 
/home/bill/w/proj/ultra-96/oe-v2018.3/build/tmp/work/aarch64-xilinx-linux/qtwebkit/5.9.6+gitAUTOINC+bd0657f98a-r0/temp/log.do_compile.30981)
ERROR: Logfile of failure stored in: 
/home/bill/w/proj/ultra-96/oe-v2018.3/build/tmp/work/aarch64-xilinx-linux/qtwebkit/5.9.6+gitAUTOINC+bd0657f98a-r0/temp/log.do_compile.30981
NOTE: recipe qtwebkit-5.9.6+gitAUTOINC+bd0657f98a-r0: task do_compile: Failed
ERROR: Task 
(/home/bill/w/proj/ultra-96/oe-v2018.3/sources/core/../meta-qt5/recipes-qt/qt5/qtwebkit_git.bb:do_compile)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 2 tasks of which 1 didn't need to be 
rerun and 1 failed.
NOTE: Writing buildhistory

Tail end of log.do_complie is:  (I can attach full version if needed)
/home/bill/w/proj/ultra-96/oe-v2018.3/build/tmp/work/aarch64-xilinx-linux/qtwebkit/5.9.6+gitAUTOINC+bd0657f98a-r0/build/Source/WebCore//.obj/bindings/js/JSBindingsAllInOne.o:
 In function `WebCore::JSXMLHttpRequest::send(JSC::ExecState*)':
JSBindingsAllInOne.cpp:(.text._ZN7WebCore16JSXMLHttpRequest4sendEPN3JSC9ExecStateE+0x30):
 undefined reference to `WebCore::InspectorInstrumentation::s_frontendCounter'
JSBindingsAllInOne.cpp:(.text._ZN7WebCore16JSXMLHttpRequest4sendEPN3JSC9ExecStateE+0x34):
 undefined reference to `WebCore::InspectorInstrumentation::s_frontendCounter'
/home/bill/w/proj/ultra-96/oe-v2018.3/build/tmp/work/aarch64-xilinx-linux/qtwebkit/5.9.6+gitAUTOINC+bd0657f98a-r0/build/Source/WebCore//.obj/bindings/js/JSBindingsAllInOne.o:
 In function 
`WebCore::JSInspectorFrontendHost::showContextMenu(JSC::ExecState*)':

Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components

[Manjukumar Harthikote Matha]

Hi Martin/Jean,


> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Martin Siegumfeldt
> Sent: Friday, December 14, 2018 11:58 AM
> To: Jean-Francois Dagenais 
> Cc: Alejandro Enedino Hernandez Samaniego ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a
> multilib hack to build standalone components
> 
> Hi Jean-Francois,
> 
> Appreciate your input, however, since we don't use meta-xilinx-tools, the
> workaround of a dual dependency (from both image- and u-boot) towards PMUFW
> appears more feasible for us.
> 

This is something that should be fixed in OE-core, we are working on it

Thanks,
Manju

> Thanks,
> Martin
> 
> From: Jean-Francois Dagenais 
> Sent: Thursday, December 13, 2018 2:31:30 PM
> To: Martin Siegumfeldt
> Cc: Alejandro Enedino Hernandez Samaniego; meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a
> multilib hack to build standalone components
> 
> On Dec 12, 2018, at 3:21 AM, Martin Siegumfeldt
> mailto:m...@gomspace.com>> wrote:
> 
> It looks to me as Manju's proposal of adding it as an image dependency may 
> work
> when building the image, but appears to be subject to a race condition between
> pmu-firmware and virtual/bootloader.
> 
>  I instigated the idea to transform the fsbl build from a class to a proper 
> recipe and
> tying it the the wic stage using. I then had to resolve this same race and if 
> I
> remember correctly, the fix looked like this:
> 
> https://www.mail-archive.com/meta-xilinx@yoctoproject.org/msg02458.html
> 
> Not sure if it applies to your specific situation here. I have not invested 
> much time in
> the multi-config stuff. I resorted to meta-xilinx-tools a while back, managed 
> to
> "make it work" in our CI docker environment and have not looked back since.
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Thud release update

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Friday, December 14, 2018 2:44 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] Thud release update
> 
> Hi Manjukumar,
> 
> On 13/12/18 00:04, Manjukumar Harthikote Matha wrote:
> >
> >
> >> -Original Message-
> >> From: Manjukumar Harthikote Matha
> >> Sent: Wednesday, December 12, 2018 11:42 AM
> >> To: Luca Ceresoli ; meta-xilinx@yoctoproject.org
> >> Subject: RE: [meta-xilinx] Thud release update
> >>
> >> Hi Luca,
> >>
> >>> -Original Message-
> >>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> >>> Sent: Wednesday, December 12, 2018 8:31 AM
> >>> To: Manjukumar Harthikote Matha ; meta-
> >>> xil...@yoctoproject.org
> >>> Subject: Re: [meta-xilinx] Thud release update
> >>>
> >>> Hi Manjukumar,
> >>>
> >>> On 29/11/18 18:07, Manjukumar Harthikote Matha wrote:
> >>>> Hi All,
> >>>>
> >>>> Thud release branch is under-testing as of now, we will start sending 
> >>>> patches
> >> next
> >>> week and start merging to master:
> >>>> Please check the tree here:
> >>>> https://github.com/Xilinx/meta-xilinx/commits/master-next
> >>>>
> >>>> Major changes:
> >>>> meta-xilinx-standalone layer to support building toolchain for MB and 
> >>>> pmu-
> >>> firmware
> >>>> Proposal was sent here:
> >>>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-
> >> September/004051.html
> >>>>
> >>>> There are two ways to build pmu-firmware: One using multiconfig and 
> >>>> other as
> >>> two separate distros
> >>>>
> >>>> 1) multiconfig way:
> >>>>  - You need to add the dependency in the image file, for example in core-
> >>> image-minimal you will need
> >>>>  do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-
> >>> firmware:do_deploy"
> >>>>
> >>>>
> >>>>  - Add conf/multiconfig in the build directory and create pmu.conf and
> >>> zcu102.conf under conf/multiconfig
> >>>>pmu.conf  consists of
> >>>>  MACHINE="zynqmp-pmu"
> >>>>  DISTRO="xilinx-standalone"
> >>>>  GCCVERSION="7.%"
> >>>>  TMPDIR="${TOPDIR}/pmutmp"
> >>>>
> >>>>  zcu102.conf consists of
> >>>>  MACHINE="zcu102-zynqmp"
> >>>>  DISTRO="poky"
> >>>>- In local.conf multiconfig is enabled by: BBMULTICONFIG 
> >>>> ?= "zcu102
> >>> pmu"
> >>>>  - bitbake multiconfig:zcu102:core-image-minimal
> >>>>
> >>>> This will build pmu-firmware in   build/pmutmp and all the linux images 
> >>>> in
> >> build/tmp
> >>>
> >>> [Disclaimer: I did not double-check everything I state below since it
> >>> takes hours for each test]
> >>>
> >>> I tried this setup and building u-boot-xlnx fails:
> >>>
> >>>   $ bitbake multiconfig:zcu102:core-image-minimal
> >>>   [...]
> >>>   Cannot read
> >>> ../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-
> >> pmu.bin
> >>>
> >>> This can be reproduced with the attached script.
> >>>
> >>
> >> From script it seems you are missing do_image[mcdepends] =
> >> "multiconfig:zcu102:pmu:pmu-firmware:do_deploy" in your image file?
> >> I think you could also add in local.conf
> >>
> >
> > Spoke too soon :)
> >
> > You need both, we are looking into why both lines will be required.
> > In Local.conf
> > do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"
> > In u-boot-xlnx
> > do_compile[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"
> 
> I confirm adding *both* lines let me finish my first multiconfig build.
> 
> I also don't understand the need for the do_image[mcdepends] line: it
> should be implied by the fact that the image depends on u-boot-xlnx,
> which in turn depends on pmu-firmware:do_deploy.
> 
> Since I have no zcu102 to runtime test, I tried building for zcu106. It
> doesn't build as is, do you have plans to support it?
> 

Yes I will push updated git tree to master-next (it will be a force push).
I tested on zcu102 with patches rebased from Mike L for pmu-configs for SD boot.
However I am not able to boot zcu106.

<..>

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Thud release update

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Manjukumar Harthikote Matha
> Sent: Wednesday, December 12, 2018 11:42 AM
> To: Luca Ceresoli ; meta-xilinx@yoctoproject.org
> Subject: RE: [meta-xilinx] Thud release update
> 
> Hi Luca,
> 
> > -Original Message-
> > From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> > Sent: Wednesday, December 12, 2018 8:31 AM
> > To: Manjukumar Harthikote Matha ; meta-
> > xil...@yoctoproject.org
> > Subject: Re: [meta-xilinx] Thud release update
> >
> > Hi Manjukumar,
> >
> > On 29/11/18 18:07, Manjukumar Harthikote Matha wrote:
> > > Hi All,
> > >
> > > Thud release branch is under-testing as of now, we will start sending 
> > > patches
> next
> > week and start merging to master:
> > > Please check the tree here:
> > > https://github.com/Xilinx/meta-xilinx/commits/master-next
> > >
> > > Major changes:
> > > meta-xilinx-standalone layer to support building toolchain for MB and pmu-
> > firmware
> > > Proposal was sent here:
> > > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-
> September/004051.html
> > >
> > > There are two ways to build pmu-firmware: One using multiconfig and other 
> > > as
> > two separate distros
> > >
> > > 1) multiconfig way:
> > >   - You need to add the dependency in the image file, for example in core-
> > image-minimal you will need
> > >   do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-
> > firmware:do_deploy"
> > >
> > >
> > >   - Add conf/multiconfig in the build directory and create pmu.conf and
> > zcu102.conf under conf/multiconfig
> > >pmu.conf  consists of
> > >   MACHINE="zynqmp-pmu"
> > >   DISTRO="xilinx-standalone"
> > >   GCCVERSION="7.%"
> > >   TMPDIR="${TOPDIR}/pmutmp"
> > >
> > >   zcu102.conf consists of
> > >   MACHINE="zcu102-zynqmp"
> > >   DISTRO="poky"
> > >- In local.conf multiconfig is enabled by: BBMULTICONFIG 
> > > ?= "zcu102
> > pmu"
> > >   - bitbake multiconfig:zcu102:core-image-minimal
> > >
> > > This will build pmu-firmware in   build/pmutmp and all the linux images in
> build/tmp
> >
> > [Disclaimer: I did not double-check everything I state below since it
> > takes hours for each test]
> >
> > I tried this setup and building u-boot-xlnx fails:
> >
> >   $ bitbake multiconfig:zcu102:core-image-minimal
> >   [...]
> >   Cannot read
> > ../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-
> pmu.bin
> >
> > This can be reproduced with the attached script.
> >
> 
> From script it seems you are missing do_image[mcdepends] =
> "multiconfig:zcu102:pmu:pmu-firmware:do_deploy" in your image file?
> I think you could also add in local.conf
> 

Spoke too soon :)

You need both, we are looking into why both lines will be required.
In Local.conf
do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"
In u-boot-xlnx
do_compile[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"

Thanks,
Manju

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Thud release update

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Wednesday, December 12, 2018 8:31 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] Thud release update
> 
> Hi Manjukumar,
> 
> On 29/11/18 18:07, Manjukumar Harthikote Matha wrote:
> > Hi All,
> >
> > Thud release branch is under-testing as of now, we will start sending 
> > patches next
> week and start merging to master:
> > Please check the tree here:
> > https://github.com/Xilinx/meta-xilinx/commits/master-next
> >
> > Major changes:
> > meta-xilinx-standalone layer to support building toolchain for MB and pmu-
> firmware
> > Proposal was sent here:
> > https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-September/004051.html
> >
> > There are two ways to build pmu-firmware: One using multiconfig and other as
> two separate distros
> >
> > 1) multiconfig way:
> > - You need to add the dependency in the image file, for example in core-
> image-minimal you will need
> > do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-
> firmware:do_deploy"
> >
> >
> > - Add conf/multiconfig in the build directory and create pmu.conf and
> zcu102.conf under conf/multiconfig
> >pmu.conf  consists of
> > MACHINE="zynqmp-pmu"
> > DISTRO="xilinx-standalone"
> > GCCVERSION="7.%"
> > TMPDIR="${TOPDIR}/pmutmp"
> >
> > zcu102.conf consists of
> > MACHINE="zcu102-zynqmp"
> > DISTRO="poky"
> >- In local.conf multiconfig is enabled by: BBMULTICONFIG ?= 
> > "zcu102
> pmu"
> > - bitbake multiconfig:zcu102:core-image-minimal
> >
> > This will build pmu-firmware in   build/pmutmp and all the linux images in 
> > build/tmp
> 
> [Disclaimer: I did not double-check everything I state below since it
> takes hours for each test]
> 
> I tried this setup and building u-boot-xlnx fails:
> 
>   $ bitbake multiconfig:zcu102:core-image-minimal
>   [...]
>   Cannot read
> ../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-pmu.bin
> 
> This can be reproduced with the attached script.
> 

>From script it seems you are missing do_image[mcdepends] = 
>"multiconfig:zcu102:pmu:pmu-firmware:do_deploy" in your image file?
I think you could also add in local.conf

Thanks,
Manju

<...>

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Luca Ceresoli
> Sent: Tuesday, December 11, 2018 7:45 AM
> To: Alejandro Enedino Hernandez Samaniego ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe
> 
> Hi Alejandro,
> 
> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> > This patch ports the pmu-firmware recipe from meta-xilinx-bsp to be
> > used with the standalone/baremetal toolchain and also upgrades it to
> > the latest release at this point.
> >
> > The recipe was trimmed down, and a few changes had to be made to make
> > it compatible with the baremetal layer, DEPENDS, pass include dir,
> > license and such.
> >
> > Signed-off-by: Alejandro Enedino Hernandez Samaniego
> > 
> > Signed-off-by: Manjukumar Matha
> > 
> 
> I tried to test your entire patch series but with bad luck. Well, indeed I 
> tested the
> patches from the github meta-xilinx repo up to [0], not sure whether the repo 
> is
> more up to date than the patches here.
> 
> The first issue is that xilinx-standalone is compatible with thud, but on the 
> mentioned
> commit (as well as on master) the mete-xilinx-bsp layer is compatible with 
> sumo
> only. I solved by cherry-picking [1].
> 
> Then I followed the instructions in README.md and 'bitbake newlib' ran 
> successfully.
> But 'bitbake pmu-firmware' gives:
> 
> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift 
> -mxl-pattern-compare  -
> mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul -mxl-soft-div --
> sysroot=/home/ceresoli/temp/prova-thud-
> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot
> -o executable.elf  pm_master.o  pm_api.o  xpfw_error_manager.o xpfw_restart.o
> pm_config.o  xpfw_mod_legacy.o  pm_requirement.o pm_node_reset.o  pm_core.o
> pm_system.o  pm_common.o  xpfw_xpu.o pm_gic_proxy.o  xpfw_aib.o
> xpfw_events.o  pm_binding.o pm_mmio_access.o  xpfw_scheduler.o  pm_slave.o
> xpfw_mod_pm.o  pm_ddr.o pm_qspi.o  pm_sram.o  xpfw_mod_sched.o
> xpfw_mod_rtc.o  pm_usb.o pm_extern.o  xpfw_user_startup.o
> xpfw_rom_interface.o  xpfw_mod_wdt.o pm_proc.o  pm_reset.o  pm_callbacks.o
> xpfw_mod_stl.o  idle_hooks.o xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o
> xpfw_mod_dap.o xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o
> xpfw_module.o pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o  pm_gpp.o
> pm_power.o xpfw_mod_em.o  pm_pll.o  pm_clock.o  pm_notifier.o  xpfw_start.o  -
> MMD -MP -Wl,--build-id=none -I/home/ceresoli/temp/prova-thud-
> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot/usr/include
> -Os -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
> -Wl,--start-group,-lxilfpga,-lxilsecure,-lxil,-lgcc,-lc,--end-group
> -nostartfiles -Wl,--gc-sections -L../misc/zynqmp_pmufw_bsp/psu_pmu_0/lib
> -Tlscript.ld
> lto1: fatal error: multiple prevailing defs for 'XUsbPsu_DisableIntr'
> compilation terminated.
> lto-wrapper: fatal error: microblazeel-xilinx-elf-gcc returned 1 exit status
> compilation terminated.
> /home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-
> cmp-xilinx-elf/pmu-firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot-
> native/usr/bin/microblazeel-xilinx-elf/../../libexec/microblazeel-xilinx-
> elf/gcc/microblazeel-xilinx-elf/8.2.0/ld:
> error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> Makefile:28: recipe for target 'executable.elf' failed
> make: *** [executable.elf] Error 1
> 
> I then tried with current master-next [2] and got:
> 
> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift 
> -mxl-pattern-compare  -
> mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul -mxl-soft-div --
> sysroot=/home/ceresoli/temp/prova-thud-
> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
> firmware/v2018.3+gitAUTOINC+56f3da2afb-r0/recipe-sysroot
> -o executable.elf  pm_master.o  xpfw_error_manager.o  xpfw_restart.o
> pm_notifier.o  xpfw_mod_legacy.o  pm_requirement.o  pm_node_reset.o
> pm_core.o  pm_system.o  pm_config.o  xpfw_xpu.o  pm_gic_proxy.o xpfw_aib.o
> xpfw_events.o  pm_binding.o  pm_mmio_access.o xpfw_scheduler.o  pm_slave.o
> pm_pinctrl.o  xpfw_mod_pm.o  pm_ddr.o pm_qspi.o  pm_sram.o
> xpfw_mod_sched.o  xpfw_mod_rtc.o  pm_usb.o pm_extern.o  xpfw_user_startup.o
> xpfw_rom_interface.o  xpfw_mod_wdt.o pm_proc.o  pm_reset.o  pm_callbacks.o
> xpfw_mod_stl.o  idle_hooks.o xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o
> xpfw_mod_dap.o xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o
> xpfw_module.o pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o  pm_gpp.o
> pm_power.o xpfw_mod_em.o  pm_pll.o  pm_clock.o  xpfw_start.o  -MMD -MP -
> Wl,--build-id=none -I/home/ceresoli/temp/prova-thud-
> 

Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Tuesday, December 11, 2018 8:15 AM
> To: Manjukumar Harthikote Matha ; Alejandro Enedino
> Hernandez Samaniego ; meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe
> 
> Hi Manjukumar,
> 
> On 11/12/18 17:07, Manjukumar Harthikote Matha wrote:
> > Hi Luca,
> >
> >> -Original Message-
> >> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> >> boun...@yoctoproject.org] On Behalf Of Luca Ceresoli
> >> Sent: Tuesday, December 11, 2018 7:45 AM
> >> To: Alejandro Enedino Hernandez Samaniego ;
> >> meta- xil...@yoctoproject.org
> >> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port
> >> pmu-firmware recipe
> >>
> >> Hi Alejandro,
> >>
> >> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> >>> This patch ports the pmu-firmware recipe from meta-xilinx-bsp to be
> >>> used with the standalone/baremetal toolchain and also upgrades it to
> >>> the latest release at this point.
> >>>
> >>> The recipe was trimmed down, and a few changes had to be made to
> >>> make it compatible with the baremetal layer, DEPENDS, pass include
> >>> dir, license and such.
> >>>
> >>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
> >>> 
> >>> Signed-off-by: Manjukumar Matha
> >>> 
> >>
> >> I tried to test your entire patch series but with bad luck. Well,
> >> indeed I tested the patches from the github meta-xilinx repo up to
> >> [0], not sure whether the repo is more up to date than the patches here.
> >>
> >> The first issue is that xilinx-standalone is compatible with thud,
> >> but on the mentioned commit (as well as on master) the
> >> mete-xilinx-bsp layer is compatible with sumo only. I solved by 
> >> cherry-picking [1].
> >>
> >> Then I followed the instructions in README.md and 'bitbake newlib' ran
> successfully.
> >> But 'bitbake pmu-firmware' gives:
> >>
> >> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift
> >> -mxl-pattern-compare  - mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul
> >> -mxl-soft-div --
> >> sysroot=/home/ceresoli/temp/prova-thud-
> >> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
> >> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot
> >> -o executable.elf  pm_master.o  pm_api.o  xpfw_error_manager.o
> >> xpfw_restart.o pm_config.o  xpfw_mod_legacy.o  pm_requirement.o
> >> pm_node_reset.o  pm_core.o pm_system.o  pm_common.o  xpfw_xpu.o
> >> pm_gic_proxy.o  xpfw_aib.o xpfw_events.o  pm_binding.o
> >> pm_mmio_access.o  xpfw_scheduler.o  pm_slave.o xpfw_mod_pm.o
> >> pm_ddr.o pm_qspi.o  pm_sram.o  xpfw_mod_sched.o xpfw_mod_rtc.o
> >> pm_usb.o pm_extern.o  xpfw_user_startup.o xpfw_rom_interface.o
> >> xpfw_mod_wdt.o pm_proc.o  pm_reset.o  pm_callbacks.o xpfw_mod_stl.o
> >> idle_hooks.o xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o
> >> xpfw_mod_dap.o xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o
> >> xpfw_module.o pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o
> >> pm_gpp.o pm_power.o xpfw_mod_em.o  pm_pll.o  pm_clock.o
> >> pm_notifier.o  xpfw_start.o  - MMD -MP -Wl,--build-id=none
> >> -I/home/ceresoli/temp/prova-thud-
> >> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
> >> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot/usr/include
> >> -Os -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
> >> -Wl,--start-group,-lxilfpga,-lxilsecure,-lxil,-lgcc,-lc,--end-group
> >> -nostartfiles -Wl,--gc-sections
> >> -L../misc/zynqmp_pmufw_bsp/psu_pmu_0/lib
> >> -Tlscript.ld
> >> lto1: fatal error: multiple prevailing defs for 'XUsbPsu_DisableIntr'
> >> compilation terminated.
> >> lto-wrapper: fatal error: microblazeel-xilinx-elf-gcc returned 1 exit
> >> status compilation terminated.
> >> /home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazee
> >> l-v9.2-bs-
> >> cmp-xilinx-elf/pmu-firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-s
> >> ysroot-
> >> native/usr/bin/microblazeel-xilinx-elf/../../libexec/microblazeel-xil
> >> inx-
> >> elf/gcc/microblazeel-xilinx-elf/8.2.0/ld:
> >> error: lto-wrapper failed
> >> collect2: error: ld returned 1 exit status
> >

Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components

[Manjukumar Harthikote Matha]

Hi Jean-Francois,

The next patch series will clean the commented line including a change to 
provide user-path for PMU-FW
https://github.com/Xilinx/meta-xilinx/commit/e0c181b0963aabca581866b58123ef50f0b6b122

This is the tree for next release
https://github.com/Xilinx/meta-xilinx/commits/master-next

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Jean-Francois 
Dagenais
Sent: Friday, December 07, 2018 7:12 PM
To: Alejandro Enedino Hernandez Samaniego 
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] [PATCH 9/9] zynqmp-pmu: Remove class that uses a 
multilib hack to build standalone components




On Dec 6, 2018, at 4:56 PM, Alejandro Enedino Hernandez Samaniego 
mailto:alejandro.enedino.hernandez-samani...@xilinx.com>>
 wrote:

diff --git a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc 
b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
index 9cf09ff..6233bc8 100644
--- a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
+++ b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
@@ -65,7 +65,7 @@ python () {

if providesbin and d.getVar("SOC_FAMILY") in ["zynqmp"]:
# depend on the pmu-firmware build
-d.appendVar("DEPENDS", " virtual/pmu-firmware")
+#d.appendVar("DEPENDS", " virtual/pmu-firmware")

Just delete the line, let's not accumulate stale, commented code around.

# determine the path relative to the source tree
relpath = 
os.path.relpath(d.expand("${DEPLOY_DIR_IMAGE}/pmu-${MACHINE}.bin"), 
d.getVar("S"))
# setup PMU Firmware path via MAKEFLAGS
--
2.7.4

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] meta-xilinx git location ?

[Manjukumar Harthikote Matha]

Hi Peter and Luca,

Yes all of it is correct.

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Peter Smith
Sent: Thursday, November 29, 2018 2:40 AM
To: l...@lucaceresoli.net
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] meta-xilinx git location ?

Yep, that is my understanding too, well described thank you.
Best Regards
Peter


On Thu, 29 Nov 2018 at 09:39, Luca Ceresoli 
mailto:l...@lucaceresoli.net>> wrote:
Hi Arno,

On 29/11/18 08:31, Arno Steffens wrote:
> Hello, I am a bit confused to see that in GIT (linked in Yocto 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/ ->
> git://git.yoctoproject.org/meta-xilinx
>  ) there are no commits since August.

As far as I can understand, the repo on 
git.yoctoproject.org is the
"yocto-official" repository, which contains master and a branch for each
yocto release (rocko, sumo,...). It uses the open-source community workflow.

The "other" repo is at https://github.com/Xilinx/meta-xilinx, which has
the same branches and additionally has:
 - master-next, which is what you can expect to see in a while on the
   master branch of both repos
 - xilinx-*, the fork branches that xilinx uses to release their own
   reference designs. They implement the Xilinx workflow, and are in
   sync with their development tools (Vivado, Petalinux...)

Look at the github one for bleeding-edge development and xilinx-specific
code.

More info about the two workflows in [0], slides 11-13.

> But in this mailing list I can see commits (especially regarding thud).

Commits are not notified in this list. What you see are patches, which
don't always get accepted. There have been patches to bump to thud in
November 5, but they have not been accepted.

However, since yesterday the master-next branch has this commit:

  17a5f3321f83 layer.conf: Add thud as LAYERSERIES_COMPAT

so it looks like thud support is coming soon.

[0] http://lucaceresoli.net/wp-content/uploads/zynqmp-linux.pdf

--
Luca
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Thud release update

[Manjukumar Harthikote Matha]

Hi All,

Thud release branch is under-testing as of now, we will start sending patches 
next week and start merging to master:
Please check the tree here: 
https://github.com/Xilinx/meta-xilinx/commits/master-next

Major changes:
meta-xilinx-standalone layer to support building toolchain for MB and 
pmu-firmware
Proposal was sent here: 
https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-September/004051.html

There are two ways to build pmu-firmware: One using multiconfig and other as 
two separate distros

1) multiconfig way:
- You need to add the dependency in the image file, for example in 
core-image-minimal you will need
do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"


- Add conf/multiconfig in the build directory and create pmu.conf and 
zcu102.conf under conf/multiconfig
   pmu.conf  consists of 
MACHINE="zynqmp-pmu"
DISTRO="xilinx-standalone"
GCCVERSION="7.%"
TMPDIR="${TOPDIR}/pmutmp"

zcu102.conf consists of
MACHINE="zcu102-zynqmp"
DISTRO="poky"   
   - In local.conf multiconfig is enabled by: BBMULTICONFIG ?= 
"zcu102 pmu"
- bitbake multiconfig:zcu102:core-image-minimal

This will build pmu-firmware in   build/pmutmp and all the linux images in 
build/tmp

See how to use multiconfig here:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#dev-building-images-for-multiple-targets-using-multiple-configurations

2) Build each distro independently. 
Use the above pmu.conf contents in local.conf and build (bitbake pmu-firmware)
Use the above zcu102.conf contents in local.conf and build (bitbake 
core-image-minimal)

We are in the process of testing the Thud release branch, we are targeting Dec 
12th for Thud branch.

We had a proposal to merge meta-petalinux to meta-xilinx, we will target this 
for next release.
meta-xilinx-tools will remain independent layer, we don't see it merging with 
meta-xilinx anytime soon.

Please test and provide feedback on the layer changes

Thanks,
Manju








-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] yocto support for Xilinx ZCU102 Evaluation Kit

[Manjukumar Harthikote Matha]

Hi Vinod,

These links can help:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841862/How+to+build+images+through+yocto

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842041/How+to+SD+boot+with+Yocto+images

To add MALIbinaries:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842033/Adding+MALI+userspace+binaries+in+Yocto+builds

Thanks,
Manju


From: Vinod Kumar [mailto:vinod.ku...@mobiliya.com]
Sent: Tuesday, October 16, 2018 11:38 PM
To: meta-xil...@lists.yoctoproject.org; Manjukumar Harthikote Matha 

Subject: yocto support for Xilinx ZCU102 Evaluation Kit


Hi Xilinx team,



We are planning to use Xilinx ZCU102 Evaluation Kit for one of our projects and 
looking for yocto support. Xilinx ZCU102 Evaluation Kit is powered by Zynq 
Ultrascale+ MPSoC device (Zynq UltraScale XCZU9EG-2FFVB1156 FPGA) and would 
like to know availability of yocto support for the same.



Below xilinx yocto project do not lists XCZU9EG-2FFVB1156 FPGA device. Please 
help us to find the yocto support for the same.



https://github.com/Xilinx/meta-xilinx
[https://avatars0.githubusercontent.com/u/3189299?s=400=4]<https://github.com/Xilinx/meta-xilinx>

GitHub - Xilinx/meta-xilinx: Xilinx device and board 
...<https://github.com/Xilinx/meta-xilinx>
github.com
Join GitHub today. GitHub is home to over 28 million developers working 
together to host and review code, manage projects, and build software together.





Thanks.



BR

Vinod
[https://scm.agreeyamobility.net/site/Mobiliya_LOGO.png]

www.mobiliya.com<https://www.mobiliya.com>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Device Tree mismatch in xilinx-v2017.3 (meta-xilinx vs meta-xilinx-tools)

[Manjukumar Harthikote Matha]

Hi Jesse,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Kleve, Jesse R
> Sent: Wednesday, October 03, 2018 1:47 PM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Device Tree mismatch in xilinx-v2017.3 (meta-xilinx vs 
> meta-
> xilinx-tools)
> 
> I’m building off of the Xilinx-v2017.3 branch. When I go to boot with the 
> device tree
> and kernel I get a mismatch in zynqmp_plat_init for the power management API.
> 
> Kernel panic – not syncing: zynqmp_plat_init power management API version 
> error.
> Expected: v0.3 – Found: v1.0
> 
> In Xilinx-v2017.3, the kernel is 4.9 which expects v0.3 yet meta-xilinx-tools 
> is
> producing a device tree set for v1.0. Am I misconfiguring something here?
> 

Are you using https://github.com/xilinx/meta-xilinx-tools/tree/rel-v2017.3 

> Thanks,
> Jesse
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Ultra96 UART

[Manjukumar Harthikote Matha]

Hi Simon,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of simon.g...@doulos.com
> Sent: Wednesday, October 03, 2018 1:19 AM
> To: tom.cur...@avnet.com
> Cc: meta-xil...@lists.yoctoproject.org
> Subject: Re: [meta-xilinx] Ultra96 UART
> 
> Hi Tom
> 
> 
> Thanks for the extra information. I was able to regenerate the HDF with (I 
> think) the
> appropriate changes in the PSU UART configuration (just changing UART1 to
> MIO[0..1], is that all that is required?). I then (eventually) managed to get 
> everything
> to build in Yocto using the new HDF by setting the HDF_PATH appropriately in 
> my
> local.conf.
> 
> 
> With the new boot.bin etc. I see the FSBL output now (a step forward) but 
> nothing
> more - I guess U-Boot is not loading properly from the boot.bin?
> 

Are you using rel-v2018.2 branches?

Is this used while building u-boot? 
https://github.com/Xilinx/meta-xilinx-tools/blob/rel-v2018.2/recipes-bsp/u-boot/u-boot-xlnx_%25.bbappend

> 
> I am slightly confused as to why this is necessary. Manju from Xilinx said 
> they have
> verified that it works but you are saying that the HDF provided by default in 
> meta-
> xilinx* is incorrect - have I missed something?
> 
> 

We use the mezzanine card for the UART, hence the need for EMIO. 

Thanks,
Manju

> Thanks in advance
> Simon
> 
> 
> ---
> Date: Fri, 28 Sep 2018 21:24:27 +
> From: "Curran, Tom (EM)"  <mailto:tom.cur...@avnet.com> >
> To: "meta-xil...@lists.yoctoproject.org 
> <mailto:meta-xil...@lists.yoctoproject.org>
> "
>  <mailto:meta-xil...@lists.yoctoproject.org> >
> Subject: Re: [meta-xilinx] Ultra96 UART
> Message-ID:
> <0434c4d44760fb40aafb554c7c241caf10796...@cmx039usmb.avnet.com
> <mailto:0434C4D44760FB40AAFB554C7C241CAF107960EB@CMX039USMB.AVNET.
> COM> >
> Content-Type: text/plain; charset="utf-8"
> 
> Yes, the user STDIN/STDOUT UART is psu_uart_1 in the image that gets built via
> meta-xilinx, etc., BUT the UART is mapped out through EMIO to the low speed
> expansion header:
> 
> #HD_GPIO_5 on FPGA / Connector pin 13 / UART1_rxd set_property PACKAGE_PIN
> G5 [get_ports UART1_rxd]
> #HD_GPIO_4 on FPGA / Connector pin 11 / UART1_txd set_property PACKAGE_PIN
> F6 [get_ports UART1_txd]
> 
> You can get a look at the hardware platform by installing the posted 
> PetaLinux BSP
> for the Ultra96 board:
> https://www.xilinx.com/member/forms/download/xef.html?filename=xilinx-
> ultra96-reva-v2018.2-final.bsp
> <https://www.xilinx.com/member/forms/download/xef.html?filename=xilinx-
> ultra96-reva-v2018.2-final.bsp>
> 
> See Xilinx UG1144 for the BSP install instructions:
> http://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1144-
> petalinux-tools-reference-guide.pdf
> <http://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1144
> -petalinux-tools-reference-guide.pdf>
> 
> To use the Avnet USB UART/JTAG adapter the UART needs to be changed from EMIO
> to MIO[0:1] in the PSU config of the Vivado design.  Then it should be 
> possible to
> regenerate the hdf file and drop it in the correct folder and run a new 
> bitbake build.
> 
> --Tom
> 
> 
> From: meta-xilinx-boun...@yoctoproject.org <mailto:meta-xilinx-
> boun...@yoctoproject.org>  [mailto:meta-xilinx-boun...@yoctoproject.org
> <mailto:meta-xilinx-boun...@yoctoproject.org> ] On Behalf Of Manjukumar
> Harthikote Matha
> Sent: Wednesday, September 26, 2018 11:17 AM
> To: Tomas Thoresen mailto:tom...@xilinx.com> >;
> simon.g...@doulos.com <mailto:simon.g...@doulos.com> ; meta-
> xil...@lists.yoctoproject.org <mailto:meta-xil...@lists.yoctoproject.org>
> Subject: Re: [meta-xilinx] Ultra96 UART
> 
> Hi,
> 
> Yes it should be psu_uart_1. Please use rel-v2018.3 branches from 
> github.com/xilinx
> tree, we have verified and it works.
> https://github.com/Xilinx/meta-xilinx-tools/blob/rel-
> v2018.2/classes/xsctyaml.bbclass#L15-L16 
> <https://github.com/Xilinx/meta-xilinx-
> tools/blob/rel-v2018.2/classes/xsctyaml.bbclass#L15-L16>
> 
> You can use repo command to get the release branches
> http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto
> <http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto>
> 
> Thanks,
> Manju
> 
> From: meta-xilinx-boun...@yoctoproject.org <mailto:meta-xilinx-
> boun...@yoctoproject.org> <mailto:meta-xilinx-boun...@yoctoproject.org
> <mailto:meta-xilinx-boun...@yoctoproject.org&g

Re: [meta-xilinx] ZCU111

[Manjukumar Harthikote Matha]

Hi Fraz,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Franz Forstmayr
> Sent: Friday, September 28, 2018 12:06 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] ZCU111
> 
> Hello,
> is there already a support for ZCU111 boards with a RFSoC on it?
> There's no machine conf yet. Should I use the meta-xilinx rel-v2018.2 branch 
> from
> github? And will the boot.bin be generated automatically?
> I can't find support for ZCU111 Boards in xsdk.
> 
You can use repo command to get the release branches  rel-v2018.2
http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto

It will build the required boot components for ZCU111 RFSoC

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Ultra96 UART

[Manjukumar Harthikote Matha]

Hi,

Yes it should be psu_uart_1. Please use rel-v2018.3 branches from 
github.com/xilinx tree, we have verified and it works.
https://github.com/Xilinx/meta-xilinx-tools/blob/rel-v2018.2/classes/xsctyaml.bbclass#L15-L16

You can use repo command to get the release branches
http://www.wiki.xilinx.com/How%20to%20build%20images%20through%20yocto

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Tomas Thoresen
Sent: Wednesday, September 26, 2018 2:04 AM
To: simon.g...@doulos.com; meta-xil...@lists.yoctoproject.org
Subject: Re: [meta-xilinx] Ultra96 UART

Hi Simon,

If I’m not mistaking, I believe it uses uart1 instead of uart0...

So, something like this:

YAML_BSP_CONFIG[stdin]="set,psu_uart_1"
YAML_BSP_CONFIG[stdout]="set,psu_uart_1"


Hope this helps.

Cheers,

Tomas

From: 
meta-xilinx-boun...@yoctoproject.org
 [mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of 
simon.g...@doulos.com
Sent: 26 September 2018 09:48
To: 
meta-xil...@lists.yoctoproject.org
Subject: [meta-xilinx] Ultra96 UART

Hi

I am trying to get a meta-xilinx/meta-xilinx-tools build (using versions Rocko 
& rel-v2018.2) to boot on an Ultra96 board. Following the various bits of 
guidance from this list I have successfully built, and have all the files I 
would expect in tmp/deploy/images/.

The files do not seem to boot - or at least I don't see anything on the serial 
(via the Avnet serial to USB dongle for the Ultra96).

I have read on another forum 
(http://zedboard.org/content/j6-serial-port-appears-not-be-working) that the 
default config of the FSBL for the Ultra96 board does not configure the UART 
properly and indeed using a 'hacked' boot.bin which has been 'fixed' from that 
forum entry I can boot the board and see output on the UART.

My questions are:

- Has anyone else successfully booted an Ultra96 using 
meta-xilinx/meta-xilinx-tools?
- If so, did you see anything on the UART? Were any changes made to the FSBL 
configuration to achieve this?

Any comments or guidance gratefully received!

Thanks & regards
Simon Goda


-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH v2 1/2] device-tree: Consolidate device-tree recipe and append

[Manjukumar Harthikote Matha]

Hi Nathan,

> -Original Message-
> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
> Sent: Wednesday, August 29, 2018 1:25 AM
> To: meta-xilinx@yoctoproject.org
> Cc: Nathan Rossi ; Manjukumar Harthikote Matha
> 
> Subject: [PATCH v2 1/2] device-tree: Consolidate device-tree recipe and append
> 
> With the introduction of devicetree.bbclass in oe-core/meta, remove the
> implementation of device tree compilation from device-tree.bb keeping the 
> meta-
> xilinx specific information and licensing. Also consolidate the 
> device-tree.bb and
> device-tree.bbappend.
> 
> The only differences between the existing device-tree.bb implementation and 
> the
> devicetree.bbclass implementation is the device trees are deployed in a
> "devicetree/" subdirectory within the deployed images directory.
> 

Series looks good, thanks. 
I am in process of verifying the patch, will apply after testing.

Thanks,
Manju

<...>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Ultra96 BSP

[Manjukumar Harthikote Matha]

Hi Philip,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Philip Balister
> Sent: Monday, September 17, 2018 9:03 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Ultra96 BSP
> 
> Is there a BSP for the Ultra96 board? I took a quick look in meta-xilinx and 
> didn't see
> a machine definition.
> 

We are working on a recipe that can work with OSL (SPL, pmu-frimware etc). I 
had sent a patch few months back, however the board resets using the SPL flow. 

We have it working with meta-xilinx-tools layer and is pushed out in release 
branches in github.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Kernel (linux-xlnx) hangs when trying to mount root (SD card & NFS)

[Manjukumar Harthikote Matha]

Hi Jesse,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Kleve, Jesse R
> Sent: Wednesday, September 12, 2018 6:08 PM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Kernel (linux-xlnx) hangs when trying to mount root 
> (SD card &
> NFS)
> 
> I’m trying to get my petalinux dom0 kernel to mount my rootfs on top of Xen. 
> I’m
> running on the zcu102. The issue I’m having is that the boot hangs at 
> mounting the
> rootfs. I’ve tried setting the rootfs to my second partition on my SD card as 
> well as a
> NFS mount.
> 
> I think I’ve ruled out it being an issue with my SD card since I’ve been 
> trying NFS too.
> Also, I can get the SD card to mount as the rootfs if I run my kernel 
> bare-metal
> without Xen. Because of this, I don’t think this post will help me but I 
> could be
> wrong.
> https://forums.xilinx.com/t5/Embedded-Linux/Xilinx-Linux-does-not-detect-SD-
> card-on-boot/m-p/504439#M10196
> 


Check this link, I think u-boot bootargs needs to be changed for SD boot

http://www.wiki.xilinx.com/Booting%20Xen%20on%20ZCU102%20using%20SD%20card

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Error on build meta-xilinx

[Manjukumar Harthikote Matha]

Hi Arturo

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Arturo Lara Martinez
> Sent: Monday, September 10, 2018 3:01 AM
> To: meta-xil...@lists.yoctoproject.org
> Subject: [meta-xilinx] Error on build meta-xilinx
> 
> Hi,
> 
> 
> 
> 
> 
> My name is Arturo from Spain, and I'm trying to build a Yocto project for 
> Xilinx.
> 
> 
> 
> 
> I just added meta-xilinx layer, no more layers, and I configure local.conf 
> setting
> MACHINE to "zcu102-zynqmp" and adding the layers to the build as say the build
> readme file.
> 
> 
> 
> 
> I don't do any more and I get an error on build:
> 
> 
> 
> 
> ERROR: zynqmp-pmu-binutils-cross-microblazeel-2.31-r0 do_patch: Command Error:
> 'quilt --quiltrc /home/arturo/source/poky/build/tmp/work/x86_64-linux/zynqmp-
> pmu-binutils-cross-microblazeel/2.31-r0/recipe-sysroot-native/etc/quiltrc 
> push'
> exited with 0  Output:
> Applying patch 0003-Disable-the-warning-message-for-eh_frame_hdr.patch
> patching file bfd/elf-eh-frame.c
> Hunk #1 FAILED at 1042.
> 1 out of 1 hunk FAILED -- rejects in file bfd/elf-eh-frame.c Patch 
> 0003-Disable-the-
> warning-message-for-eh_frame_hdr.patch does not apply (enforce with -f)
> ERROR: zynqmp-pmu-binutils-cross-microblazeel-2.31-r0 do_patch: Function 
> failed:
> patch_do_patch
> ERROR: Logfile of failure stored in:
> /home/arturo/source/poky/build/tmp/work/x86_64-linux/zynqmp-pmu-binutils-
> cross-microblazeel/2.31-r0/temp/log.do_patch.20101
> ERROR: Task (virtual:zynqmp-pmu:/home/arturo/source/poky/meta/recipes-
> devtools/binutils/binutils-cross_2.31.bb:do_patch) failed with exit code '1'
> 
> 
> I don't know if I miss any step or is something wrong, also try to clone 
> again repos
> form poky and meta-xilinx, but the error still there.
> 
> 
> 
> 
> what I do for prepare to build was:
> 
> 1.
>   sudo apt-get install gawk wget git-core diffstat unzip texinfo 
> gcc-multilib \
>build-essential chrpath socat cpio python python3 python3-pip 
> python3-
> pexpect \
>xz-utils debianutils iputils-ping libsdl1.2-dev xterm
> 2.
>   git clone git://git.yoctoproject.org/poky
> 3.
>   source oe-init-build-env
> 4.
>   cd ~/pokygit clone https://git.yoctoproject.org/git/meta-xilinx
> 5.
>   *Add to local.conf MACHINE ?= "zcu102-zynqmp"*
> 
> 
> 6.
> 
>   bitbake-layers add-layer ../meta-xilinx/meta-xilinx-bsp/
> 7.
> 
>   bitbake-layers add-layer ../meta-xilinx/meta-xilinx-contrib/
> 8.
> 
>   bitbake core-image-minimal
> 

Use a released branch like rocko or sumo instead of master

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] xserver-xorg recipe fails with mali

[Manjukumar Harthikote Matha]

Hi Noor,

rel-v2018.1 branch is compatible only with Rocko branch.

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Ahsan, Noor
Sent: Friday, August 31, 2018 4:12 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] xserver-xorg recipe fails with mali

Hello,

We are using rel-v2018.1 branch with oe-core sumo branch. We are building 
xserver-xorg with mali and facing some build issues. Xserver-xorg now needs 
libgbm which is coming from glamor packageconfig but mali is not providing 
libgbm. If we remove that dependency the configure of xserver-xorg fails saying

| checking for "gbm >= 10.2.0"... no
| configure: error: Glamor for Xorg requires gbm >= 10.2.0

Is there any solution to this.

Noor
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] meta-xilinx-tools

[Manjukumar Harthikote Matha]

Thanks for the patch Hafiz, will test and integrate

Thanks,
Manju

From: meta-xilinx-boun...@yoctoproject.org 
[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of Karim, Hafiz Abdul
Sent: Thursday, August 16, 2018 7:56 AM
To: meta-xil...@lists.yoctoproject.org
Subject: [meta-xilinx] meta-xilinx-tools


Hi,



I tried to bake pmu-firmware recipe.  I got "Exception: ImportError: No module 
named 'yaml'"

because in class xsctyaml.bbclass PYTHON_SITEPACKAGES_DIR is set to 
/usr/lib64/python3.5/site-packages while python native is at /usr/lib... 
instead of

/usr/lib64/...



My fix is attached.



Thanks.

Hafiz Abdul karim
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] petaLinux2018.2

[Manjukumar Harthikote Matha]

From: General-ChunTian Cai [mailto:general-chuntian@cn.abb.com] 
Sent: Monday, August 13, 2018 8:32 PM
To: Manjukumar Harthikote Matha ; nat...@nathanrossi.com
Cc: meta-xil...@lists.yoctoproject.org
Subject: petaLinux2018.2

Hi All,
I downloaded and installed petaLinux2018.2 on ubuntu16.04 (install folder is 
$HOME/xlnx). I want build u-boot.elf for ZU3 CPU. 

I have no git proxy so I want the yocto installed by petaLinux.


Why are you mixing PetaLinux and Yocto? Use Yocto as-is or stick with PetaLinux 
commands, don't mix and match


<...>

<...>
  # delete the old tarball, we don't need it anymore
    rm 
/home/ubuntu/xlnx/components/yocto/source/aarch64/tmp/work/zynqmp_generic-xilinx-linux/cloud-image-controller/1.0-r0/x86_64-deploy-cloud-image-controller-populate-sdk/petalinux-glibc-x86_64-cloud-image-controller-aarch64-toolchain-2018.2.tar.xz
which triggered exception OSError: [Errno 12] Cannot allocate memory

This error mainly happens when the host system is exhausted out of resources. 
Use BB_NUMBER_OF_THREADS and PARALLEL_MAKE to reduce the load.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Support for PicoZed 7030 and FMC V2 Carrier

[Manjukumar Harthikote Matha]

Hi Andy,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Andreas Galauner
> Sent: Tuesday, July 31, 2018 1:39 PM
> To: meta-xilinx@yoctoproject.org; Thomas Goodwin
> 
> Subject: Re: [meta-xilinx] Support for PicoZed 7030 and FMC V2 Carrier
> 
> On 10.07.2018 17:05, Thomas Goodwin wrote:
> > Hello,
> >
> > I'm attempting to build the picozed-zynq7 machine using meta-xilinx
> > with Poky 2.4.2.  I've tried using the /rocko/ branch as well as
> > /rel-v2018.2/.  For the latter, I had to patch the machine definition
> > since it was missing /require
> > /(PR: https://github.com/Xilinx/meta-xilinx/pull/9).  My layer
> > configuration is:
> >
> > BBLAYERS ?= " \
> >   /ssd/yocto_projects/picozed/poky/meta \
> >   /ssd/yocto_projects/picozed/poky/meta-poky \
> >   /ssd/yocto_projects/picozed/poky/meta-xilinx/meta-xilinx-bsp \
> >   "
> >
> > In each case, I can build /core-image-minimal/, however there is no
> > console output on boot over the UART.  The D10 and D11 PS LEDs on the
> > FMC carrier card are flashing in sync.
> >
> > Has anyone else successfully built for this target recently?
> 
> Yes, the u-boot device tree is broken for the Picozed. There is no console 
> defined
> (the chosen/stdout-path node is missing) and because of that u-boot panics and
> the board resets. That's why the LEDs are "blinking"
> 
> I stepped through the code using JTAG and found out what's causing this after 
> a
> longer debugging session. I fixed the device tree and it started to work. I 
> also
> added some more stuff to it like USB, QSPI and the Ethernet MAC. In theory 
> that
> should make them work as well, but I'm not sure if I ever tested that.

Can you submit the patch to u-boot mainline?

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Nothing PROVIDES 'virtual/xilinx-platform-init'

[Manjukumar Harthikote Matha]

Hi Arno,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Arno Steffens
> Sent: Friday, July 27, 2018 12:59 AM
> To: meta xilinx 
> Subject: [meta-xilinx] Nothing PROVIDES 'virtual/xilinx-platform-init'
> 
> Hello,
> After upgrade to Sumo I found some errors, that I can't understand.
> As fas as I can see the microzed_zynq7 is still available?
> 
> ERROR: Nothing PROVIDES 'virtual/xilinx-platform-init' (but
> /home/user/y/yocto25/poky/meta/recipes-bsp/u-boot/u-boot_2018.01.bb
> DEPENDS on or otherwise requires it)
> zybo-linux-bd PROVIDES virtual/xilinx-platform-init but was skipped: 
> incompatible
> with machine microzed-zynq7 (not in COMPATIBLE_MACHINE)
> platform-init PROVIDES virtual/xilinx-platform-init but was skipped: 
> incompatible
> with machine microzed-zynq7 (not in COMPATIBLE_MACHINE)
> ERROR: Required build target 'virtual/boot-bin' has no buildable providers.
> Missing or unbuildable dependency chain was: ['virtual/boot-bin', 
> 'virtual/xilinx-
> platform-init']
> 
> I checked u-boot_2018.01.bb, it included u-boot-common_2018.01.inc, but I 
> can't
> see a requirement for vitural/xilinx-platform-init?
> 
> And also I found "microzed-zynq7" is still in meta-xilinx, as for instance:
> ./meta-xilinx-bsp/recipes-bsp/device-tree/device-
> tree.bbappend:COMPATIBLE_MACHINE_microzed-zynq7 = ".*"
> 
> So what happened here?
> 
> As background:
> I created my own layer and set in
> meta-my/conf/local.conf.sample
> # This sets the default machine to be qemux86 if no other machine is selected:
> MACHINE ??= "microzed-zynq7"
> 
> Than I call
> TEMPLATECONF=~/sdd/yocto25/meta-my/conf/ source ~/sdd/yocto25/poky/oe-
> init-build-env ~/sdd/yocto25/my
> 

There is an issue on meta-xilinx-contrib recipe causing the issue. I have sent 
out a patch to fix this

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Openssl incompatible compression

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Nathan Rossi
> Sent: Tuesday, July 24, 2018 11:14 PM
> To: Maarten Brock 
> Cc: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] Openssl incompatible compression
> 
> On 25 July 2018 at 02:11, Maarten Brock  wrote:
> > Hello all,
> >
> > I'm new to this mailing list, so forgive me if I post this question in the
> > wrong place.
> >
> > I'm using Petalinux 2018.2 on a Zynq which comes with openssl 1.0.2l and I
> > want to exchange encrypted files with an x86 linux which has openssl 1.0.2g.
> > I use aes256 for encryption. However the Zynq gives 'bad decrypt' error
> > messages when trying to decrypt the files from the x86. The same goes vice
> > versa.
> >
> > I also tried with openssl 1.0.2g and openssl 1.0.2o on windows. Works fine
> > with x86 linux, but not with the Zynq.
> >
> > Then I compiled openssl 1.0.2p from source for the Zynq and that also works.
> >
> > In short, it's the openssl that petalinux/yocto provides that is
> > incompatible.
> >
> > Going back to an older petalinux 2017.4 which has openssl 1.0.2j also works
> > as expected.
> >
> > Is this a known problem that is maybe already fixed? I couldn't find any
> > mention of it.
> 
> So I am not sure on the specifics on the PetaLinux side. But in
> oe-core there was a armv7 issue with binutils 2.29 and openssl which
> was patched in the sumo branch. But it sounds like the same issue you
> are describing (aes related).
> 
> It affected both versions of openssl (1.0.2m and 1.1.0g)
> http://git.openembedded.org/openembedded-
> core/commit/?id=977db3843b629112539d3eb766c845127c0de497
> http://git.openembedded.org/openembedded-
> core/commit/?id=e76dcfbd6e1ad6fc147a0607dcdaf8e7ea98b610
> 

The above patches were not present in Rocko v2.4.1 (PetaLinux 2018.2 uses this 
version). The newer release of Rocko v2.4.2 has included this fix and should be 
in PetaLinux 2018.3

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] PMUFW debugging with debug flags

[Manjukumar Harthikote Matha]

Hi,

Can you try the following
EXTRA_COMPILER_FLAGS_append = " -DXPFW_DEBUG_DETAILED -DDEBUG_MODE -DENABLE_EM"

This should be reflected in the log.do_compile 
Also note, uart settings for PMU firmware matters to check the prints in 
appropriate console

Thanks,
Manju


> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Peter Smith
> Sent: Monday, July 23, 2018 6:55 AM
> To: Giordon Stark 
> Cc: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] PMUFW debugging with debug flags
> 
> I think that's correct yes. It will get the source of the PMU firmware from 
> the repo
> below using the 2018.2 tag:
> EMBEDDEDSW_REPO ?= "git://github.com/Xilinx/embeddedsw.git;protocol=https
>  "
> Best Regards
> Peter
> 
> 
> On Mon, 23 Jul 2018 at 14:47, Giordon Stark   > wrote:
> 
> 
>   So is the m-x-t layer using a recipe described by this page
> (http://www.wiki.xilinx.com/PMU+Firmware) and not the m-x-bsp layer?
> 
>   That's unfortunate if so. I'd rather not pull in m-x-t right now.
> 
>   Giordon
> 
>   On Thu, Jul 19, 2018 at 9:00 AM Peter Smith   > wrote:
> 
> 
>   The two recipes are different for sure, I noticed this only 
> yesterday
> and yes you need xsct for m-x-t
> 
>   On Thu, 19 Jul 2018, 14:58 Giordon Stark,   > wrote:
> 
> 
>   Hi JF,
> 
>   No, but I am on rocko so it's got the two different 
> layers
> under meta-xilinx and I'm using the meta-xilinx-bsp version. Is 
> meta-xilinx-tools
> completely different? The main reason I'm not using meta-xilinx-tools right 
> now is
> that my understanding is I need the SDK installed on the machine and point 
> m-x-t
> at it, and I'm just trying to get things in a way that doesn't depend on 
> something
> external to yocto...
> 
>   Giordon
> 
>   On Thu, Jul 19, 2018 at 8:55 AM Jean-Francois Dagenais
> mailto:jeff.dagen...@gmail.com> > wrote:
> 
> 
>   Hi Giordon,
> 
>   > On Jul 19, 2018, at 8:58 AM, Giordon Stark
> mailto:kra...@gmail.com> > wrote:
>   >
>   > However, when recompiling and re-running -- I
> do not see extra debug information from the PMUFW -- so I'm patching the 
> kernel
> drivers/clk/zynqmp/pll.c to get more information about the PLL hang itself in 
> the
> meantime.
>   >
>   > Any ideas? Did I do something wrong in
> enabling the debug flags?
> 
>   Are you using the meta-xilinx-tools pmu_firmware
> recipe?
> 
>   I ask because, coincidently, I am discussing a
> patch in xsctbase:do_configure about cleaning the xsct workspace on
> do_configure start to avoid these kinds of behaviour. See
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-June/003916.html and
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-July/003986.html
> 
>   Turns out I had the manual "rm" in my local repo
> only, but the point remains.
> 
>   Hope this helps!
> 
>   --
> 
>   Giordon Stark
> 
>   --
>   ___
>   meta-xilinx mailing list
>   meta-xilinx@yoctoproject.org  xil...@yoctoproject.org>
>   https://lists.yoctoproject.org/listinfo/meta-xilinx
> 
> 
>   --
> 
>   Giordon Stark

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Where are the TUNE_CCARGS when compiling for cortex-a53 with zynqmp

[Manjukumar Harthikote Matha]

Hi Maxime,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Maxime Roussin-Belanger
> Sent: Friday, July 13, 2018 10:05 AM
> To: nat...@nathanrossi.com
> Cc: meta-xil...@lists.yoctoproject.org
> Subject: [meta-xilinx] Where are the TUNE_CCARGS when compiling for cortex-
> a53 with zynqmp
> 
> Hello!
> 
> When are compiling our recipes with a cross aarch64-gcc compiler, we don't see
> any "-march=armv8-a -mtune=cortex-a57.cortex-a53" flags in the Makefiles and 
> in
> the log.do_compile or log.do_configure.
> 
> We require tune-zynqmp.conf in our machine configuration and that means we do
> see the aarch64 flags, but not the cortex tune. I didn't find any 
> tune-cortexa53,
> does that mean there is nothing to do for that CPU and that we should just use
> the default aarch64 tune?
> 

The require file here
https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/conf/machine/include/tune-zynqmp.inc#L11

includes all the required tune for aarch64
https://github.com/openembedded/openembedded-core/blob/master/meta/conf/machine/include/arm/arch-arm64.inc

> Are they implicit(the compiler flags) when using an aarch64 cross compiler?
> 
Yes
> Do I have to create my own tune file for the cortex-a57.cortex-a53?
> 
Don't think so you need one for aarch64

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] xsctbase: do not delete CWD when do_configure starts

[Manjukumar Harthikote Matha]

Hi Jean-Francois,

I updated the master to track rel-v2018.2 branch. 
I don't think we had rm -rf ${XSCTH_WS} in xsctbase.bbclass, is this something 
in your tree?

Thanks,
Manju

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Manjukumar Harthikote Matha
> Sent: Monday, July 16, 2018 1:21 AM
> To: Jean-Francois Dagenais ; meta-
> xil...@yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH] xsctbase: do not delete CWD when
> do_configure starts
> 
> Hi Jean-Francois,
> 
> I might have missed this patch, will look into it this week
> 
> Thanks,
> Manju
> 
> > -Original Message-
> > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> > boun...@yoctoproject.org] On Behalf Of Jean-Francois Dagenais
> > Sent: Friday, July 13, 2018 9:30 AM
> > To: meta-xilinx@yoctoproject.org
> > Subject: Re: [meta-xilinx] [PATCH] xsctbase: do not delete CWD when
> > do_configure starts
> >
> > anyone? Manju?
> >
> > > On Jun 7, 2018, at 10:19 AM, Jean-Francois Dagenais
> >  wrote:
> > >
> > > This is to fix these errors in the configure.log:
> > >
> > > shell-init: error retrieving current directory: getcwd: cannot
> > > access parent directories: No such file or directory
> > > chdir: error retrieving current directory: getcwd: cannot access
> > > parent
> > > directories: No such file or directory
> > >
> > > Signed-off-by: Jean-Francois Dagenais 
> > > ---
> > > classes/xsctbase.bbclass | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/classes/xsctbase.bbclass b/classes/xsctbase.bbclass
> > > index
> > > 74d8067..d764898 100644
> > > --- a/classes/xsctbase.bbclass
> > > +++ b/classes/xsctbase.bbclass
> > > @@ -27,7 +27,7 @@ do_configure() {
> > > export RDI_PLATFORM=lnx64
> > > export SWT_GTK3=0
> > >
> > > -rm -rf ${XSCTH_WS}
> > > +ls -A | xargs rm -rf
> > >
> > > if [ -d "${S}/patches" ]; then
> > >rm -rf ${S}/patches
> > > --
> > > 2.11.0
> > >
> >
> > --
> > ___
> > meta-xilinx mailing list
> > meta-xilinx@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-xilinx
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [[meta-xilinx-bsp][PATCH v2]] device-tree.bb: add missing include path

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Martin Siegumfeldt
> Sent: Tuesday, July 17, 2018 12:56 AM
> To: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] [[meta-xilinx-bsp][PATCH v2]] device-tree.bb: add
> missing include path
> 
> Ping? Manju?
> 
> From: Martin Siegumfeldt 
> Sent: Thursday, June 21, 2018 2:36 PM
> To: meta-xilinx@yoctoproject.org
> Cc: Martin Siegumfeldt
> Subject: [[meta-xilinx][meta-xilinx-bsp][PATCH v2]] device-tree.bb: add 
> missing
> include path
> 
> This patch adds a missing include path for generic kernel DTC
> includes.
> 
> Signed-off-by: Martin Siegumfeldt 
> Reviewed-by: Nathan Rossi 
> ---
>  meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb 
> b/meta-xilinx-
> bsp/recipes-bsp/device-tree/device-tree.bb
> index dc49cbb..d1b6771 100644
> --- a/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> +++ b/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> @@ -30,6 +30,7 @@ SYSROOT_DIRS += "/boot/devicetree"
>  KERNEL_DTS_INCLUDE ??= " \
> ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
> ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/include \
> +   ${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
> "
>  # For arm64/zynqmp the xilinx specific includes are subdired under a vendor
> directory.
>  KERNEL_DTS_INCLUDE_append_zynqmp = " \
> --
> 2.14.1
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-tools] error while building pmu-firmware

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Ahsan, Noor [mailto:noor_ah...@mentor.com]
> Sent: Wednesday, July 18, 2018 2:50 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@lists.yoctoproject.org
> Subject: RE: [meta-xilinx-tools] error while building pmu-firmware
> 
> 
> 
> >-Original Message-
> >From: Ahsan, Noor
> >Sent: Monday, July 02, 2018 5:27 PM
> >To: 'Manjukumar Harthikote Matha' ; meta-
> xil...@lists.yoctoproject.org
> >Subject: RE: [meta-xilinx-tools] error while building pmu-firmware
> >
> >
> >
> >>> but I think this is not correct as for 64bit architecture the
> >>> PYTHON_SITEPACKAGES_DIR is set to /usr/lib64/python3.5/site-packages
> >>> but python native will be location in /usr/lib/ not in /usr/lib64.
> >>> This will cause the above error that I am getting. Have anybody seen this
> issue?
> >>>
> >>
> >>Can you try installing it on the host using
> >>pip3 install pyyaml
> >
> >I think the meaning of this line https://github.com/Xilinx/meta-xilinx-
> tools/blob/rel->v2018.2/classes/xsctyaml.bbclass#L3 was that that yaml will be
> used which is building our build system. We >should not use host pyyaml.
> 
> 
> Any update on this?

I am not able to reproduce the error, were you able install in the host as well 
to see if it works?

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] xsctbase: do not delete CWD when do_configure starts

[Manjukumar Harthikote Matha]

Hi Jean-Francois,

I might have missed this patch, will look into it this week

Thanks,
Manju

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Jean-Francois Dagenais
> Sent: Friday, July 13, 2018 9:30 AM
> To: meta-xilinx@yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH] xsctbase: do not delete CWD when
> do_configure starts
> 
> anyone? Manju?
> 
> > On Jun 7, 2018, at 10:19 AM, Jean-Francois Dagenais
>  wrote:
> >
> > This is to fix these errors in the configure.log:
> >
> > shell-init: error retrieving current directory: getcwd: cannot access
> > parent directories: No such file or directory
> > chdir: error retrieving current directory: getcwd: cannot access
> > parent
> > directories: No such file or directory
> >
> > Signed-off-by: Jean-Francois Dagenais 
> > ---
> > classes/xsctbase.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/classes/xsctbase.bbclass b/classes/xsctbase.bbclass index
> > 74d8067..d764898 100644
> > --- a/classes/xsctbase.bbclass
> > +++ b/classes/xsctbase.bbclass
> > @@ -27,7 +27,7 @@ do_configure() {
> > export RDI_PLATFORM=lnx64
> > export SWT_GTK3=0
> >
> > -rm -rf ${XSCTH_WS}
> > +ls -A | xargs rm -rf
> >
> > if [ -d "${S}/patches" ]; then
> >rm -rf ${S}/patches
> > --
> > 2.11.0
> >
> 
> --
> ___
> meta-xilinx mailing list
> meta-xilinx@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Mali Kernel Module for ZCU102

[Manjukumar Harthikote Matha]

Hi Emily,

You can use something like this
https://github.com/Xilinx/meta-xilinx/blob/rel-v2018.2/meta-xilinx-bsp/conf/machine/include/machine-xilinx-default.inc#L32-L36

The above can be used from master/sumo branch.

This hasn't been added yet to master, note that not all variants of FPGA 
support MALI 400 GPU.
I will send a patch this week to update the defaults using the override 
mechanism.

Thanks,
Manju

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Jean-Francois Dagenais
> Sent: Sunday, July 15, 2018 5:06 PM
> To: Emily Smith 
> Cc: Luca Ceresoli ; meta-xil...@lists.yoctoproject.org
> Subject: Re: [meta-xilinx] Mali Kernel Module for ZCU102
> 
> Hi Emily,
> 
> The lines you are quoting are from includes (.inc) so you should be getting 
> them
> on the zcu102 machine conf. What version of meta-xilinx are you using?
> 
> In recent versions, the mali stuff is triggered by the SOC_VARIANT variable 
> being
> at least "eg". This triggers a series of smart yocto "overrides" and all the 
> mali stuff
> follows. As usual, "grep" is your friend in figuring most of this stuff out. 
> There is no
> nice walkthrough, one has to hack a little bit to get things going the way 
> you want
> to. ;) It gets much easier as you "suffer" along the way. (I'm talking about 
> yocto in
> general here ;)
> 
> Cheers!
> 
> 
> 
>   On Jul 13, 2018, at 6:29 PM, Emily Smith   > wrote:
> 
>   Hi Luca / All -
> 
>   Like I mentioned previously, my machine conf didn't have the lines you
> indicated
> 
>   PREFERRED_PROVIDER_virtual/libgles2 = "libmali-xlnx"
>   PREFERRED_PROVIDER_virtual/egl  = "libmali-xlnx"
> 
> 
> 
>   Is there a reason why they aren't in the default machine conf for ZCU102
> since it does have the Mali 400 GPU?
> 
> 
>   When I do add them, I end up with this error:
> 
> 
> 
>   ERROR: Nothing PROVIDES 'virtual/libgl' (but
> /local/d6/easmith5/BuildOS/openembedded-core/meta/recipes-
> graphics/mesa/libglu_9.0.0.bb, /local/d6/easmith5/BuildOS/openembedded-
> core/meta/recipes-graphics/glew/glew_2.0.0.bb DEPENDS on or otherwise
> requires it)
>   mesa-gl PROVIDES virtual/libgl but was skipped:
> PREFERRED_PROVIDER_virtual/libgl set to mesa, not mesa-gl
>   mesa PROVIDES virtual/libgl but was skipped:
> PREFERRED_PROVIDER_virtual/libgles2 set to libmali-xlnx, not mesa
>   mesa PROVIDES virtual/libgl but was skipped:
> PREFERRED_PROVIDER_virtual/libgles2 set to libmali-xlnx, not mesa
>   mesa-gl PROVIDES virtual/libgl but was skipped:
> PREFERRED_PROVIDER_virtual/libgl set to mesa, not mesa-gl
> 
> 
> 
> 
> 
> 
>   I haven't had any luck trying to set the preferred provider for 
> virtual/libgl
> to get rid of this error.
> 
> 
>   In the recipe I'm currently working on I did also set RDEPENDS for 
> libmali-
> xlnx, but I'm not sure that worked properly. It seems to have built fine, but 
> I still
> don't seem to have the mali kernel module afterwards.
>   Do you have any further suggestions?
> 
> 
>   Thanks very much for your time!
>   Emily
> 
> 
> 
>   From: Luca Ceresoli   >
>   Sent: Friday, July 13, 2018 3:22:52 AM
>   To: Emily Smith; meta-xil...@lists.yoctoproject.org  xil...@lists.yoctoproject.org>
>   Subject: Re: [meta-xilinx] Mali Kernel Module for ZCU102
> 
> 
>   Hi Emily,
> 
>   On 12/07/2018 17:12, Emily Smith wrote:
>   > Hi Everyone -
>   >
>   >
>   > I'm using poky and bitbake to build an OS for the Xilinx ZCU102 board,
>   > and I'm having trouble with the Mali Kernel Module here:
>   >
>   > https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-
> bsp/recipes-graphics/mali
>   >
>   >
>   > I thought it should be built with the  /meta-xilinx/meta-xilinx-bsp
>   > layer added in bitbake, but  I'm not seeing a .ko file anywhere that's
>   > produced, or on the board once I boot it.  Nothing was showing up
>   > with lsmod either. Do I need to enable anything, or set any variables
>   > for this to be built in the first place?
>   >
>   >
>   > Any information you can give me would be very helpful.
> 
>   kernel-module-mali is pulled in by libmali-xlnx:
> 
> $ git grep -B1 kernel-module-mali
> .../libmali-xlnx.bb-RDEPENDS_${PN} = " \
> .../libmali-xlnx.bb:   kernel-module-mali \
> 
>   Is libmali-xlnx built?
> 
>   A few things to check, in top-bottom order:
>1. your machine conf should have something like
>   PREFERRED_PROVIDER_virtual/libgles2 = "libmali-xlnx"
>   PREFERRED_PROVIDER_virtual/egl  = "libmali-xlnx"
>2. libmali-xlnx should then be built
>3. libmali-xlnx RDEPENDS on kernel-module-mali, so it should
>   be built as 

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2] libmali-xlnx.bb: Add recipe to support MALI 400 binaries

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: Manjukumar Matha [mailto:manjukumar.harthikote-ma...@xilinx.com]
> Sent: Thursday, June 21, 2018 8:53 AM
> To: meta-xilinx@yoctoproject.org
> Cc: Manjukumar Harthikote Matha 
> Subject: [meta-xilinx-bsp][PATCH v2] libmali-xlnx.bb: Add recipe to support 
> MALI
> 400 binaries
> 
> This recipe allows user to fetch the MALI 400 binaries from xilinx.com 
> manually
> and use it with compatible machines based on UltraScale+ for
> libgles1/libgles2 and egl libraries.
> 
> Signed-off-by: Manjukumar Matha 
> ---
> Changelog:
> 
>  v2: add COMPATIBLE_MACHINE as zynqmpeg and zynqmpev
>  add PACKAGE ARCH as soc_family and soc_variant
>  The above changes are to meet the criteria for SOC_VARIANT introduced in
>  recent patches
> 
>  .../recipes-graphics/libgles/files/egl.pc  |  12 +++
>  .../recipes-graphics/libgles/files/glesv1.pc   |  12 +++
>  .../recipes-graphics/libgles/files/glesv1_cm.pc|  12 +++
>  .../recipes-graphics/libgles/files/glesv2.pc   |  12 +++
>  .../recipes-graphics/libgles/libmali-xlnx.bb   | 108 
> +
>  5 files changed, 156 insertions(+)
>  create mode 100644 meta-xilinx-bsp/recipes-graphics/libgles/files/egl.pc
>  create mode 100644 meta-xilinx-bsp/recipes-graphics/libgles/files/glesv1.pc
>  create mode 100644 
> meta-xilinx-bsp/recipes-graphics/libgles/files/glesv1_cm.pc
>  create mode 100644 meta-xilinx-bsp/recipes-graphics/libgles/files/glesv2.pc
>  create mode 100644 meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> 
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/files/egl.pc 
> b/meta-xilinx-
> bsp/recipes-graphics/libgles/files/egl.pc
> new file mode 100644
> index 000..f9935f2
> --- /dev/null
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/files/egl.pc
> @@ -0,0 +1,12 @@
> +prefix=/usr
> +exec_prefix=${prefix}
> +libdir=/usr/lib
> +includedir=/usr/include
> +
> +Name: egl
> +Description: MALI EGL library
> +Requires.private:
> +Version: r8p0
> +Libs: -L${libdir} -lEGL
> +Libs.private: -lm -lpthread -ldl
> +Cflags: -I${includedir}
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/files/glesv1.pc 
> b/meta-xilinx-
> bsp/recipes-graphics/libgles/files/glesv1.pc
> new file mode 100644
> index 000..4895400
> --- /dev/null
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/files/glesv1.pc
> @@ -0,0 +1,12 @@
> +prefix=/usr
> +exec_prefix=${prefix}
> +libdir=/usr/lib
> +includedir=/usr/include
> +
> +Name: glesv1
> +Description: MALI OpenGL ES 1.1 library
> +Requires.private:
> +Version: r8p0
> +Libs: -L${libdir} -lGLESv1_CM
> +Libs.private: -lm -lpthread -ldl
> +Cflags: -I${includedir}
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/files/glesv1_cm.pc 
> b/meta-
> xilinx-bsp/recipes-graphics/libgles/files/glesv1_cm.pc
> new file mode 100644
> index 000..888af87
> --- /dev/null
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/files/glesv1_cm.pc
> @@ -0,0 +1,12 @@
> +prefix=/usr
> +exec_prefix=${prefix}
> +libdir=/usr/lib
> +includedir=/usr/include
> +
> +Name: gles_cm
> +Description: Mali OpenGL ES 1.1 CM library
> +Requires.private:
> +Version: r8p0
> +Libs: -L${libdir} -lGLESv1_CM
> +Libs.private: -lm -lpthread -ldl
> +Cflags: -I${includedir}
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/files/glesv2.pc 
> b/meta-xilinx-
> bsp/recipes-graphics/libgles/files/glesv2.pc
> new file mode 100644
> index 000..5047c39
> --- /dev/null
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/files/glesv2.pc
> @@ -0,0 +1,12 @@
> +prefix=/usr
> +exec_prefix=${prefix}
> +libdir=/usr/lib
> +includedir=/usr/include
> +
> +Name: glesv2
> +Description: MALI OpenGL ES 2.0 library
> +Requires.private:
> +Version: r8p0
> +Libs: -L${libdir} -lGLESv2
> +Libs.private: -lm -lpthread -ldl
> +Cflags: -I${includedir}
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb 
> b/meta-xilinx-
> bsp/recipes-graphics/libgles/libmali-xlnx.bb
> new file mode 100644
> index 000..3e675d9
> --- /dev/null
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> @@ -0,0 +1,108 @@
> +DESCRIPTION = "libGLES for ZynqMP with Mali 400"
> +
> +LICENSE = "Proprietary"
> +LICENSE_FLAGS = "xilinx"
> +LIC_FILES_CHKSUM =
> "file://${COMMON_LICENSE_DIR}/Proprietary;md5=0557f9d92cf58f2ccdd50f62f8
> ac0b28"
> +
> +inherit distro_features_check
> +inherit xilinx-fetch-restricted
> +
> +ANY_OF_DISTRO_FEATURES = "fbdev x11"
> +
> +PROVIDES += "virtual/libgles1 virtual/libgles2 virt

Re: [meta-xilinx] [meta-xilinx-contrib][PATCH v4 4/4] minized-zynq7: Add wireless support

[Manjukumar Harthikote Matha]

Hi Clement,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Clement Laigle
> Sent: Tuesday, June 12, 2018 2:39 PM
> To: meta-xil...@lists.yoctoproject.org
> Subject: [meta-xilinx] [meta-xilinx-contrib][PATCH v4 4/4] minized-zynq7: Add
> wireless support
> 
> The Minized has a wireless connectivity (WiFi / Bluetooth). This recipes add
> drivers to use the murata wireless module.
> 
> Signed-off-by: Clement Laigle 
> ---
>  .../linux-firmware/linux-firmware_%.bbappend   | 33 
> ++
>  .../linux/linux-xlnx/v2018.1/wifi-bluetooth.cfg| 33 
> ++
>  .../linux/linux-xlnx_2018.1.bbappend   |  1 +
>  3 files changed, 67 insertions(+)
>  create mode 100644 meta-xilinx-contrib/recipes-kernel/linux-firmware/linux-
> firmware_%.bbappend
>  create mode 100644 meta-xilinx-contrib/recipes-kernel/linux/linux-
> xlnx/v2018.1/wifi-bluetooth.cfg
> 
> diff --git a/meta-xilinx-contrib/recipes-kernel/linux-firmware/linux-
> firmware_%.bbappend b/meta-xilinx-contrib/recipes-kernel/linux-firmware/linux-
> firmware_%.bbappend
> new file mode 100644
> index 000..2ba5178
> --- /dev/null
> +++ b/meta-xilinx-contrib/recipes-kernel/linux-firmware/linux-
> firmware_%.bbappend
> @@ -0,0 +1,33 @@
> +SUMMARY = "minized-wireless:  Wi-Fi/BT drivers and firmware for the Murata
> 1DX module"
> +
> +LIC_FILES_CHKSUM_append_minized-zynq7 = "file://${WORKDIR}/cyw-fmac-
> fw/LICENCE.cypress;md5=cbc5f665d04f741f1e006d2096236ba7"
> +
> +SRC_URI_append_minized-zynq7 = " \
> +   git://github.com/murata-wireless/cyw-fmac-
> fw;protocol=git;branch=orga;destsuffix=cyw-fmac-fw;name=cyw-fmac-fw \
> +   git://github.com/murata-wireless/cyw-fmac-
> nvram;protocol=git;branch=orga;destsuffix=cyw-fmac-nvram;name=cyw-fmac-
> nvram \
> +   
> git://github.com/murata-wireless/cyw-bt-patch;protocol=git;branch=morty-
> orga;destsuffix=cyw-bt-patch;name=cyw-bt-patch \
> +   git://github.com/murata-wireless/cyw-fmac-utils-
> imx32;protocol=git;branch=orga;destsuffix=cyw-fmac-utils-imx32;name=cyw-
> fmac-utils-imx32 \
> +"
> +
> +SRCREV_cyw-fmac-fw = "2242fd3f67a913fbfff8678cc8f7761629dca8ca"
> +SRCREV_cyw-fmac-nvram = "d12c2ac1b93941eaa03063bb7cb3c1ee1aa1b7d0"
> +SRCREV_cyw-bt-patch = "9216e0d9f778009b5667d032886dfd49174c4b3a"
> +SRCREV_cyw-fmac-utils-imx32 =
> "060688dfe76df98751207c8146268ce7fd80b6ab"
> +SRCREV_FORMAT = "default+cyw-fmac-fw+cyw-fmac-nvram+cyw-bt-patch+cyw-
> fmac-utils-imx32"
> +
> +do_install_append_minized-zynq7() {
> +
> +   install -d ${D}${sysconfdir}/firmware
> +   install -d ${D}${bindir}
> +
> +   cp ${WORKDIR}/cyw-fmac-fw/brcmfmac43430-sdio.bin
> ${D}/lib/firmware/brcm/brcmfmac43430-sdio.bin
> +   cp ${WORKDIR}/cyw-fmac-nvram/brcmfmac43430-sdio.txt
> ${D}/lib/firmware/brcm
> +   cp ${WORKDIR}/cyw-bt-patch/CYW43430A1.1DX.hcd
> ${D}${sysconfdir}/firmware
> +   cp ${WORKDIR}/cyw-fmac-utils-imx32/wl ${D}${bindir}/wl
> +}
> +
> +FILES_${PN}-bcm43430_append_minized-zynq7 = " \
> +   /lib/firmware/brcm/brcmfmac43430-sdio.bin \
> +   /lib/firmware/brcm/brcmfmac43430-sdio.txt \
> +   ${sysconfdir}/firmware/BCM43430A1.1DX.hcd \
> +"


I was thinking more in the lines of this recipe
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux-firmware/linux-firmware_%25.bbappend?h=master

You can see how they are updating the outdated linux-firmware files for BRCM 
firmware.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 0/4] Add SOC_VARIANT as override

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: Manjukumar Matha [mailto:manjukumar.harthikote-ma...@xilinx.com]
> Sent: Monday, May 28, 2018 1:34 AM
> To: meta-xilinx@yoctoproject.org
> Cc: Manjukumar Harthikote Matha 
> Subject: [meta-xilinx-bsp][PATCH 0/4] Add SOC_VARIANT as override
> 
> UltraScale+ FPGA has different variants of silicon to support different
> features like MALI400, VCU. Categorically there are three variants: cg 
> devices, eg
> devices(MALI 400) and ev devices (MALI 400+ VCU)
> 
> See detailed description of products here:
> https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-
> mpsoc.html#productTable
> 
> dr devices are based for UltraScale+ RFSoC
> 
> This patch allows machineoverides to be extended as zynqmp(cg|eg|ev|dr) and
> mali400/vcu (based on functionality).
> 
> This will extend MACHINEOVERRIDES for each device variant as:
> cg --> zynqmpcg
> eg --> zynqmpeg
> ev --> zynqmpev
> 
> and adds mali400:vcu as MACHINEOVERRIDES based on SoC feature.
> 
> Similarly for Zynq 7000 devices there are two variants
> https://www.xilinx.com/products/silicon-devices/soc/zynq-
> 7000.html#productTable
> 
> Available SOC_VARIANT's for zynq:
> "7zs" - Zynq-7000 Single A9 Core
> "7z"  - Zynq-7000 Dual A9 Core
> 
> This will extend MACHINEOVERRIDES for each device variant as:
> 7zs --> zynq7zs
> 7z  --> zynq7z
> 
> This helps in grouping of settings for similar SoC.
> One best example is to pin providers to MALI400 binaries.  If the mali400 is
> present in the override then default provider will be libmali-xlnx.  mali400 
> will be
> a override only for SOC_VARIANT which are eg and ev devices.
> 
> PREFERRED_PROVIDER_virtual/libgles1_mali400= "libmali-xlnx"
> PREFERRED_PROVIDER_virtual/libgles2_mali400= "libmali-xlnx"
> PREFERRED_PROVIDER_virtual/egl_mali400 = "libmali-xlnx"
> 
> This patch also adds packages to be a part of the feed based on SOC_FAMILY and
> SOC_VARIANT
> 
> The use case is to share the sstate-cache or feeds for packages which are 
> zynqmp
> based. Some packages can be SoC family based instead of machine.
> 
> Alejandro Enedino Hernandez Samaniego (1):
>   machine-xilinx-overrides.inc: Provide override mechanism depending on
>SoC features
> 
> Vineeth Chowdary Karumanchi (3):
>   tune-zynqmp.inc: Set default SOC_VARIANT to eg
>   tune-zynq.inc: Set SOC_VARIANT for zynq devices to 7z
>   conf/machine/*.conf: Add SOC_VARIANT for each machine
> 
>  .../machine/include/machine-xilinx-overrides.inc| 21 
> +
>  meta-xilinx-bsp/conf/machine/include/tune-zynq.inc  |  6 ++
>  .../conf/machine/include/tune-zynqmp.inc|  7 +++
>  meta-xilinx-bsp/conf/machine/microzed-zynq7.conf|  3 +++
>  meta-xilinx-bsp/conf/machine/picozed-zynq7.conf |  3 +++
>  meta-xilinx-bsp/conf/machine/qemu-zynq7.conf|  3 +++
>  meta-xilinx-bsp/conf/machine/zc702-zynq7.conf   |  2 ++
>  meta-xilinx-bsp/conf/machine/zc706-zynq7.conf   |  3 +++
>  meta-xilinx-bsp/conf/machine/zcu102-zynqmp.conf |  3 +++
>  meta-xilinx-bsp/conf/machine/zcu104-zynqmp.conf |  3 +++
>  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf |  3 +++
>  meta-xilinx-bsp/conf/machine/zedboard-zynq7.conf|  3 +++
>  .../conf/machine/zybo-linux-bd-zynq7.conf   |  3 +++
>  meta-xilinx-bsp/conf/machine/zybo-zynq7.conf|  3 +++
>  14 files changed, 66 insertions(+)
>  create mode 100644 meta-xilinx-bsp/conf/machine/include/machine-xilinx-
> overrides.inc
> 
> --
> 2.7.4

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Zynqmp QSPI boot: FSBL or SPL?

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Magne Munkejord
> Sent: Monday, June 11, 2018 8:42 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Zynqmp QSPI boot: FSBL or SPL?
> 
> Hi
> 
> I'm trying to generate boot images for QSPI for a custom board in Yocto but 
> ran
> into some issues.
> I use meta-xilinx-bsp and meta-xilinx-tools 2018.1 branches and I have added 
> u-
> boot and linux machines + DTS pathces.
> 
> Can the files generated by Yocto be used to boot from QSPI?
> I did not find it in any readme but a patch in u-boot-xlnx suggested I need to
> follow a special QSPI partition layout and a special atf-spi.ub:
> https://github.com/Xilinx/u-boot-
> xlnx/commit/378a437a49dd3d17a9a544768051b2336e5ed874
> Is there an easy way to make Yocto generate this special atf-spi.ub?
> 

You can add a bbappend, see the existing recipe which generates atf-uboot.ub.
On similar line you can create atf-spi.ub

> 
> I tried an alternate approach by setting PREFERRED_PROVIDER_virtual/boot-bin =
> xilinx-bootbin to use FSBL and generate a BOOT.bin for QSPI. But the FSBL 
> seems
> to require PMUFW version 1.0. I got around this by cherry-picking a commit 
> from
> master branch to get a newer pmu-firmware recipe. But now I also need a newer
> kernel recipe. So I am not sure this is a reasonable path forward.
> 

Pin PREFERRED_PROVIDER_virtual/pmu-firmware = "pmu-firmware" from 
meta-xilinx-tools
Being on 2018.1 branches, it will build all the components including v4.14 
kernel.

> In general which boot method would you recommend for QSPI? SPL or FSBL.

Flow depends on what you need. If you are sticking with SPL, then use Yocto 
release branches like master, rocko, morty etc 

If you using SPL flow, see Mikes input here
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-November/003343.html

Also check on Xilinx forum for any solution on FSBL flow.

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-contrib][PATCH 3/3 v3] minized-zynq7: Add wireless support

[Manjukumar Harthikote Matha]

Hi Clement,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Clement Laigle
> Sent: Sunday, June 10, 2018 3:23 PM
> To: meta-xil...@lists.yoctoproject.org
> Subject: [meta-xilinx] [meta-xilinx-contrib][PATCH 3/3 v3] minized-zynq7: Add
> wireless support
> 
> The Minized has a wireless connectivity (WiFi / Bluetooth). This recipes add
> drivers to use the murata wireless module.
> 
> Signed-off-by: Clement Laigle 
> ---
> 
> Changes in v2:
>   - split patch
> 
> Changes in v3:
>   - Modify partition QSPI
>   - Remove unnecessary recipes
>   - Fix Licence
> 
> ---
>  .../minized-wireless/minized-wireless.bb   | 43 
> ++
>  .../linux/linux-xlnx/v2018.1/wifi-bluetooth.cfg| 33 
> ++
>  .../linux/linux-xlnx_2018.1.bbappend   |  1 +
>  3 file changed, 77 insertions(+)
>  create mode 100644 meta-xilinx-contrib/recipes-bsp/minized-wireless/minized-
> wireless.bb
>  create mode 100644 meta-xilinx-contrib/recipes-kernel/linux/linux-
> xlnx/v2018.1/wifi-bluetooth.cfg
> 
> diff --git 
> a/meta-xilinx-contrib/recipes-bsp/minized-wireless/minized-wireless.bb
> b/meta-xilinx-contrib/recipes-bsp/minized-wireless/minized-wireless.bb
> new file mode 100644
> index 000..78e618b
> --- /dev/null
> +++ b/meta-xilinx-contrib/recipes-bsp/minized-wireless/minized-wireless.bb
> @@ -0,0 +1,43 @@
> +SUMMARY = "minized-wireless:  Wi-Fi/BT drivers and firmware for the Murata
> 1DX module"
> +LICENSE = "Proprietary"
> +LIC_FILES_CHKSUM = "file://cyw-fmac-
> fw/LICENCE.cypress;md5=cbc5f665d04f741f1e006d2096236ba7"
> +
> +SRC_URI = " \
> + git://github.com/murata-wireless/cyw-fmac-
> fw;protocol=git;branch=orga;destsuffix=cyw-fmac-fw;name=cyw-fmac-fw \
> + git://github.com/murata-wireless/cyw-fmac-
> nvram;protocol=git;branch=orga;destsuffix=cyw-fmac-nvram;name=cyw-fmac-
> nvram \
> + git://github.com/murata-wireless/cyw-bt-
> patch;protocol=git;branch=morty-orga;destsuffix=cyw-bt-patch;name=cyw-bt-
> patch \
> + git://github.com/murata-wireless/cyw-fmac-utils-
> imx32;protocol=git;branch=orga;destsuffix=cyw-fmac-utils-imx32;name=cyw-
> fmac-utils-imx32 \
> +"
> +
> +SRCREV_cyw-fmac-fw = "2242fd3f67a913fbfff8678cc8f7761629dca8ca"
> +SRCREV_cyw-fmac-nvram = "d12c2ac1b93941eaa03063bb7cb3c1ee1aa1b7d0"
> +SRCREV_cyw-bt-patch = "9216e0d9f778009b5667d032886dfd49174c4b3a"
> +SRCREV_cyw-fmac-utils-imx32 =
> "060688dfe76df98751207c8146268ce7fd80b6ab"
> +
> +DEPENDS = "libnl virtual/kernel"
> +
> +S = "${WORKDIR}"
> +
> +do_install() {
> + install -d ${D}/lib/firmware/brcm
> + install -d ${D}${sysconfdir}/firmware
> + install -d ${D}${bindir}
> +
> + install -m 644 ${S}/cyw-fmac-fw/brcmfmac43430-sdio.bin
> ${D}/lib/firmware/brcm/brcmfmac43430-sdio.bin
> + install -m 644 ${S}/cyw-fmac-nvram/brcmfmac43430-sdio.txt
> ${D}/lib/firmware/brcm/brcmfmac43430-sdio.txt
> + install -m 644 ${S}/cyw-bt-patch/CYW43430A1.1DX.hcd
> ${D}${sysconfdir}/firmware/BCM43430A1.1DX.hcd
> + install -m 755 ${S}/cyw-fmac-utils-imx32/wl ${D}${bindir}/wl
> +}
> +
> +PACKAGES =+ "${PN}-mfgtest"
> +
> +FILES_${PN} = " \
> + /lib/firmware/brcm/brcmfmac43430-sdio.bin \
> + /lib/firmware/brcm/brcmfmac43430-sdio.txt \
> + ${sysconfdir}/firmware/BCM43430A1.1DX.hcd \
> +"
> +
> +FILES_${PN}-mfgtest = " \
> + ${bindir}/wl \
> +"
> +


See the firmware here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm

I think the above recipe would be a bbappend to this instead of a new recipe:
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-contrib][PATCH 1/3 v2] Minized: Add machine config

[Manjukumar Harthikote Matha]

Hi Clement,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Clement Laigle
> Sent: Sunday, June 03, 2018 10:16 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] [meta-xilinx-contrib][PATCH 1/3 v2] Minized: Add 
> machine
> config
> 
> Add machine config for MiniZed
> 

Some more details about board (Zynq board), capabilities, etc
Also some booting instructions would be helpful in commit message

> Changes in v2:
> - split patch
> 

Send the machine configuration to meta-xilinx-bsp layer

> Signed-off-by: Clement Laigle 
> ---
>  .../conf/machine/minized-zynq7.conf| 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 meta-xilinx-contrib/conf/machine/minized-zynq7.conf
> 
> diff --git a/meta-xilinx-contrib/conf/machine/minized-zynq7.conf 
> b/meta-xilinx-
> contrib/conf/machine/minized-zynq7.conf
> new file mode 100644
> index 000..fc8a9b2
> --- /dev/null
> +++ b/meta-xilinx-contrib/conf/machine/minized-zynq7.conf
> @@ -0,0 +1,31 @@
> +#@TYPE: Machine
> +#@NAME: minized-zynq7
> +#@DESCRIPTION: Machine support for MiniZed. (http://www.minized.org/)
> +
> +require conf/machine/include/tune-zynq.inc
> +require conf/machine/include/machine-xilinx-default.inc
> +require conf/machine/include/machine-xilinx-board.inc
> +
> +MACHINE_FEATURES = "ext2 vfat usbhost wifi bluetooth"
> +
> +MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "cypress-orga-backport
> minized-wireless"
> +
> +# u-boot configuration
> +PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
> +UBOOT_MACHINE = "zynq_minized_config"

Do you know which version of u-boot supports this configuration?

> +SPL_BINARY = "spl/boot.bin"
> +
> +EXTRA_IMAGEDEPENDS += " \
> + u-boot-zynq-uenv \
> + virtual/boot-bin \
> + "
> +
> +SERIAL_CONSOLE = "115200 ttyPS0"

Use SERIAL_CONSOLES, as pointed by Luca earlier, we should switch to using 
SERIAL_CONSOLES

<..>

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Yocto fo Pynq Z1?

[Manjukumar Harthikote Matha]

Hi Matt,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Matthew Clark
> Sent: Friday, June 01, 2018 12:59 PM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] Yocto fo Pynq Z1?
> 
> I've got a Pynq Z1 and I'd like to build Yocto on it instead of the Ubuntu 
> distro.  Is
> there a recipe for that board?  I know it's zynq, but I don't know which 
> particular
> flavor to use or if I need to custom make a recipe.
> 

You need to make a custom recipe. There is no Yocto support for PYNQ yet

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Manjukumar Harthikote Matha]

> -Original Message-
> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> Sent: Wednesday, May 30, 2018 2:33 AM
> To: Manjukumar Harthikote Matha ; meta-
> xil...@yoctoproject.org
> Cc: Devarsh Thakkar ; Devarsh Thakkar
> 
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2] zcu106-zynqmp.conf: Add
> support for ZCU106 Evaluation Kit
> 
> Hi Manjukumar, Devarsh,
> 
> On 29/05/2018 04:04, Manjukumar Matha wrote:
> > From: Devarsh Thakkar 
> >
> > The ZCU106 Evaluation Kit enables designers to jumpstart designs for
> > video conferencing, surveillance, Advanced Driver Assisted Systems
> > (ADAS) and streaming and encoding applications. This kit features a
> > Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
> > and interfaces, enabling development for a wide range of applications.
> > The included ZU7EV device is equipped with a quad-core ARM® Cortex™-A53
> > applications processor, dual-core Cortex-R5 real-time processor,
> > Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265 video
> > codec, and 16nm FinFET+ programmable logic.
> >
> > This patch adds machine configuration file for ZCU106 Evaluation Kit
> > with required setting of board specific yocto variables needed for
> > compilation of bootloader, kernel and device-tree.
> >
> > - linux-xlnx is the kernel provider
> > - u-boot-xlnx is the u-boot provider which will also generate SPL boot.bin
> > - hwcodec is provided by libomxil-xlnx recipe, this will pull in
> >   additional dependencies of VCU kernel modules, control software,
> >   firmware binaries
> >
> > Depending on the application need you may want to pass the appropriate
> > CMA size in bootargs or set CONFIG_CMA_SIZE_MBYTES in kernel.
> >
> > While using SPL flow, you may need to provide additional hack to pass
> > the PMU config object. This is similar to all ZU+ boards, due to gap in
> > SPL flow unable to load PMU config object.
> 
> Thanks for the added comments.
> 
> > Signed-off-by: Devarsh Thakkar 
> > Tested-by: Maulik Desai 
> > Signed-off-by: Manjukumar Matha  ma...@xilinx.com>
> > ---
> > Changelog:
> > v2: Add commit message to describe the providers and state of SPL boot.
> > Also add the requirement of CMA size required based on appliction
> >
> >  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf| 33
> ++
> >  .../recipes-bsp/u-boot/u-boot-xlnx_2018.1.bb   |  1 +
> >  2 files changed, 34 insertions(+)
> >  create mode 100644 meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> >
> > diff --git a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf b/meta-xilinx-
> bsp/conf/machine/zcu106-zynqmp.conf
> > new file mode 100644
> > index 000..42ac479
> > --- /dev/null
> > +++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> > @@ -0,0 +1,33 @@
> > +#@TYPE: Machine
> > +#@NAME: zcu106-zynqmp
> > +#@DESCRIPTION: Machine support for ZCU106 Evaluation Board.
> > +
> > +require conf/machine/include/tune-zynqmp.inc
> > +require conf/machine/include/machine-xilinx-default.inc
> > +require conf/machine/include/machine-xilinx-board.inc
> > +include conf/machine/include/zynqmp-pmu-config.inc
> > +
> > +MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
> > +
> > +UBOOT_MACHINE = "xilinx_zynqmp_zcu106_revA_defconfig"
> > +SPL_BINARY = "spl/boot.bin"
> > +
> > +SERIAL_CONSOLE = "115200 ttyPS0"
> 
> SERIAL_CONSOLE is deprecated, I think this should become SERIAL_CONSOLES.
> 

I will merge this as is and send out another patch for all machines to use
SERIAL_CONSOLES

Thanks,
Manju
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Manjukumar Harthikote Matha]

Hi Luca,

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Manjukumar Harthikote Matha
> Sent: Monday, May 28, 2018 11:04 AM
> To: Luca Ceresoli ; meta-xilinx@yoctoproject.org
> Cc: Devarsh Thakkar 
> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf: 
> Add
> support for ZCU106 Evaluation Kit
> 
> Hi Luca,
> 
> > -Original Message-
> > From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
> > Sent: Monday, May 28, 2018 10:38 AM
> > To: Manjukumar Harthikote Matha ; meta-
> > xil...@yoctoproject.org
> > Cc: Devarsh Thakkar ; Devarsh Thakkar
> > 
> > Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf:
> Add
> > support for ZCU106 Evaluation Kit
> >
> > Hi Manjukumar, Devarsh,
> >
> > I'm glad to see zcu106 support coming! However I have a few questions about
> this
> > patch, see below.
> >
> > On 28/05/2018 09:40, Manjukumar Matha wrote:
> > > From: Devarsh Thakkar 
> > >
> > > The ZCU106 Evaluation Kit enables designers to jumpstart designs for
> > > video conferencing, surveillance, Advanced Driver Assisted Systems
> > > (ADAS) and streaming and encoding applications. This kit features a
> > > Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
> > > and interfaces, enabling development for a wide range of applications.
> > > The included ZU7EV device is equipped with a quad-core ARM®
> > > Cortex™-A53 applications processor, dual-core Cortex-R5 real-time
> > > processor,
> > > Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265
> > > video codec, and 16nm FinFET+ programmable logic.
> >
> > I find this marketing-style paragraph rather useless in this context.
> 
> It's better to have a description of board capabilities.
> 
> > Why not replacing it with a short, technical description of how the board 
> > boots
> > (U-Boot SPL, ATF etc), which device drivers are enabled etc?
> >
> 
> I can edit some info to commit message
> 
> > > This patch adds machine configuration file for ZCU106 Evaluation Kit
> > > with required setting of board specific yocto variables needed for
> > > compilation of bootloader, kernel and device-tree
> > >
> > > Signed-off-by: Devarsh Thakkar 
> > > Tested-by: Maulik Desai 
> > > Signed-off-by: Manjukumar Matha
> > > 
> > > ---
> > >  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf | 33
> > > +
> > >  1 file changed, 33 insertions(+)
> > >  create mode 100644 meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> > >
> > > diff --git a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> > > b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> > > new file mode 100644
> > > index 000..42ac479
> > > --- /dev/null
> > > +++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> > > @@ -0,0 +1,33 @@
> > > +#@TYPE: Machine
> > > +#@NAME: zcu106-zynqmp
> > > +#@DESCRIPTION: Machine support for ZCU106 Evaluation Board.
> > > +
> > > +require conf/machine/include/tune-zynqmp.inc
> > > +require conf/machine/include/machine-xilinx-default.inc
> > > +require conf/machine/include/machine-xilinx-board.inc
> > > +include conf/machine/include/zynqmp-pmu-config.inc
> > > +
> > > +MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
> > > +
> > > +UBOOT_MACHINE = "xilinx_zynqmp_zcu106_revA_defconfig"
> > > +SPL_BINARY = "spl/boot.bin"
> > > +
> > > +SERIAL_CONSOLE = "115200 ttyPS0"
> > > +SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
> > > +
> > > +KERNEL_DEVICETREE = "xilinx/zynqmp-zcu106-revA.dtb"
> > > +
> > > +PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx"
> > > +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-xlnx"
> > > +PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-
> firmware"
> > > +
> > > +EXTRA_IMAGEDEPENDS += " \
> > > + u-boot-zynq-uenv \
> > > + arm-trusted-firmware \
> > > + virtual/pmu-firmware \
> > > + virtual/boot-bin \
> > > + "
> > > +
> > > +IMAGE_BOOT_FILES += "uEnv.txt atf-uboot.ub ${KERNEL_IMAGETYPE}-
> zynqmp-
> > zcu106-revA.dtb"

Re: [meta-xilinx] [meta-xilinx-contrib][PATCH] layer.conf: Add LAYERSERIES_COMPAT for sumo release

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: Manjukumar Matha [mailto:manjukumar.harthikote-ma...@xilinx.com]
> Sent: Friday, May 25, 2018 7:25 PM
> To: meta-xilinx@yoctoproject.org
> Cc: Manjukumar Harthikote Matha <manju...@xilinx.com>
> Subject: [meta-xilinx-contrib][PATCH] layer.conf: Add LAYERSERIES_COMPAT for
> sumo release
> 
> Add LAYERSERIES_COMPAT for sumo release
> 
> Signed-off-by: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
> ---
>  meta-xilinx-contrib/conf/layer.conf | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta-xilinx-contrib/conf/layer.conf b/meta-xilinx-
> contrib/conf/layer.conf
> index 41ea5aa..ad24877 100644
> --- a/meta-xilinx-contrib/conf/layer.conf
> +++ b/meta-xilinx-contrib/conf/layer.conf
> @@ -11,3 +11,6 @@ BBFILE_PRIORITY_xilinx-contrib = "5"
> 
>  LAYERDEPENDS_xilinx-contrib = "core"
>  LAYERDEPENDS_xilinx-contrib = "xilinx"
> +
> +LAYERSERIES_COMPAT_xilinx-contrib = "sumo"
> +
> --
> 2.7.4

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH] layer.conf: Add LAYERSERIES_COMPAT for sumo release

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: Manjukumar Matha [mailto:manjukumar.harthikote-ma...@xilinx.com]
> Sent: Friday, May 25, 2018 7:23 PM
> To: meta-xilinx@yoctoproject.org
> Cc: Manjukumar Harthikote Matha <manju...@xilinx.com>
> Subject: [meta-xilinx-bsp][PATCH] layer.conf: Add LAYERSERIES_COMPAT for sumo
> release
> 
> Add LAYERSERIES_COMPAT for sumo release
> 
> Signed-off-by: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
> ---
>  meta-xilinx-bsp/conf/layer.conf | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta-xilinx-bsp/conf/layer.conf 
> b/meta-xilinx-bsp/conf/layer.conf index
> dac3e24..55f6680 100644
> --- a/meta-xilinx-bsp/conf/layer.conf
> +++ b/meta-xilinx-bsp/conf/layer.conf
> @@ -10,3 +10,6 @@ BBFILE_PATTERN_xilinx = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_xilinx = "5"
> 
>  LAYERDEPENDS_xilinx = "core"
> +
> +LAYERSERIES_COMPAT_xilinx = "sumo"
> +
> --
> 2.7.4

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 0/4] Update pacthes for kc705 microblazeel machine

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: Manjukumar Matha [mailto:manjukumar.harthikote-ma...@xilinx.com]
> Sent: Friday, May 25, 2018 6:56 PM
> To: meta-xilinx@yoctoproject.org
> Cc: Manjukumar Harthikote Matha <manju...@xilinx.com>
> Subject: [meta-xilinx-bsp][PATCH 0/4] Update pacthes for kc705 microblazeel
> machine
> 
> This series updates the kc705 microblazeel machine to work with 2018.1 xilinx
> kernel and u-boot.
> 
> This sereis does the following
>  - Adds UBOOT_MACHINE
>  - Pins teh providers to vendor tree
>  - Adds the u-boot patch which contains dts, micorblazr configs
>  - Fetches the new bitstream for 2018.1
> 
> Manjukumar Matha (4):
>   kc705-microblazeel.conf: Add UBOOT_MACHINE to kc705
>   kc705-microblazeel.conf: Pin providers to Xilinx kernel and u-boot
>   u-boot-xlnx_2018.1.bb: Add support to build kc705 microblazeel
>   kc705-bitstream_2018.1.bb: Update kc705 bitstream
> 
>  .../conf/machine/kc705-microblazeel.conf   |3 +
>  .../reference-design/kc705-bitstream_2017.3.bb |   48 -
>  .../reference-design/kc705-bitstream_2018.1.bb |   48 +
>  ...aze-kc705-Convert-microblaze-generic-to-k.patch | 1168
> 
>  .../recipes-bsp/u-boot/u-boot-xlnx_2018.1.bb   |2 +
>  5 files changed, 1221 insertions(+), 48 deletions(-)  delete mode 100644 
> meta-
> xilinx-bsp/recipes-bsp/reference-design/kc705-bitstream_2017.3.bb
>  create mode 100644 meta-xilinx-bsp/recipes-bsp/reference-design/kc705-
> bitstream_2018.1.bb
>  create mode 100644 meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-
> xlnx/v2018.1/microblaze-kc705-Convert-microblaze-generic-to-k.patch
> 
> --
> 2.7.4

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH] u-boot-xlnx.inc: Remove deploying u-boot-spl.bin for runqemu

[Manjukumar Harthikote Matha]

Applied

Thanks,
Manju

> -Original Message-
> From: Manjukumar Matha [mailto:manjukumar.harthikote-ma...@xilinx.com]
> Sent: Friday, May 25, 2018 12:18 PM
> To: meta-xilinx@yoctoproject.org
> Cc: Manjukumar Harthikote Matha <manju...@xilinx.com>
> Subject: [meta-xilinx-bsp][PATCH] u-boot-xlnx.inc: Remove deploying u-boot-
> spl.bin for runqemu
> 
> Due to this change 54e2729ed43f82b8cfd96395fb68e447a9b60f86, zcu102
> runqemu does not depend on u-boot-spl.bin. It requires just ATF and u-boot to 
> be
> present. Hence deploying of u-boot-spl.bin is no longer required.
> 
> Signed-off-by: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
> ---
>  meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx.inc | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx.inc b/meta-xilinx-
> bsp/recipes-bsp/u-boot/u-boot-xlnx.inc
> index ec42181..689249f 100644
> --- a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx.inc
> +++ b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx.inc
> @@ -18,9 +18,3 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot:"
>  FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot-xlnx:"
>  FILESEXTRAPATHS_prepend := "${@'${THISDIR}/u-boot-
> xlnx/${XILINX_RELEASE_VERSION}:' if d.getVar('XILINX_RELEASE_VERSION') else
> ''}"
> 
> -do_deploy_append_zcu102-zynqmp () {
> - # deploy u-boot-spl.bin for use by runqemu/QEMU
> - if [ -e ${B}/spl/u-boot-spl.bin ];then
> - install -Dm 0644 ${B}/spl/u-boot-spl.bin ${DEPLOYDIR}/u-boot-
> spl.bin
> - fi
> -}
> --
> 2.7.4

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] u-boot-spl-zynq-init.inc: Fix parallellism issue

[Manjukumar Harthikote Matha]

> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Niko Mauno
> Sent: Friday, May 25, 2018 2:58 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] [PATCH] u-boot-spl-zynq-init.inc: Fix parallellism 
> issue
> 
> A race issue can be induced by do_zynq_platform_init() being fired
> before do_unpack(), resulting in
> 
>   | DEBUG: Executing shell function do_zynq_platform_init
>   | cp: cannot create regular file '.../git/board/xilinx/zynq/': No such file 
> or
> directory
>   | WARNING: exit code 1 from a shell command.
> 
> Mitigate issue by adding dependency to completion of do_unpack task
> for custom do_zynq_platform_init task. Also update comment on previous
> line to match the actions on next.
> 
> Signed-off-by: Niko Mauno 
> ---
>  meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc 
> b/meta-
> xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
> index 50eae1f..9cf09ff 100644
> --- a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
> +++ b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
> @@ -47,8 +47,8 @@ python () {
>  if (currentconfig not in hasconfigs) or 
> (d.getVar("FORCE_PLATFORM_INIT") ==
> "1"):
>  # force the dependency on a recipe that provides the platform 
> init files
>  d.appendVar("DEPENDS", " virtual/xilinx-platform-init")
> -# setup task to modify platform init after unpack and before 
> configure
> -bb.build.addtask("do_zynq_platform_init", "do_configure",
> "do_prepare_recipe_sysroot", d)
> +# setup task to modify platform init after unpack and
> prepare_recipe_sysroot, and before configure
> +bb.build.addtask("do_zynq_platform_init", "do_configure", 
> "do_unpack
> do_prepare_recipe_sysroot", d)
> 
>  if "boot.bin" not in d.getVar("SPL_BINARY"):
>  # not deploying the boot.bin, just building SPL
> --


Applied

Thanks,
Manju

-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx