date:20170818

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

2017-08-18 Thread Mike Looijmans


On 17-08-17 23:57, Nathan Rossi wrote:

On 17 August 2017 at 23:12, Mike Looijmans  wrote:

I'm attempting to revive my build for the MPSOC machines. If one does
something like this:

MACHINE=zcu102-zynqmp bitbake my-image

I get parsing errors like:

ERROR: ExpansionError during parsing /home/mike/projects/@@@.bb
Traceback (most recent call last):

...

bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression
was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
Fetcher failure: The SRCREV_FORMAT variable must be set when multiple SCMs
are used.


Looks like a very odd failure, unfortunately I cannot reproduce with
pyro or master on recipes that use version control or dynamic SRCREV
features. Could you provide some build config info and if possible the
recipe that is generating the error?


I made a "bare" clone of oe-core, meta-oe and meta-xilinx. Ran a build, which 
went okay.


I copied this recipe into meta-xilinx for parsing, and got the error:

(topic-miami-monitor-lib.bb, fetches a C program from github)

...

SUMMARY = "Example and/or library for reading SOM monitor devices"
LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=9eef91148a9b14ec7f9df333daebc746"


GITHUB_TOPIC_URI ?= "git://github.com/topic-embedded-products"
SRC_URI = "${GITHUB_TOPIC_URI}/${PN}"

SRCREV = "ef7db896aa7282626431f7ab6723a9a9d62aea93"

inherit gitpkgv

PV = "0+${SRCPV}"
PKGV = "0+${GITPKGV}"
S = "${WORKDIR}/git"


do_install() {
install -d ${D}${bindir}
install -m 755 ${B}/topic-miami-monitor-example ${D}${bindir}
}

...

ERROR: ExpansionError during parsing 
/home/mike/projects/xilinx-platform/meta-xilinx/recipes-test/topic/topic-miami-monitor-lib.bb

Traceback (most recent call last):
  File "/home/mike/projects/xilinx-platform/bitbake/lib/bb/data_smart.py", 
line 412, in DataSmart.expandWithRefs(s='0+${SRCPV}', varname='PV'):

 try:
>s = __expand_var_regexp__.sub(varparse.var_sub, s)
 try:
  File "/home/mike/projects/xilinx-platform/bitbake/lib/bb/data_smart.py", 
line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(2, 10), 
match='${SRCPV}'>):

 else:
>var = self.d.getVarFlag(key, "_content")
 self.references.add(key)
  File "/home/mike/projects/xilinx-platform/bitbake/lib/bb/data_smart.py", 
line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
noweakdefault=False, parsing=False):

 cachename = var + "[" + flag + "]"
>value = self.expand(value, cachename)

  File "/home/mike/projects/xilinx-platform/bitbake/lib/bb/data_smart.py", 
line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', varname='SRCPV'):

 def expand(self, s, varname = None):
>return self.expandWithRefs(s, varname).value

  File "/home/mike/projects/xilinx-platform/bitbake/lib/bb/data_smart.py", 
line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
varname='SRCPV'):

 except Exception as exc:
>raise ExpansionError(varname, s, exc) from exc

bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was 
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
failure: The SRCREV_FORMAT variable must be set when multiple SCMs are used.



...

mike:~/projects/xilinx-platform/build$ cat conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"

# Top dir is three dirs back
LAYERTOPDIR := 
"${@os.path.dirname(os.path.dirname(os.path.dirname(d.getVar('FILE', True}"


BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS = " \
  ${LAYERTOPDIR}/oe-core/meta \
  ${LAYERTOPDIR}/meta-oe/meta-oe \
  ${LAYERTOPDIR}/meta-xilinx \
  "



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

[meta-xilinx] How to boot the ZynqMP?

2017-08-18 Thread Mike Looijmans

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.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

2017-08-18 Thread Nathan Rossi

