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

2017-04-27 Thread Philip Balister 
On 04/27/2017 12:59 PM, Mike Looijmans wrote:
> On 27-04-17 16:11, Nathan Rossi wrote:
> ...
>> Looking at the differences, ignoring the obvious zynqmp/microblaze
>> changes there are only a few features that are available in
>> u-boot-xlnx that are not in mainline:
>>  * partial bitstream loading support
>>  * secure/encrypted bitstream loading support
>>  * support for rsa verification of images
>>  * board configs/devicetrees for various Xilinx internal boards
> 
> You missed one: Dual-QSPI flash support. That only exists on
> u-boot-xlnx, it never got implemented in a way acceptable to upstream.
> 
> The same goes for the kernel. The only way to get dual-qspi flash to
> work is to use the xlnx bootloader and kernel.

But surely this could be handled as patches adding this feature to
mainline, and not carrying a custom u-boot source tree forever.

Philip


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

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

2017-04-27 Thread Mike Looijmans 

On 27-04-17 16:11, Nathan Rossi wrote:
...

Looking at the differences, ignoring the obvious zynqmp/microblaze
changes there are only a few features that are available in
u-boot-xlnx that are not in mainline:
 * partial bitstream loading support
 * secure/encrypted bitstream loading support
 * support for rsa verification of images
 * board configs/devicetrees for various Xilinx internal boards


You missed one: Dual-QSPI flash support. That only exists on 
u-boot-xlnx, it never got implemented in a way acceptable to upstream.


The same goes for the kernel. The only way to get dual-qspi flash to 
work is to use the xlnx bootloader and kernel.




--
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] [PATCH] machine-xilinx-default.inc: Default to u-boot for Zynq

2017-04-27 Thread Nathan Rossi 
On 28 April 2017 at 01:36, Manjukumar Harthikote Matha
 wrote:
>
>
>> -Original Message-
>> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
>> Sent: Thursday, April 27, 2017 7:11 AM
>> To: Manjukumar Harthikote Matha 
>> Cc: Philip Balister ; meta-xil...@lists.yoctoproject.org
>> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to 
>> u-boot for
>> Zynq
>>
>> On 27 April 2017 at 08:21, Manjukumar Harthikote Matha
>>  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Philip Balister [mailto:phi...@balister.org]
>> >> Sent: Wednesday, April 26, 2017 12:38 PM
>> >> To: Manjukumar Harthikote Matha ; Nathan Rossi
>> >> 
>> >> Cc: meta-xil...@lists.yoctoproject.org
>> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to 
>> >> u-boot
>> for
>> >> Zynq
>> >>
>> >> On 04/26/2017 03:06 PM, Manjukumar Harthikote Matha wrote:
>> >> >
>> >> >
>> >> >> -Original Message-
>> >> >> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
>> >> >> Sent: Wednesday, April 26, 2017 10:54 AM
>> >> >> To: Manjukumar Harthikote Matha 
>> >> >> Cc: meta-xil...@lists.yoctoproject.org
>> >> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc:
>> >> >> Default to u-boot for Zynq
>> >> >>
>> >> >> On 27 April 2017 at 02:41, Manjukumar Harthikote Matha
>> >> >>  wrote:
>> >> >>>
>> >> >>>
>> >>  -Original Message-
>> >>  From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>> >>  boun...@yoctoproject.org] On Behalf Of Nathan Rossi
>> >>  Sent: Wednesday, April 26, 2017 4:57 AM
>> >>  To: meta-xil...@lists.yoctoproject.org
>> >>  Subject: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default
>> >>  to u-boot for Zynq
>> >> 
>> >>  Upstream U-Boot provides an almost complete environment for the
>> >>  majority of Zynq targets and specifically covers all the boot
>> >>  functionality required for the boards in the meta-xilinx layer. As
>> >>  such default to
>> >> >> the mainline version of U-Boot.
>> >> 
>> >>  For users that require or prefer to use u-boot-xlnx this can be
>> >>  selected on a per- machine basis using:
>> >> 
>> >>    PREFERRED_PROVIDER_virtual/bootloader = "u-boot-xlnx"
>> >> 
>> >>  Signed-off-by: Nathan Rossi 
>> >>  ---
>> >>   conf/machine/include/machine-xilinx-default.inc | 1 +
>> >>   1 file changed, 1 insertion(+)
>> >> 
>> >>  diff --git a/conf/machine/include/machine-xilinx-default.inc
>> >>  b/conf/machine/include/machine-xilinx-default.inc
>> >>  index 13e4df5746..f9e7e3a33f 100644
>> >>  --- a/conf/machine/include/machine-xilinx-default.inc
>> >>  +++ b/conf/machine/include/machine-xilinx-default.inc
>> >>  @@ -19,6 +19,7 @@ PREFERRED_VERSION_linux-xlnx ?= "4.6-xilinx-
>> v2016.4%"
>> >> 
>> >>   # U-Boot Configuration
>> >>   XILINX_DEFAULT_UBOOT := "u-boot-xlnx"
>> >>  +XILINX_DEFAULT_UBOOT_zynq := "u-boot"
>> >>   XILINX_DEFAULT_UBOOT_zynqmp := "u-boot"
>> >> >>>
>> >> >>> Why have any preferred_provider? Distro can provide these settings.
>> >> >>> For ex: meta-petalinux can provide u-boot-xlnx, oe-core can provide
>> >> >>> u-boot
>> >> >>>
>> >> >>> Any thoughts?
>> >> >>
>> >> >> Unfortunately not picking a provider for "virtual/bootloader" will
>> >> >> result in bitbake attempting to build all providers (since
>> >> >> EXTRA_IMAGEDEPENDS is depending on virtual/bootloader), as bitbake
>> >> >> has no idea which one is desired (and they are all compatible).
>> >> >>
>> >> >> --
>> >> >> NOTE: multiple providers are available for virtual/bootloader
>> >> >> (u-boot-xlnx, u-boot- xlnx-dev, u-boot)
>> >> >> NOTE: consider defining a PREFERRED_PROVIDER entry to match
>> >> >> virtual/bootloader ...
>> >> >> ERROR: Multiple .bb files are due to be built which each provide
>> >> >> virtual/bootloader ...
>> >> >> 
>> >> >> --
>> >> >>
>> >> >> Also note, meta-petalinux or other layers should already be able to
>> >> >> override this default (by setting with ??=) either in a distro conf
>> >> >> or in a machine conf e.g. zynq- generic (for meta-petalinux).
>> >> >>
>> >> > If this is the case then why meta-xilinx should peg to upstream u-boot 
>> >> > by
>> default?
>> >> It should peg to u-boot-xlnx or linux-xlnx by default. We know that there 
>> >> are
>> >> patches/drivers which are not upstreamed yet, and only available in 
>> >> Xilinx specific
>> >> tree. This layer is specific to Xilinx updates and should stick to 
>> >> defaults supported
>> by
>> >> Xilinx. Other distros or layer stack which use meta-xilinx should override
>> depending
>> >> on their requirements not the other way round.
>>
>> It should be noted that Xilinx does work with

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

