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

[Jean-Francois Dagenais]

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

> 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

Re: [meta-xilinx] zynqmp support in warrior branch

[Jean-Francois Dagenais]

Hi Adrian

> On Oct 25, 2019, at 13:37, Adrian Fiergolski 
>  wrote:
> 
> Hi,
> 
> I debugged the problem further. The PMU firmware, SPL and ATF pass 
> successfully with warrior branch. ATF sets entry-point at 0x800 where I 
> see binary of u-boot.bin. The boot process enter there and stops somewhere in 
> _binary_u_boot_bin_start. Thus, I suspect problem with U-Boot relocation. Has 
> anybody experienced similar issue? My understanding is that U-Boot takes size 
> of RAM memory from device tree and a board providing 2GB DDR, would have an 
> entry:

Sorry for the late reply I got pretty swamped over the last few weeks. I am not 
sure at all if this is any related to a past experience I had with the PMU 
overwriting my kernel image in RAM from a miscalculation of where it should 
copy the FSBL for warm resets I think... anyway, see here if this helps at all:

https://www.mail-archive.com/meta-xilinx@yoctoproject.org/msg03049.html

Cheers!
-- 
___
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

[Jean-Francois Dagenais]

Hi Manju,

> On Oct 24, 2019, at 15:02, Manjukumar Harthikote Matha  
> wrote:
> 
> 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.

This branch indeed makes things well organized, but it doesn't change anything 
to my problem unfortunately. I tried it and get the very same conflicts as when 
trying to merge xilinx-v2019.1 with v4.19.80

You can try it yourself:

git checkout xilinx/xlnx_rebase_v4.19
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
v4.19.80
git merge FETCH_HEAD


You'll get a bunch of conflicts for files that have been changed by Xilinx and 
by stable.

Then try:

git checkout xilinx-v2019.1
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
v4.19.80
git merge FETCH_HEAD

I am almost done with the conflict resolutions, but I had to botch some of the 
complicated ones. I could afford to do so since I don't use all the files 
affected. This means my work is not really useable by others. If the real 
maintainers of these changes did the merge, they would have much better 
resolution than me.

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

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

[Jean-Francois Dagenais]

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?


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

Re: [meta-xilinx] rootfs on ram

[Jean-Francois Dagenais]

Hi Jek,

> On Sep 16, 2019, at 11:15, Jek F.  wrote:
> 
> Hi everyone, i propose again the question i desccribed to you at the 
> beginning of the summer because I haven't been able to solve it yet.
> Sorry if i'm boring, but this is a very important topic to me.
> 
> 
> I'm using a microzed, and i need to create an image that mount rootf on ram.
> I tried to follow the yocto manual for initramfs 
> (https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-an-initramfs-image),
>  but at bitbake it returns this error:
> 
> ERROR: Nothing PROVIDES 'core-image-minimal-initramfs'
> core-image-minimal-initramfs was skipped: incompatible with host 
> arm-poky-linux-gnueabi (not in COMPATIBLE_HOST)
> core-image-minimal-initramfs was skipped: incompatible with host 
> arm-poky-linux-gnueabi (not in COMPATIBLE_HOST)
> 
> Any suggestion?

Indeed, the last lines of core-image-minimal-initramfs.bb are:
# Use the same restriction as initramfs-live-install
COMPATIBLE_HOST = "(i.86|x86_64).*-linux"

You would need to why they put that there... My hunch is that loading an initrd 
image is very bootload specific. So you can remove them, or override the line 
with a bbappend. You will be missing some glue to make it work though.

On zynqmp, one can use u-boot to load the initrd.

I have this in my machine.conf:
INITRAMFS_FSTYPES = "cpio.gz.u-boot"


Then in my image classes that make the initrd rootfs, I have:
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"

(The image recipes use INITRAMFS_FSTYPES to not include knowledge of the 
bootloader/machine underneath. This is just good practice, so you can do 
whatever you want for your recipes.)

But then this will make the .cpio.gz.u-boot file. If you want an image which 
you can dd on, say, an SD card, you need another image for this, one which 
doesn't really make a rootfs, a relevant one anyway, but is bundled in the end 
with the WIC framework with the initrd.cpio.gz.u-boot file included. Your WKS 
file can just mention the boot part, no second rootfs. 

I have this in my other image:
INITRD_IMAGE = "the-initrd-rootfs-recipe"
IMAGE_FSTYPES = "wic.lz4"


Just specifying wic.lz4 is not enough, you need to specify the kickstart file 
to use:
WKS_FILES = "my-bootonly.wks"

I personally specify this to all my images by using an IMAGE_CLASSES in my 
machine.conf:

IMAGE_CLASSES += "my-image-wic"

This is "my-image-wic.bbclass":

WKS_FILES ?= "my-bootonly.wks"
WIC_CREATE_EXTRA_ARGS = " --no-fstab-update"

do_image_wic[depends] += "\
xilinx-bootbin:do_deploy \
e2fsprogs-native:do_populate_sysroot \
"

python () {
initRdImage = d.getVar("INITRD_IMAGE")
if initRdImage:
d.appendVarFlag("do_image_wic", "depends", " " + initRdImage + 
":do_image_complete")
}

IMAGE_CMD_wic_append() {
cd ${DEPLOY_DIR_IMAGE}

ln -sfv ${IMAGE_LINK_NAME}.wic.lz4 ${IMAGE_LINK_NAME}.sdcard.lz4
}


here's my-bootonly.wks (1 line only):
part /boot --source bootimg-partition --fstype=vfat --label boot --active 
--align 4096 --extra-space 10

The "bootimg-partition" wic plugin mentioned above expects variable 
IMAGE_BOOT_FILES to be set. Usually, this is defined in the machine.conf:
IMAGE_BOOT_FILES = "\
BOOT-${MACHINE}.bin;boot.bin \
Image \
${MACHINE}.dtb \
uEnv.txt.example \
${INITRD_IMAGE}.cpio.gz.u-boot;initrd.cpio.gz.u-boot \
"

Then you need to make your u-boot configuration find a load as initrd a file 
named initrd.cpio.gz.u-boot...


This should get you going. I may be doing way more manually than is required. I 
had developed this a while back and it's been working fine for us since.


Cheers!




smime.p7s
Description: S/MIME cryptographic signature
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] XDMA cyclic mode

[Jean-Francois Dagenais]

> On Aug 29, 2019, at 21:30, Jean-Francois Dagenais  
> wrote:
> 
> 
> Here you go... (and for all)
> 
> CC Tony McDowell from Xilinx, because we talked about this case at the 
> conference in San Diego just last week!
> 
> It should apply and compile on xilinx's xilinx-v2019.1 branch (linux 4.19).


If you prefer, I could send you a patchset for the original breakdown of my 
changes which apply onto 322bd63129b02044d3266b5739aa07b50edb76e4... ?
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] XDMA cyclic mode

[Jean-Francois Dagenais]

> On Aug 28, 2019, at 09:59, Leon Woestenberg  wrote:
> 
> Hello Jean-Francois,
> 
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-February/004235.html
> 
> I am the original author of the XDMA device driver, and although I am no 
> longer involved I feel your pain (still using XDMA for my own projects).
> 
> I am also developing cyclic transfer of real-time audio with XDMA, in cyclic 
> DMA mode.
> 
> Can you share your changes?
> 
> Regards,
> 
> Leon.
> 

Here you go... (and for all)

CC Tony McDowell from Xilinx, because we talked about this case at the 
conference in San Diego just last week!

It should apply and compile on xilinx's xilinx-v2019.1 branch (linux 4.19).


---
>From d0fbbb9d7a96dd1ba574320833211aadb6b01334 Mon Sep 17 00:00:00 2001
From: Jean-Francois Dagenais 
Date: Mon, 19 Nov 2018 10:26:18 -0500
Subject: [PATCH] dma: xilinx_dma_s: introduce a forked xilinx_dma
 driver

The main reason for this fork is that while working on repairing
cyclic mode, many other long coming and necessary cleanups were made
to the driver but Xilinx had completely reshaped the driver behind
closed doors. Some of their fixes we addressing similar issues I had
so the clash was intense.

I could not afford to rebase my extensive work to submit upstream,
having already invested time in our project to fix this mess of a
driver... sorry guys, but let's be honest, it became a bit of a mess
with the fusion of all the previous drivers. So I reluctantly forked
it because we needed the cyclic mode to work, and it did in this
version...

Sad, I know.

Note that there is still a fundamental issue with the cyclic DMA mode
because although the tx and rx are declared as separate channels, the
underlying fabric has only one reset signal. This means that they are
indeed coupled. This version tries to best address this by printk'ing
a message when a reset for a channel should have been performed, but
didn't to not halt the other channel's ongoing streaming. (see the
long printk in xilinx_dma_axi_chan_reset).

Signed-off-by: Jean-Francois Dagenais 
---
 drivers/dma/Kconfig   |7 +
 drivers/dma/xilinx/Makefile   |1 +
 drivers/dma/xilinx/xilinx_dma_s.c | 2979 +
 3 files changed, 2987 insertions(+)
 create mode 100644 drivers/dma/xilinx/xilinx_dma_s.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 510823259fe3..69e22c78f0f7 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -587,6 +587,13 @@ config XILINX_DMA
  AXI DMA engine provides high-bandwidth one dimensional direct
  memory access between memory and AXI4-Stream target peripherals.
 
+config XILINX_DMA_S
+   tristate "Forked version of Xilinx AXI DMAS Engine"
+   depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
+   select DMA_ENGINE
+   help
+ We use the s2mm and mm2s parts for audio (cyclic repaired).
+
 config XILINX_ZYNQMP_DMA
tristate "Xilinx ZynqMP DMA Engine"
depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile
index ca29c5d1b279..92bc2fbff9d8 100644
--- a/drivers/dma/xilinx/Makefile
+++ b/drivers/dma/xilinx/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_XILINX_VDMATEST) += vdmatest.o
 obj-$(CONFIG_XILINX_CDMATEST) += cdmatest.o
 obj-$(CONFIG_XILINX_DPDMA) += xilinx_dpdma.o
 obj-$(CONFIG_XILINX_DMA) += xilinx_dma.o
+obj-$(CONFIG_XILINX_DMA_S) += xilinx_dma_s.o
 obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o
 xilinx_ps_pcie_dma-objs := xilinx_ps_pcie_main.o xilinx_ps_pcie_platform.o
 obj-$(CONFIG_XILINX_PS_PCIE_DMA) += xilinx_ps_pcie_dma.o
diff --git a/drivers/dma/xilinx/xilinx_dma_s.c 
b/drivers/dma/xilinx/xilinx_dma_s.c
new file mode 100644
index ..e6db1a8a5ad5
--- /dev/null
+++ b/drivers/dma/xilinx/xilinx_dma_s.c
@@ -0,0 +1,2979 @@
+/*
+ * DMA driver for Xilinx Video DMA Engine
+ *
+ * Copyright (C) 2010-2014 Xilinx, Inc. All rights reserved.
+ *
+ * Based on the Freescale DMA driver.
+ *
+ * Description:
+ * The AXI Video Direct Memory Access (AXI VDMA) core is a soft Xilinx IP
+ * core that provides high-bandwidth direct memory access between memory
+ * and AXI4-Stream type video target peripherals. The core provides efficient
+ * two dimensional DMA operations with independent asynchronous read (S2MM)
+ * and write (MM2S) channel operation. It can be configured to have either
+ * one channel or two channels. If configured as two channels, one is to
+ * transmit to the video device (MM2S) and another is to receive from the
+ * video device (S2MM). Initialization, status, interrupt and management
+ * registers are accessed through an AXI4-Lite slave interface.
+ *
+ * The AXI Direct Memory Access (AXI DMA) core is a soft Xilinx IP core that
+ * provides high-bandwidth one dimensional direct memory access between memory
+ * and AXI4-Stream target peripherals. It supports one 

Re: [meta-xilinx] [PATCH] libmali-xlnx: inherit update-alternatives only on rw-rootfs builds

[Jean-Francois Dagenais]

Hi Mike,

> On Jul 16, 2019, at 01:38, Mike Looijmans  wrote:
> 
> This should not work, IMAGE_FEATURES is only valid in the image recipe and 
> won't be (fully) visible outside that.
> 

Indeed. It seems I have worked around the problem a little fast and thought my 
solution was useable by others. 

> I frequently build multiple images in a single bitbake run where one is 
> read-only and the other is not, e.g.: "bitbake my-image-sdcard 
> my-image-norflash"

Did you have any recipe(s) included in the read-only image which had the 
update-alternative inheritance? If so, how did you make it work? My do_rootfs 
fails saying it cannot complete the postinst steps for libmali-xlnx because of 
the RO rootfs.

In any case, I will probably not pursue this much further. For me, as I said 
before, for most embedded systems, a choice is made as to what the drawing 
backend will be (X11, wayland or fbdev) for the system, and only one version is 
needed/wanted. So since I already maintain a fork of meta-xilinx, I will simply 
clean out the update-alternative stuff from libmali-xlnx.

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

[meta-xilinx] [PATCH] libmali-xlnx: inherit update-alternatives only on rw-rootfs builds

[Jean-Francois Dagenais]

update-alternatives.bbclass adds a target-ran post-inst step which
cannot work on RO rootfs systems. Thankfully an error was put in place
in poky's base image class to detect this.

With this patch, on these builds, the default lib (MALI_BACKEND_DEFAULT)
prevails as the active library. Others may be used through other tricks
if they are installed by the do_install step.

This is obviously not a perfect solution, but at least do_rootfs is
allowed to complete. Furthermore, on embedded systems, this should cover
most cases since arguably few of us bundle the multiple implementations
of libmali on a given machine.

Signed-off-by: Jean-Francois Dagenais 
---
 meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb | 3 ++-
 1 file changed, 2 insertions(+), 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 b37e061..af873e6 100644
--- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
+++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
@@ -4,7 +4,8 @@ LICENSE = "Proprietary"
 LICENSE_FLAGS = "xilinx"
 LIC_FILES_CHKSUM = "file://README.md;md5=d5750ae6496dd931669b454b5aaae2cd"
 
-inherit distro_features_check update-alternatives
+inherit distro_features_check
+INHERIT += '${@bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs", "", 
"update-alternatives", d)}'
 
 ANY_OF_DISTRO_FEATURES = "x11 fbdev wayland"
 
-- 
2.11.0

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

[meta-xilinx] sdbootdev on u-boot 2019.1

[Jean-Francois Dagenais]

Has anyone tried booting from the second sdhci controller since 2019.1?

2882b39d564bfa531d86aa22900658285483107d in u-boot-xlnx removes 
env_set("sdbootdev", "1") yet xilinx_zynqmp.h still relies on it!

Am I the only one with this problem?
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

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

[Jean-Francois Dagenais]

Hi Manju,

> On Jul 9, 2019, at 15:22, Manjukumar Harthikote Matha  
> wrote:
> 
> 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

That's fine for the "partition attributes" of the definitions, which I have 
left as is. I just thought putting the list of partitions in the variable 
BIF_PARTITION_ATTR was a arbitrary, or am I not seeing something correctly?

Why not put the list of partitions (used as flag names on the other vars as 
well) on the BIF_PARTITION_DEPENDS or BIF_PARTITION_IMAGE then? Why is the 
_ATTR the one carrying the "top level" list of partition "names"?

After spending minutes analyzing the whole picture, it just seemed to me like 
there was such a distinct thing called "List of BIF partitions" and that the 
BIF_PARTITION_ATTR variable which, like it's brothers _IMAGE and _DEPENDS, is 
mostly used as storage for the varFlags (with partition name as key), seemed to 
have been arbitrarily chosen as the storage (getVar instead of getVarFlag) for 
the list of partitions.

My 2 cents. ;)

> 
>> 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 ?= ""


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

[meta-xilinx] [contrib][RFC] linux-boot-simple: introduce ultra trivial kernel Image launcher

[Jean-Francois Dagenais]

This very crude linux loader assumes the kernel image, the dtb and itself have
been copied to RAM at the addresses given at compile time (see variables in
recipe).

The kernel will use the "/chosen/bootargs" from the dtb.

It is meant to "replace" u-boot for very simple cases. One can load all these
binaries from boot.bin using the bif file "load=" syntax. FSBL then blindly
copies those to the specfied HW addresses.

Follow the thread around this message:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-June/004433.html

Signed-off-by: Jean-Francois Dagenais 
---
 .../linux-boot-simple/files/linux-boot-simple.s| 45 ++
 .../linux-boot-simple/linux-boot-simple.bb | 29 ++
 2 files changed, 74 insertions(+)
 create mode 100644 
meta-xilinx-contrib/recipes-bsp/linux-boot-simple/files/linux-boot-simple.s
 create mode 100644 
meta-xilinx-contrib/recipes-bsp/linux-boot-simple/linux-boot-simple.bb

diff --git 
a/meta-xilinx-contrib/recipes-bsp/linux-boot-simple/files/linux-boot-simple.s 
b/meta-xilinx-contrib/recipes-bsp/linux-boot-simple/files/linux-boot-simple.s
new file mode 100644
index 000..4aa9a0d
--- /dev/null
+++ 
b/meta-xilinx-contrib/recipes-bsp/linux-boot-simple/files/linux-boot-simple.s
@@ -0,0 +1,45 @@
+/*
+* (C) Copyright 2015 - 2019, Xilinx, Inc
+*
+* Originally written by Edgar E. Iglesias and Jason Wu.
+* Modified for yocto by Jean-Francois Dagenais
+*
+* Set yocto variables BOOT_LOAD_KERNEL_ADDRESS and BOOT_LOAD_DTB_ADDRESS and
+* BOOT_LOAD_LINUX_BOOT_SIMPLE at the global scope (e.g. local.conf,
+* machine.conf or distro.conf) to tell this code where in RAM the kernel and
+* device-tree blob are.
+*
+* See linux-boot-simple.bb
+*
+* Example use in machine.conf with xilinx-bootbin's BIF_PARTITION_... 
variables:
+* (mymachine.conf)
+* BOOT_LOAD_DTB_ADDRESS = "0x6"
+* BOOT_LOAD_KERNEL_ADDRESS = "0x8"
+* BOOT_LOAD_LINUX_BOOT_SIMPLE = "0x5F000"
+* BIF_PARTITION_ATTR[linux-trampoline] = 
"destination_cpu=a53-0,exception_level=el-2"
+* BIF_PARTITION_IMAGE[linux-trampoline] = 
"${DEPLOY_DIR_IMAGE}/linux-boot-simple.elf"
+* BIF_PARTITION_DEPENDS[linux-trampoline] = "linux-boot-simple:do_deploy"
+* BIF_PARTITION_ATTR[dtb] := "load=${BOOT_LOAD_DTB_ADDRESS}"
+* BIF_PARTITION_IMAGE[dtb] = "${DEPLOY_DIR_IMAGE}/${MACHINE}.dtb"
+* BIF_PARTITION_DEPENDS[dtb] = "virtual/kernel:do_deploy"
+* BIF_PARTITION_ATTR[kernel] := "load=${BOOT_LOAD_KERNEL_ADDRESS}"
+* BIF_PARTITION_IMAGE[kernel] = "${DEPLOY_DIR_IMAGE}/Image-${MACHINE}.bin"
+* BIF_PARTITION_DEPENDS[kernel] = "virtual/kernel:do_deploy"
+*
+* Then replace "u-boot" with "linux-trampoline" in the list of bif partitions:
+* BIF_PARTITION_ATTR_mymachine = "fsbl bitstream pmu atf linux-trampoline dtb 
kernel"
+*/
+   .section.text
+   .global _start
+_start:
+   ldr  x17, kernel_start
+   ldr  x0, kernel_dts
+   mov  x1, xzr
+   mov  x2, xzr
+   mov  x3, xzr
+   blr  x17
+   .balign 8
+kernel_start:
+   .dword   __BOOT_LOAD_KERNEL_ADDRESS__
+kernel_dts:
+   .dword   __BOOT_LOAD_DTB_ADDRESS__
diff --git 
a/meta-xilinx-contrib/recipes-bsp/linux-boot-simple/linux-boot-simple.bb 
b/meta-xilinx-contrib/recipes-bsp/linux-boot-simple/linux-boot-simple.bb
new file mode 100644
index 000..7f0d57b
--- /dev/null
+++ b/meta-xilinx-contrib/recipes-bsp/linux-boot-simple/linux-boot-simple.bb
@@ -0,0 +1,29 @@
+SUMMARY = "Simple Boot Loader for embedded devices"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+SRC_URI += "file://linux-boot-simple.s"
+
+B = "${WORKDIR}/build"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+inherit xsct-tc
+
+do_configure() {
+sed "s/__BOOT_LOAD_KERNEL_ADDRESS__/${BOOT_LOAD_KERNEL_ADDRESS}/" 
${WORKDIR}/${PN}.s > ${B}/${PN}.s
+sed -i "s/__BOOT_LOAD_DTB_ADDRESS__/${BOOT_LOAD_DTB_ADDRESS}/" 
${B}/${PN}.s
+}
+
+do_compile() {
+aarch64-none-elf-gcc -nostartfiles -nodefaultlibs 
-Wl,--build-id=none,-Ttext=${BOOT_LOAD_LINUX_BOOT_SIMPLE} ${PN}.s -o ${PN}.elf
+}
+
+do_install[noexec] = "1"
+
+inherit deploy
+
+do_deploy() {
+cp ${B}/linux-boot-simple.elf ${DEPLOYDIR}
+}
+addtask deploy before do_build after do_compile
-- 
2.11.0

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