On 18 August 2017 at 19:22, Mike Looijmans  wrote:
> On 17-08-17 23:57, Nathan Rossi wrote:
>>
>> On 17 August 2017 at 23:12, Mike Looijmans 
>> wrote:
>>>
>>> I'm attempting to revive my build for the MPSOC machines. If one does
>>> something like this:
>>>
>>> MACHINE=zcu102-zynqmp bitbake my-image
>>>
>>> I get parsing errors like:
>>>
>>> ERROR: ExpansionError during parsing /home/mike/projects/@@@.bb
>>> Traceback (most recent call last):
>
> ...
>>>
>>> bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
>>> expression
>>> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
>>> Fetcher failure: The SRCREV_FORMAT variable must be set when multiple
>>> SCMs
>>> are used.
>>
>>
>> Looks like a very odd failure, unfortunately I cannot reproduce with
>> pyro or master on recipes that use version control or dynamic SRCREV
>> features. Could you provide some build config info and if possible the
>> recipe that is generating the error?
>
>
> I made a "bare" clone of oe-core, meta-oe and meta-xilinx. Ran a build,
> which went okay.
>
> I copied this recipe into meta-xilinx for parsing, and got the error:
>
> (topic-miami-monitor-lib.bb, fetches a C program from github)
>
> ...
>
> SUMMARY = "Example and/or library for reading SOM monitor devices"
> LICENSE = "GPLv3"
> LIC_FILES_CHKSUM = "file://COPYING;md5=9eef91148a9b14ec7f9df333daebc746"
>
>
> GITHUB_TOPIC_URI ?= "git://github.com/topic-embedded-products"
> SRC_URI = "${GITHUB_TOPIC_URI}/${PN}"

Ah, there is the issue. PN, which is modified for
native/nativesdk/multilib/"zynqmp-pmu" class extenders.

So what happens is that for the normal target parsing PN="foo", but
when it parses with the extended classes PN="zynqmp-pmu-foo" (or
similar) for those. Which results in multiple SRC_URI's. Using "PN" in
something like the SRC_URI is probably going to cause pain in other
ways too. Most recipes use BPN to get the name of the recipe, there
are a few that use PN though in meta-oe at least but they don't enable
any classextenders (and none of them use git src_uris).

I will make a patch to have the zynqmp-pmu config only extend the used
recipes (gcc/etc.), I had not figured out a good way to do it
previously, but have a sane solution to that now. However I would
still recommend you avoid using PN in the way you have.

https://github.com/nathanrossi/meta-xilinx/commit/2d462040fdcadda70e08a5568f1c9217ea7e0624

Will post it on list after some testing, specifically with pyro so it
can be backported to that branch too.

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

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

2017-08-18 Thread Mike Looijmans

On 18-08-17 16:51, Nathan Rossi wrote:

On 18 August 2017 at 19:22, Mike Looijmans wrote:

On 17-08-17 23:57, Nathan Rossi wrote:

On 17 August 2017 at 23:12, Mike Looijmans
wrote:

I'm attempting to revive my build for the MPSOC machines. If one does
something like this:

MACHINE=zcu102-zynqmp bitbake my-image

I get parsing errors like:

ERROR: ExpansionError during parsing /home/mike/projects/@@@.bb
Traceback (most recent call last):

...

bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
expression
was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
Fetcher failure: The SRCREV_FORMAT variable must be set when multiple
SCMs
are used.

Looks like a very odd failure, unfortunately I cannot reproduce with
pyro or master on recipes that use version control or dynamic SRCREV
features. Could you provide some build config info and if possible the
recipe that is generating the error?

I made a "bare" clone of oe-core, meta-oe and meta-xilinx. Ran a build,
which went okay.

I copied this recipe into meta-xilinx for parsing, and got the error:

(topic-miami-monitor-lib.bb, fetches a C program from github)

...

SUMMARY = "Example and/or library for reading SOM monitor devices"
LICENSE = "GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=9eef91148a9b14ec7f9df333daebc746"