2017-04-27 Thread Manjukumar Harthikote Matha 


> -Original Message-
> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
> Sent: Thursday, April 27, 2017 7:11 AM
> To: Manjukumar Harthikote Matha 
> Cc: Philip Balister ; meta-xil...@lists.yoctoproject.org
> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to 
> u-boot for
> Zynq
>
> On 27 April 2017 at 08:21, Manjukumar Harthikote Matha
>  wrote:
> >
> >
> >> -Original Message-
> >> From: Philip Balister [mailto:phi...@balister.org]
> >> Sent: Wednesday, April 26, 2017 12:38 PM
> >> To: Manjukumar Harthikote Matha ; Nathan Rossi
> >> 
> >> Cc: meta-xil...@lists.yoctoproject.org
> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to 
> >> u-boot
> for
> >> Zynq
> >>
> >> On 04/26/2017 03:06 PM, Manjukumar Harthikote Matha wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
> >> >> Sent: Wednesday, April 26, 2017 10:54 AM
> >> >> To: Manjukumar Harthikote Matha 
> >> >> Cc: meta-xil...@lists.yoctoproject.org
> >> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc:
> >> >> Default to u-boot for Zynq
> >> >>
> >> >> On 27 April 2017 at 02:41, Manjukumar Harthikote Matha
> >> >>  wrote:
> >> >>>
> >> >>>
> >>  -Original Message-
> >>  From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> >>  boun...@yoctoproject.org] On Behalf Of Nathan Rossi
> >>  Sent: Wednesday, April 26, 2017 4:57 AM
> >>  To: meta-xil...@lists.yoctoproject.org
> >>  Subject: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default
> >>  to u-boot for Zynq
> >> 
> >>  Upstream U-Boot provides an almost complete environment for the
> >>  majority of Zynq targets and specifically covers all the boot
> >>  functionality required for the boards in the meta-xilinx layer. As
> >>  such default to
> >> >> the mainline version of U-Boot.
> >> 
> >>  For users that require or prefer to use u-boot-xlnx this can be
> >>  selected on a per- machine basis using:
> >> 
> >>    PREFERRED_PROVIDER_virtual/bootloader = "u-boot-xlnx"
> >> 
> >>  Signed-off-by: Nathan Rossi 
> >>  ---
> >>   conf/machine/include/machine-xilinx-default.inc | 1 +
> >>   1 file changed, 1 insertion(+)
> >> 
> >>  diff --git a/conf/machine/include/machine-xilinx-default.inc
> >>  b/conf/machine/include/machine-xilinx-default.inc
> >>  index 13e4df5746..f9e7e3a33f 100644
> >>  --- a/conf/machine/include/machine-xilinx-default.inc
> >>  +++ b/conf/machine/include/machine-xilinx-default.inc
> >>  @@ -19,6 +19,7 @@ PREFERRED_VERSION_linux-xlnx ?= "4.6-xilinx-
> v2016.4%"
> >> 
> >>   # U-Boot Configuration
> >>   XILINX_DEFAULT_UBOOT := "u-boot-xlnx"
> >>  +XILINX_DEFAULT_UBOOT_zynq := "u-boot"
> >>   XILINX_DEFAULT_UBOOT_zynqmp := "u-boot"
> >> >>>
> >> >>> Why have any preferred_provider? Distro can provide these settings.
> >> >>> For ex: meta-petalinux can provide u-boot-xlnx, oe-core can provide
> >> >>> u-boot
> >> >>>
> >> >>> Any thoughts?
> >> >>
> >> >> Unfortunately not picking a provider for "virtual/bootloader" will
> >> >> result in bitbake attempting to build all providers (since
> >> >> EXTRA_IMAGEDEPENDS is depending on virtual/bootloader), as bitbake
> >> >> has no idea which one is desired (and they are all compatible).
> >> >>
> >> >> --
> >> >> NOTE: multiple providers are available for virtual/bootloader
> >> >> (u-boot-xlnx, u-boot- xlnx-dev, u-boot)
> >> >> NOTE: consider defining a PREFERRED_PROVIDER entry to match
> >> >> virtual/bootloader ...
> >> >> ERROR: Multiple .bb files are due to be built which each provide
> >> >> virtual/bootloader ...
> >> >> 
> >> >> --
> >> >>
> >> >> Also note, meta-petalinux or other layers should already be able to
> >> >> override this default (by setting with ??=) either in a distro conf
> >> >> or in a machine conf e.g. zynq- generic (for meta-petalinux).
> >> >>
> >> > If this is the case then why meta-xilinx should peg to upstream u-boot by
> default?
> >> It should peg to u-boot-xlnx or linux-xlnx by default. We know that there 
> >> are
> >> patches/drivers which are not upstreamed yet, and only available in Xilinx 
> >> specific
> >> tree. This layer is specific to Xilinx updates and should stick to 
> >> defaults supported
> by
> >> Xilinx. Other distros or layer stack which use meta-xilinx should override
> depending
> >> on their requirements not the other way round.
>
> It should be noted that Xilinx does work with upstream U-Boot, since
> Xilinx has an active maintainer (and active contributors). I would
> call that support, but that is open to your own interpretation.
>
> >> > PREFERRED_PROVIDER_virtual/bootloader = "u-boot" should be specific