Re: [meta-xilinx] [linux-xlnx] uio as module fails to link

[Jean-Francois Dagenais]

> On Jul 9, 2019, at 12:59, Hyun Kwon  wrote:
> 
> 
> The Kconfig takes care of it by selecting CONFIG_DMA_SHARED_BUFFER because
> I didn't want to add #ifdefs for downstream changes.

Ok. But what if someone has no use for DMABUF and doesn't want the extra code
weight, but does want UIO? I.e. a dmabuf-less UIO module? I mean, UIO exists
without all these functions. Automatically adding all this code to the module,
although it would not bother me all that much, might upset some.

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

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

[Jean-Francois Dagenais]

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

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"
+
 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
+bootgen -image bootgen-${image}.bif -arch ${SOC_FAMILY} 
${BOOTGEN_EXTRA_ARGS} -w -o boot-${image}.bin
+if [ ! -e ${bootbin} ]; then
+bbfatal "bootgen ${bootbin} failed. See log"
+fi
+done
 }
 
 do_compile_append_versal() {
 dd if=/dev/zero bs=256M count=1  > ${B}/QEMU_qspi.bin
-   

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

[Jean-Francois Dagenais]

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() {
-   :
-}
-
 QEMUQSPI_BASE_NAME ?= "QEMU_qspi-${MACHINE}-${DATETIME}"
 QEMUQSPI_BASE_NAME[vardepsexclude] = "DATETIME"
 
-- 
2.11.0

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

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

[Jean-Francois Dagenais]

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"
 
 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 
u-boot'}"
+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"
@@ -27,11 +27,11 @@ do_patch[noexec] = "1"
 
 def get_bootbin_depends(d):
 bootbindeps = ""
-bifpartition = (d.getVar("BIF_PARTITION_ATTR", True) or "").s

[meta-xilinx] xilinx-bootbin improvements

[Jean-Francois Dagenais]

Hi guys,

Here are a few changes I have been using. The first is a variable naming
improvement, the second cleans up the inherited recipe steps which don't make
sense for this recipe, the third is a feature addition.

Enjoy.

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

Re: [meta-xilinx] Custom ps7_init_gpl in Yocto Project

[Jean-Francois Dagenais]

Hi Nathan,

> On Jul 9, 2019, at 09:23, Nathan Rossi  wrote:
> 
> You should not need to do this change to xilinx-init-platform.bbclass,
> however you will need to make sure you recipe populates into the
> sysroot correctly. By default /usr/src is not populated into the
> sysroot (not to be confused with packaging). This is the purpose of
> the "SYSROOT_DIRS" line in platform-init.bb
> (http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/tree/meta-xilinx-bsp/recipes-bsp/platform-init/platform-init.bb#n24).

Great... for me. This will fix my problem. Unfortunately for Jek, I don't think 
this will help since he is using platform-init.bb.

Jek, I suggest you look carefully at u-boot-spl-zynq-init.inc. Several 
variables must work right in order for your psu_init files to end up in 
u-boot's source directory prior to the configure and compile steps.

Good luck!

Thanks for the info Nathan!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Custom ps7_init_gpl in Yocto Project

[Jean-Francois Dagenais]

Hi Jek, Xilinx people,

> On Jul 7, 2019, at 12:51, Jek F.  wrote:
> 
> i'm a newbie and i'm tring to build an image for microzed with a custom 
> ps7_init_gpl created in Vivado. I tried to create a custom layer 
> (meta-mylayer/recipes-bsp/platform-init/platform-init.bbappend) to append 
> ps7_init_gpl files but this didn't work. Which is the right way to Insert 
> ps7_init_gpl files in Yocto Project?
> 

I also had trouble with this. I worked around it by changing 
xilinx-init-platform.bbclass:

-PLATFORM_INIT_DIR ?= "/usr/src/xilinx-platform-init"
+PLATFORM_INIT_DIR ?= "/usr/lib/xilinx-platform-init"

I was not using platform-init per se but our own recipe which declares it is 
providing "virtual/xilinx-platform-init". So my u-boot recipe was indeed 
pulling on my platform-init files. And my custom platform-init recipe was 
indeed providing the psu_init_gpl.[ch] files in the default package. But 
somehow do_prepare_recipe_sysroot did not put the psu_init_gpl files under 
tmp/work/mymachine/u-boot/*/recipe_sysroot/usr/src ?

I don't know exactly why it didn't work with /usr/src because I had to move on. 
Perhaps there is a special case in populate_recipe_sysroot for /usr/src? I know 
normally, the /usr/src contents are collected by the "${PN}-dbg" packaging, not 
the default "${PN}" packaging.

It may be a regression caused by an update to the poky layer. The original code 
in xilinx-init-platform.bbclass from Nathan is dated 2017-01-14 which would be 
2-3 Yocto releases back.

Hope this helps!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [linux-xlnx] uio as module fails to link

[Jean-Francois Dagenais]

Quick turn-around!

> On Jul 8, 2019, at 14:51, Hyun Kwon  wrote:
> 
> Hi JFD,
> 
> Thanks for reporting the issue.
> 
> On Mon, 2019-07-08 at 09:01:03 -0700, Jean-Francois Dagenais wrote:
>> Anyone tried that? I get:
>> 
>> WARNING: modpost: missing MODULE_LICENSE() in drivers/uio/uio_dmabuf.o
>> see include/linux/module.h for more information
>> ERROR: "uio_dmabuf_map" [drivers/uio/uio.ko] undefined!
>> ERROR: "uio_dmabuf_unmap" [drivers/uio/uio.ko] undefined!
>> ERROR: "uio_dmabuf_cleanup" [drivers/uio/uio.ko] undefined!
>> 
>> uio/Makefile shows:
>> obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
>> 
>> I got it to compile by hacking uio.c to #include uio_dmabuf.c instead of the 
>> .h but that's probably not the correct way to fix this.
>> 
> 
> The easiest fix would be to merge uio_dmabuf.c into uio.c. Please see
> the attached patch and let me know if you see any other better way.

> Hehe, that was essentially what my #include "uio_dmabuf.c" was doing. This 
> patch
> fixes the problem. See my suggestion below.
> 
> Thanks,
> -hyun
> 
> From 84cbe02cf2775dca911c2b734dded794150698a8 Mon Sep 17 00:00:00 2001
> From: Hyun Kwon 
> Date: Mon, 8 Jul 2019 11:37:03 -0700
> Subject: [PATCH 1/1] uio: dmabuf: Merge the dmabuf functions into uio.c
> 
> With a separate uio_dmabuf.c, it's tricky to build the uio as
> a separate kernel module.
> 
> Reported-by: Jean-Francois Dagenais 
> Signed-off-by: Hyun Kwon 

Tested-by: Jean-Francois Dagenais 

> ---
> drivers/uio/Makefile |   2 +-
> drivers/uio/uio.c| 191 ++
> drivers/uio/uio_dmabuf.c | 210 ---
> 3 files changed, 192 insertions(+), 211 deletions(-)
> delete mode 100644 drivers/uio/uio_dmabuf.c
> 
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index 7af888a..aea3e17 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> -obj-$(CONFIG_UIO)+= uio.o uio_dmabuf.o
> +obj-$(CONFIG_UIO)+= uio.o
> obj-$(CONFIG_UIO_CIF) += uio_cif.o
> obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
> obj-$(CONFIG_UIO_DMEM_GENIRQ) += uio_dmem_genirq.o
> diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> index e054fa7..175fb6b 100644
> --- a/drivers/uio/uio.c
> +++ b/drivers/uio/uio.c
> @@ -26,6 +26,7 @@
> #include 
> #include 
> #include 
> +#include 
> 
> #include 
> 
> @@ -455,6 +456,196 @@ static irqreturn_t uio_interrupt(int irq, void *dev_id)
>   return ret;
> }

Would it be better to put all this dmabuf inside a
#ifdef CONFIG_DMA_SHARED_BUFFER
maybe? (Or IS_REACHABLE(CONFIG_DMA_SHARED_BUFFER), not sure which formulation 
works for all cases...)

> 
> +struct uio_dmabuf_mem {
> + int dbuf_fd;
> + struct dma_buf *dbuf;
> + struct dma_buf_attachment *dbuf_attach;
> + struct sg_table *sgt;
> + enum dma_data_direction dir;
> + struct list_head list;
> +};
> +
> +long uio_dmabuf_map(struct uio_device *dev, struct list_head *dbufs,
> + struct mutex *dbufs_lock, void __user *user_args)
> +{
> + struct uio_dmabuf_args args;
> + struct uio_dmabuf_mem *dbuf_mem;
> + struct dma_buf *dbuf;
> + struct dma_buf_attachment *dbuf_attach;
> + enum dma_data_direction dir;
> + struct sg_table *sgt;
> + long ret;
> +
> + if (copy_from_user(, user_args, sizeof(args))) {
> + ret = -EFAULT;
> + dev_err(dev->dev.parent, "failed to copy from user\n");
> + goto err;
> + }
> +
> + dbuf = dma_buf_get(args.dbuf_fd);
> + if (IS_ERR(dbuf)) {
> + dev_err(dev->dev.parent, "failed to get dmabuf\n");
> + return PTR_ERR(dbuf);
> + }
> +
> + dbuf_attach = dma_buf_attach(dbuf, dev->dev.parent);
> + if (IS_ERR(dbuf_attach)) {
> + dev_err(dev->dev.parent, "failed to attach dmabuf\n");
> + ret = PTR_ERR(dbuf_attach);
> + goto err_put;
> + }
> +
> [...]

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

[meta-xilinx] [linux-xlnx] uio as module fails to link

[Jean-Francois Dagenais]

Anyone tried that? I get:

WARNING: modpost: missing MODULE_LICENSE() in drivers/uio/uio_dmabuf.o
see include/linux/module.h for more information
ERROR: "uio_dmabuf_map" [drivers/uio/uio.ko] undefined!
ERROR: "uio_dmabuf_unmap" [drivers/uio/uio.ko] undefined!
ERROR: "uio_dmabuf_cleanup" [drivers/uio/uio.ko] undefined!

uio/Makefile shows:
obj-$(CONFIG_UIO)   += uio.o uio_dmabuf.o

I got it to compile by hacking uio.c to #include uio_dmabuf.c instead of the .h 
but that's probably not the correct way to fix this.

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

[Jean-Francois Dagenais]

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?

> 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

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

[Jean-Francois Dagenais]

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)}"

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)

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

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

[meta-xilinx] [meta-xilinx-tools][2019.1][patch 1/2] fpga-manager-util: don't overwrite xsctyaml DEPENDS

[Jean-Francois Dagenais]

The hard assignment of DEPENDS removes what xsctyaml.bbclass assigned.
The result is that do_create_yaml fails at import yaml.

  (Exception: ImportError: No module named 'yaml')

Signed-off-by: Jean-Francois Dagenais 
---
 recipes-bsp/fpga-manager-util/fpga-manager-util_1.0.bb | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/recipes-bsp/fpga-manager-util/fpga-manager-util_1.0.bb 
b/recipes-bsp/fpga-manager-util/fpga-manager-util_1.0.bb
index 782361d..bb6f725 100644
--- a/recipes-bsp/fpga-manager-util/fpga-manager-util_1.0.bb
+++ b/recipes-bsp/fpga-manager-util/fpga-manager-util_1.0.bb
@@ -23,7 +23,12 @@ SRC_URI_append = " \
file://multipleHDF.tcl \
file://base-hsi.tcl \
"
-DEPENDS = "virtual/hdf virtual/bitstream virtual/dtb dtc-native"
+DEPENDS += "\
+virtual/hdf \
+virtual/bitstream \
+virtual/dtb \
+dtc-native \
+"
 
 PACKAGE_ARCH ?= "${MACHINE_ARCH}"
 COMPATIBLE_MACHINE ?= "^$"
-- 
2.11.0

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

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

[Jean-Francois Dagenais]

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"
-- 
2.11.0

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

[meta-xilinx] (no subject)

[Jean-Francois Dagenais]

Hey guys,

Here are some things I stumbled upon while trying to use fpga-manager-util 
without 
meta-petalinux BTW. 

I don't see how the recipe could have ever worked since the yaml python module
is absent from recipe-sysroot-native!

Enjoy!

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

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

[Jean-Francois Dagenais]

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

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

[Jean-Francois Dagenais]

> On Jun 21, 2019, at 14:56, Manjukumar Harthikote Matha  
> wrote:
> 
> Are you on 2018.3 or 2019.1 release?

2019.1


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

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

> On Jun 20, 2019, at 09:35, Michal Simek  wrote:
> 
> On 20. 06. 19 15:24, Jean-Francois Dagenais wrote:
> 

Guys, FYI...

I found out that it was a misconfigured PMU firmware build which had 
XPAR_MICROBLAZE_DDR_RESERVE_SA set to 0 in the BSP's xparameters.h, resulting 
in FSBL_STORE_ADDR being 0x8 (the load aodress of the kernel). When FSBL 
ran ATF, the PMU got busy copying the FSBL code over parts of my kernel!!

The cause is probably that the handoff file comes from 2018.3 while using 
embeddedsw 2019.1... we will confirm this tomorrow.

So I am now in linux using the trampoline!

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

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Hi Michal,

> On Jun 20, 2019, at 08:18, Michal Simek  wrote:
> 
> Hi,
> 
> I have not a problem with this. I just retest it on zcu104.
> my bootgen version is not capable to work with Image. It should be
> Image.bin.

What is different between Image and Image.bin? I could not find the expression 
in any of the linux/arch/arm64/...Makefiles.

Is it just Image renamed to Image.bin and this somehow makes a difference to 
bootgen? I switched to the Image-mymachine.bin symlink in my DEPLOYDIR and it 
makes no difference. I also tried loading my DTB at the same address as you, no 
difference, of course.

I am booting on SD, are you?

I see two FSBL banners in your pastebin (https://pastebin.com/Um1vmqpc)
Xilinx Zynq MP First Stage Boot Loader 
Release 2019.1   May 24 2019  -  18:30:01
Xilinx Zynq MP First Stage Boot Loader 
Release 2019.1   May 24 2019  -  18:30:01
PMU Firmware 2019.1 May 24 2019   18:28:19
PMU_ROM Version: xpbr-v8.1.0-0
NOTICE:  ATF running on XCZU7EG/EV/silicon v4/RTL5.1 at 0xfffea000

Shooting in the dark here... but is the FSBL copying itself to RAM then 
restarting? Or did you just copy/pasted two lines by mistake?

Could there be some configuration missing from my kernel defconfig perhaps? (I 
will investigate this now.) Or some bad/missing configuration from our handoff 
file? I am still using the one generated by vivado 2018.3. Should we align this 
now to be sure?

I will try and build these products for zcu104 then do deep comparisons of 
config files and generated code. Perhaps if I can swap in my psu_init.c/h I 
could try and boot it on my board...

Anyway thanks for answering my questions. I will really make sure to send in 
patches for this alternate boot flow.

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

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Hi Michal, all.

(My previous mail contained screenshots which did not make it to the list for 
all. Michal got it and responded however...)

> On Jun 20, 2019, at 04:17, Michal Simek  wrote:
> 
> can you send your bif file?
> 

Sure, here:

the_ROM_image:
{
 [bootloader,  destination_cpu=a53-0] 
/builds/yocto/mymachine/tmp/deploy/images/mymachine/fsbl-mymachine.elf
 [destination_cpu=pmu] 
/builds/yocto/mymachine/tmp/deploy/images/mymachine/pmu-firmware-mymachine.elf
 [destination_cpu=a53-0, exception_level=el-3, trustzone] 
/builds/yocto/mymachine/tmp/deploy/images/mymachine/arm-trusted-firmware.elf
 [destination_cpu=a53-0, exception_level=el-2] 
/builds/yocto/mymachine/tmp/deploy/images/mymachine/linux-boot-simple.elf
 [load=0xff2000] 
/builds/yocto/mymachine/tmp/deploy/images/mymachine/mymachine.dtb
 [load=0x8] 
/builds/yocto/mymachine/tmp/deploy/images/mymachine/Image
}

It is generated from xilinx-bootbin.bb, linux-boot-simple is the trampoline 
code you provided. 

   .section.text
   .global _start
_start:
   ldr  x17, kernel_start
   ldr  x0, kernel_dts
   mov  x1, xzr
   mov  x2, xzr
   mov  x3, xzr
   blr  x17
   .balign 8
kernel_start:
   .dword   __BOOT_LOAD_KERNEL_ADDRESS__
kernel_dts:
   .dword   __BOOT_LOAD_DTB_ADDRESS__

I have this in my layer as 
recipes-bsp/linux-boot-simple/files/linux-boot-simple.S, the two symbols at the 
end are replaced by the recipe I made 
(recipes-bsp/linux-boot-simple/linux-boot-simple.bb)
SUMMARY = "Simple Boot Loader for linux ARM Image file"
LICENSE = "GPLv2"

SRC_URI += "file://linux-boot-simple.s"

B = "${WORKDIR}/build"

PACKAGE_ARCH = "${MACHINE_ARCH}"

inherit xsct-tc

do_configure() {
sed "s/__BOOT_LOAD_KERNEL_ADDRESS__/${BOOT_LOAD_KERNEL_ADDRESS}/" 
${WORKDIR}/${PN}.s > ${B}/${PN}.s
sed -i "s/__BOOT_LOAD_DTB_ADDRESS__/${BOOT_LOAD_DTB_ADDRESS}/" 
${B}/${PN}.s
}

do_compile() {
aarch64-none-elf-gcc -nostartfiles -nodefaultlibs 
-Wl,--build-id=none,-Ttext=${BOOT_LOAD_LINUX_BOOT_SIMPLE} ${PN}.s -o ${PN}.elf
}

do_install[noexec] = "1"

inherit deploy

do_deploy() {
cp ${B}/linux-boot-simple.elf ${DEPLOYDIR}
}
addtask deploy before do_build after do_compile


And in my mymachine.conf:

...
BOOT_LOAD_DTB_ADDRESS = "0xff2000"
BOOT_LOAD_KERNEL_ADDRESS = "0x8"
BOOT_LOAD_LINUX_BOOT_SIMPLE = "0x5F000"

# override the auto addition of fpga, and add dtb, kernel image and an ATF to 
linux trampoline to boot.bin:
BIF_PARTITION_ATTR_mymachine = "fsbl pmu atf linux-trampoline dtb kernel"

BIF_PARTITION_ATTR[linux-trampoline] = 
"destination_cpu=a53-0,exception_level=el-2"
BIF_PARTITION_IMAGE[linux-trampoline] = 
"${DEPLOY_DIR_IMAGE}/linux-boot-simple.elf"
BIF_PARTITION_DEPENDS[linux-trampoline] = "linux-boot-simple:do_deploy"

BIF_PARTITION_ATTR[dtb] := "load=${BOOT_LOAD_DTB_ADDRESS}"
BIF_PARTITION_IMAGE[dtb] = "${DEPLOY_DIR_IMAGE}/${MACHINE}.dtb"
BIF_PARTITION_DEPENDS[dtb] = "virtual/kernel:do_deploy"

BIF_PARTITION_ATTR[kernel] := "load=${BOOT_LOAD_KERNEL_ADDRESS}"
BIF_PARTITION_IMAGE[kernel] = "${DEPLOY_DIR_IMAGE}/Image"
BIF_PARTITION_DEPENDS[kernel] = "virtual/kernel:do_deploy"
...

The missing BIF_PARTITION entries come from 
meta-xilinx-tools/recipes-bsp/bootbin/machine-xilinx-zynqmp.inc


> On 19. 06. 19 22:27, Jean-Francois Dagenais wrote:
>> Hi Michal, guys,
>> 
>> Any ideas Michal? I have been debugging this for 4 days and it doesn't
>> look like I'm moving ahead much. You made it sound so simple but it is
>> not so simple apparently...
>> 
>> Since my last post below, I have hacked head.S to include
>> _inval_dcache_area so as to make the branch call nearer and it works.
>> (Which is weird in itself... but all I do now is stretching my
>> knowledge, so I'm having fun here!)
>> 
>> I am able to reach start_kernel from main.c. Then things start getting
>> weird...
>> 
>> Here's my debug boot log:
>> https://pastebin.com/QxA0AQfh
>> 
>> This is where things stop making sense...
>> 
>> I placed a few breakpoints in start_kernel after this line and I end up
>> stuck here:
>> 

So here were the screenshots of xsdk, anyone cares?

>> 
>> 
>> Please help guys!! Or should I direct to linaro or linux-arm mailing lists?
>> 
>> Here, "HELP" could just be a debugging technique I might use, a
>> configuration, a debug flag somewhere, etc.
>> 
>> Thanks all!

Thanks for your help Michal!

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

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Hi Michal, guys,

> On Jun 14, 2019, at 03:20, Michal Simek  wrote:
> 
> If you want to boot just linux without u-boot you can simply run
> FSBL->ATF->linux-boot.bin->Linux. That's what I have described in
> previous email. And I would put linux-boot.bin to RAM out of Linux image.

Yup, I got that. Thanks for your very precious help. I am deep into debugging 
this with xsdk 2019.1 now. I have a breakpoint at 0x8 and in assembly, I 
can see it executing "bl preserve_boot_args" (in arch/arm64/kernel/head.S), 
then jump to preserve_boot_args and when it hits "b _inval_dcache_area // tail 
call", the Disassembly window shows:
000949c0:   .word 0x0409
000949c4:   .word 0x0060004e
000949c8:   .word 0x4409
000949cc:   .word 0x0060004e
...
Then issuing a "step into" again at the debugger makes the CPU jump at 
PC:0xa048814450408200 !!

When I boot using the usual u-boot proper, once in linux Image, it follows the 
same route in head.S, and after a single step into that same "b 
_inval_dcache_area", it looks much better, i.e. assembly instructions.



Looking at register dumps between the two sequences, I noticed "Vector Base 
Address Register (EL2)" register looks well initialized on the u-boot proper 
side, and uninitialized with value: 0xa048814450408140,  which is way to close 
to the PC above to be a coincidence!

So it looks like u-boot proper left the MMU perhaps, or something in the CPU 
state which makes things run smoother than if not.

I'm seeing what I guess are significant discrepancies in these registers:
Translation Table Base Register 0 (EL2)
u-boot: 3ffe, linux-boot.bin: 000100801310

3:4:2:0:2, Translation Control Register (EL2)
u-boot: 80823518, linu-boot.bin: 8080

3:4:10:2:0, Memory Attribute Indirection Register (EL2)
u-boot: 00ff440c0400, linux-boot.bin: 400012080024000c

3:4:12:0:0, Vector Base Address Register (EL2)
u-boot: 3ff12800, linux-boot.bin: a048814450408140


I am no Arm64 CPU architecture expert. Maybe someone can translate this info 
into hints without us having to read (and understand) the whole ARM64 TRM doc? 
Something like "The ATF did not cleanup such and such" or whatever.


> 
> And sure you can use SPL instead of FSBL which likely don't need to use
> any trampoline code (linux-boot.bin). If this is packed in FIT I also
> think that you don't need to use any trampoline for booting. But I
> didn't test it to be 100% sure.

Actually, I rather like the monolithic boot.bin that bootgen creates. Maybe 
this can also be done with mkImage... At this point though, for our current use 
cases, I seen not advantages for using spl, so far.

If I were though, I'm not sure how I would achieve everything without 
linux-boot.bin... I suppose I would have to make ATF come back to the SPL code 
using the handoff structure so SPL can proceed with falcon booting the kernel? 
This would most likely require new code in SPL right? Thanks for adding a few 
details.

Anyway, thanks all of you for your interest and support!

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

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Thanks Michal!

This is awesome. I can certainly use this. Please review my assumptions below...

> On Jun 12, 2019, at 07:39, Michal Simek  wrote:
> 
> Create bif like this.
> Image - one partition load addr 0x8 as data
> dtb - one partition load addr 0x1 as data
> 
> ATF - one partition (as today) EL3
> Trampoline code below() EL2-ns with filled kernel start to 0x8 and
> dtb at 0x1
> 
> fsbl starts ATF and it will pass handoff structure and primary program
> will be trampoline executed in EL2 which will just pass proper arguments
> to kernel.


So in essence, the program below becomes a standalone binary file which
essentially replaces "u-boot.bin" correct? Let's call it linux-boot.bin
(inspired by comment in code below).

This would mean that boot.bin file must contain linux-boot.bin so FSBL loads it
to RAM prior to passing execution to ATF. If correct, linux-boot.bin must be
loaded at 0xfffc8000 (if following the example below), correct?

If I understand all this correctly, I could either use FSBL with a boot.bin
containing basically everything needed to boot up to the kernel, including
linux-boot.bin. Or I could use SPL inside an u-boot's mkimage made boot.bin
configured to load a FIT image containing atf, linux-boot.bin,kernelImage,dtb ?

If I understand FIT correctly, it is basically a "better", more straight forward
way to load multiples binaries into RAM rather than messing with
CONFIG_SPL_FS_LOAD_ARGS_NAME, CONFIG_SYS_SPL_ARGS_ADDR,
CONFIG_SPL_FS_LOAD_KERNEL_NAME and CONFIG_SPL_FS_LOAD_PAYLOAD_NAME... correct?

> 
> And that should be it.
> 
> /*
> * (C) Copyright 2015 - 2019, Xilinx, Inc
> *
> * Drops EL from 3 down to 2 and sets up the CPU for AArch64 execution.
> *
> * The kernel start address and DTB location can easily be patched at
> runtime
> * before jumping to this code-snippet if needed.
> *
> * To for example build and link to 0xfffc8000:
> * aarch64-none-elf-gcc -nostartfiles -nodefaultlibs \
> *  -Wl,--build-id=none,-Ttext=0xfffc8000
> linux-boot.s -o linux-boot
> *
> * Written by Edgar E. Iglesias and Jason Wu.
> */
>.section.text
>.global _start
> _start:
>ldr x17, kernel_start
>ldr x0, kernel_dts
>mov x1, xzr
>mov x2, xzr
>mov x3, xzr
>blr x17
>.balign 8
> kernel_start:
>.dword  ${kernel_start}
> kernel_dts:
>.dword  ${kernel_dts}

Thanks again for taking the time. I shall submit a patch in README.booting.md if
my endeavour looks upstreamable.

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

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

> On Jun 12, 2019, at 03:03, Michal Simek  wrote:
> 
> There is no real need to run any u-boot if you want to short boot up
> time. Just let fsbl to load ATF and ATF directly starts kernel.

Great then! I can use that.

Please verify my assumptions... ATF is not a loader (loading from file/disk to 
RAM) so I imagine the kernel and dtb would have been previously loaded 
somewhere in RAM by FSBL because they are also mentioned in my BIF and thus are 
bundled in my boot.bin file?

Can you point at anything what so ever (pdf, txt file in a repo, video, 
confluence/wiki page, mailing list archive message, etc.) which shows a shred 
of details on how to do this please? I just need a tiny bit to grab onto and I 
can run with it after.

Your suggestion is great but I don't know for example, if it requires me to 
write a bit of code (which would be fine) or not. I've searched for hours in 
docs and code etc. but perhaps I am not using the right terms in my searches.

Thanks for taking the time!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Anyone?

> On Jun 10, 2019, at 23:51, Jean-Francois Dagenais  
> wrote:
> 
> Hi guys,
> 
> Is this possible? I am shooting for fastest boot possible and thought this 
> would be the way to achieve it. What is the smallest cost I have to expect 
> for having u-boot proper in the boot flow? I.e. is my assumption that I must 
> skip it to achieve fastest boot true.
> 
> FYI, I've decided to postpone fpga load to linux init. This simplifies things 
> a bit in SPL, but there is still the mix of ATF and Falcon which I am not 
> sure. I am fuzzy on the ATF terminology so thank you for bearing with me as I 
> learn.
> 
> Can anyone point to a working example (board config .h and defconfig files 
> for example) or which pieces are required to make it work. 
> 
> I found this on arm-community: "Solved the problem. U-Boot SPL copies ATF in 
> OCRAM, and ATF calls Kernel directly passing in the FDT address."
> 
> BTW, we boot both SD and eMMC on the same board. Right now I got my SPL to 
> open a FIT image made by kernel-fitimage.bbclass but it obviously doesn't go 
> far.
> 
> But its still a bit vague. If I have to guess, the FIT image would describe 
> to load the kernel at an address which also appears in my dts/dtb so ATF 
> knows where to jump to next.
> 
> Thanks for clues an pointers fellas!


Please help. Michal, I saw you were involved with this...
https://lists.denx.de/pipermail/u-boot/2016-October/269080.html

I am drowning in a sea of legacy and generic code flows within SPL. I am 
wondering what design/methods to use if doing a new zynqmp based design. I see 
a bunch of flows where different images can be loaded:

CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
CONFIG_SPL_FS_LOAD_ARGS_NAME
CONFIG_SPL_FS_LOAD_KERNEL_NAME

I see comments in include/configs/xilinx_zynqmp.h like "/* u-boot is like dtb 
*/" which adds to the confusion.

... or should I try, if at all possible, to boot directly to linux from FSBL? 
Or do this 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841976/Prepare+boot+image#Preparebootimage-Example:FSBLpre-loadsLinuximages
 and make a very stripped down u-boot proper (no MMC driver needed), and boot 
into pre-loaded kernel?

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

[meta-xilinx] SPL->ATF->Linux

[Jean-Francois Dagenais]

Hi guys,

Is this possible? I am shooting for fastest boot possible and thought this 
would be the way to achieve it. What is the smallest cost I have to expect for 
having u-boot proper in the boot flow? I.e. is my assumption that I must skip 
it to achieve fastest boot true.

FYI, I've decided to postpone fpga load to linux init. This simplifies things a 
bit in SPL, but there is still the mix of ATF and Falcon which I am not sure. I 
am fuzzy on the ATF terminology so thank you for bearing with me as I learn.

Can anyone point to a working example (board config .h and defconfig files for 
example) or which pieces are required to make it work. 

I found this on arm-community: "Solved the problem. U-Boot SPL copies ATF in 
OCRAM, and ATF calls Kernel directly passing in the FDT address."

BTW, we boot both SD and eMMC on the same board. Right now I got my SPL to open 
a FIT image made by kernel-fitimage.bbclass but it obviously doesn't go far.

But its still a bit vague. If I have to guess, the FIT image would describe to 
load the kernel at an address which also appears in my dts/dtb so ATF knows 
where to jump to next.

Thanks for clues an pointers fellas!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Warrior release 06/30

[Jean-Francois Dagenais]

Hi all,

> On Jun 5, 2019, at 12:11, Luca Ceresoli  wrote:
> 
> It's your choice. I think the differences are not many (way less than
> for the kernel at least).
> 
> What are the big pieces from xilinx/u-boot not yet upstreamed?
> 
> AFAIK only Dual QSPI. But git diff is your friend.
> 
>> * What do you guys do to get the pm_cfg_obj.c generated? Manually?
> 
> Manually here. It's enough for my needs. BTW I'm not using
> meta-xilinx-tools.

Thanks for that... I've hit a few rough patches trying to get the config object 
through fsbl. staging.bbclass was choking on this in my pmu-firmware bbappend:
do_configure[mcdepends] = "multiconfig:pmu:mymachine:fsbl:do_deploy" it seems. 
Assumptions broken... made a simple fix but will have to inspect it further if 
this whole endeavour pans out.

Since I still use meta-xilinx-tools, I may just use pmu-firmware from that and 
ditch multiconfig and -standalone completely. It does make bitbake terribly 
longer to start. meta-xilinx-tools got much better since the introduction of 
xsct-tarball.bbclass. Cleaned up our huge docker image and made upgrades 
trivial compare to a manually tedious process before. Kudos on Xilinx for that.

from your linked in reply:
> I never tried to use falcon mode on ZynqMP, but I suspect it's a no-go if you 
> want to load your bitstream before Linux boots.

So I thought the SPL had support for fpga... I have CONFIG_SPL_FPGA_SUPPORT in 
my config, and yes I was hoping to get that done prior to jumping in linux. If 
I understand correctly, it is always the PMU that actually programs the FPGA 
bin file? Communicated through IPI? I was convinced this was done by SPL...

FYI right now I am in very early stage of running my freshly made u-boot 
boot.bin with the SPL. I am reacquainting myself with the SPL execution and 
debugging techniques (been a while). Right now I need to get more verbosity 
from SPL, only what looks like DTS parsing prints are coming out. And my PMUFW 
(with my cfg object), which I know was on my u-boot mkimage cmdline, I'm not 
even sure it gets programmed by the CSU...

Anyway, making progress, but lots of things grinding the effort to an almost 
crawl... (not complaining, this is all just fun btw.)

Thanks for any heads up and pointers fellas.
Cheers!

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

Re: [meta-xilinx] Warrior release 06/30

[Jean-Francois Dagenais]

That is great news!

> On Jun 3, 2019, at 14:07, Manjukumar Harthikote Matha  
> wrote:
> 
> 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/

Thanks again Luca. Hey, here's my question from the post comment, and a bonus 
one:

* Does this mean we should switch to mainline u-boot or does xilinx/u-boot 
closely tracks that mainline? What are the big pieces from xilinx/u-boot not 
yet upstreamed?
* What do you guys do to get the pm_cfg_obj.c generated? Manually? I have my 
own provider recipe for virtual/hdf which tracks internal releases made by our 
Vivado people. So far, I have exploited the hdf opaquely through 
meta-xilinx-tools. I was hoping to keep on generating pm_cfg_obj.c completely 
automatically.

Switching to SPL boot flow compromises this part. So I am currently thinking of 
still generating it with the fsbl_git.bb recipe from meta-xilinx-tools. I have 
"sabotaged" the fsbl recipe through a bbappend which does this:
# replace fsbl's do_deploy:
do_deploy() {
install -Dm 0644 
${B}/${XSCTH_PROJ}/zynqmp_fsbl_bsp/psu_cortexa53_0/libsrc/xilpm_v*/src/pm_cfg_obj.c
 ${DEPLOYDIR}/
}

# don't waste time compiling and installing:
do_compile[noexec] = "1"
do_install[noexec] = "1"

This way, only the do_configure is important and I exploit the deploy to 
transport the pm_cfg_obj.c from fsbl to standalone:pmu-firmware where I can 
pull on this and use it:

my pmu-firmware_2019.1.bbappend:
SRC_URI += "\
  file://0001-Load-XPm_ConfigObject-at-boot.patch \
"

do_configure[mcdepends] = "multiconfig:pmu:dublin:fsbl:do_deploy"

# Inspired by Luca's zynqmp-pmufw-builder
do_configure_append () {
sed 's!"pm_defs.h"!"${S}/lib/sw_services/xilpm/src/common/pm_defs.h"!' \
${DEPLOY_DIR_IMAGE}/pm_cfg_obj.c > ${B}/pmu-firmware/pm_cfg_obj.c
}

I have a feeling this is way overkill... but I don't want to loose out on 
auto-generated freebies when we upgrade Vivado and meta-xilinx-tools. These 
freebies are still a bit opaque to me at this point, might not be worth all the 
fuss? Anyone has any ideas on this?

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

Re: [meta-xilinx] pmu-firmware configure failure

[Jean-Francois Dagenais]

> On Jun 4, 2019, at 13:40, Alejandro Hernandez 
>  wrote:
> 
> Multiconfig should not have anything to do with this,
> I'm not exactly sure what you are running into, since I'm not able to 
> reproduce it
> but I don't see why those directories would exist, I would try cleaning as 
> well and that will probably fix it.
> 
> 
> Also, once we release the warrior branch, pmu-firmware should work with 
> master and warrior (from oe-core) just fine,
> and there will be a small change on the way multiconfig is setup to make it 
> faster.
> 
> Cheers,
> 
> Alejandro

Hi Alejandro,

Thanks for your help.

Check my last reply. It was this 
https://github.com/Xilinx/meta-xilinx/blob/64aa3d35ae9e612355677d1fb8d06143be06d92e/meta-xilinx-standalone/recipes-standalone/pmu-firmware/pmu-firmware_2018.3.bb#L28
 from master which I had from a bad merge with 2019.1 that caused the error.

You guys should check this from my last reply though:
> So 6aa787afce5ae454ce0a072fbf93e47e3960ada1 should have also removed the 
> mention of xsecure_sha2_pmu.a. Also, copy_bsp.sh should have "set -e" at the 
> top so it fails if the script fails one of its steps.

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

Re: [meta-xilinx] pmu-firmware configure failure

[Jean-Francois Dagenais]

Hi guys, (Xilinx embeddedsw repo people, read on below please.)

Figured it out. You were correct Luca. I made a simple bblayers/local.conf 
setup in an empty dir.

> On Jun 4, 2019, at 04:04, Luca Ceresoli  wrote:
> 
> Do you mean the "rel-v2019.1" branch of meta-xilinx? Or the
> "xilinx-v2019.1" tag of embeddedsw? Or the "release-2019.1" branch
> branch of embeddedsw?

I was not *EXACTLY* on meta-xilinx/rel-v2019.1, I had extra bits from 
meta-xilinx/master in my pmu-firmware_2019.1.bb (the xilfpga stuff in 
do_configure) which just fails. The xsecure_sha2_pmu.a error was a 
distraction... but an error non the less.

So Kalyani's 6aa787afce5ae454ce0a072fbf93e47e3960ada1 patch should have also 
removed the mention of xsecure_sha2_pmu.a. Also, copy_bsp.sh should have "set 
-e" at the top so it fails if the script fails one of its steps.

> 
> In other words, can you describe the exact steps to have a setup that
> reproduces your problem? Or try from scratch by adding the needed layers
> and do a build without changes? I suspect there's something
> "non-standard" in your setup. Except for being non-multiconfig, my
> working setup is very basic.
> 
>>> Does a non-multiconfig setup work?
>> Will try this tomorrow.
>> 
>> In the mean time, I inspected copy_bsp.sh more carefully and it seems that 
>> commit 6aa787afce5ae454ce0a072fbf93e47e3960ada1 (and 
>> ae0d2a0989e3855d2044ab55dabc78ff35e38137 ??? ) removes 
>> lib/sw_services/xilsecure/src/xsecure_sha2_pmu.a so I am really wondering 
>> how this: 
>> https://github.com/Xilinx/embeddedsw/blob/86e2a1940f997f291ea5c1628f3c8a945133f100/lib/sw_apps/zynqmp_pmufw/misc/copy_bsp.sh#L93
>>  would work for anyone!
>> 
>> Luca, you say it works for you on 2019.1
> 
> I had tried branch rel-v2019.1 of meta-xilinx, with whatever
> pmu-firmware commit it uses. I didn't look into the embeddedsw git repo.
> 
>> have you tried with a really clean workdir for pmu-firmware (bitbake 
>> pmu-firmware -c cleanall)? (Just to be sure)
> 
> Done that now. It keeps on building succeessfully.

Thanks for the assistance Luca! I am now moving on to the next issue(s)! ;)

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