GITHUB_TOPIC_URI ?= "git://github.com/topic-embedded-products"
SRC_URI = "${GITHUB_TOPIC_URI}/${PN}"

Ah, there is the issue. PN, which is modified for
native/nativesdk/multilib/"zynqmp-pmu" class extenders.

So what happens is that for the normal target parsing PN="foo", but
when it parses with the extended classes PN="zynqmp-pmu-foo" (or
similar) for those. Which results in multiple SRC_URI's. Using "PN" in
something like the SRC_URI is probably going to cause pain in other
ways too. Most recipes use BPN to get the name of the recipe, there
are a few that use PN though in meta-oe at least but they don't enable
any classextenders (and none of them use git src_uris).

I missed that memo on the BPN introduction I guess :)

Anyway, it'd be a good thing to replace PN in these recipes by BPN. That
I'll do for sure.

I will make a patch to have the zynqmp-pmu config only extend the used
recipes (gcc/etc.), I had not figured out a good way to do it
previously, but have a sane solution to that now. However I would
still recommend you avoid using PN in the way you have.

I tried something similar using something like:
BBCLASSEXTEND_pn-gcc_append
but that didn't quite work for some packages.

https://github.com/nathanrossi/meta-xilinx/commit/2d462040fdcadda70e08a5568f1c9217ea7e0624

Are you aware that this commit drops the "PACKAGE_EXTRA_ARCHS_append"
assignment?

Will post it on list after some testing, specifically with pyro so it
can be backported to that branch too.

I'll test along...

Kind regards,
--
Mike Looijmans

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

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

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

2017-08-18 Thread Mike Looijmans


On 18-08-17 18:24, Mike Looijmans wrote:

On 18-08-17 16:51, Nathan Rossi wrote:
https://github.com/nathanrossi/meta-xilinx/commit/2d462040fdcadda70e08a5568f1c9217ea7e0624 


Are you aware that this commit drops the "PACKAGE_EXTRA_ARCHS_append" 
assignment?


Drop that remark, I should have read the commit message :)

--
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



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

[meta-xilinx] [PATCH 1/4] recipes-microblaze/glibc: Remove glibc patches

2017-08-18 Thread Alistair Francis

The meta layer has moved to glibc 2.26 so these bbappends no longer
apply. As these patches don't apply to glibc 2.26 and some other similar
patches have been merged just remove these patches.

Signed-off-by: Alistair Francis 
---
 ...oBlaze-fix-up-pt-vfork-symbol-definitions.patch | 105 -
 .../glibc/glibc-initial_2.25.bbappend  |   4 -
 recipes-microblaze/glibc/glibc_2.25.bbappend   |   4 -
 3 files changed, 113 deletions(-)
 delete mode 100644 
recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
 delete mode 100644 recipes-microblaze/glibc/glibc-initial_2.25.bbappend
 delete mode 100644 recipes-microblaze/glibc/glibc_2.25.bbappend

diff --git 
a/recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
 
