On 22-08-17 20:04, Manjukumar Harthikote Matha wrote:
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 cons
I managed to get it booting with some manual work.
- The meta-xilinx overlay delivers the ATF and PMU firmware.
- My own layer delivers u-boot and kernel and devicetree for my own board
The FSBL I've manually built using Vivado/SDK. The trick to get that working
was that Vivado version >= 2017
On 22-08-17 20:08, Manjukumar Harthikote Matha wrote:
Hi Mike,
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
Ple
> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> Sent: Tuesday, August 22, 2017 12:03 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] [PATCH] layer.conf: Add "meta-python" as a l
Hi Giordon,
meta-xilinx-tools with xsct in your path would enable the same way , instead of
using the Vivado GUI to generate fsbl/pmu/boot.bin
http://www.wiki.xilinx.com/Using+meta-xilinx-tools+layer
Thanks,
Manju
From: meta-xilinx-boun...@yoctoproject.org
[mailto:meta-xilinx-boun...@yoctoproj
Hi Mike,
> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> Sent: Tuesday, August 22, 2017 12:54 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] meta-xilinx-tools fails on "device-t
> -Original Message-
> From: Manjukumar Harthikote Matha
> Sent: Tuesday, August 22, 2017 11:14 AM
> To: 'Mike Looijmans' ; meta-xilinx@yoctoproject.org
> Subject: RE: [meta-xilinx] meta-xilinx-tools fails on
> "device-tree-generation" script
>
> Hi Mike,
>
> > -Original Message---
Hi Mike,
> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> Sent: Tuesday, August 22, 2017 1:05 AM
> To: meta-xilinx@yoctoproject.org
> Subject: [meta-xilinx] [PATCH] u-boot-xlnx: does not depend
Hi Manju,
Were there changes recently to get this working? When I tried
meta-xilinx-tools back when I wrote the wiki as a second option instead of
going through the GUI -- I kept getting stuck on the PMU FW portion and was
unable to get the board to continue booting (instead it would do a kernel
p
On Tue, Aug 22, 2017 at 7:33 AM, Nathan Rossi wrote:
> Limit the appending/enabling of the zynqmp-pmu BBCLASSEXTEND to only
> specific recipes which are used for the building of pmu-firmware. This
> is just binutils, gcc, newlib, libgloss and pmu-firmware itself.
>
> The limiting is done based on
On Tue, Aug 22, 2017 at 7:31 AM, Nathan Rossi wrote:
> On 22 August 2017 at 04:07, Alistair Francis
> wrote:
>> 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 s
On Tue, Aug 22, 2017 at 7:30 AM, Nathan Rossi wrote:
> On 22 August 2017 at 04:07, Alistair Francis
> wrote:
>> Backport a mainline ATF patch to the Xilinx tree in order to fix the ATF
>> build.
>>
>> Signed-off-by: Alistair Francis
>
> Applied.
Thanks, this will also be fixed in the 2017.3 rel
Hi,
I'll share my experiences as it has been somewhat painful -- but I did
manage to have success booting from an SD card directly for MPSOC. I'm
working on QSPI boot -- but I wrote my experiences/guide here:
https://github.com/kratsg/meta-l1calo/wiki/ZynqMP:-Prepare-and-Boot-Hardware
You can al
When using multilib the MULTILIB_VARIANTS variable is populated, this
triggers differing code paths in certain recipes. These are not desired
for the firmware building, since they modify the install paths.
Also set the DEFAULTTUNE to avoid changes to BASELIB/baselib when
multilib is used, as it at
Limit the appending/enabling of the zynqmp-pmu BBCLASSEXTEND to only
specific recipes which are used for the building of pmu-firmware. This
is just binutils, gcc, newlib, libgloss and pmu-firmware itself.
The limiting is done based on the BPN of the recipe, which is not
provided as an override so
On 22 August 2017 at 06:37, Alistair Francis wrote:
> On Mon, Aug 21, 2017 at 2:20 AM, Nathan Rossi wrote:
>> Limit the appending/enabling of the zynqmp-pmu BBCLASSEXTEND to only
>> specific recipes which are used for the building of pmu-firmware. This
>> is just binutils, gcc, newlib, libgloss a
On 22 August 2017 at 04:07, Alistair Francis
wrote:
> 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_
On 22 August 2017 at 04:07, Alistair Francis
wrote:
> Backport a mainline ATF patch to the Xilinx tree in order to fix the ATF
> build.
>
> Signed-off-by: Alistair Francis
Applied.
Thanks,
Nathan
> ---
> .../arm-trusted-firmware/arm-trusted-firmware.inc | 2 ++
> .../arm-trusted-firmware_20
u-boot-xlnx_%.bbappend forces a non-existent dependency between u-boot-xlnx
and virtual/dtb. Nothing in u-boot references this dtb, so remove the bbappend.
Signed-off-by: Mike Looijmans
---
recipes-bsp/u-boot/u-boot-xlnx_%.bbappend | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 recipes
I added "meta-xilinx-tools" to my layers and start a build for the zcu102
board.
I'm running into this error:
mike@mikebuntu:~/projects/xilinx-platform/build$ bitbake
core-image-minimalLoading cache: 100%
|##| Time: 0:00:00
Lo
Attempting to build this layer results in the following error:
ERROR: Nothing PROVIDES 'python3-pyyaml-native'. Close matches:
python3-rpm-native
python3-pycurl-native
python3-pygpgme-native
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable
21 matches
Mail list logo