Re: [meta-xilinx] Nothing PROVIDES 'python3-pyyaml-native'

2017-04-27 Thread Giuseppe Di Guglielmo 
I am pretty sure I changed the correct files. If I do not do so, it
complains about the nonexisting "gitenterprise" URL. I could wait until May
5th, but I am on a deadline, and the earlier I workaround the issue, the
better.


classes/xsctapp.bbclass b/classes/xsctapp.bbclass

-EMBEDDEDSW_REPO ?= "git://
gitenterprise.xilinx.com/embeddedsw/embeddedsw.git;protocol=https"
+EMBEDDEDSW_REPO ?= "
https://github.com/Xilinx/embeddedsw/embeddedsw.git;protocol=https;

recipes-bsp/device-tree/device-tree-generation_git.bb
b/recipes-bsp/device-tree/device-tree-generation_git.bb

-SRC_URI = "git://
gitenterprise.xilinx.com/Linux/device-tree-xlnx.git;protocol=https;branch=${BRANCH}
"
+SRC_URI = "git://
github.com/Xilinx/device-tree-xlnx.git;protocol=https;branch=${BRANCH}"

Giuseppe

On Thu, Apr 27, 2017 at 7:41 AM, Jean-Francois Dagenais <
jeff.dagen...@gmail.com> wrote:

>
> On Apr 26, 2017, at 21:44, Giuseppe Di Guglielmo <
> giuseppe.diguglie...@gmail.com> wrote:
>
> Updating the URLs to github.com/Xilinx generates the following errors
> that I do not know how to fix. Do you have any idea?
>
> It may be a proble with the revision numbers coded in the *.bb files.
>
> Giuseppe
> 
> ERROR: An uncaught exception occurred in runqueue
> | ETA:  0:00:03
> Traceback (most recent call last):
>   File 
> "/home/giuseppe/research/projects/zynq/yocto/poky/bitbake/lib/bb/runqueue.py",
> line 948, in RunQueueData.p
> repare():
>  (mc, fn, taskname, taskfn) = split_tid_mcfn(tid)
> >self.runtaskentries[tid].hash =
> bb.parse.siggen.get_taskhash(taskfn, taskname, procdep,
> self.dataCaches[mc])
>  task = self.runtaskentries[tid].task
>   File 
> "/home/giuseppe/research/projects/zynq/yocto/poky/meta/lib/oe/sstatesig.py",
> line 139, in SignatureGenerat
> orOEBasicHash.get_taskhash(fn='/home/giuseppe/research/
> projects/zynq/yocto/meta-xilinx-tools/recipes-bsp/fsbl/fsbl_git.bb',
> task='do_fetch', deps=[], dataCache= 0x7fe5b4301ba8>):
>  def get_taskhash(self, fn, task, deps, dataCache):
> >h = super(bb.siggen.SignatureGeneratorBasicHash,
> self).get_taskhash(fn, task, deps, dataCache)
>
>
> Are you sure you changed the URL on the right .bb file? It looks like it's
> the fsbl recipe that is failing it's "do_fetch" step (fsbl_git.bb in your
> error log)
>
> If that still doesn't work, disregard my advice and see with the "real"
> xilinx guys to chime in ;) Yocto has a steep learning slope. Deciphering
> these error logs can be a pain, especially in the beginning.
>
>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Zynq FPGA bitfile