b/recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
deleted file mode 100644
index ed37d63..000
--- 
a/recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
+++ /dev/null
@@ -1,105 +0,0 @@
-From 873fc4bf58d6cc8d579a65224350ce3adddc6c2a Mon Sep 17 00:00:00 2001
-From: Nathan Rossi 
-Date: Wed, 23 Nov 2016 22:30:29 +1000
-Subject: [PATCH] MicroBlaze: fix up pt-vfork symbol definitions
-
-Due to the reuse of the alpha/pt-vfork.S implementation additional
-symbols are emitted for libpthread which are invalid due to the
-non-existence of a '__libc_vfork' symbol/implementation. A symbol is
-emitted which references __libc_vfork and is invalid which causes the
-linker to emit a corrupt symbol entry:
-
-180:  0x24a91 NOTYPE  LOCAL  DEFAULT  UND 
-
-Depending on the internals of the linker this corrupt symbol is either a
-valid symbol as above or an completely invalid symbol that causes issues
-when linking against libpthread.so:
-
-179: 564b 0x825fd688 : 11 : 4 HIDDEN
-[: 54]   UND 
-
-In both cases this is the 'vfork@GLIBC_2.18' compat_symbol which is
-aliased as the local '__libc_vfork'. (in libpthread.so)
-
-12:  0 NOTYPE  GLOBAL DEFAULT  UND vfork@GLIBC_2.18
-
-Due to how MicroBlaze differs from other architectures, it is special in
-that it only implements '__vfork' and due to the weak_alias in vfork.S
-also defines 'vfork' for both libc and libpthread. No other symbols
-(e.g. '__vfork_compat') are part of the ABI.
-
-This change removes the compatible symbol generation provided by
-alpha/pt-vfork.S and sets up the 'vfork' and '__vfork' symbols to be
-provided in libpthread based on SHLIB_COMPAT. This avoids the generation
-of invalid symbols but maintains the expected libc and libpthread vfork
-ABIs.
-
-Signed-off-by: Nathan Rossi 
-Upstream-Status: Pending

- sysdeps/unix/sysv/linux/microblaze/pt-vfork.S | 40 ++-
- sysdeps/unix/sysv/linux/microblaze/vfork.S|  4 ++-
- 2 files changed, 42 insertions(+), 2 deletions(-)
-
-diff --git a/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S 
b/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
-index 65cc3823ac..82bc36eecc 100644
 a/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
-+++ b/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
-@@ -1 +1,39 @@
--#include 
-+/* vfork ABI-compatibility entry points for libpthread.
-+   Copyright (C) 2014-2016 Free Software Foundation, Inc.
-+   This file is part of the GNU C Library.
-+
-+   The GNU C Library is free software; you can redistribute it and/or
-+   modify it under the terms of the GNU Lesser General Public
-+   License as published by the Free Software Foundation; either
-+   version 2.1 of the License, or (at your option) any later version.
-+
-+   The GNU C Library is distributed in the hope that it will be useful,
-+   but WITHOUT ANY WARRANTY; without even the implied warranty of
-+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-+   Lesser General Public License for more details.
-+
-+   You should have received a copy of the GNU Lesser General Public
-+   License along with the GNU C Library; if not, see
-+   .  */
-+
-+#include 
-+
-+/* libpthread used to have its own vfork implementation that differed
-+   from libc's only in having a pointless micro-optimization.  There
-+   is no longer any use to having a separate copy in libpthread, but
-+   the historical ABI requires it.  For static linking, there is no
-+   need to provide anything here--the libc version will be linked in.
-+   For shared library ABI compatibility, there must be __vfork and
-+   vfork symbols in libpthread.so.  */
-+
-+#if (SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_20) \
-+ || SHLIB_COMPAT (libpthread, GLIBC_2_1_2, GLIBC_2_20))
-+
-+#include 
-+
-+#endif
-+
-+#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_20)
-+weak_alias (__vfork, vfork)
-+#endif
-+
-diff --git a/sysdeps/unix/sysv/linux/microblaze/vfork.S 
b/sysdeps/unix/sysv/linux/microblaze/vfork.S
-index 9592cb4f28..b537f1ce34 100644
 a/sysdeps/unix/sysv/linux/microblaze/vfork.S
-+++ b/sysdeps/u

Re: [meta-xilinx] [PATCH 1/4] recipes-microblaze/glibc: Remove glibc patches

2017-08-18 Thread Alistair Francis

On Fri, Aug 18, 2017 at 9:29 AM, Alistair Francis
 wrote:
> The meta layer has moved to glibc 2.26 so these bbappends no longer
> apply. As these patches don't apply to glibc 2.26 and some other similar
> patches have been merged just remove these patches.
>
> Signed-off-by: Alistair Francis 
> ---