Re: [meta-xilinx] pmu-firmware configure failure

[Jean-Francois Dagenais]

Thanks for the comeback Luca.

> On Jun 3, 2019, at 03:47, Luca Ceresoli  wrote:
> 
> Not really I'm afraid, but I tried building a pmufw now without
> multiconfig and it succeeds in master, thud and the shiny new
> rel-v2019.01 branch on xilinx's github and they all succeed.
> 
> Which commit are you using?
v2019.1
> Does a non-multiconfig setup work?
Will try this tomorrow.

In the mean time, I inspected copy_bsp.sh more carefully and it seems that 
commit 6aa787afce5ae454ce0a072fbf93e47e3960ada1 (and 
ae0d2a0989e3855d2044ab55dabc78ff35e38137 ??? ) removes 
lib/sw_services/xilsecure/src/xsecure_sha2_pmu.a so I am really wondering how 
this: 
https://github.com/Xilinx/embeddedsw/blob/86e2a1940f997f291ea5c1628f3c8a945133f100/lib/sw_apps/zynqmp_pmufw/misc/copy_bsp.sh#L93
 would work for anyone!

Luca, you say it works for you on 2019.1, have you tried with a really clean 
workdir for pmu-firmware (bitbake pmu-firmware -c cleanall)? (Just to be sure)