2017-04-27 Thread Stephane Mancini 
Hello,
with petalinux 2016.4 and
http://www.wiki.xilinx.com/Using+meta-xilinx-tools+layer


I managed to get an image but, where is the fpga bit file ?
How to setup the conf file to select a fpga bit file ?



Also, it seems that there is no sdimage such as the digilent one to copy
with 'dd'
https://github.com/Digilent/meta-manifest/wiki/Quick-start-guide

Which file should I use to flash the sd ?




-- 
|Stéphane Mancini   Maitre de Conférences 
| Grenoble-INP Ensimag/TIMA SLS
| Tel : +33 4 76 57 43 58
| TIMA Laboratory
| 46, Av Félix Viallet, 38031 Grenoble Cedex
| Email : stephane.manc...@grenoble-inp.fr
| http://tima.imag.fr

Join us for the DASIP Conference
Visit http://www.ecsi.org/dasip/


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

Re: [meta-xilinx] [PATCH 4/5] u-boot-spl-zynq-init.inc: Add support for ZynqMP

2017-04-27 Thread Nathan Rossi 
On 26 April 2017 at 23:02, Jean-Francois Dagenais
 wrote:
>
>> On Apr 26, 2017, at 07:41, Nathan Rossi  wrote:
>>
>> Update to using the xilinx-platform-init.bbclass and depending on the
>> 'virtual/xilinx-platform-init' provider. This allows for more generic
>> support of platform-init (between Zynq7, ZynqMP and any future targets).
>>
>> This change also renames some of the variables used for defining the
>> source of the platform-init files for SPL. Specifically HAS_PS7INIT is
>> renamed to HAS_PLATFORM_INIT, and FORCE_PS7INIT is renamed to
>> FORCE_PLATFORM_INIT. However for compatibility the existing variables
>> still function as expected.
>>
>> Signed-off-by: Nathan Rossi 
>> ---
>> recipes-bsp/u-boot/u-boot-spl-zynq-init.inc | 58 
>> +
>> recipes-bsp/u-boot/u-boot-xlnx_2016.4.bb|  2 +-
>> recipes-bsp/u-boot/u-boot_%.bbappend|  2 +-
>> 3 files changed, 36 insertions(+), 26 deletions(-)
>>
>> diff --git a/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc 
>> b/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
>> index cc06de6cc5..442a24f9b2 100644
>> --- a/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
>> +++ b/recipes-bsp/u-boot/u-boot-spl-zynq-init.inc
>> @@ -1,38 +1,48 @@
>> -inherit zynq7-platform-paths
>> +inherit xilinx-platform-init
>> +
>> +PLATFORM_BOARD_DIR ?= ""
>> +PLATFORM_BOARD_DIR_zynq = "board/xilinx/zynq"
>> +PLATFORM_BOARD_DIR_zynqmp = "board/xilinx/zynqmp"
>>
>> do_configure_prepend() {
>> - if ${@bb.utils.contains('DEPENDS', 'virtual/zynq7-platform-init', 
>> 'true', 'false', d)}; then
>> - if [ -d "${S}/board/xilinx/zynq/custom_hw_platform" ]; then
>> - cp ${PLATFORM_INIT_STAGE_DIR}/ps7_init_gpl.h 
>> ${S}/board/xilinx/zynq/custom_hw_platform/
>> - cp ${PLATFORM_INIT_STAGE_DIR}/ps7_init_gpl.c 
>> ${S}/board/xilinx/zynq/custom_hw_platform/
>> - else
>> - cp ${PLATFORM_INIT_STAGE_DIR}/ps7_init_gpl.h 
>> ${S}/board/xilinx/zynq/
>> - cp ${PLATFORM_INIT_STAGE_DIR}/ps7_init_gpl.c 
>> ${S}/board/xilinx/zynq/
>> - fi
>> - if [ -n "${FORCE_PS7INIT}" ]; then
>> - # overwrite all the existing platforms ps7_init files, 
>> this is a shotgun approach and only works due to
>> - # u-boot being built for each machine seperately with 
>> seperate source directories.
>> - for i in ${S}/board/xilinx/zynq/*/; do
>> - cp ${PLATFORM_INIT_STAGE_DIR}/ps7_init_gpl.h $i
>> - cp ${PLATFORM_INIT_STAGE_DIR}/ps7_init_gpl.c $i
>> + if ${@bb.utils.contains('DEPENDS', 'virtual/xilinx-platform-init', 
>> 'true', 'false', d)}; then
>> + for f in ${PLATFORM_INIT_FILES}; do
>> + if [ -d 
>> "${S}/${PLATFORM_BOARD_DIR}/custom_hw_platform" ]; then
>> + cp ${PLATFORM_INIT_STAGE_DIR}/$f 
>> ${S}/${PLATFORM_BOARD_DIR}/custom_hw_platform/
>> + else
>> + cp ${PLATFORM_INIT_STAGE_DIR}/$f 
>> ${S}/${PLATFORM_BOARD_DIR}/
>> + fi
>> + # Newer u-boot sources use the init files in a sub 
>> directory named
>> + # based on the name of the device tree. This is not 
>> straight
>> + # forward to detect. Instead of detecting just 
>> overwrite all the
>> + # platform init files so that the correct one is 
>> always used. This
>> + # shotgun approach only works due to this recipe being 
>> machine arch
>> + # specific. Do this overwrite un-conditionally as 
>> there is no
>> + # guarantees that the chosen board config does not 
>> have the device
>> + # tree config set.
>> + for i in ${S}/${PLATFORM_BOARD_DIR}/*/; do
>> + [ -d $i ] && cp ${PLATFORM_INIT_STAGE_DIR}/$f 
>> $i
>>   done
>> - fi
>> + done
>>   fi
>> }
>>
>> -FORCE_PS7INIT[doc] = "This variable is used to force the overriding of all 
>> ps7_init_gpl.* files in u-boot source with what is provided by 
>> virtual/zynq7-platform-init."
>> +FORCE_PLATFORM_INIT[doc] = "This variable is used to force the overriding 
>> of all platform init files in u-boot source."
>>
>> python () {
>> - # Determine if target machine needs to provide a custom ps7_init_gpl.*
>> - if d.getVar("SOC_FAMILY", True) == "zynq":
>> - if d.getVar("SPL_BINARY", True):
>> + hasconfigs = (d.getVar("HAS_PLATFORM_INIT") or "").split() + 
>> (d.getVar("HAS_PS7INIT") or "").split()
>> + forceoverride = (d.getVar("FORCE_PLATFORM_INIT") == "1") or 
>> (d.getVar("FORCE_PS7INIT"))
>> +
>> + # Determine if target machine needs to provide a custom platform init 
>>

Re: [meta-xilinx] [PATCH 9/9] qemuboot-xilinx.bbclass: Rework qemu-xilinx setup

2017-04-27 Thread Nathan Rossi 
On 27 April 2017 at 04:17, Alistair Francis  wrote:
> On Wed, Apr 26, 2017 at 7:52 AM, Alistair Francis  
> wrote:
>> On Tue, Apr 25, 2017 at 10:53 PM, Nathan Rossi  
>> wrote:
>>> On 26 April 2017 at 04:11, Alistair Francis  wrote:
 On Tue, Apr 25, 2017 at 10:54 AM, Alistair Francis  
 wrote:
> On Thu, Apr 20, 2017 at 3:35 AM, Nathan Rossi  
> wrote:
>> This change reworks how the meta-xilinx layer enables and provides the
>> custom version of QEMU based on Xilinx's fork of QEMU. The existing
>> implementation relied on the single sysroot which was changed in oe-core
>> such that now recipes have their own sysroots (RSS support).
>> Additionally oe-core now provides the QEMU binaries to the runqemu
>> script via the 'qemu-helper-native' recipes sysroot as opposed to the
>> image sysroot.
>>
>> These rework changes allow for a single machine to select the targeted
>> QEMU version as well as to provide the qemuboot config specific to the
>> targeted QEMU version. The selection of QEMU version is now handled by
>> PREFERRED_PROVIDER mechanics with the meta-xilinx layer providing an
>> additional recipe that is equivalent to qemu-helper-native and which
>> also provides said target allowing for the machine to select via the use
>> of PREFERRED_PROVIDER_qemu-helper-native. This recipe
>> (qemu-xilinx-helper-native) however instead provides the sysroot
>> populated with qemu-xilinx instead of qemu.
>>
>> Additionally the XILINX_QEMUBOOT variable is replaced with the
>> qemuboot-xilinx.bbclass, this provides the overrides for setting up
>> qemu-xilinx specific QB_* args. Additionally this bbclass points runqemu
>> at the qemu-xilinx-helper-native sysroot for QEMU binaries.
>>
>> These changes also work towards making the meta-xilinx layer better
>> handle multiple qemuboot.conf variants as well as handling different
>> QEMU versions.
>>
>> This change also removes the 'qemu-system-xilinx' MACHINE_FEATURES, this
>> is due to MACHINE_FEATURES no longer being available for native recipes.
>> Additionally there is no longer any logic that needs to know this any
>> way.
>>
>> Signed-off-by: Nathan Rossi 
>> ---
>>  classes/qemuboot-xilinx.bbclass| 27 +++
>>  conf/machine/include/machine-xilinx-qemu.inc   | 39 
>> --
>>  conf/machine/ml605-qemu-microblazeel.conf  |  1 +
>>  conf/machine/qemu-zynq7.conf   |  1 +
>>  conf/machine/s3adsp1800-qemu-microblazeeb.conf |  1 +
>>  conf/machine/zcu102-zynqmp.conf|  8 +++--
>>  .../qemu/qemu-xilinx-helper-native_1.0.bb  | 20 +++
>>  7 files changed, 61 insertions(+), 36 deletions(-)
>>  create mode 100644 classes/qemuboot-xilinx.bbclass
>>  create mode 100644 
>> recipes-devtools/qemu/qemu-xilinx-helper-native_1.0.bb
>>
>> diff --git a/classes/qemuboot-xilinx.bbclass 
>> b/classes/qemuboot-xilinx.bbclass
>> new file mode 100644
>> index 00..a2f5ef3eb6
>> --- /dev/null
>> +++ b/classes/qemuboot-xilinx.bbclass
>> @@ -0,0 +1,27 @@
>> +
>> +inherit qemuboot
>> +
>> +# enable the overrides for the context of the conf only
>> +OVERRIDES .= ":qemuboot-xilinx"
>> +
>> +# setup the target binary
>> +QB_SYSTEM_NAME_prepend = "qemu-xilinx/"
>> +
>> +# Default machine targets for Xilinx QEMU (FDT Generic)
>> +QB_MACHINE_aarch64 = "-machine arm-generic-fdt"
>> +QB_MACHINE_arm = "-machine arm-generic-fdt-plnx"
>
> Hey Nathan,
>
> This should be: "arm-generic-fdt-7series", that name is the old name
>
>> +QB_MACHINE_microblaze = "-machine microblaze-generic-fdt"
>
> This should be "microblaze-generic-fdt-plnx", I'm not sure why this
> wasn't always this.
>>>
>>> I just moved them from the .inc to the .bbclass. You should ask past
>>> Alistair why he used those values ;). They are currently not used, but
>>> i've updated the patch to make them the values you provided above.
>>
>> Yeah, I know. Past Alistair didn't know what he was doing apparently.
>>
>> Thanks for updating it.
>>
>>>
>
>> +
>> +# defaults
>> +QB_DEFAULT_KERNEL ?= "none"
>
> For the newer QEMU builds (my other patch that hangs after ATF) we
> need to ensure that QB_DEFAULT_KERNEL is NULL when booting Xilinx's
> fork of QEMU. It appears that using the QEMU -kernel loader must
> somehow overwrite images that we want to boot which is why the boot
> fails.
>
> Adding a QB_DEFAULT_KERNEL_qemuboot-xilinx = "none" in
> machine-xilinx-qemu.inc fixes the issue, can you add that in