Ah, my under the line was lost.

I'm a little unsure about this one. Once this patch is applied I can't
boot the QEMU machines on QEMU. I'm not sure that is broken by this
though, or master just doesn't work as I can't build master without
this patch.

Thanks,
Alistair

>  ...oBlaze-fix-up-pt-vfork-symbol-definitions.patch | 105 
> -
>  .../glibc/glibc-initial_2.25.bbappend  |   4 -
>  recipes-microblaze/glibc/glibc_2.25.bbappend   |   4 -
>  3 files changed, 113 deletions(-)
>  delete mode 100644 
> recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
>  delete mode 100644 recipes-microblaze/glibc/glibc-initial_2.25.bbappend
>  delete mode 100644 recipes-microblaze/glibc/glibc_2.25.bbappend
>
> diff --git 
> a/recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
>  
> b/recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
> deleted file mode 100644
> index ed37d63..000
> --- 
> a/recipes-microblaze/glibc/files/MicroBlaze-fix-up-pt-vfork-symbol-definitions.patch
> +++ /dev/null
> @@ -1,105 +0,0 @@
> -From 873fc4bf58d6cc8d579a65224350ce3adddc6c2a Mon Sep 17 00:00:00 2001
> -From: Nathan Rossi 
> -Date: Wed, 23 Nov 2016 22:30:29 +1000
> -Subject: [PATCH] MicroBlaze: fix up pt-vfork symbol definitions
> -
> -Due to the reuse of the alpha/pt-vfork.S implementation additional
> -symbols are emitted for libpthread which are invalid due to the
> -non-existence of a '__libc_vfork' symbol/implementation. A symbol is
> -emitted which references __libc_vfork and is invalid which causes the
> -linker to emit a corrupt symbol entry:
> -
> -180:  0x24a91 NOTYPE  LOCAL  DEFAULT  UND 
> -
> -Depending on the internals of the linker this corrupt symbol is either a
> -valid symbol as above or an completely invalid symbol that causes issues
> -when linking against libpthread.so:
> -
> -179: 564b 0x825fd688 : 11 : 4 HIDDEN
> -[: 54]   UND 
> -
> -In both cases this is the 'vfork@GLIBC_2.18' compat_symbol which is
> -aliased as the local '__libc_vfork'. (in libpthread.so)
> -
> -12:  0 NOTYPE  GLOBAL DEFAULT  UND vfork@GLIBC_2.18
> -
> -Due to how MicroBlaze differs from other architectures, it is special in
> -that it only implements '__vfork' and due to the weak_alias in vfork.S
> -also defines 'vfork' for both libc and libpthread. No other symbols
> -(e.g. '__vfork_compat') are part of the ABI.
> -
> -This change removes the compatible symbol generation provided by
> -alpha/pt-vfork.S and sets up the 'vfork' and '__vfork' symbols to be
> -provided in libpthread based on SHLIB_COMPAT. This avoids the generation
> -of invalid symbols but maintains the expected libc and libpthread vfork
> -ABIs.
> -
> -Signed-off-by: Nathan Rossi 
> -Upstream-Status: Pending
> 
> - sysdeps/unix/sysv/linux/microblaze/pt-vfork.S | 40 
> ++-
> - sysdeps/unix/sysv/linux/microblaze/vfork.S|  4 ++-
> - 2 files changed, 42 insertions(+), 2 deletions(-)
> -
> -diff --git a/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S 
> b/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
> -index 65cc3823ac..82bc36eecc 100644
>  a/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
> -+++ b/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
> -@@ -1 +1,39 @@
> --#include 
> -+/* vfork ABI-compatibility entry points for libpthread.
> -+   Copyright (C) 2014-2016 Free Software Foundation, Inc.
> -+   This file is part of the GNU C Library.
> -+
> -+   The GNU C Library is free software; you can redistribute it and/or
> -+   modify it under the terms of the GNU Lesser General Public
> -+   License as published by the Free Software Foundation; either
> -+   version 2.1 of the License, or (at your option) any later version.
> -+
> -+   The GNU C Library is distributed in the hope that it will be useful,
> -+   but WITHOUT ANY WARRANTY; without even the implied warranty of
> -+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> -+   Lesser General Public License for more details.
> -+
> -+   You should have received a copy of the GNU Lesser General Public
> -+   License along with the GNU C Library; if not, see
> -+   .  */
> -+
> -+#include 
> -+
> -+/* libpthread used to have its own vfork implementation that differed
> -+   from libc's only in having a pointless micro-optimization.  There
> -+   is no longer any use to having a separate copy in libpthread, but
> -+   the historical ABI requires it.  For static linking, there is no
> -+   need to provide anything here--the libc version will be linked in.
> -+   For shared library ABI co

[meta-xilinx] [PATCH 4/4] arm-trusted-firmware: Fix a false positive out of bounds

2017-08-18 Thread Alistair Francis

This error is received while building
services/std_svc/psci/psci_common.c: In function 'psci_do_state_coordination':
services/std_svc/psci/psci_common.c:220:27: error: array subscript is above
array bounds [-Werror=array-bounds]
  psci_req_local_pwr_states[pwrlvl - 1][cpu_idx] = req_pwr_state;

Patch 555ebb34db8f3424c1b394df2f10ecf9c1f70901 explains why the error
is seen and supposibly includes a fix. As the fix appears not to work,
let's disable the error checking.

Signed-off-by: Alistair Francis 
---
 recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc 
b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
index 759cc10..747874d 100644
--- a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
+++ b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
@@ -24,11 +24,12 @@ ATF_BASE_NAME[vardepsexclude] = "DATETIME"
 COMPATIBLE_MACHINE = "zynqmp"
 PLATFORM_zynqmp = "zynqmp"
 
+CFLAGS_append = " -Wno-error=array-bounds"
+
 # requires CROSS_COMPILE set by hand as there is no configure script
 export CROSS_COMPILE="${TARGET_PREFIX}"
 
 # Let the Makefile handle setting up the CFLAGS and LDFLAGS as it is a 
standalone application
-CFLAGS[unexport] = "1"
 LDFLAGS[unexport] = "1"
 AS[unexport] = "1"
 LD[unexport] = "1"
-- 
2.11.0

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

[meta-xilinx] [PATCH 3/4] arm-trusted-firmware: Fix a double const build error

2017-08-18 Thread Alistair Francis

Signed-off-by: Alistair Francis 
---
 .../arm-trusted-firmware/arm-trusted-firmware.inc  |  3 +++
 ...zynqmp-Remove-duplicate-const-declaration.patch | 30 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
recipes-bsp/arm-trusted-firmware/files/zynqmp-Remove-duplicate-const-declaration.patch

diff --git a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc 
b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
index 217919c..759cc10 100644
--- a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
+++ b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
@@ -12,8 +12,11 @@ DEPENDS += "u-boot-mkimage-native"
 S = "${WORKDIR}/git"
 B = "${WORKDIR}/build"
 
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
 BRANCH = "master"
 SRC_URI = 
"git://github.com/Xilinx/arm-trusted-firmware.git;protocol=https;branch=${BRANCH}"
+SRC_URI += "file://zynqmp-Remove-duplicate-const-declaration.patch"
 
 ATF_BASE_NAME ?= "${PN}-${PKGE}-${PKGV}-${PKGR}-${DATETIME}"
 ATF_BASE_NAME[vardepsexclude] = "DATETIME"
diff --git 
a/recipes-bsp/arm-trusted-firmware/files/zynqmp-Remove-duplicate-const-declaration.patch
 
b/recipes-bsp/arm-trusted-firmware/files/zynqmp-Remove-duplicate-const-declaration.patch
new file mode 100644
index 000..dd127fb
--- /dev/null
+++ 
b/recipes-bsp/arm-trusted-firmware/files/zynqmp-Remove-duplicate-const-declaration.patch
@@ -0,0 +1,30 @@
+From a97f6272b7a7a8e3249df34c22479b3893746395 Mon Sep 17 00:00:00 2001
+From: Soren Brinkmann 
+Date: Sat, 1 Jul 2017 20:24:47 -0700
+Subject: [PATCH] zynqmp: Remove duplicate 'const' declaration
+
+Fixing compilation errors due to duplicate 'const' keyword:
+  plat/xilinx/zynqmp/pm_service/pm_client.c:39:29: error: duplicate 'const' 
declaration specifier [-Werror=duplicate-decl-specifier]
+   static const struct pm_proc const pm_procs_all[] = {
+   ^
+
+Signed-off-by: Soren Brinkmann 
+---
+Upstream Status: Accepted in mainline, patch send to Xilinx
+
+ plat/xilinx/zynqmp/pm_service/pm_client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/xilinx/zynqmp/pm_service/pm_client.c 
b/plat/xilinx/zynqmp/pm_service/pm_client.c
+index f11725d78..08369b99e 100644
+--- a/plat/xilinx/zynqmp/pm_service/pm_client.c
 b/plat/xilinx/zynqmp/pm_service/pm_client.c
+@@ -31,7 +31,7 @@ DEFINE_BAKERY_LOCK(pm_client_secure_lock);
+ extern const struct pm_ipi apu_ipi;
+ 
+ /* Order in pm_procs_all array must match cpu ids */
+-static const struct pm_proc const pm_procs_all[] = {
++static const struct pm_proc pm_procs_all[] = {
+   {
+   .node_id = NODE_APU_0,
+   .pwrdn_mask = APU_0_PWRCTL_CPUPWRDWNREQ_MASK,
-- 
2.11.0

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

[meta-xilinx] [PATCH 2/4] machine-xilinx-default.inc: Remove image_types_uboot

2017-08-18 Thread Alistair Francis

This has changed in the meta layer and breaks the build, as it appears
it is no longer required just remove it.

Signed-off-by: Alistair Francis 
---
 conf/machine/include/machine-xilinx-default.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/machine-xilinx-default.inc 
b/conf/machine/include/machine-xilinx-default.inc
index 5ab7494..02238c1 100644
--- a/conf/machine/include/machine-xilinx-default.inc
+++ b/conf/machine/include/machine-xilinx-default.inc
@@ -7,7 +7,6 @@ MACHINE_FEATURES_BACKFILL_CONSIDERED_append_microblaze = " 
qemu-usermode"
 
 # File System Configuration
 IMAGE_FSTYPES ?= "tar.gz cpio cpio.gz.u-boot"
-IMAGE_CLASSES += "image_types_uboot"
 
 # Kernel Configuration
 XILINX_DEFAULT_KERNEL := "linux-xlnx"
-- 
2.11.0

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

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

2017-08-18 Thread 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 causes tons of recipes to fail to parse because of PMU build

[meta-xilinx] How to boot the ZynqMP?

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

Re: [meta-xilinx] ZynqMP causes tons of recipes to fail to parse because of PMU build

[meta-xilinx] [PATCH 1/4] recipes-microblaze/glibc: Remove glibc patches

Re: [meta-xilinx] [PATCH 1/4] recipes-microblaze/glibc: Remove glibc patches

[meta-xilinx] [PATCH 4/4] arm-trusted-firmware: Fix a false positive out of bounds

[meta-xilinx] [PATCH 3/4] arm-trusted-firmware: Fix a double const build error

[meta-xilinx] [PATCH 2/4] machine-xilinx-default.inc: Remove image_types_uboot

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

11 matches

Site Navigation

Mail list logo

Footer information