...And what's happening in the embeddedsw repo?? There is a branch called 
release-v2019.1 but there is a fork from commit 
6d04739c1ddc8727911e8b14163336c86ceafa10 where almost all commits are repeated 
and there's a tag xilinx-v2019.1 on top. The two branches are almost identical. 
A few differences in pdfs, licenses and htmls and an extra 
lib/sw_services/xilsem directory on the xilinx-v2019.1 side.

What gives?? How confusing is this! Which are we suppose to use? Don't get me 
wrong... I am glad I can access the code here. ;) But it looks like Xilinx is 
using some patch/apply workflow internally and it's not working tip top.

Cheers and thanks for the help guys!
/jfd
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] pmu-firmware configure failure

[Jean-Francois Dagenais]

Hi guys,

I'm trying to switch from meta-xilinx-tools' pmu-firmware to 
meta-xilinx-standalone.

I've setup my multiconfig as per README.building.md and am trying to build. 
Pmu-firmware fails the copy_bsp.sh 

BSP directory already exists
Standalone directory already exists
csudma directory already exists
uartps directory already exists
ipipsu directory already exists
ttcps directory already exists
emacps directory already exists
iicps directory already exists
sdps directory already exists
qspipsu directory already exists
gpiops directory already exists
usbpsu directory already exists
wdtps directory already exists
sysmonpsu directory already exists
cpu directory already exists
mv: cannot stat 
'../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilsecure/src/xsecure_sha2_pmu.a': 
No such file or directory
mv: cannot stat 
'/builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/git/lib/sw_apps/zynqmp_pmufw/src/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src/interface/zynqmp/*':
 No such file or directory
WARNING: 
/builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/temp/run.do_configure.11740:1
 exit 1 from 'mv 
/builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/git/lib/sw_apps/zynqmp_pmufw/src/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src/interface/zynqmp/*
 
/builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/git/lib/sw_apps/zynqmp_pmufw/src/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src'
ERROR: Function failed: do_configure (log file is located at 
/builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/temp/log.do_configure.11740)

I vaguely remember from my relatively short time spent on the xsdk (both in 
eclipse and through meta-xilinx-tools) that the BSP was a separate build 
project. How would this work here? Who would build the BSP in a bitbake build.

standalone's pmu-firmware defines:
BSP_DIR ?= "${S}/../misc/zynqmp_pmufw_bsp"
BSP_TARGETS_DIR ?= "${BSP_DIR}/psu_pmu_0/libsrc"
Is there some dependency missing? Or maybe a step for the BSP prior to 
pmu-firmware:do_configure ? Or maybe some black magic from meta-petalinux 
(which I currently don't use)?

I am a bit clueless here, there's definitely a gap in the 
meta-xilinx/.../READMEs.

Any clues anyone?
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] xilinx_uartps infinite wait loop

[Jean-Francois Dagenais]

Hi Shubhrajyoti,

Thanks for the patch. It looks good, but I am not able to test this just now, 
it will have to wait a few days.

I can provide feedback though... see below.

> On May 16, 2019, at 01:42, Shubhrajyoti Datta  wrote:
> 
> From 92129ad79d3863b37936b2b383f4827926d15934 Mon Sep 17 00:00:00 2001
> From: Shubhrajyoti Datta 
> Date: Thu, 16 May 2019 10:55:13 +0530
> Subject: [PATCH] serial: uartps: Add timeout for the wait for tx empty
> 
> Make the wait for the TX empty have a timeout.
> In case there is no cable connected then the loop
> runs forever.
> 
> Signed-off-by: Shubhrajyoti Datta 
> ---
>  drivers/tty/serial/xilinx_uartps.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/xilinx_uartps.c 
> b/drivers/tty/serial/xilinx_uartps.c
> index 75e1027..5752f12 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -689,16 +689,26 @@ static void cdns_uart_set_termios(struct uart_port 
> *port,
>   unsigned int baud, minbaud, maxbaud;
>   unsigned long flags;
>   unsigned int ctrl_reg, mode_reg;
> + ulong timeout;
>  
> - spin_lock_irqsave(>lock, flags);
> + timeout = jiffies + msecs_to_jiffies(1000);

1 second seems like a very long time. Zynqmp integrators are most likely making 
products targeting very fast boot time.

I had an idea... Instead of testing TX FIFO empty for the timeout, could we 
instead detect if the TX FIFO depth has changed at all? So make the timeout 
much smaller, say, how much time it should take for a byte to go out at the 
current baud rate. Then each time the fifo byte count changes, the "timer" 
(jiffies + msecs_to_jiffies(byte_xfer_timeout);) is reset. Hopefully, the value 
for byte_xfer_timeout would be small enough to be almost inconsequential.

>  
> - /* Wait for the transmit FIFO to empty before making changes */
> - if (!(readl(port->membase + CDNS_UART_CR) &
> - CDNS_UART_CR_TX_DIS)) {
> - while (!(readl(port->membase + CDNS_UART_SR) &
> - CDNS_UART_SR_TXEMPTY)) {
> - cpu_relax();
> + spin_lock_irqsave(>lock, flags);
> + while (1) {
> + if (time_after_eq(jiffies, timeout)) {
> + spin_unlock_irqrestore(>lock, flags);
> + dev_dbg(port->dev, "timed out waiting for tx empty");

Hmm... I was thinking this may be more than a dev_dbg, especially if the 
timeout remains 1 second. Integrators will most likely be glad to get this as a 
warning, explaining why their board takes a second longer to boot.

Is there a way to prevent systemd from changing the termios parameters? (the 
legacy SystemV "init" does that also, and blocks here indefinitely btw.)

> + return;
>   }
> + /* Wait for the transmit FIFO to empty before making changes */
> + if ((readl(port->membase + CDNS_UART_CR) &
> + CDNS_UART_CR_TX_DIS))
> + break;
> +
> + if ((readl(port->membase + CDNS_UART_SR) &
> + CDNS_UART_SR_TXEMPTY))
> + break;
> + cpu_relax();
>   }

Another idea could be to check if the new termios settings do in fact require a 
flush of the TX Fifo before going on... I would bet it doesn't and the wait 
might not even be necessary in almost all cases (i.e. baud rate and bit 
configuration, set by the FSBL are the same as what linux is trying to 
configure.)

>  
>   /* Disable the TX and RX to set baud rate */
> -- 
> 2.1.1
> 

Thanks again for the help!
Cheers!

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

Re: [meta-xilinx] xilinx_uartps infinite wait loop

[Jean-Francois Dagenais]

> On Apr 17, 2019, at 11:22, Michal Simek  wrote:
> 
> +Shubhrajyoti.
> 

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH] arm-trusted-firmware.inc: Add support to build ATF for versal devices

[Jean-Francois Dagenais]

> On Apr 30, 2019, at 03:14, Luca Ceresoli  wrote:
> 
>> EXTRA_OEMAKE_zynqmp_append = "${@' ZYNQMP_CONSOLE=${ATF_CONSOLE}' if 
>> d.getVar('ATF_CONSOLE', True) != '' else ''}"
>> +EXTRA_OEMAKE_append_versal = "${@' VERSAL_CONSOLE=${ATF_CONSOLE}' if 
>> d.getVar('ATF_CONSOLE', True) != '' else ''}"
> 
> Not related to your addition, but the zynqmp line before this has
> swapped "append" and "zynqmp" with respect to the usual syntax. It looks
> like it works anyway, but perhaps it's worth cleaning it up in a
> separate patch.