Re: [meta-xilinx] [PATCH] qemu: Update to the 2017.1 release

2017-04-27 Thread Nathan Rossi 
On 26 April 2017 at 03:42, Alistair Francis  wrote:
> On Thu, Apr 20, 2017 at 3:39 AM, Nathan Rossi  wrote:
>> On 20 April 2017 at 08:57, Alistair Francis  
>> wrote:
>>> Update the QEMU and QEMU device tree commit SHAs to the 2017.1 release.
>>
>> Looks like this needs some corresponding qemuboot config changes for
>> zcu102? With this update the boot hangs just after ATF, see below:
>>
>> NOTICE:  ATF running on XCZUUNKN/QEMU v1/RTL0.0 at 0xfffea000
>> NOTICE:  BL31: Secure code at 0x6000
>> NOTICE:  BL31: Non secure code at 0x800
>> NOTICE:  BL31: v1.2(release):a9e3716615
>> NOTICE:  BL31: Built : 17:03:41, Apr 20 2017
>>
>> <>
>
> Hey Nathan,
>
> I have figured out what causes the hang, I'll reply to your other
> patch with some comments.
>
> Thanks for pointing this out.
>
> Alistair
>
>>
>> Regards,
>> Nathan
>>
>>>
>>> Signed-off-by: Alistair Francis 