Yes, this current form means that "EXTRA_OEMAKE" has an override for zynqmp, 
onto which we append stuff.

Whereas the other form:

EXTRA_OEMAKE_append_zynqmp = "..."

Means: on the standard EXTRA_OEMAKE append, in the case of of zynqmp, the 
following stuff.

So the first form completely replaces the base EXTRA_OEMAKE whereas the second 
form appends on the base EXTRA_OEMAKE in case of "zynqmp".

One of those many yocto "gotchas" I'v been bitten by in the past. Thought it 
might be good to add my 2 cents here.

Cheers! ;)
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] xilinx_uartps infinite wait loop

[Jean-Francois Dagenais]

Hi all,

In the last year, in xilinx_uartps.c, this loop appeared at the top of 
cdns_uart_set_termios

/* Wait for the transmit FIFO to empty before making changes */
if (!(readl(port->membase + CDNS_UART_CR) &
CDNS_UART_CR_TX_DIS)) {
while (!(readl(port->membase + CDNS_UART_SR) &
CDNS_UART_SR_TXEMPTY)) {
cpu_relax();
}
}


When (and this happens by default for us) ttyPS0 is a console for init or 
Systemd, it goes into this function, then, if no cable is connected, it will 
wait forever, essentially looking like the system doesn't boot since Systemd is 
very early in it's process and doesn't do anything else.

My current workaround is to add "console=tty0" (a virtual console) to the 
kernel command line. But this is a hassle when the console is required since I 
need to hack my boot parameters to switch the console back to ttyPS0. But when 
I do, then this system absolutely needs this cable sucking the bytes off the tx 
fifo otherwise the system doesn't reboot or completely boots.

This loop seems quite odd since it has no out. Would it be reasonable to add a 
timed out where if some amount of time has passed, the code can assume no-one 
cares about the bytes in the FIFO and we can proceed anyway? Or better, a way 
to detect no cable is connected and thus the loop will run forever?


Thanks!
-- 
___
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

[Jean-Francois Dagenais]

Hi, so I did a bit of testing...

> On Apr 5, 2019, at 11:42, Jean-Francois Dagenais  
> wrote:
> 
>> It is trying to reset the PP, and fails. Can you check if the power islands 
>> are turned on. 
>> 
>> Can you tell me the output of the following:
>> Devmem 0xFD4B006C
>> Devmem 0xFD4B4004

# devmem2 0xFD4B006C
/dev/mem opened.
Memory mapped at address 0x7f9f5c6000.
Read at address  0xFD4B006C (0x7f9f5c606c): 0x0B070101
# devmem2 0xFD4B4004
/dev/mem opened.
Memory mapped at address 0x7fb7cc2000.
Bus error


I am looking at how to introspect the power island status... Is this a good 
place to start? 
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842232/Zynq+UltraScale+MPSoC+Power+Management+-+Linux+Kernel


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

[meta-xilinx] [meta-xilinx-bsp][PATCH 4/4] libmali-xlnx:gbm: make version recognizable

[Jean-Francois Dagenais]

Build systems (like meson), will look for >= of gbm pkg-config. "r8p0"
makes these systems choke and fail to recognize gbm completely.

The other .pc files next to gbm.pc suffer the same problem but have not
caused me problems yet.

17.2 is a best minimal guess when comparing gbm.h relative to the one in
mesa.

Signed-off-by: Jean-Francois Dagenais 
---
 meta-xilinx-bsp/recipes-graphics/libgles/files/gbm.pc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/files/gbm.pc 
b/meta-xilinx-bsp/recipes-graphics/libgles/files/gbm.pc
index 02ea94e..45c2df4 100644
--- a/meta-xilinx-bsp/recipes-graphics/libgles/files/gbm.pc
+++ b/meta-xilinx-bsp/recipes-graphics/libgles/files/gbm.pc
@@ -6,7 +6,7 @@ includedir=/usr/include
 Name: gbm
 Description: MALI gbm library
 Requires.private:
-Version: r8p0
+Version: 17.2
 Libs: -L${libdir} -lgbm
 Libs.private: -lm -lpthread -ldl
 Cflags: -I${includedir}
-- 
2.11.0

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

[meta-xilinx] [meta-xilinx-bsp][PATCH 3/4] libmali-xlnx: clean and fix FILESEXTRAPATHS

[Jean-Francois Dagenais]

Normally, when the colon ':' separator is on the right, the assignment
is meant to be prepended to the variable. Using the "_append" override
with both colon and spaces is an incoherent use of the FILESEXTRAPATH
variable:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-FILESEXTRAPATHS

Also removed the r8p0... path as it doesn't exist.

Signed-off-by: Jean-Francois Dagenais 
---
 meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb 
b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
index 9834816..fdcc064 100644
--- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
+++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
@@ -20,9 +20,7 @@ PROVIDES += "\
 virtual/libgbm \
 "
 
-FILESEXTRAPATHS_append := " \
-${THISDIR}/files: \
-${THISDIR}/r8p0-00rel0: "
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
 
 
 # Fetch the MALI 400 binaries from here
-- 
2.11.0

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

[meta-xilinx] [meta-xilinx-bsp][PATCH 1/4] libmali-xlnx: clean untar step

[Jean-Francois Dagenais]

Better describes what is happening in the recipe.

Signed-off-by: Jean-Francois Dagenais 
---
 meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb | 7 ++-
 1 file changed, 6 insertions(+), 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 8acc42e..5bf7d4d 100644
--- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
+++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
@@ -7,6 +7,10 @@ LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/Proprietary;md5=0557f9d92cf58f2
 inherit distro_features_check
 inherit xilinx-fetch-restricted
 
+# Skip the unwanted steps
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
 ANY_OF_DISTRO_FEATURES = "fbdev x11 wayland"
 
 PROVIDES += "\
@@ -65,10 +69,11 @@ USE_X11 = "${@bb.utils.contains("DISTRO_FEATURES", "x11", 
"yes", "no", d)}"
 USE_FB = "${@bb.utils.contains("DISTRO_FEATURES", "fbdev", "yes", "no", d)}"
 USE_WL = "${@bb.utils.contains("DISTRO_FEATURES", "wayland", "yes", "no", d)}"
 
-do_compile() {
+do_untar_bins() {
# Extract the MALI binaries into workdir
tar -xf ${WORKDIR}/mali/rel-v2018.3/r8p0-01rel0.tar -C ${S}
 }
+addtask untar_bins after do_unpack before do_install
 
 do_install() {
 #Identify the ARCH type
-- 
2.11.0

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

[meta-xilinx] misc libmali-xlnx fixes

[Jean-Francois Dagenais]

Hi guys,

I was working on updated versions of wayland on poky and ran into a coulple of
issues. This series adresses those and cleans certain things a bit.

The patches are not tightly coupled and can be cherry-picked.

Cheers!

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

[meta-xilinx] [meta-xilinx-bsp][PATCH 2/4] libmali-xlnx: remove libwayland-egl from archive

[Jean-Francois Dagenais]

>From wayland >= 1.15, it is provided by wayland and thus conflict
occurs.

Signed-off-by: Jean-Francois Dagenais 
---
 .../recipes-graphics/libgles/files/wayland-egl.pc| 12 
 meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb |  7 ---
 2 files changed, 4 insertions(+), 15 deletions(-)
 delete mode 100644 
meta-xilinx-bsp/recipes-graphics/libgles/files/wayland-egl.pc

diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/files/wayland-egl.pc 
b/meta-xilinx-bsp/recipes-graphics/libgles/files/wayland-egl.pc
deleted file mode 100644
index 719fb3e..000
--- a/meta-xilinx-bsp/recipes-graphics/libgles/files/wayland-egl.pc
+++ /dev/null
@@ -1,12 +0,0 @@
-prefix=/usr
-exec_prefix=${prefix}
-libdir=/usr/lib
-includedir=/usr/include
-
-Name: wayland-egl
-Description: MALI wayland-egl library
-Requires.private:
-Version: r8p0
-Libs: -L${libdir} -lwayland-egl
-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
index 5bf7d4d..9834816 100644
--- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
+++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
@@ -18,7 +18,6 @@ PROVIDES += "\
 virtual/libgles2 \
 virtual/egl \
 virtual/libgbm \
-virtual/libwayland-egl \
 "
 
 FILESEXTRAPATHS_append := " \
@@ -36,7 +35,6 @@ SRC_URI = " \
 file://glesv1_cm.pc \
 file://glesv1.pc \
 file://glesv2.pc \
-file://wayland-egl.pc \
 file://gbm.pc \
 "
 
@@ -108,7 +106,6 @@ do_install() {
 if [ "${USE_WL}" = "yes" ]; then
install -m 0644 ${S}/${PV}/glesHeaders/GBM/gbm.h ${D}${includedir}/
install -m 0644 ${WORKDIR}/gbm.pc ${D}${libdir}/pkgconfig/gbm.pc
-   install -m 0644 ${WORKDIR}/wayland-egl.pc 
${D}${libdir}/pkgconfig/wayland-egl.pc
install -Dm 0644 ${S}/${PV}/${ARCH_PLATFORM_DIR}/wayland/libMali.so.8.0 
${D}${libdir}/wayland/libMali.so.8.0
ln -snf wayland/libMali.so.8.0 ${D}${libdir}/libMali.so.8.0
 elif [ "${USE_X11}" = "yes" ]; then
@@ -125,6 +122,10 @@ do_install() {
 if ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'false', 'true', d)}; 
then
 sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)$/#if (1)/' 
${D}${includedir}/EGL/eglplatform.h
 fi
+
+# libwayland-egl has been moved to wayland 1.15+
+rm -f ${D}${libdir}/libwayland-egl*
+rmdir --ignore-fail-on-non-empty ${D}${libdir}/pkgconfig
 }
 
 
-- 
2.11.0

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

[Jean-Francois Dagenais]

> On Apr 4, 2019, at 16:19, Madhurkiran Harikrishnan  
> wrote:
> 
> Hi JFD,
> 
> It is trying to reset the PP, and fails. Can you check if the power islands 
> are turned on. 
> 
> Can you tell me the output of the following:
> Devmem 0xFD4B006C
> Devmem 0xFD4B4004

Thanks for the support guys. I had to revert back to 4.14 for the time being.

I will get back on this in a bit and test this. Bear with me.

Talk in a couple of days...
-- 
___
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

[Jean-Francois Dagenais]

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

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.

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

[Jean-Francois Dagenais]

> On Apr 1, 2019, at 16:21, Manjukumar Harthikote Matha  
> wrote:
> 
> 
> Can you try with linux-xlnx master? https://github.com/Xilinx/linux-xlnx 
> 

I am only missing the last two commits: "revert spi..." and "zynqmp-reset defer 
probe..." Shouldn't matter right?

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

Any idea where to start? Could it be related to our handoff file?

Thanks.

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

[Jean-Francois Dagenais]

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

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

[  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 
>  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_memory_os_alloc-Remove-__GFP_COLD.patch |  33 +
> ...memory_secure-Add-header-file-dma-direct..patch |  34 +
> ...4-linux-mali_-timer-Get-rid-of-init_timer.patch | 156 +
> 4 files changed, 226 insertions(+)
> create mode 100644 
> meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0012-linux-mali_memory_os_alloc-Remove-__GFP_COLD.patch
> create mode 100644 
> meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0013-linux-mali_memory_secure-Add-header-file-dma-direct..patch
> create mode 100644 
> meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0014-linux-mali_-timer-Get-rid-of-init_timer.patch
> 

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

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

[Jean-Francois Dagenais]

Hi guys,

> On Mar 21, 2019, at 09:03, 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?

We also had a long standing performance test which only recently (2018.3) 
started acting up. Our drill down though showed that is seemed to have been 
related to previous write operations causing the internal eMMC chip's 
controller to perform outstanding background operations (BKOPS). We sort of 
worked around the problem by doing a full blkdiscard of the entire device 
(because we could) prior to the write test.

Not sure if it is related to your query but it might help.

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

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

[Jean-Francois Dagenais]

> On Mar 20, 2019, at 14:34, Jaewon Lee  wrote:
> 
> Hi Jean,
> 
> Just tested this again,  as long as the tarball is there in downloads, it 
> will not redownload.
> If it starts with a fresh tmp directory, xsct-tarball will reextract to 
> tmp/sysroots-xsct, but will not redownload tarball
> 
> Please check again

If I remember correctly, the problem with disabling the fetcher cache is that 
it will bypass mirrors as well. Mirrors would typically be LAN local.

In any case, when downloading to the "downloads" folder, it is essential to 
include version numbers in the target file. Otherwise, when you'll update to 
2018.4 for example, fetcher will look in the local downloads folder and 
consider the "xsct.tar.xz" file as the correct file. Then only your manual 
xsct-tarbal.bbclass hash will detect the file as incorrect and re-download it, 
from the original URL.

So if you had 2 build directories, say one using v2018.3 and the other v2018.4, 
and both build directories pointing to the same download directory (which is 
common and recommended even), then the builds in each would fight over the 
common file in downloads/xsct/xsct.tar.xz and constantly overwrite it with the 
"correct" version.

This is what the "downloadfilename" SRC_URI flag is for. I assumed you had to 
add the "cache = False" because you had trouble with this. If not, then why 
would you want to disable the nice cache feature of the bitbake fetcher?

I would strongly recommend applying my patch before you guys release 2018.4! ;)

Cheers!

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

Re: [meta-xilinx] [meta-xilinx-bsp][RFC] libmali: Use update-alternatives to switch between GL backends

[Jean-Francois Dagenais]

Hi guys,

Thanks for your work on this...

> On Mar 13, 2019, at 14:26, Manjukumar Matha 
>  wrote:
> 
> From: Alejandro Enedino Hernandez Samaniego 
> 
> libmali provides GL backends based on x11, fbdev and wayland,
> we should be able to switch between them at runtime since it is
> the same ABI, it should only be a matter of loading the correct
> shared library by the interpreter (dynamic linker).
> 
> Use the update-alternatives class, to provide a way for the user
> to choose the desired backend at runtime, do this by setting
> priorities, the package with the highest priority will be chosen
> as default at build time, but it can easily be changed at runtime
> afterwards.
> This change implies that the libmali package will install all

Nitpicking: missing line between above paragraph separation.