Applied.

Thanks,
Nathan

>>> ---
>>>  recipes-devtools/qemu/qemu-devicetrees_2017.1.bb | 2 +-
>>>  recipes-devtools/qemu/qemu-xilinx_2017.1.bb  | 2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/recipes-devtools/qemu/qemu-devicetrees_2017.1.bb 
>>> b/recipes-devtools/qemu/qemu-devicetrees_2017.1.bb
>>> index c51751e..dc38f75 100644
>>> --- a/recipes-devtools/qemu/qemu-devicetrees_2017.1.bb
>>> +++ b/recipes-devtools/qemu/qemu-devicetrees_2017.1.bb
>>> @@ -7,7 +7,7 @@ inherit deploy
>>>
>>>  LIC_FILES_CHKSUM = 
>>> "file://Makefile;beginline=1;endline=27;md5=7348b6cbcae69912cb1dee68d6c68d99"
>>>
>>> -SRCREV = "1085e32a9ddc232963512923332094a58a05d1af"
>>> +SRCREV = "294ffabc02d8a3933f7acfb225648966af8d"
>>>  SRC_URI = 
>>> "git://github.com/Xilinx/qemu-devicetrees.git;protocol=https;nobranch=1"
>>>
>>>  S = "${WORKDIR}/git"
>>> diff --git a/recipes-devtools/qemu/qemu-xilinx_2017.1.bb 
>>> b/recipes-devtools/qemu/qemu-xilinx_2017.1.bb
>>> index 8fba4d1..f149da0 100644
>>> --- a/recipes-devtools/qemu/qemu-xilinx_2017.1.bb
>>> +++ b/recipes-devtools/qemu/qemu-xilinx_2017.1.bb
>>> @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = " \
>>> 
>>> file://COPYING.LIB;endline=24;md5=c04def7ae38850e7d3ef548588159913 \
>>> "
>>>
>>> -SRCREV = "a83265d7403ee49c9a911c920961ef29deac96eb"
>>> +SRCREV = "45d810957b0f837a5685fbe4bc8d9e3268c1fe64"
>>>  SRC_URI = "git://github.com/Xilinx/qemu.git;protocol=https;nobranch=1"
>>>
>>>  S = "${WORKDIR}/git"
>>> --
>>> 2.11.0
>>>
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 0/9] Fixes for pyro and general updates

2017-04-27 Thread Nathan Rossi 
On 20 April 2017 at 20:35, Nathan Rossi  wrote:
> This series includes fixes for changes that have occurred for the
> oe-core pyro release as well as some changes to existing functionality.
>
> Summary of changes:
>   * Fix up depends on unzip vs unzip-native for zybo-linux-bd.bb
>   * Fix up README formatting
>   * Remove linux-yocto version pinning, always default to the newest
>   * Enable ZYNQMP_PM_API_DEBUGFS for linux-xlnx kernels
>   * Remove MACHINE_DEVICETREE support
>   * Update qemuboot/qemu-xilinx support for using Xilinx's QEMU
>
> Nathan Rossi (9):
>   zybo-linux-bd.bb: Depend on unzip-native instead of unzip
>   machine-xilinx-default.inc: Remove linux-yocto version pinning
>   README.*: Fix up bullet point nesting
>   README.booting.md: Update and add notes
>   linux/config: Enable ZYNQMP_PM_API_DEBUGFS for linux-xlnx kernels
>   device-tree.bbappend: Move use of MACHINE_DEVICETREE to SRC_URI
>   machine-xilinx-qemu.inc: Don't use MACHINE_DEVICETREE for dtb
> detection
>   device-tree: Improve, clean up and remove MACHINE_DEVICETREE
>   qemuboot-xilinx.bbclass: Rework qemu-xilinx setup

Merged this series.

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

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

2017-04-27 Thread Nathan Rossi 
On 27 April 2017 at 08:21, Manjukumar Harthikote Matha
 wrote:
>
>
>> -Original Message-
>> From: Philip Balister [mailto:phi...@balister.org]
>> Sent: Wednesday, April 26, 2017 12:38 PM
>> To: Manjukumar Harthikote Matha ; Nathan Rossi
>> 
>> Cc: meta-xil...@lists.yoctoproject.org
>> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default to 
>> u-boot for
>> Zynq
>>
>> On 04/26/2017 03:06 PM, Manjukumar Harthikote Matha wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Nathan Rossi [mailto:nat...@nathanrossi.com]
>> >> Sent: Wednesday, April 26, 2017 10:54 AM
>> >> To: Manjukumar Harthikote Matha 
>> >> Cc: meta-xil...@lists.yoctoproject.org
>> >> Subject: Re: [meta-xilinx] [PATCH] machine-xilinx-default.inc:
>> >> Default to u-boot for Zynq
>> >>
>> >> On 27 April 2017 at 02:41, Manjukumar Harthikote Matha
>> >>  wrote:
>> >>>
>> >>>
>>  -Original Message-
>>  From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>>  boun...@yoctoproject.org] On Behalf Of Nathan Rossi
>>  Sent: Wednesday, April 26, 2017 4:57 AM
>>  To: meta-xil...@lists.yoctoproject.org
>>  Subject: [meta-xilinx] [PATCH] machine-xilinx-default.inc: Default
>>  to u-boot for Zynq
>> 
>>  Upstream U-Boot provides an almost complete environment for the
>>  majority of Zynq targets and specifically covers all the boot
>>  functionality required for the boards in the meta-xilinx layer. As
>>  such default to
>> >> the mainline version of U-Boot.
>> 
>>  For users that require or prefer to use u-boot-xlnx this can be
>>  selected on a per- machine basis using:
>> 
>>    PREFERRED_PROVIDER_virtual/bootloader = "u-boot-xlnx"
>> 
>>  Signed-off-by: Nathan Rossi 
>>  ---
>>   conf/machine/include/machine-xilinx-default.inc | 1 +
>>   1 file changed, 1 insertion(+)
>> 
>>  diff --git a/conf/machine/include/machine-xilinx-default.inc
>>  b/conf/machine/include/machine-xilinx-default.inc
>>  index 13e4df5746..f9e7e3a33f 100644
>>  --- a/conf/machine/include/machine-xilinx-default.inc
>>  +++ b/conf/machine/include/machine-xilinx-default.inc
>>  @@ -19,6 +19,7 @@ PREFERRED_VERSION_linux-xlnx ?= "4.6-xilinx-v2016.4%"
>> 
>>   # U-Boot Configuration
>>   XILINX_DEFAULT_UBOOT := "u-boot-xlnx"
>>  +XILINX_DEFAULT_UBOOT_zynq := "u-boot"
>>   XILINX_DEFAULT_UBOOT_zynqmp := "u-boot"
>> >>>
>> >>> Why have any preferred_provider? Distro can provide these settings.
>> >>> For ex: meta-petalinux can provide u-boot-xlnx, oe-core can provide
>> >>> u-boot
>> >>>
>> >>> Any thoughts?
>> >>
>> >> Unfortunately not picking a provider for "virtual/bootloader" will
>> >> result in bitbake attempting to build all providers (since
>> >> EXTRA_IMAGEDEPENDS is depending on virtual/bootloader), as bitbake
>> >> has no idea which one is desired (and they are all compatible).
>> >>
>> >> --
>> >> NOTE: multiple providers are available for virtual/bootloader
>> >> (u-boot-xlnx, u-boot- xlnx-dev, u-boot)
>> >> NOTE: consider defining a PREFERRED_PROVIDER entry to match
>> >> virtual/bootloader ...
>> >> ERROR: Multiple .bb files are due to be built which each provide
>> >> virtual/bootloader ...
>> >> 
>> >> --
>> >>
>> >> Also note, meta-petalinux or other layers should already be able to
>> >> override this default (by setting with ??=) either in a distro conf
>> >> or in a machine conf e.g. zynq- generic (for meta-petalinux).
>> >>
>> > If this is the case then why meta-xilinx should peg to upstream u-boot by 
>> > default?
>> It should peg to u-boot-xlnx or linux-xlnx by default. We know that there are
>> patches/drivers which are not upstreamed yet, and only available in Xilinx 
>> specific
>> tree. This layer is specific to Xilinx updates and should stick to defaults 
>> supported by
>> Xilinx. Other distros or layer stack which use meta-xilinx should override 
>> depending
>> on their requirements not the other way round.