> backends regardless of which one was chosen, but it will only use
> one as default.
> 
> Use the x11 backend by default at build time; given that it is
> the same ABI, applications which depend on libmali, can build
> regardless of the chosen backend at build time.

Mh. Since it doesn't make a difference at build time, perhaps using the
"headless" backend would be the better, lowest dependency, choice.

> 
> Update-alternatives uses a set of commands on the postinst
> scripts when creating the root filesystem, which basically create
> the soft link between the chosen alternative and the binary/library.
> This usually works seamlessly (for binaries), but it does not in the
> case of libraries, because ldconfig is run at the end of the
> do_rootfs task, and it removes the link that was just created,
> it is important to note that this is simply normal ldconfig behavior
> and its not something we can fix, so we defer execution of
> update-alternatives until the first boot, hence avoiding the link
> removal by ldconfig.
> 
> Switching backends at build time will also help to avoid longer
> build times, since it will only invalidate the do_package task,
> rebuilding an image after switching a backend (at build time)
> should only execute the do_package task along with the do_rootfs
> task.

Hooray!

> 
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> Signed-off-by: Manjukumar Matha 
> ---
> .../recipes-graphics/libgles/libmali-xlnx.bb   | 101 ++---
> 1 file changed, 67 insertions(+), 34 deletions(-)
> 
> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb 
> b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> index 504ea6d..7191c25 100644
> --- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
> @@ -4,9 +4,9 @@ LICENSE = "Proprietary"
> LICENSE_FLAGS = "xilinx"
> LIC_FILES_CHKSUM = "file://README.md;md5=d5750ae6496dd931669b454b5aaae2cd"
> 
> -inherit distro_features_check
> +inherit distro_features_check update-alternatives
> 
> -ANY_OF_DISTRO_FEATURES = "fbdev x11"
> +REQUIRED_DISTRO_FEATURES = "x11 fbdev wayland"
> 
> PROVIDES += "virtual/libgles1 virtual/libgles2 virtual/egl virtual/libgbm"
> 
> @@ -40,22 +40,14 @@ PACKAGE_ARCH = "${SOC_FAMILY}"
> 
> S = "${WORKDIR}/git"
> 
> -X11RDEPENDS = "libxdamage libxext libx11 libdrm libxfixes"
> -X11DEPENDS = "libxdamage libxext virtual/libx11 libdrm libxfixes"
> +# If were switching at runtime, we need all RDEPENDS needed for all backends 
> available
> +RDEPENDS_${PN} = " kernel-module-mali libxdamage libxext libx11 libdrm 
> libxfixes"

I believe this will install x11 libs in images even if one doesn't have "x11" in
DISTRO_FEATURES. This is my case and I would not use the recipe like this. I
would argue that typical embedded systems will choose in advance which of the
variant (x11, wayland, fbdev, headless) would be used and to keep things tight,
would expect unused libs and components not to make it to the rootfs. The cues
in DISTRO_FEATURES should be honoured as was the case in the recipe right now.

> 
> -RDEPENDS_${PN} = " \
> - kernel-module-mali \
> - ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '${X11RDEPENDS}', '', 
> d)} \
> - "
> +# We dont build anything but we want to avoid QA warning build-deps
> +DEPENDS = "wayland"

Won't this cause wayland libs to be built and installed on systems which don't
even have "wayland" in their DISTRO_FEATURES? I'm pretty sure there's a way to
clear those QA errors. I think the bin_package.bbclass is what you want here.
Certainly it is my opinion that since the recipe doesn't configure or compile it
doesn't need any extra DEPENDS, only RDEPENDS are required. If you use
bin_package.bbclass (and in any case in fact) the current "do_compile" should be
replaced by:

do_untar_bins() {
# Extract the MALI binaries into workdir tar -xf
${WORKDIR}/mali/rel-v2018.3/r8p0-01rel0.tar -C ${S}
} addtask untar_bins after do_unpack before do_install


> 
> -DEPENDS = "\
> - ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '${X11DEPENDS}', '', d)} 
> \
> - 

Re: [meta-xilinx] [meta-xilinx-bsp][RFC] layer.conf: Depend on openembedded-layer

[Jean-Francois Dagenais]

> On Mar 13, 2019, at 14:26, Manjukumar Matha 
>  wrote:
> 
> This layer depends on openembedded-layer for xf86 recipe.
> Add the layer dependency to meet the meta-xilinx layer needs.
> 
> Signed-off-by: Manjukumar Matha 
> ---
> meta-xilinx-bsp/conf/layer.conf | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/meta-xilinx-bsp/conf/layer.conf b/meta-xilinx-bsp/conf/layer.conf
> index fc51165..5631ee9 100644
> --- a/meta-xilinx-bsp/conf/layer.conf
> +++ b/meta-xilinx-bsp/conf/layer.conf
> @@ -10,6 +10,7 @@ BBFILE_PATTERN_xilinx = "^${LAYERDIR}/"
> BBFILE_PRIORITY_xilinx = "5"
> 
> LAYERDEPENDS_xilinx = "core"
> +LAYERDEPENDS_xilinx = "openembedded-layer"

It could be an idea to add this conditionally on "x11" being present in 
DISTRO_FEATURES?

> 
> LAYERSERIES_COMPAT_xilinx = "sumo thud"
> 
> -- 
> 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] [PATCH v2] kernel-module-mali: add patch to check dma_map_page error

[Jean-Francois Dagenais]

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\
"
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
new file mode 100644
index 000..5363c37
--- /dev/null
+++ 
b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0007-fix-driver-failed-to-check-map-error.patch
@@ -0,0 +1,17 @@
+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,10 @@ int mali_mem_os_alloc_pages(mali_mem_os_
+   /* Ensure page is flushed from CPU caches. */
+   dma_addr = dma_map_page(_platform_device->dev, new_page,
+   0, _MALI_OSK_MALI_PAGE_SIZE, 
DMA_BIDIRECTIONAL);
+-  dma_unmap_page(_platform_device->dev, dma_addr,
+- _MALI_OSK_MALI_PAGE_SIZE, DMA_BIDIRECTIONAL);
++  err = dma_mapping_error(_platform_device->dev, dma_addr);
++  if (likely(!err))
++  dma_unmap_page(_platform_device->dev, dma_addr,
++ _MALI_OSK_MALI_PAGE_SIZE, 
DMA_BIDIRECTIONAL);
+   dma_addr = dma_map_page(_platform_device->dev, new_page,
+   0, _MALI_OSK_MALI_PAGE_SIZE, 
DMA_BIDIRECTIONAL);
+ 
-- 
2.11.0

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

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

[Jean-Francois Dagenais]

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.

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

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

[Jean-Francois Dagenais]

Hi Hyun,

> On Feb 21, 2019, at 17:25, Hyun Kwon  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-driv

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

[Jean-Francois Dagenais]

Sorry, the subject should be:

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

instead of "dma_UNmap_page"

> On Feb 19, 2019, at 10:39, Jean-Francois Dagenais  
> 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 
> ---
> .../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 \
>   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
> 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 = dma_map_page(_platform_device->dev, new_page,
> + 0, _MALI_OSK_MALI_PAGE_SIZE, 
> DMA_BIDIRECTIONAL);
> +-dma_unmap_page(_platform_device->dev, dma_addr,
> +-   _MALI_OSK_MALI_PAGE_SIZE, DMA_BIDIRECTIONAL);
> ++if (!dma_mapping_error(_platform_device->dev, dma_addr))
> ++dma_unmap_page(_platform_device->dev, dma_addr,
> ++   _MALI_OSK_MALI_PAGE_SIZE, 
> DMA_BIDIRECTIONAL);
> + dma_addr = dma_map_page(_platform_device->dev, new_page,
> + 0, _MALI_OSK_MALI_PAGE_SIZE, 
> DMA_BIDIRECTIONAL);
> + 
> -- 
> 2.11.0
> 

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

[meta-xilinx] libmali and wayland

[Jean-Francois Dagenais]

There is a discussion started here:
https://github.com/Xilinx/meta-xilinx/pull/11/commits/2a00ba8b3e052732eb1c714bebc6f247aa474628#r258102571
about the new conflicts around libwayland-egl being provided/installed by both 
the libmali-xlnx recipe and the default wayland recipe from poky.

It would be nice to continue the discussion and the proposed patches on github 
directly... as teams do in 2019... wink wink! :P

Is Xilinx working on this?

Another suggestion: it would help if Xilinx could push --force to say a 
"master-next" branch so we can detect whether we should hack things on our own 
or if Xilinx is working on some of the issues we experience between releases.

Cheers all!
P.S. Anyone heading to San Diego for the Embedded Linux Conference? I am.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

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

[Jean-Francois Dagenais]

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 
---
 .../recipes-graphics/mali/kernel-module-mali.bb  |  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/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\
"
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
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 = dma_map_page(_platform_device->dev, new_page,
+   0, _MALI_OSK_MALI_PAGE_SIZE, 
DMA_BIDIRECTIONAL);
+-  dma_unmap_page(_platform_device->dev, dma_addr,
+- _MALI_OSK_MALI_PAGE_SIZE, DMA_BIDIRECTIONAL);
++  if (!dma_mapping_error(_platform_device->dev, dma_addr))
++  dma_unmap_page(_platform_device->dev, dma_addr,
++ _MALI_OSK_MALI_PAGE_SIZE, 
DMA_BIDIRECTIONAL);
+   dma_addr = dma_map_page(_platform_device->dev, new_page,
+   0, _MALI_OSK_MALI_PAGE_SIZE, 
DMA_BIDIRECTIONAL);
+ 
-- 
2.11.0

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

[meta-xilinx] mali-utgard DMA-API check map error

[Jean-Francois Dagenais]

Hi all,

Here's a patch which fixes a DMA-API debug check error I am getting.

I am not sure why I get this error once when our Qt based eglfs app starts.

Things work correctly after that. Frankly, I kind of blindly followed the
recommendation to check the map call error and skip the unmap if an error
occures. But why is the map causing the error in the first place?

This is why this patch comes with this intro. Basically, it would be wise if
Xilinx's display experts were to look at the issue.

Cheers!

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

Re: [meta-xilinx] yocto for pynq

[Jean-Francois Dagenais]

> On Feb 13, 2019, at 09:39, Ahmadmunthar Zaklouta  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] ZCU102 boot issue

[Jean-Francois Dagenais]

Hi guys,

> On Jan 28, 2019, at 14:39, Manjukumar Harthikote Matha  
> 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.

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

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

[Jean-Francois Dagenais]

> On Dec 19, 2018, at 8:12 PM, Manjukumar Matha 
>  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.

> 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 9/9] zynqmp-pmu: Remove class that uses a multilib hack to build standalone components

[Jean-Francois Dagenais]

> On Dec 12, 2018, at 3:21 AM, Martin Siegumfeldt  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

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

[Jean-Francois Dagenais]

> On Dec 6, 2018, at 4:56 PM, Alejandro Enedino Hernandez Samaniego 
>  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] [PATCH 1/9] binutils: rebase microblaze patches fro binutils 2.31

[Jean-Francois Dagenais]

typo in commit message: "fro" instead of "for"
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 4/9] Adds gcc bbappend to fix configure options, and enable --sysroot behavior

[Jean-Francois Dagenais]

> On Dec 7, 2018, at 6:23 AM, Jean-François Dagenais  
> wrote:
> 
> ... or "adds tests for" ;)

Sorry for this confusing addition after the quote...

So just in case, I meant you should use use "Add tests for..." instead of "Adds 
tests..."

I realize this might seem a bit picky, sorry... it just caught my attention.

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

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

[Jean-Francois Dagenais]

> On Jul 23, 2018, at 9:47 AM, 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?

Well, there's a recipe in m-x-t which compile the same (and only) PMUFW code 
using the xsct tools (Xilinx SDK "back-end"). Since the page you point to are 
using the Xilinx SDK GUI to perform the build, I would assume the m-x-t recipe 
matches that the closest.

I have not yet tried the m-x-bsp layer pmu fw recipe so I cannot offer much 
help as to what deviation one might expect. Perhaps other more experienced devs 
will chime in... Nathan perhaps?-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

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

[Jean-Francois Dagenais]

Hi Giordon,

> On Jul 19, 2018, at 8:58 AM, Giordon Stark  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!
-- 
___
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

[Jean-Francois Dagenais]

> On Jul 18, 2018, at 6:21 PM, Manjukumar Harthikote Matha 
>  wrote:
> 
> 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?

Hmmm... indeed!

I added this a year ago or so because upon re-running the do_configure task on 
xsctbase'd recipes, the xsct tools would react differently if it was a first 
run (empty ${B} dir), or a re-run on the same "workspace". Adding the manual 
cleaning of the directory fixed this and made the process solid and 
reproducible.

I guess you can apply the change to your tree and see if it makes sense to you. 
Or I can resend a clean patch if you prefer.

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

[meta-xilinx] libmali EGLDeviceExt support

[Jean-Francois Dagenais]

Hi all,

We have a dual screen setup running on top of xilinx/linux/4.14's new XLNX DRM 
(Thanks Hyun, great job with the refactor BTW). So far I can only set the dual 
display through the native KMS modetest command line.

Now we need to make Qt5 work. To make things clean, we thought we'd use the 
modern APIs for this, namely something like this: 
http://doc.qt.io/qt-5/embedded-linux.html#advanced-eglfs-kms-features in order 
to setup the cloned screens on /dev/dri/card0.

The problem is that the libMali provided binaries only use /dev/fb0 and the 
corresponding EGL header files are too old such that EGLDeviceEXT is not 
defined. Thus Qt's generic 
qtbase/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice will 
simply not work.

Is there any way xilinx will provide a updated libmali package? Or is there any 
other ways to use the MALI on top of EGLFS? We are trying, if possible, to 
avoid larger window frameworks such as X11 and wayland. And we are also under 
the impression, so far and perhaps falsely, that we cannot setup our screen 
cloning using the currently provided libmali-xlnx stack.

Thanks for any pointers.
/jfd


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

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

[Jean-Francois Dagenais]

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
> 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 well
> 
> Bye,
> -- 
> 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

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

[Jean-Francois Dagenais]

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

Re: [meta-xilinx] Working behind proxy issue

[Jean-Francois Dagenais]

> On Jun 27, 2018, at 3:19 AM, Gielmuda, Pawel (GE Aviation) 
>  wrote:
> 
> So I stuck in both of this methods and already look through the internet. Any 
> tip will be most helpful.  
> 

It looks like your corporate firewall is messing (in the middle style) with the 
SSL certificates that the servers (docker, apt, etc) are using. So either you 
add the certificate authority (a.k.a. Root Certificate) that the firewall is 
using to make the it's certificate to your trusted certificates (Google: 
"ubuntu add my corporate root certificate") or you completely bypass your 
firewall by connecting to a VPN tunnel service.

Try this google search maybe:
workaround firewall messing with certificates 


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

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

[Jean-Francois Dagenais]

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

Re: [meta-xilinx] [PATCH] bootbin: fix race condition in create_bif

[Jean-Francois Dagenais]

Hi Manju!

> On May 16, 2018, at 12:36 PM, Manjukumar Harthikote Matha 
>  wrote:
> 
> Will change python code to add  
> bootbindeps = bootbindeps + " " + attrdepends[cfg] + ":do_deploy" 
> instead of do_deploy in BIF_PARTITION_DEPENDS and apply it.

See the last part of my commit message. The reason I chose to do it like this is
explained. Essentially, when xilinx-bootbin.bb adds the "do_deploy" it assumes
that the source of BIF_ATTRIBUTE_xyz used a "DEPLOY_DIR" file. This creates an
unhealthy assumption, tightly couples xilinx-bootbin.bb and the BIF_ATTRIBUTE
assignments and makes the recipe more fragile.

If I were to use a file found in say ${STAGING_DIR_HOST}, then xilinx-bootbin.bb
would incorrectly add ":do_deploy" when in fact, ":do_populate_sysroot" should 
be
appended.

Putting the ":do_deploy" in xilinx-bootbin.bb sure means less characters 
overall, but
that doesn't mean it's objectively "better". ;)

I recommend leaving my patch as-is, i.e.  as I it was "signed-off".-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] [PATCH] bootbin: fix race condition in create_bif

[Jean-Francois Dagenais]

This problem was introduced by a622db96dd962c9a5ceb999ccd99da7ad7a40faf

>From documentation of DEPENDS variable:
[...]This mechanism is implemented by having do_configure depend on the
do_populate_sysroot task of each recipe listed in DEPENDS[...]

This is why the xilinx-bootbin:do_configure task can start as soon as
(for example) bitstream-extraction:do_populate_sysroot succeeds.
Consequently, bitstream-extraction:do_deploy may not have run yet when
xilinx-bootbin:do_configure (and create_bif) runs. The result is a
python stack trace pointing at line 'if os.stat(imagestr).st_size == 0:'
with an error which looks like this:

Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/builds/yocto/mymachine/tmp/deploy/images/mymachine/download-mymachine.bit'

A re-attempt of the build will ultimately succeed as the do_deploy of
each dependency is spawned in parallel and get to do their job.

Targeting the "do_deploy" steps specifically fixes the problem
completely.

The ':do_deploy' is added to the BIF_PARTITION_DEPENDS, otherwise, it
would force the files assigned to BIF_PARTITION_IMAGE to be in the
DEPLOY_DIR.

Signed-off-by: Jean-Francois Dagenais <jeff.dagen...@gmail.com>
---
 README.md |  6 +++---
 recipes-bsp/bootbin/machine-xilinx-zynq.inc   |  6 +++---
 recipes-bsp/bootbin/machine-xilinx-zynqmp.inc | 10 +-
 recipes-bsp/bootbin/xilinx-bootbin_1.0.bb |  2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/README.md b/README.md
index bd78938..f9f30c3 100644
--- a/README.md
+++ b/README.md
@@ -79,7 +79,7 @@ IMAGE_CLASSES += " xilinx-bootbin"
 BIF_PARTITION_ATTR= "fsbl u-boot"
 
 BIF_PARTITION_IMAGE[fsbl]="${DEPLOY_DIR_IMAGE}/fsbl-${MACHINE}.elf"
-BIF_PARTITION_DEPENDS[fsbl]="virtual/fsbl"
+BIF_PARTITION_DEPENDS[fsbl]="virtual/fsbl:do_deploy"
 
 BIF_PARTITION_IMAGE[u-boot]="${DEPLOY_DIR_IMAGE}/u-boot-${MACHINE}.elf"
 
@@ -95,11 +95,11 @@ BIF_PARTITION_ATTR= "fsbl pmu atf u-boot"
 
 BIF_PARTITION_ATTR[fsbl]="bootloader"
 BIF_PARTITION_IMAGE[fsbl]="${DEPLOY_DIR_IMAGE}/fsbl-${MACHINE}.elf"
-BIF_PARTITION_DEPENDS[fsbl]="virtual/fsbl"
+BIF_PARTITION_DEPENDS[fsbl]="virtual/fsbl:do_deploy"
 
 BIF_PARTITION_ATTR[pmu]="destination_cpu=pmu"
 BIF_PARTITION_IMAGE[pmu]="${DEPLOY_DIR_IMAGE}/pmu-${MACHINE}.elf"
-BIF_PARTITION_DEPENDS[pmu]="virtual/pmufw"
+BIF_PARTITION_DEPENDS[pmu]="virtual/pmufw:do_deploy"
 
 BIF_PARTITION_ATTR[atf]="destination_cpu=a53-0,exception_level=el-3,trustzone"
 
BIF_PARTITION_IMAGE[atf]="${DEPLOY_DIR_IMAGE}/arm-trusted-firmware-${TUNE_PKGARCH}.elf"
diff --git a/recipes-bsp/bootbin/machine-xilinx-zynq.inc 
b/recipes-bsp/bootbin/machine-xilinx-zynq.inc
index aa537d6..b8d75c4 100644
--- a/recipes-bsp/bootbin/machine-xilinx-zynq.inc
+++ b/recipes-bsp/bootbin/machine-xilinx-zynq.inc
@@ -5,13 +5,13 @@ BIF_PARTITION_ATTR ?= "fsbl bitstream u-boot"
 #bootloader is FSBL. Location where FSBL binary is present and dependency to 
build FSBL
 BIF_PARTITION_ATTR[fsbl] ?= "bootloader"
 BIF_PARTITION_IMAGE[fsbl] ?= "${DEPLOY_DIR_IMAGE}/fsbl-${MACHINE}.elf"
-BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl"
+BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl:do_deploy"
 
 #specify BIF partition attributes for u-boot
 #Location where u-boot binary is present
 BIF_PARTITION_IMAGE[u-boot] ?= "${DEPLOY_DIR_IMAGE}/u-boot-${MACHINE}.elf"
-BIF_PARTITION_DEPENDS[u-boot] ?= "virtual/bootloader"
+BIF_PARTITION_DEPENDS[u-boot] ?= "virtual/bootloader:do_deploy"
 
 # enable bitstream-Note this is not enabled by default (missing in 
BIF_PARTITION_ATTR)
 BIF_PARTITION_IMAGE[bitstream] ?= "${DEPLOY_DIR_IMAGE}/download-${MACHINE}.bit"
-BIF_PARTITION_DEPENDS[bitstream] ?= "virtual/bitstream"
+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 fe1b36c..3734880 100644
--- a/recipes-bsp/bootbin/machine-xilinx-zynqmp.inc
+++ b/recipes-bsp/bootbin/machine-xilinx-zynqmp.inc
@@ -8,27 +8,27 @@ BIF_PARTITION_ATTR ?= "fsbl bitstream pmu atf u-boot"
 # bootloader is FSBL. Location where FSBL binary is present and dependency to 
build FSBL
 BIF_PARTITION_ATTR[fsbl] ?= "bootloader, destination_cpu=a53-0"
 BIF_PARTITION_IMAGE[fsbl] ?= "${DEPLOY_DIR_IMAGE}/fsbl-${MACHINE}.elf"
-BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl"
+BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl:do_deploy"
 
 # specify BIF partition attributes for PMU Firmware
 # destination cpu for PMU. Location where PMU binary is present and dependency 
to build PMU Firmware
 BIF_PARTITION_ATTR[pmu] ?= "destination_cpu=pmu"
 BIF_PARTIT

Re: [meta-xilinx] How to patch fsbl

[Jean-Francois Dagenais]

> On May 2, 2018, at 6:39 AM, David Roman  wrote:
> 
> I'm using fsbl_git recipe from meta-xilinx-tools (branch rel-v2016.4) and 
> wanted to patch the fsbl_hooks.c source code. To do it I created a 
> fsbl_git.bbappend with the next two lines:
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> SRC_URI_append = " file://fsbl_hooks.patch"
> 
> but the file doesn't get patched, is there another way to patch it or modify 
> fsbl_hooks.c?

This is very standard yocto procedure:
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe

This answer is also good:
https://stackoverflow.com/questions/45584131/how-patching-works-in-yocto

You have to make sure your bbappend is it the same dir relative to the root of 
your layer.