It should be noted that Xilinx does work with upstream U-Boot, since
Xilinx has an active maintainer (and active contributors). I would
call that support, but that is open to your own interpretation.

>> > PREFERRED_PROVIDER_virtual/bootloader = "u-boot" should be specific to 
>> > boards
>> other than the Xilinx eval boards, for example in zybo/microzed.
>>
>> I'd be happiest if meta-xilinx used upstream u-boot and a bbappend to add 
>> patches
>> that are not upstream yet. This way we (the consumers) know exactly what the 
>> delta
>> is to upstream.
>>
> Yes agreed on the methodology, that it would be the best if we maintained 
> patchset on top upstream master for u-boot or kernel.
> But currently we don't have this model, and pinning down meta-xilinx to 
> upstream u-boot by default and not fetching Xilinx specific trees is not the

Re: [meta-xilinx] Nothing PROVIDES 'python3-pyyaml-native'

2017-04-27 Thread Jean-Francois Dagenais 

> On Apr 26, 2017, at 21:44, Giuseppe Di Guglielmo 
>  wrote:
> 
> Updating the URLs to github.com/Xilinx  generates 
> the following errors that I do not know how to fix. Do you have any idea? 
> 
> It may be a proble with the revision numbers coded in the *.bb files.
> 
> Giuseppe
> 
> ERROR: An uncaught exception occurred in runqueue 
> | ETA:  0:00:03
> Traceback (most recent call last):
>   File 
> "/home/giuseppe/research/projects/zynq/yocto/poky/bitbake/lib/bb/runqueue.py",
>  line 948, in RunQueueData.p
> repare():
>  (mc, fn, taskname, taskfn) = split_tid_mcfn(tid)
> >self.runtaskentries[tid].hash = 
> bb.parse.siggen.get_taskhash(taskfn, taskname, procdep,
> self.dataCaches[mc])
>  task = self.runtaskentries[tid].task
>   File 
> "/home/giuseppe/research/projects/zynq/yocto/poky/meta/lib/oe/sstatesig.py", 
> line 139, in SignatureGenerat
> orOEBasicHash.get_taskhash(fn='/home/giuseppe/research/projects/zynq/yocto/meta-xilinx-tools/recipes-bsp/fsbl/fsbl_git.bb
>  ', task='do_fetch', deps=[], dataCache= object at 0x7fe5b4301ba8>):
>  def get_taskhash(self, fn, task, deps, dataCache):
> >h = super(bb.siggen.SignatureGeneratorBasicHash, 
> self).get_taskhash(fn, task, deps, dataCache)
> 

Are you sure you changed the URL on the right .bb file? It looks like it's the 
fsbl recipe that is failing it's "do_fetch" step (fsbl_git.bb in your error log)

If that still doesn't work, disregard my advice and see with the "real" xilinx 
guys to chime in ;) Yocto has a steep learning slope. Deciphering these error 
logs can be a pain, especially in the beginning.

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