If the patch is found and copied into the work dir of the fsbl recipe (i.e. 
build/tmp/work/yourmachine-poky-linux/fsbl/2018.1+gitAUTOINC+aaa566bc3f-r0/fsbl_hooks.patch
 ) it should try to apply it. If the patch is bad, it will fail the yocto build.

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH] recipes-multimedia/vcu/*.bb: Introduce hwcodec and required firmware, ko and software libraries for VCU

[Jean-Francois Dagenais]

> On Apr 30, 2018, at 3:30 AM, Nathan Rossi  wrote:
> 
> At the end of the day the filename matters very little assuming the PV
> is set in the recipe as that is the important value, especially for
> these recipes since its very likely there will only be one version
> available at a time. So you could just leave the version part of the
> recipe filename off entirely and just use e.g. "kernel-module-vcu.bb"
> (like kernel-module-mali).


I agree completely with Nathan here. Over time, we have also come to this exact
conclusion for our own private layers. Since we only carry one version at a time
of each of our recipes, and we set PV explicitly within each one, we keep the
_version.bb part completely out and only use recipe-name.bb.

Cheers!


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

Re: [meta-xilinx] [meta-xilinx-tools][PATCH 0/3] Use HOSTTOOLS for xlsclients and Xvfb dependencies

[Jean-Francois Dagenais]

Much cleaner! Thanks Manju!

reviewed-by: Jean-Francois Dagenais <jeff.dagen...@gmail.com>



> On Apr 23, 2018, at 7:24 PM, Manjukumar Matha 
> <manjukumar.harthikote-ma...@xilinx.com> wrote:
> 
> Use HOSTTOOLS for Xvfb and xlsclients dependency for xsct tool.  Previously 
> the
> paths were hardcoded in xsct preventing the use of HOSTTOOLS, this has been
> fixed from 2018.1 release. This patch series will revert the usage of /usr/bin
> path for bitbake and adds the requirement to have Xvfb and xlscient on the 
> host
> system.
> 
> Manjukumar Matha (3):
>  Revert "xsct-tc: append the local system's /usr/bin dir as Xvfb
>fallback"
>  layer.conf: Add Xvfb and xlsclients to HOSTTOOLS
>  README.md : Add the requirements of Xvfb and xlsclients
> 
> README.md   | 12 
> classes/xsct-tc.bbclass |  1 -
> conf/layer.conf |  2 +-
> 3 files changed, 5 insertions(+), 10 deletions(-)
> 
> -- 
> 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] Cannot load VFS from SDCard partitioned using wic

[Jean-Francois Dagenais]

> On Feb 25, 2018, at 15:34, Giordon Stark  wrote:
> 
> I used the wic file created to flash an SD card using dd. I also copied 
> system.dtb and created a BOOT.bin to copy into the first (boot) partition. 
> However, the SD card seems readable, and shows the right partitions.. but I 
> still cannot get the kernel to load the FS from it?
> 

Hi Giordon,

In my experience on our board, the SD is quite finicky. For me it boiled down 
to certain SD cards that will work and others that don't. Of course there may 
be underlying issue, but we have not pinpointed them just yet. As a workaround, 
we simply avoid the "bad" SD cards. Maybe try lower speed cards.

As for manually copying files on the wic generated sdcard image, you shouldn't 
have to do this.

Here's a wic file I created for this purpose (there's another pretty similar in 
poky, we use this because we need extra space in the first partition) :

$ cat ./scripts/lib/wic/canned-wks/zynq-wic-sdcard.wks
# short-description: Create SD card image with a boot partition
# long-description: Creates a partitioned SD card image. Boot files
# are located in the first vfat partition.

# !! the partition alignment must match that found in test files
# we add 6MB to the boot partition to allow devs to copy a fpga.bin for example
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label 
ZBOOT --active --align 4096 --extra-space 6
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs  --align 
4096 --extra-space 


Of course, I use my patch for boot.bin as a normal recipe:
https://www.mail-archive.com/meta-xilinx@yoctoproject.org/msg02179.html

Here's my slightly different version of the file:
SUMMARY = "Generates boot.bin using bootgen tool"
DESCRIPTION = "Manages task dependencies and creation of boot.bin. Use the \
BIF_PARTITION_xyz global variables and flags to determine what makes it into \
the image."

LICENSE = "BSD"

include machine-xilinx-${SOC_FAMILY}.inc

inherit xsct-tc deploy

PROVIDES = "virtual/boot-bin"

PACKAGE_ARCH = "${MACHINE_ARCH}"

BIF_FILE_PATH ?= "${B}/bootgen.bif"
BIF_FILE_PATH = "${WORKDIR}/bootgen.bif"

# this recipe is almost like an image recipe, taken from image.bbclass:
inherit nopackages
deltask do_fetch
deltask do_unpack
deltask do_patch
do_install[noexec] = "1"

def create_bif(config, attrflags, attrimage, common_attr, biffd, d):
import re, os
for cfg in config:
if cfg not in attrflags and common_attr:
error_msg = "%s: invalid ATTRIBUTE" % (cfg)
bb.error("BIF attribute Error: %s " % (error_msg))
else:
if common_attr:
cfgval = attrflags[cfg].split(',')
cfgstr = "\t [%s] %s\n" % (cfg,', '.join(cfgval))
else:
if cfg not in attrimage:
error_msg = "%s: invalid or missing elf or image" % (cfg)
bb.error("BIF atrribute Error: %s " % (error_msg))
imagestr = d.expand(attrimage[cfg])
if os.stat(imagestr).st_size == 0:
bb.warn("Empty file %s, excluding from bif file" 
%(imagestr))
continue
if cfg in attrflags:
cfgval = attrflags[cfg].split(',')
cfgstr = "\t [%s] %s\n" % (', '.join(cfgval), imagestr)
else:
cfgstr = "\t %s\n" % (imagestr)
biffd.write(cfgstr)

return

python do_configure() {

fp = d.getVar("BIF_FILE_PATH", True)
biffd = open(fp, 'w')
biffd.write("the_ROM_image:\n")
biffd.write("{\n")

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)

bifpartition = (d.getVar("BIF_PARTITION_ATTR", 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)

biffd.write("}")
biffd.close()
}

do_configure[vardeps] += "BIF_PARTITION_ATTR BIF_PARTITION_IMAGE 
BIF_COMMON_ATTR"
do_configure[depends] += "${@get_bootbin_depends(d)}"

def get_bootbin_depends(d):
bootbindeps = ""
bifpartition = (d.getVar("BIF_PARTITION_ATTR", True) or "").split()
attrdepends = d.getVarFlags("BIF_PARTITION_DEPENDS") or {}
for cfg in bifpartition:
if cfg in attrdepends:
bootbindeps = bootbindeps + " " + attrdepends[cfg] + ":do_deploy"

return bootbindeps


do_compile() {
cd ${WORKDIR}
rm -f ${B}/BOOT.bin
bootgen -image ${BIF_FILE_PATH} -arch ${SOC_FAMILY} -w -o ${B}/BOOT.bin
if [ ! -e ${B}/BOOT.bin ]; then
bbfatal "bootgen failed. See log"
fi
}

BOOTBIN_BASE_NAME ?= "BOOT-${MACHINE}-${DATETIME}"
BOOTBIN_BASE_NAME[vardepsexclude] = "DATETIME"

do_deploy() {
install -d ${DEPLOYDIR}
 

Re: [meta-xilinx] Using wic to generate sd-image and writing it correctly

[Jean-Francois Dagenais]

> On Feb 20, 2018, at 16:29, Giordon Stark  wrote:
> 
> 
> The script looks formatted weird in my email, but how is this script run or 
> where? Is it part of bitbake, or separately? Do you use the wic output file, 
> etc...?
> 
> 

Sorry about that, that'll teach me to think I can get away with a quick answer 
from an iPhone.

Here again:

if $IS_SD_CARD; then
printWarning "adjusting sdcard's partitions"
set +e
command="sudo partprobe /dev/$DEVICE"
echo "$command"; $command
sudo udevadm settle
command="sudo e2fsck -f /dev/${DEVICE}2"
echo "$command"; $command
command="sudo parted /dev/${DEVICE} resizepart 2 '100%'"
echo "$command"; $command
sudo udevadm settle
command="sudo resize2fs /dev/${DEVICE}2"
echo "$command"; $command
set -e

sync
fi



Sow we use a wrapper script called "writewic 
/path/to/tmp/image/deploy/myimage.wic /dev/sdX". It is invoked completely 
outside bitbake, post image build.

It will raw write (using dd or the like) to the device, then run the bit I 
pasted above.

I think this should/could be part of the poky/scripts directory as it is 
generic code which anybody could use. (I didn't check if someone already did 
something like this in there or in poky-contrib)

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

Re: [meta-xilinx] [meta-xilinx-tools][PATCH] xilinx-bootbin: Convert to recipe instead of bbclass

[Jean-Francois Dagenais]

> On Jan 8, 2018, at 16:48, Manjukumar Harthikote Matha  
> wrote:
> 
> I would like to keep packaging, will send a v2 to skip tasks as you have 
> mentioned below. 

Ok... but what is packaged? There is no "do_install"... am I missing something?

Anyway, your call!
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] How to boot the ZynqMP?

[Jean-Francois Dagenais]

> On Aug 21, 2017, at 04:20, Mike Looijmans  wrote:
> 
> 
> I recall having done this stuff about half a year ago, and at least then I 
> could create an SPL based loader that actually booted. The layer above looks 
> like regression to me.

Xilinx "official" support is in FSBL for zynqmp. They removed the SPL zynqmp 
stuff from their u-boot fork if I am not mistaken. And they configure 
everything using their own stack including other layers such as meta-linaro and 
meta-petalinux.

> 
> Current state is that if I generate FSBL using Vivado SDK I can make it load 
> u-boot by generating a boot.bin containing the FSBL and u-boot.elf. But then 
> I don't have the PMU firmware and ATF and thus the kernel won't run.

Had the same problem. This is because we are hanging on to the old trail 
(without the extra layers Xilinx wants us to use).

> 
> I tried putting ATF and PMU firmware from the meta-xilinx build into the 
> boot.bin using the proper attributes, but that results in complete and utter 
> quiet hangup after power-up. I only see the FSBL start message on the uart.

I had to fork a machine from zcu102 in u-boot (so I forked u-boot-xlnx) in my 
env. Also forked meta-xilinx-tools such that my machine does the same 
configuration of xilinx-bootbin as zcu102 so the ATF and PMU firmware are 
bundled inside boot.bin. My fork of 
u-boot-xlnx/include/configs/xilinx_zynqmp_zcu102.h is where I tie it all 
together with the right file names for linux image and dtb to match what I have 
put into the partition using wic, and the default names that yocto uses for 
those.

It was a bit of a hassle, and a annoyance compared to the ease of build of the 
zynq7 series board, but in the end, learned a lot and am more than ever the 
master of my domain! ;)

Hope this helps a bit.
Cheers!
/jfd

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

Re: [meta-xilinx] How to boot the ZynqMP?

[Jean-Francois Dagenais]

Hi Mike,

> On Aug 18, 2017, at 08:25, Mike Looijmans  wrote:
> 
> I have a zcu102 board. I built "core-image-minimal" for the board. This 
> succeeded. Now I have a bunch of files in the image deploy directory.
> 
> What do I do with these files to boot the board from an SD card?
> 
> For the Zynq, one needed boot.bin, u-boot.img and uImage.
> 
> For the zynqmp, there's also the arm-trusted-firmware and pmu-firmware. I 
> have no idea whatsoever what I'm supposed to do with these. There is no 
> boot.bin at all.
> 
> 
> The wiki pages aren't any help either, they're either outdated or just plain 
> wrong.
> 

Yeah, on zynq7, things were simpler with u-boot providing both the SPL (or 
first stage boot.bin file), and the proper u-boot loader for the kernel. Things 
were all nicely tied together. Now, one has to tie a few knots to get 
"burnable" products ready-made by yocto.

Take a look at https://github.com/Xilinx/meta-xilinx-tools/blob/master/README.md

Basically, I switched to meta-xilinx-tools. This wasn't pretty since I am bound 
to building everything in docker containers through gitlab-ci. I finally 
managed to get things working the way we need it to.

It's not a pretty tool stack, the Xilinx SDK is pretty hacky (cmd line tools 
have dependencies to X11 and run a fake gui to execute commands), but the trail 
is pretty beaten by now and most of the kinks have been run over a number of 
times! ;)

Basically, through IMAGE_CLASSES, xilinx-bootbin tasks are added to every 
images (which is being debated on meta-xilinx now, I submitted a patch where 
xilinx-bootbin becomes a proper recipe). Anyway, once you have the boot.bin, 
simply copying it to the first fat partition of SD (or eMMC) is good enough. I 
use a slightly modified version of 
http://git.yoctoproject.org/cgit.cgi/poky/tree/scripts/lib/wic/canned-wks/sdimage-bootpart.wks
 where I add more files to the boot partition:


I made zynq-wic-sdcard.bbclass automatically inherited by all images through 
IMAGE_CLASSES with this content:

WKS_FILES = "zynq-wic-sdcard.wks"
IMAGE_DEPENDS_wic += "dosfstools-native mtools-native e2fsprogs-native"

do_image_wic[depends] += "\
xilinx-bootbin:do_deploy \
"

python () {
initRdImage = d.getVar("INITRD_IMAGE", True)
if initRdImage:
d.appendVarFlag("do_image_wic", "depends", " " + initRdImage + 
":do_image_complete")
}

IMAGE_CMD_wic_append() {
cd ${DEPLOY_DIR_IMAGE}

ln -sfv ${IMAGE_LINK_NAME}.wic.lz4 ${IMAGE_LINK_NAME}.sdcard.lz4
}

===
And here's zynq-wic-sdcard.wks:

# short-description: Create SD card image with a boot partition
# long-description: Creates a partitioned SD card image. Boot files
# are located in the first vfat partition.

# !! the partition alignment must match that found in test files
# we add 6MB to the boot partition to allow devs to copy a fpga.bin for example
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label 
ZBOOT --active --align 4096 --extra-space 6
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs  --align 
4096 --extra-space 5




You can find my patch on meta-xilinx which turns xilinx-bootbin into a recipe 
(https://www.mail-archive.com/meta-xilinx@yoctoproject.org/msg01664.html). This 
is for the do_image_wic[depends] += "xilinx-bootbin:do_deploy" to work ;)

Enjoy!

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

Re: [meta-xilinx] ZynqMP XADC in default DTS?

[Jean-Francois Dagenais]

> On Jul 19, 2017, at 16:00, Giordon Stark  wrote:
> 
> Thanks J-F! We suspected it was a missing addition to the DTS so I'll 
> probably synthesize a new block design with the hwmon included.

Yeah our firmware guys added a new block for that, hence the override of the 
"reg" property in my "ams_pl" node. But this was to get the customizable 
channels if I remember correctly.

> 
> Any chance this was documented somewhere -- because this isn't obvious.
> 

It wasn't obvious but figure 9-1 of the TRM (ug1085) with the  "PL Fabric" box 
was what clued them into what we thought was the correct way to do it. The 
documentation is indeed lacking in this area.

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

Re: [meta-xilinx] [PATCH 4/7] xilinx-bootbin: convert to a normal recipe

[Jean-Francois Dagenais]

> On Jul 18, 2017, at 17:59, Manjukumar Harthikote Matha 
>  wrote:
> 
> Added EXTRA_IMAGEDEPENDS += "xilinx-bootbin" so that it always builds boot.bin
> 

I had meditated on this approach. Problem is this will trigger a build of
xilinx-bootbin when one is trying to bake an initrd or squashfs image recipe
which is pointless. It really comes down to the type of image the user is trying
to bake. In the end I felt it was up to developers to define this dependency. I
personnaly use the SD/eMMC boot paths so I declare that my wic image depends on
xilinx-bootbin:do_deploy (like I mentioned in the commit msg). There are only
2-3 other boot paths for zynq so there may be a way to clearly define each one
with it's pull on xilinx-bootbin.

We could add machine specific (e.g.  for each supported zynqmps?

For example, I've made my own image class:

WKS_FILES = "zynq-wic-sdcard.wks"
IMAGE_DEPENDS_wic += "dosfstools-native mtools-native e2fsprogs-native"

do_image_wic[depends] += "\
xilinx-bootbin:do_deploy \
"

python () {
initRdImage = d.getVar("INITRD_IMAGE", True)
if initRdImage:
d.appendVarFlag("do_image_wic", "depends", " " + initRdImage + 
":do_image_complete")
}

IMAGE_CMD_wic_append() {
cd ${DEPLOY_DIR_IMAGE}

ln -sfv ${IMAGE_LINK_NAME}.wic.lz4 ${IMAGE_LINK_NAME}.sdcard.lz4
}



The class is written such that it doesn't trigger any change in behaviour for
initrds.

==
in my machine.conf:
IMAGE_CLASSES += "zynq-wic-sdcard"

==
And here's the kickstart file for reference (fork of sdimage-bootpart.wks)
# short-description: Create SD card image with a boot partition
# long-description: Creates a partitioned SD card image. Boot files
# are located in the first vfat partition.

# !! the partition alignment must match that found in test files
# we add 6MB to the boot partition to allow devs to copy a fpga.bin for example
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label 
ZBOOT --active --align 4096 --extra-space 6
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label rootfs  --align 
4096 --extra-space 5




I really hope we can make this patch work as I truly reflects better the nature
of xilinx-bootbin... and fixes a race when building more than one image (which
is as common as simply having an initrd as a dependency of another boot image).

>> +
>> +python do_configure() {
>> +
> 
> Trying to see if we can get rid of "python" keyword here.
> This will be consistent like other recipes in Yocto.

That's fine. This is there only because I renamed the bbclass to a bb. I have no
strong opinion of it.

Cheers!

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

Re: [meta-xilinx] [PATCH 4/7] xilinx-bootbin: convert to a normal recipe

[Jean-Francois Dagenais]

Hey guys,

No one sent any feedback on this one. This is one of the highest priority 
patches in the
series.


> On Jul 6, 2017, at 13:16, Jean-Francois Dagenais <jeff.dagen...@gmail.com> 
> wrote:
> 
> The BOOT.bin product cannot be made by a task attached to every image
> recipe like it is now because it means that each image recipe built,
> wheather sequencially or in parallel, will compete to overwrite the
> same BOOT.bin file in the DEPLOY_DIR_IMAGE directory.
> 
> Plus, doing the boot.bin while making an initramfs makes no sense.
> 
> Instead, the BOOT.bin product as a recipe on it's own, will behave
> better in the yocto build system.
> 
> The recipe can be triggered through normal depencency at machine level,
> or as part of image_types dependencies, etc.
> 
> For a wic made sdcard image, something like this works well at the:
> machine scope:
> 
> do_image_wic[depends] += "\
> xilinx-bootbin:do_deploy \
> "
> IMAGE_BOOT_FILES = "\
>   BOOT.bin \
> ...
> "
> 
> Signed-off-by: Jean-Francois Dagenais <jeff.dagen...@gmail.com>
> ---
> classes/xilinx-bootbin.bbclass |  83 ---
> conf/machine/include/machine-xilinx-zynqmp.inc |   2 -
> recipes-bsp/bootbin/xilinx-bootbin_1.0.bb  | 105 +
> 3 files changed, 105 insertions(+), 85 deletions(-)
> delete mode 100644 classes/xilinx-bootbin.bbclass
> create mode 100644 recipes-bsp/bootbin/xilinx-bootbin_1.0.bb
> 
> diff --git a/classes/xilinx-bootbin.bbclass b/classes/xilinx-bootbin.bbclass
> deleted file mode 100644
> index db2235b..000
> --- a/classes/xilinx-bootbin.bbclass
> +++ /dev/null
> @@ -1,83 +0,0 @@
> -inherit xsct-tc
> -
> -BIF_COMMON_ATTR ?= ''
> -BIF_PARTITION_ATTR ?= ''
> -BIF_PARTITION_IMAGE ?= ''
> -BIF_PARTITION_DEPENDS ?= ''
> -BIF_FILE_PATH = "${WORKDIR}/bootgen.bif"
> -
> -def create_bif(config, attrflags, attrimage, common_attr, biffd, d):
> -import re, os
> -for cfg in config:
> -if cfg not in attrflags and common_attr:
> -error_msg = "%s: invalid ATTRIBUTE" % (cfg)
> -bb.error("BIF attribute Error: %s " % (error_msg))
> -else:
> -if common_attr:
> -cfgval = attrflags[cfg].split(',')
> -cfgstr = "\t [%s] %s\n" % (cfg,', '.join(cfgval))
> -else:
> -if cfg not in attrimage:
> -error_msg = "%s: invalid or missing elf or image" % (cfg)
> -bb.error("BIF atrribute Error: %s " % (error_msg))
> -imagestr = d.expand(attrimage[cfg])
> -if os.stat(imagestr).st_size == 0:
> -bb.warn("Empty file %s, excluding from bif file" 
> %(imagestr))
> -continue
> -if cfg in attrflags:
> -cfgval = attrflags[cfg].split(',')
> -cfgstr = "\t [%s] %s\n" % (', '.join(cfgval), imagestr)
> -else:
> -cfgstr = "\t %s\n" % (imagestr)
> -biffd.write(cfgstr)
> -
> -return
> -
> -python do_create_bif() {
> -
> -fp = d.getVar("BIF_FILE_PATH", True)
> -biffd = open(fp, 'w')
> -biffd.write("the_ROM_image:\n")
> -biffd.write("{\n")
> -
> -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)
> -
> -bifpartition = (d.getVar("BIF_PARTITION_ATTR", 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)
> -
> -biffd.write("}")
> -biffd.close()
> -}
> -addtask do_create_bif after do_image_complete before do_xilinx_bootbin
> -
> -do_create_bif[vardeps] += "BIF_PARTITION_ATTR BIF_PARTITION_IMAGE 
> BIF_COMMON_ATTR"
> -do_create_bif[depends] += "${@get_bootbin_depends(d)}"
> -
> -def get_bootbin_depends(d):
> -bootbindeps = ""
> -bifpartition = (d.getVar("BIF_PARTITION_ATTR", True) or "").split()
> -attrdepends = d.getVarFlags("BIF_PARTITION_DEPENDS") or {}
> -for cfg in bifpartition:
> -if cfg in attrdepends:
> -bootbindeps = bootbindeps + " " + attrdepends[cfg] +

Re: [meta-xilinx] [PATCH 3/7] xsct-tc: append the local system's /usr/bin dir as Xvfb fallback

[Jean-Francois Dagenais]

> On Jul 7, 2017, at 18:02, Manjukumar Harthikote Matha 
>  wrote:
> 
> xsct in general requires xvfb to be installed on your host, I don't think it 
> works without it.
> I am assuming you encountered the issue where it complained about xvfb not 
> available.
> We tested our distro removing X11 as well (in case of microblaze) and we did 
> not encounter this issue but that might be due to the fact that xvfb was 
> installed on our host machine.

Mmmh. My case involves running my yocto build from a docker container. The 
docker image I prepared for xsct had to contain xvfb as well as a couple of 
libs and tools not found in a bare, non desktop, distro install:

FROM {our generic, non meta-xilinx-tools, yocto docker image}

RUN apt-get update\
 && apt-get -y upgrade\
 && apt-get install --no-install-recommends --no-install-suggests -y \
lib32z1 \
libgtk2.0-0 \
x11-utils\
xvfb \
 && apt-get clean \
 && apt-get autoremove



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

Re: [meta-xilinx] [PATCH 6/7] xsctbase: rebuild all products when XILINX_VER_MAIN changes

[Jean-Francois Dagenais]

> On Jul 8, 2017, at 12:41, Manjukumar Harthikote Matha 
>  wrote:
> 
> Agreed, let me look into it, there might be a way to find the tool version 
> from HDF and compare it with
> XILINX_VER_MAIN

There is! In xsct-ts.bbclass:

python do_xsct_setup () {

XILINX_XSCT_VERSION = xsct_get_version(d)
XILINX_REQ_VERSION = d.getVar("XILINX_VER_MAIN", True)
if XILINX_XSCT_VERSION != XILINX_REQ_VERSION:
bb.fatal("XSCT version does not match. Version is %s: checking for %s " 
% (XILINX_XSCT_VERSION,XILINX_REQ_VERSION))

bb.note("XSCT is valid, version is %s" % XILINX_XSCT_VERSION)
}


All that's left is to compare the version found in the HDF, and compare it with 
xsct like above.

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

Re: [meta-xilinx] [PATCH 5/7] xsctyaml: explicitely wait for do_prepare_recipy_sysroot before create_yaml

[Jean-Francois Dagenais]

> On Jul 7, 2017, at 17:46, Manjukumar Harthikote Matha 
>  wrote:
> 
>> 
>> This is an attempt at fixing a rare/irreproducible do_create_yaml failure 
>> where hard
>> link creation are failing.
>> 
> 
> 
> Can you let me know what the failure was? Was is not creating the yaml file?


Sorry, I leaked this patch. It wasn't suppose to be submitted. I was a bit 
overwhelmed by all the repo*patchsets I had to submit!

We are seeing do_create_yaml where during do_prepare_recipe_sysroot, some 
python os.link (creation of hard-links for recipe-sysroot) calls would fail 
with "file exists" and "no such file or directory". A retry succeeds. :-/

I am hosting my yocto work directory on an unsupported filesystem (a zfs 
dataset, ssshhh... :-P) so it might be related, I'll eventually get to the 
bottom of it.

In any case, disregard this one for now!

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

Re: [meta-xilinx] [PATCH 3/7] xsct-tc: append the local system's /usr/bin dir as Xvfb fallback

[Jean-Francois Dagenais]

> On Jul 7, 2017, at 17:14, Manjukumar Harthikote Matha 
>  wrote:
> 
> I will check with team here on this requirement. I am not sure if it is a 
> right idea to include /usr/bin in the PATH variable as of now. Maybe there is 
> a way to append this in local.conf or set it in your local PATH

I understand your concern. This was by far a comfortable change to make...

I have to say though, it is also a bad idea to invoke an x11 server to run a 
command-line compiler!! :-P

There are probably other pretty yocto-style ways to do this, I just couldn't 
find them. The major point of my submission was to reveal the fact that when a 
build doesn't have "x11" in the DISTRO_FEATURES, the xsct tools fail to launch!

This is not a local build (local.conf) related quirk, but a distro related 
choice. That is why in my opinion, local.conf is not suited for this solution. 
Of course, anything that can be put in a local.conf will also work in the 
distro conf file.

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

Re: [meta-xilinx] [PATCH 4/7] xilinx-bootbin: convert to a normal recipe

[Jean-Francois Dagenais]

> On Jul 6, 2017, at 13:16, Jean-Francois Dagenais <jeff.dagen...@gmail.com> 
> wrote:
> 
> +addtask do_deploy before do_build after do_compile
> +
> +#do_build[depends] += "${PN}:do_deploy"
> -- 
> 2.1.4
> 

Sorry, left a commented line in there.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx