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

[Mike Looijmans]

In 'warrior', the ATF loading was changed in u-boot and now uses a FIT image 
for uboot+atf. The hack that loads ATF as 'kernel' and u-boot as its 
devicetree is no longer working properly there.

I got this working for the miami MPSoC module using this recipe:
https://github.com/topic-embedded-products/meta-topic/blob/warrior-next/recipes-bsp/u-boot/u-boot-xlnx_2019.1.bbappend

It's the "mkimage" command that's key here.


As for the PMU, I just build a 'patched' version once using a separate build 
environment so I don't have to mess around with multiconfig. The binary it 
produces is the same for all boards and configurations anyway (there's one 
Xilinx evaluation board that's an exception to that though), so just 
considering it a firmware 'blob' works well enough. So unless you have a board 
where the PMU needs to so something, you can just use the meta-topic pre-built 
binary pmu firmware for any zynqmp board, since it contains a sort of "yes to 
all" patch that allows all peripherals (including second SD and both SPI 
ports) to work.



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: {E-mail
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 23-10-19 13:32, Adrian Fiergolski wrote:
> Hi,
> 
> I am experiencing issue booting a custom board based on ZynqMP+ device. The 
> boot process stops at ATF:
> 
> U-Boot SPL 2019.01 (Oct 23 2019 - 10:34:53 +)
> EL Level:   EL3
> Trying to boot from MMC2
> NOTICE:  ATF running on XCZU6EG/silicon v4/RTL5.1 at 0xfffea000
> NOTICE:  BL31: Secure code at 0x0
> NOTICE:  BL31: Non secure code at 0x800
> NOTICE:  BL31: v2.0(release):xilinx-v2019.1
> NOTICE:  BL31: Built : 15:12:20, Oct 22 2019
> 
> I checked with debugger and apparently, ATF fails to launch u-boot image.
> 
> As mu setup, what is reflected properly in the device-tree, uses 2 SD 
> controllers, just as a precaution, I applied two patches on PMU (link 
> <https://github.com/topic-embedded-products/meta-topic/tree/master/recipes-bsp/pmu-firmware/pmu-firmware>),
>  
> including the one enabling NODE_SD0 for the cores.
> 
> Has anybody experienced a similar issue? Can somebody confirm a successful 
> run 
> of ZynqMP+ based platform with warrior branch?
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Building Linux 5.2 for Zynq with Yocto

[Mike Looijmans]

You may want to try building a "similar" kernel first, so start with 4.14 or 
4.19.

I made a 'mainline' recipe for the topic boards (also zynq7) a while back, 
here's what the recipe looked like:

https://github.com/topic-embedded-products/meta-topic/blob/mainline-kernel-4.17/recipes-kernel/linux-zynq/linux-mainline.bb

this may help you get started.


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: {E-mail
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 27-09-19 16:42, Franz Forstmayr wrote:
> Hi Mike,
> 
> yeah I thought so too, but I'm unable to build the kernel. I get
> always the error no rule to make target uImage , see below.
> This test is fine without having an optimized NAND/QSPI driver.
> The only thing I changed in the Xilinx recipe are:
> 
> LINUX_VERSION = "5.2"
> KBRANCH = "master"
> SRCREV = "0ec"
> 
> # Add zynq defconfig here as it's not mainline
> SRC_URI_append = " file://git/arch/arm/configs/xilinx_zynq_defconfig "
> 
> Build Configuration:
> BB_VERSION   = "1.40.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "zedboard-zynq7"
> DISTRO   = "poky"
> DISTRO_VERSION   = "2.6.3"
> TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> cortexa9"
> TARGET_FPU   = "hard"
> meta
> meta-poky= "thud:e6949336479e611a142834b6d9241514cbaeaf80"
> meta-xilinx-bsp  = "rel-v2019.1:f4c53cc332397b5e5ee17f42169f7c87808c9dc7"
> meta-xilinx-tools= "master:881132b62dc01e57b8d9ace458a0005528179e14"
> meta-oe
> meta-python = "thud:2d088d252624b19df384aecc434d23afb636178f"
> 
> Initialising tasks: 100% |###| Time: 
> 0:00:00
> Sstate summary: Wanted 7 Found 0 Missed 7 Current 68 (0% match, 90% complete)
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: linux-xlnx-5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0
> do_compile: oe_runmake failed
> ERROR: linux-xlnx-5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0
> do_compile: Function failed: do_compile (log file is located at
> /media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/temp/log.do_compile.13182)
> ERROR: Logfile of failure stored in:
> /media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/temp/log.do_compile.13182
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 8 HOSTCC=gcc
> -isystem/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/usr/include
> -O2 -pipe 
> -L/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/usr/lib
> -L/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/lib
> -Wl,-rpath-link,/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/usr/lib
> -Wl,-rpath-link,/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/lib
> -Wl,-rpath,/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/usr/lib
> -Wl,-rpath,/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0/recipe-sysroot-native/lib
> -Wl,-O1 -Wl,--allow-shlib-undefined
> -Wl,--dynamic-linker=/media/franz/HDD_Linux/yocto/zynq/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
> HOSTCPP=gcc  -E uImage CC=arm-poky-linux-gnueabi-gcc
> -mno-thumb-interwork -marm -fuse-ld=bfd
> -fdebug-prefix-map=/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0=/usr/src/debug/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4d856f72c1-r0
> -fdebug-prefix-map=/media/franz/HDD_Linux/yocto/zynq/tmp/work/zedboard_zynq7-poky-linux-gnueabi/linux-xlnx/5.3-xilinx-v2019.1+gitAUTOINC+4

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

[Mike Looijmans]

On 16-07-19 18:32, Jean-Francois Dagenais wrote:
> 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.
> 

Never encountered any problems with that, and there are quite a few 
alternatives for busybox for example.

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

Maybe there's something funky in the recipe that triggers bad behaviour in 
update-alternatives?
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

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

[Mike Looijmans]

On 07-06-19 04:33, Jean-Francois Dagenais wrote:

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.



It's quicker and simpler to just skip the multiconfig and build just once for 
the "pmu" machine and then for the actual machine.



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



The FPGA programming is actually done by a DMA transfer into a "keyhole". The 
PMU just hides away the registers that initiate the transfer, but isn't 
actively involved.


The FPGA can also be programmed from within Linux, and you can even reprogram 
the FPGA (or parts thereof) through the FPGA itself (which is actually faster 
than by CPU) once it has been programmed...



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] Build and boot zcu106 image

[Mike Looijmans]

On 05-06-19 08:03, Mike Looijmans wrote:

On 04-06-19 15:26, Manjukumar Harthikote Matha wrote:

Hi Mike,


-Original Message-
From: meta-xilinx-boun...@yoctoproject.org  On Behalf Of Mike Looijmans
Sent: Tuesday, June 4, 2019 6:09 AM
To: Luca Ceresoli ; Manjukumar Harthikote Matha
; meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Build and boot zcu106 image

On 04-06-19 14:58, Luca Ceresoli wrote:

Hi Mike,

On 04/06/19 07:41, Mike Looijmans wrote:

On 03-06-19 16:25, Manjukumar Harthikote Matha wrote:

Hi Mike,


-Original Message-
From: meta-xilinx-boun...@yoctoproject.org  On Behalf Of Mike Looijmans
Sent: Monday, June 3, 2019 7:01 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Build and boot zcu106 image

Got a zcu106 board here to experiment with. With pre-built stuff,
the board boots okay.

I cloned OpenEmbedded and meta-xilinx "thud" branches, made no

changes.


Built the PMU firmware and core-image-minimal for machine zcu106-

zynqmp.




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



And what is the solution?


There's nothing "machine" dependent in the PMU recipe, so all ZynqMP
machines will build the exact same binary. Right?



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


My first attempt was actually to use my "standard" PMU stuff (patched
PMU with built-in config object) for the image, but that also
delivered the same error.


My SPL patch is just moving the cfg loading in a different place. It
would not solve your problem.

Just guessing, are you using the pm_cfg_obj.c produced by XDSK for
your FPGA design or an "enable-all" config?



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




I tried to use the "enable all" config I also use on our custom boards. In 
theory,

that should work on any board, right?

I also tried "whatever meta-xilinx delivers by default".

As for "pm_cfg_obj.c produced by XDSK", I have no clue as to how to do that,
but I'm guessing Google can help me out with that. Do you think it'd make a
difference?


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



Thanks,
Manju




I patched pmu-firmware to also include the mysterious GPIO mapping for the 
zcu106 board. No change, still only get that crash.




Could someone at Xilinx please humor us and actually build a bootloader using 
meta-xilinx-bsp "as is", i.e. using SPL, and see what happens on the zcu106 
board? I get the impression that the PMU isn't involved here.


Symptoms when the PMU isn't configured are different - at least, on OTHER 
boards. You'd first see it run u-boot SPL and then some error that e.g. a 
clock cannot be configured. Regardless of the PMU firmware, they still manage 
to get into u-boot SPL.


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

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

[Mike Looijmans]

On 04-06-19 15:26, Manjukumar Harthikote Matha wrote:

Hi Mike,


-Original Message-
From: meta-xilinx-boun...@yoctoproject.org  On Behalf Of Mike Looijmans
Sent: Tuesday, June 4, 2019 6:09 AM
To: Luca Ceresoli ; Manjukumar Harthikote Matha
; meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] Build and boot zcu106 image

On 04-06-19 14:58, Luca Ceresoli wrote:

Hi Mike,

On 04/06/19 07:41, Mike Looijmans wrote:

On 03-06-19 16:25, Manjukumar Harthikote Matha wrote:

Hi Mike,


-Original Message-
From: meta-xilinx-boun...@yoctoproject.org  On Behalf Of Mike Looijmans
Sent: Monday, June 3, 2019 7:01 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Build and boot zcu106 image

Got a zcu106 board here to experiment with. With pre-built stuff,
the board boots okay.

I cloned OpenEmbedded and meta-xilinx "thud" branches, made no

changes.


Built the PMU firmware and core-image-minimal for machine zcu106-

zynqmp.




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



And what is the solution?


There's nothing "machine" dependent in the PMU recipe, so all ZynqMP
machines will build the exact same binary. Right?



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


My first attempt was actually to use my "standard" PMU stuff (patched
PMU with built-in config object) for the image, but that also
delivered the same error.


My SPL patch is just moving the cfg loading in a different place. It
would not solve your problem.

Just guessing, are you using the pm_cfg_obj.c produced by XDSK for
your FPGA design or an "enable-all" config?



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



I tried to use the "enable all" config I also use on our custom boards. In 
theory,
that should work on any board, right?

I also tried "whatever meta-xilinx delivers by default".

As for "pm_cfg_obj.c produced by XDSK", I have no clue as to how to do that,
but I'm guessing Google can help me out with that. Do you think it'd make a
difference?


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


Thanks,
Manju




I patched pmu-firmware to also include the mysterious GPIO mapping for the 
zcu106 board. No change, still only get that crash.


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

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

[Mike Looijmans]

On 04-06-19 14:58, Luca Ceresoli wrote:

Hi Mike,

On 04/06/19 07:41, Mike Looijmans wrote:

On 03-06-19 16:25, Manjukumar Harthikote Matha wrote:

Hi Mike,


-Original Message-
From: meta-xilinx-boun...@yoctoproject.org  On Behalf Of Mike Looijmans
Sent: Monday, June 3, 2019 7:01 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Build and boot zcu106 image

Got a zcu106 board here to experiment with. With pre-built stuff, the
board
boots okay.

I cloned OpenEmbedded and meta-xilinx "thud" branches, made no changes.

Built the PMU firmware and core-image-minimal for machine zcu106-zynqmp.



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



And what is the solution?


There's nothing "machine" dependent in the PMU recipe, so all ZynqMP
machines will build the exact same binary. Right?

My first attempt was actually to use my "standard" PMU stuff (patched
PMU with built-in config object) for the image, but that also delivered
the same error.


My SPL patch is just moving the cfg loading in a different place. It
would not solve your problem.

Just guessing, are you using the pm_cfg_obj.c produced by XDSK for your
FPGA design or an "enable-all" config?



I tried to use the "enable all" config I also use on our custom boards. In 
theory, that should work on any board, right?


I also tried "whatever meta-xilinx delivers by default".

As for "pm_cfg_obj.c produced by XDSK", I have no clue as to how to do that, 
but I'm guessing Google can help me out with that. Do you think it'd make a 
difference?









Thanks,
Manju

Copied the usual files onto an SD card: atf-uboot.ub boot.bin Image
system.dtb
u-boot.bin uEnv.txt zynqmp-zcu106-revA.dtb

Put the card in the board and switch it on. All I get is this:

 Debug uart enabled
"Synchronous Abort" handler, esr 0x9640
ELR: fffc9e70
LR:  fffc6c78
x0 : fdfd00011dfdfe5d x1 : 
x2 : 0202020201a3 x3 : fdfd00011dfdfe5d
x4 :  x5 : 
x6 : 7f20 x7 : 0005
x8 : 00ad x9 : 0080
x10: fffd x11: 0064
x12: fe6a x13: 60f8a90300b080a0
x14: 8a10070a4265 x15: a5cc22ca484081d9
x16: 385a360321460003 x17: 9b800c890e560844
x18: 7e90 x19: 2000
x20:  x21: fdfd00011dfdfe5d
x22:  x23: 0001
x24: 7f20 x25: fffdae68
x26: fffdae68 x27: fffdb000
x28:  x29: 7c10

Resetting CPU ...

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


What does one have to do to actually boot that board with meta-xilinx?
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx






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

Re: [meta-xilinx] VCU usage on xilinx UZ3EG

[Mike Looijmans]

Simplest way to reduce CPU usage is to use video-for-Linux directly (it's 
quite simple actually). This will give you access to the "raw" stream from the 
camera, which is usually in YUV or MJPEG format (OpenCV forcibly converts 
everything to RGB which makes for easy programming but horrible CPU consumption).


If the USB camera provides MJPEG or H264/H265 data, you can indeed use the VCU 
to decode it. In theory.


For YUV data, you can use the MALI GPU or the programmable logic to convert it 
to RGB (if you need RGB data to begin with...). The VCU isn't much use there.


For further CPU reduction, you'll have to use something else than USB (e.g. 
mipi, dvi, hdmi, parallel data) directly into logic so the CPU isn't involved 
in the data transfer at all.



On 04-06-19 06:48, Sami Md wrote:

Hi,

We are using Xilinx UltraScale UZ3EG MpSoc

we are using OpenCV to capture the video stream from USB Camera node /dev/video0

but the CPU utilization is not good, it consumes around 80% of the CPU.

To reduce the CPU consumption, we would like use the VCU  available on UZ3EG.

Kindly let us know if there are any sample applications to demonstrate the 
working of VCU.


any links would be helpful.

Thanks and Best Regards

Sami




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

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

[Mike Looijmans]

On 03-06-19 16:25, Manjukumar Harthikote Matha wrote:
> Hi Mike,
> 
>> -Original Message-
>> From: meta-xilinx-boun...@yoctoproject.org > boun...@yoctoproject.org> On Behalf Of Mike Looijmans
>> Sent: Monday, June 3, 2019 7:01 AM
>> To: meta-xilinx@yoctoproject.org
>> Subject: [meta-xilinx] Build and boot zcu106 image
>>
>> Got a zcu106 board here to experiment with. With pre-built stuff, the board
>> boots okay.
>>
>> I cloned OpenEmbedded and meta-xilinx "thud" branches, made no changes.
>>
>> Built the PMU firmware and core-image-minimal for machine zcu106-zynqmp.
>>
> 
> I had similar issue! I think the PMU default config objects in SPL flow does 
> not work.
> Luca had config object which worked for him.


And what is the solution?


There's nothing "machine" dependent in the PMU recipe, so all ZynqMP machines 
will build the exact same binary. Right?

My first attempt was actually to use my "standard" PMU stuff (patched PMU with 
built-in config object) for the image, but that also delivered the same error.


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

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

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

[Mike Looijmans]

On 03-06-19 16:25, Manjukumar Harthikote Matha wrote:

Hi Mike,


-Original Message-
From: meta-xilinx-boun...@yoctoproject.org  On Behalf Of Mike Looijmans
Sent: Monday, June 3, 2019 7:01 AM
To: meta-xilinx@yoctoproject.org
Subject: [meta-xilinx] Build and boot zcu106 image

Got a zcu106 board here to experiment with. With pre-built stuff, the board
boots okay.

I cloned OpenEmbedded and meta-xilinx "thud" branches, made no changes.

Built the PMU firmware and core-image-minimal for machine zcu106-zynqmp.



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



And what is the solution?


There's nothing "machine" dependent in the PMU recipe, so all ZynqMP machines 
will build the exact same binary. Right?


My first attempt was actually to use my "standard" PMU stuff (patched PMU with 
built-in config object) for the image, but that also delivered the same error.





Thanks,
Manju

Copied the usual files onto an SD card: atf-uboot.ub boot.bin Image system.dtb
u-boot.bin uEnv.txt zynqmp-zcu106-revA.dtb

Put the card in the board and switch it on. All I get is this:

 Debug uart enabled
"Synchronous Abort" handler, esr 0x9640
ELR: fffc9e70
LR:  fffc6c78
x0 : fdfd00011dfdfe5d x1 : 
x2 : 0202020201a3 x3 : fdfd00011dfdfe5d
x4 :  x5 : 
x6 : 7f20 x7 : 0005
x8 : 00ad x9 : 0080
x10: fffd x11: 0064
x12: fe6a x13: 60f8a90300b080a0
x14: 8a10070a4265 x15: a5cc22ca484081d9
x16: 385a360321460003 x17: 9b800c890e560844
x18: 7e90 x19: 2000
x20:  x21: fdfd00011dfdfe5d
x22:  x23: 0001
x24: 7f20 x25: fffdae68
x26: fffdae68 x27: fffdb000
x28:  x29: 7c10

Resetting CPU ...

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


What does one have to do to actually boot that board with meta-xilinx?
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx


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

[meta-xilinx] Build and boot zcu106 image

[Mike Looijmans]

Got a zcu106 board here to experiment with. With pre-built stuff, the board 
boots okay.


I cloned OpenEmbedded and meta-xilinx "thud" branches, made no changes.

Built the PMU firmware and core-image-minimal for machine zcu106-zynqmp.

Copied the usual files onto an SD card: atf-uboot.ub boot.bin Image system.dtb 
u-boot.bin uEnv.txt zynqmp-zcu106-revA.dtb


Put the card in the board and switch it on. All I get is this:

 Debug uart enabled
"Synchronous Abort" handler, esr 0x9640
ELR: fffc9e70
LR:  fffc6c78
x0 : fdfd00011dfdfe5d x1 : 
x2 : 0202020201a3 x3 : fdfd00011dfdfe5d
x4 :  x5 : 
x6 : 7f20 x7 : 0005
x8 : 00ad x9 : 0080
x10: fffd x11: 0064
x12: fe6a x13: 60f8a90300b080a0
x14: 8a10070a4265 x15: a5cc22ca484081d9
x16: 385a360321460003 x17: 9b800c890e560844
x18: 7e90 x19: 2000
x20:  x21: fdfd00011dfdfe5d
x22:  x23: 0001
x24: 7f20 x25: fffdae68
x26: fffdae68 x27: fffdb000
x28:  x29: 7c10

Resetting CPU ...

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


What does one have to do to actually boot that board with meta-xilinx?
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel

[Mike Looijmans]

On 12-04-19 15:39, Arno Steffens wrote:
> 
> 
>> Gesendet: Mittwoch, 10. April 2019 um 07:39 Uhr
>> Von: "Mike Looijmans" 
>> An: "meta xilinx" 
>> Betreff: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
>>
>> On 07-04-19 11:41, Arno Steffens wrote:
>>> In fact, I think I have difficulties with glitches on the bus, but changes 
>>> at the boards are much more expensive and time consuming - so I'll try to 
>>> get a better stability with that gpio-bitbang driver.
>>>
>>> Thanks Mike, especially for the hints with devicetree. Are this GPIO 
>>> numbers are same as MIO-Pin-numbers? I found that the base-include for zynq 
>>> has been changed completly (at least in my eyes), so it will take some time 
>>> to adapt it to a new kernel.
>>> I created a new bitstream (IO set to GPIO instead of I2C) and (not sure 
>>> whether it is required) a new fsbl.  I don't need I2c in Uboot, but I am 
>>> wondering where this gets information about it. Including driver in kernel 
>>> is smallest issue. So altogether this becomes quite a project for me ;) but 
>>> I hope I learn a lot with that. Did all this steps just once or twice some 
>>> time ago.
>>>
>>
>> GPIO and MIO pin numbers are the same.
>>
>> The bitstream has no efect whatsoever on the MIO pins (Xilinx is very unclear
>> about this), so there's no need to change it.
>>
>> The "pinmux" settings let the kernel change the pin assignments, so there is
>> also no need to alter the bootloader. On the 7-series at least the bootloader
>> only needs enough to boot the system, the kernel can configure everything 
>> else.
>>
> 
> That partly comes to late for me. I digged around (run from one trouble to 
> next with Vivado) but finally come to a simular but not same conclusion. In 
> fact, bitstream doesn't contain pinmux, but FSBL. At least after changing 
> just FSBL i2c doesn't work at all (with old cadence i2c-kernel/devicetree). 
> So kernel/devicetree alone might not be enough (kernel 4.14)

Yeah, Xilinx is very unclear about that stuff. Some of the PS settings 
end up in the bootloader, but quite a lot (like the PS-PL 
intercommunication) doesn't end up anywhere at all and just serves to 
make Vivado show or hide pins on the processor IP.

> I changed kernel for using bitbang instead of cadence i2c driver. But with 
> devicetree I failed. I didn't get a clue how it works in detail and compiler 
> is not very helpful with debug messages. Especially this mixture of 
> zynq-7000.dtsi and dts.
> I finally end up with decompiling my previous devicetree, fiddling your miami 
> devicetree to kernel, run dtbs and decompiled the dtb.
> So I have 2 simplier decompiled devicetrees for a better side by side 
> comparison.
> With adding i2c stuff I get at least something compilable again (see 
> attached), but kernel gives me
> 
> i2c /dev entries driver
> cdns-wdt f8005000.watchdog: Xilinx Watchdog Timer at df8f6000 with timeout 10s
> 
> i2c-gpio gpios-i2c@22: could not find pctldev for node 
> /amba/slcr@f800/pinctrl@700/i2c0-default, deferring probe
> i2c-gpio gpios-i2c@28: could not find pctldev for node 
> /amba/slcr@f800/pinctrl@700/i2c1-default, deferring probe
> 
> So I have I2C0 with GPIO22,23 and I2C1 with 28,29.
> 
> (Without the last i2c entries in dts I don't get this messages, but in 
> neither of the options an entry /dev/i2c-0,1 is created).
> What is wrong/missed?

I think your kernel is lacking the zynq pinmux driver, run the kernel's 
menuconfig and enable it.

If you've already changed the pinmux in the FSBL, you can remove the 
pinmux references "pinctrl-names" and "pinctrl-0" from the gpio driver 
and that should also work, without the pinmux driver that is.

> A nice weekend,

Same!

> 
>>>> Gesendet: Freitag, 05. April 2019 um 07:44 Uhr
>>>> Von: "Mike Looijmans" 
>>>> An: "Arno Steffens" 
>>>> Cc: "meta xilinx" 
>>>> Betreff: Re: Aw: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto 
>>>> kernel
>>>>
>>>> On 04-04-19 14:03, Arno Steffens wrote:
>>>>> Thanks Mike for this clear (and surprising) words.
>>>>> The reason I thought it might help is that functions like this 
>>>>> (cdns_i2c_init_recovery_info) has been added.
>>>>
>>>> Well if you need recovery, something is broken on the bus...
>>>>
>>>>> I'll check the bitbang option. Do I have to expect performance/timing 
>>>>> issues?
>>>>&g

Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel

[Mike Looijmans]

On 07-04-19 11:41, Arno Steffens wrote:
> In fact, I think I have difficulties with glitches on the bus, but changes at 
> the boards are much more expensive and time consuming - so I'll try to get a 
> better stability with that gpio-bitbang driver.
> 
> Thanks Mike, especially for the hints with devicetree. Are this GPIO numbers 
> are same as MIO-Pin-numbers? I found that the base-include for zynq has been 
> changed completly (at least in my eyes), so it will take some time to adapt 
> it to a new kernel.
> I created a new bitstream (IO set to GPIO instead of I2C) and (not sure 
> whether it is required) a new fsbl.  I don't need I2c in Uboot, but I am 
> wondering where this gets information about it. Including driver in kernel is 
> smallest issue. So altogether this becomes quite a project for me ;) but I 
> hope I learn a lot with that. Did all this steps just once or twice some time 
> ago.
> 

GPIO and MIO pin numbers are the same.

The bitstream has no efect whatsoever on the MIO pins (Xilinx is very unclear
about this), so there's no need to change it.

The "pinmux" settings let the kernel change the pin assignments, so there is
also no need to alter the bootloader. On the 7-series at least the bootloader
only needs enough to boot the system, the kernel can configure everything else.

>> Gesendet: Freitag, 05. April 2019 um 07:44 Uhr
>> Von: "Mike Looijmans" 
>> An: "Arno Steffens" 
>> Cc: "meta xilinx" 
>> Betreff: Re: Aw: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto 
>> kernel
>>
>> On 04-04-19 14:03, Arno Steffens wrote:
>>> Thanks Mike for this clear (and surprising) words.
>>> The reason I thought it might help is that functions like this 
>>> (cdns_i2c_init_recovery_info) has been added.
>>
>> Well if you need recovery, something is broken on the bus...
>>
>>> I'll check the bitbang option. Do I have to expect performance/timing 
>>> issues?
>>> I guess I have to adjust devicetree for that too? Phu. Thats always 
>>> magic to me.
>>> Kind regards, Arno
>>
>> Here's our devicetree that sets up the bitbank stuff:
>>
>> https://github.com/topic-embedded-products/linux/blob/topic-miami/arch/arm/boot/dts/topic-miami.dtsi
>>
>> Don't forget to activate the bitbang GPIO I2C driver in the "drivers" section
>> of the kernel configuration as well.
>>
>>>
>>>> Gesendet: Donnerstag, 04. April 2019 um 07:31 Uhr
>>>> Von: "Mike Looijmans" 
>>>> An: "Arno Steffens" , "meta xilinx" 
>>>> 
>>>> Betreff: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
>>>>
>>>> Simple solution would be to just stop using the cadence driver. There are
>>>> issues in the Zynq that cannot really be resolved in software apparently, 
>>>> and
>>>> the only way around them we've found is to just use a bitbang GPIO 
>>>> controller
>>>> on the same pins. That made all problems go away.
>>>>
>>>> Chances are that moving to a newer kernel will not resolve your I2C issues 
>>>> anyway.
>>>>
>>>> On 03-04-19 13:53, Arno Steffens wrote:
>>>>> I need a more recent kernel (Zynq 7000) and wondering, what can I do.
>>>>> Why I am looking for that?
>>>>> I have I2C issues and guess I need the recovery functionality, but the 
>>>>> Cadence I2c driver that supports it is only in the current xilinx master 
>>>>> branch. Even not in mainline 4.19.
>>>>>
>>>>> Before this I2C issue popped up I took a kernel.org LTS kernel and 
>>>>> patch/take over the qspi/dma stuff that I need from the xilinx kernel. 
>>>>> But this time it will not work. What would you recommend me?
>>>>>
>>>>> Just take to master branch? That will probably never work with RT patches 
>>>>> ...
>>>>> The xlx-kernel - Which kernel-org version it is based on?
>>>>>
>>>>> Best regards, Arno

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

Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel

[Mike Looijmans]

On 04-04-19 14:03, Arno Steffens wrote:
> Thanks Mike for this clear (and surprising) words.
> The reason I thought it might help is that functions like this 
> (cdns_i2c_init_recovery_info) has been added.

Well if you need recovery, something is broken on the bus...

> I'll check the bitbang option. Do I have to expect performance/timing issues?
> I guess I have to adjust devicetree for that too? Phu. Thats always magic 
> to me.
> Kind regards, Arno

Here's our devicetree that sets up the bitbank stuff:

https://github.com/topic-embedded-products/linux/blob/topic-miami/arch/arm/boot/dts/topic-miami.dtsi

Don't forget to activate the bitbang GPIO I2C driver in the "drivers" section 
of the kernel configuration as well.

> 
>> Gesendet: Donnerstag, 04. April 2019 um 07:31 Uhr
>> Von: "Mike Looijmans" 
>> An: "Arno Steffens" , "meta xilinx" 
>> 
>> Betreff: Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel
>>
>> Simple solution would be to just stop using the cadence driver. There are
>> issues in the Zynq that cannot really be resolved in software apparently, and
>> the only way around them we've found is to just use a bitbang GPIO controller
>> on the same pins. That made all problems go away.
>>
>> Chances are that moving to a newer kernel will not resolve your I2C issues 
>> anyway.
>>
>> On 03-04-19 13:53, Arno Steffens wrote:
>>> I need a more recent kernel (Zynq 7000) and wondering, what can I do.
>>> Why I am looking for that?
>>> I have I2C issues and guess I need the recovery functionality, but the 
>>> Cadence I2c driver that supports it is only in the current xilinx master 
>>> branch. Even not in mainline 4.19.
>>>
>>> Before this I2C issue popped up I took a kernel.org LTS kernel and 
>>> patch/take over the qspi/dma stuff that I need from the xilinx kernel. But 
>>> this time it will not work. What would you recommend me?
>>>
>>> Just take to master branch? That will probably never work with RT patches 
>>> ...
>>> The xlx-kernel - Which kernel-org version it is based on?
>>>
>>> Best regards, Arno
>>>
>>
>>

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

Re: [meta-xilinx] Kernel version, xilinx git repo, yocto kernel

[Mike Looijmans]

Simple solution would be to just stop using the cadence driver. There are 
issues in the Zynq that cannot really be resolved in software apparently, and 
the only way around them we've found is to just use a bitbang GPIO controller 
on the same pins. That made all problems go away.

Chances are that moving to a newer kernel will not resolve your I2C issues 
anyway.

On 03-04-19 13:53, Arno Steffens wrote:
> I need a more recent kernel (Zynq 7000) and wondering, what can I do.
> Why I am looking for that?
> I have I2C issues and guess I need the recovery functionality, but the 
> Cadence I2c driver that supports it is only in the current xilinx master 
> branch. Even not in mainline 4.19.
> 
> Before this I2C issue popped up I took a kernel.org LTS kernel and patch/take 
> over the qspi/dma stuff that I need from the xilinx kernel. But this time it 
> will not work. What would you recommend me?
> 
> Just take to master branch? That will probably never work with RT patches ...
> The xlx-kernel - Which kernel-org version it is based on?
> 
> Best regards, Arno
> 

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

[Mike Looijmans]

On 25-03-19 09:01, Mike Looijmans wrote:

> I did notice that even on the 7 series programming the FPGA from Linux (using
> fpga-manager framework) is broken in the 2018.3 release now:
> 
> fpga_manager fpga0: writing fpga.bin to Xilinx Zynq FPGA Manager
> fpga_manager fpga0: Error after writing image data to FPGA

Strike that, the problem was that the bistream was for a different FPGA.
-- 
___
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

[Mike Looijmans]

It's definitely the PMU or ATF that causes this.

If I use the 2018.1 ATF and PMU, the SDIO controller performance is okay with 
either the 2018.1 or 2018.3 kernel. With the 2018.3 release of PMU and ATF, 
the SD performance is horrible. I also noticed it stopped USB from working.

Maybe something in the PMU-kernel or ATF-kernel interface has changed and e.g. 
clock settings aren't properly communicated?

Mike

On 21-03-19 14: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?
> 

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

[Mike Looijmans]

On the 7-series, SD performance is as usual:

# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 0.997935 seconds, 20.0MB/s


I did notice that even on the 7 series programming the FPGA from Linux (using 
fpga-manager framework) is broken in the 2018.3 release now:

fpga_manager fpga0: writing fpga.bin to Xilinx Zynq FPGA Manager
fpga_manager fpga0: Error after writing image data to FPGA


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

[Mike Looijmans]

Have only tried the MPSoC.

I haven't tried the 7k yet with 2018.3, may get to that tomorrow. I 
suspect it's something with the PMU interface and/or clock dividers.


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


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

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

[Mike Looijmans]

On 20-03-19 18:46, Manjukumar Harthikote Matha wrote:
> Hi Mike,
> 
> We tested by loading  both the vivado generated and bootgen generated 
> bitstreams using 2018.3 and it worked fine, we are able to see Done and leds 
> glowing as per our design.
> 
> Is it a custom board or zcu102?

Custom board (the Xilinx Drone Platform actually)

> Do you need this patch on thud?
> 
> https://github.com/Xilinx/meta-xilinx/commit/2c98fa11ccf33b6d9a550bebf50d2a2a876f9afb

Might be, from the description it sounds like "the FPGA
configuration code is non-functional" is what I'm experiencing here.

> 
> Thanks,
> 
> Manju
> 
>  > -Original Message-
> 
>  > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> 
>  > boun...@yoctoproject.org] On Behalf Of Mike Looijmans
> 
>  > Sent: Wednesday, March 13, 2019 6:10 AM
> 
>  > To: meta-xil...@lists.yoctoproject.org
> 
>  > Subject: [meta-xilinx] Loading FPGA firmware broken in 2018.3
> 
>  >
> 
>  > With the 2018.1 version of u-boot, atf and pmu this worked okay.
> 
>  >
> 
>  > With the "thud" release and 2018.3, loading the FPGA no longer works:
> 
>  >
> 
>  > ZynqMP> load mmc $sdbootdev:2 0x10 /lib/firmware/fpga.bin
> 
>  > 19311092 bytes read in 1900 ms (9.7 MiB/s)
> 
>  > ZynqMP> fpga load 0 0x10 $filesize
> 
>  > ZynqMP> md 0x10
> 
>  > 0010:        
> 
>  > 00100010:        
> 
>  > 00100020:        
> 
>  > 00100030:        
> 
>  > 00100040: 00bb 11220044      D.".
> 
>  > 00100050: aa995566 2000 2000 30022001    fU. ... . .0
> 
>  > 00100060:  30020001  30008001    ...0...0
> 
>  > 00100070:  2000 30008001 0007    ... ...0
> 
>  > 00100080: 2000 2000 30002001     ... ... . .0
> 
>  > 00100090: 30026001  30012001 38003fe5    .`.0. .0.?.8
> 
>  > 001000a0: 3001c001 0040 30018001 04a5a093 ...0..@0 
> <mailto:...0..@0>
> 
>  > 001000b0: 30008001 0009 2000 3000c001    ...0... ...0
> 
>  > 001000c0: 0001 3000a001 0101 3000c001    ...0...0
> 
>  > 001000d0:  30030001  2000    ...0...
> 
>  > 001000e0: 2000 2000 2000 2000    ... ... ... ...
> 
>  > 001000f0: 2000 2000 2000 30002001    ... ... ... . .0
> 
>  > ZynqMP>
> 
>  >
> 
>  >
> 
>  > No error is displayed, but the FPGA remains unprogrammed (as indicated by 
> the
> 
>  > PROG_DONE pin).
> 
>  >
> 
>  > Reverting to previous sumo version makes it work again.
> 
>  > --
> 
>  > ___
> 
>  > meta-xilinx mailing list
> 
>  > meta-xilinx@yoctoproject.org <mailto: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] Really bad SD/eMMC performance after upgrading 2018.1 to 2018.3

[Mike Looijmans]

The SD and eMMC controller has become terribly slow in 2018.3:

# echo 3 > /proc/sys/vm/drop_caches

# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 4.972666 seconds, 4.0MB/s

# dd if=/dev/mmcblk1 of=/dev/null bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (20.0MB) copied, 38.899436 seconds, 526.5KB/s


This used to be over 160MB/s for the eMMC (mmcblk0) and over 20 MB/s for the 
SD card (mmcblk0) with the 2018.1 kernel and bootloader.

This is only in Linux, the bootloader still reads at about 10MB/s from the SD 
card. So apparently the clocks are set up okay.

According to the kernel, the clocks and interface are running at full speed:

# cat /sys/kernel/debug/mmc0/ios
clock:  2 Hz
actual clock:   2 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  3 (8 bits)
timing spec:9 (mmc HS200)
signal voltage: 1 (1.80 V)
driver type:0 (driver type B)

# cat /sys/kernel/debug/mmc1/ios
clock:  5000 Hz
actual clock:   5000 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:0 (driver type B)


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

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

[Mike Looijmans]

On 21-03-19 07:33, Mike Looijmans wrote:
> On 20-03-19 18:46, Manjukumar Harthikote Matha wrote:
>> Hi Mike,
>>
>> We tested by loading  both the vivado generated and bootgen generated 
>> bitstreams using 2018.3 and it worked fine, we are able to see Done and leds 
>> glowing as per our design.
>>
>> Is it a custom board or zcu102?
> 
> Custom board (the Xilinx Drone Platform actually)
> 
>> Do you need this patch on thud?
>>
>> https://github.com/Xilinx/meta-xilinx/commit/2c98fa11ccf33b6d9a550bebf50d2a2a876f9afb
>>  
> 
> Might be, from the description it sounds like "the FPGA
> configuration code is non-functional" is what I'm experiencing here.

Built the PMU with the above patch, and now programming the PL works.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] devtmpfs: error mounting -2

[Mike Looijmans]

since error "2" is this:

#define ENOENT 2/* No such file or directory */

my guess would be that your rootfs does not actually contain a "/dev" 
directory for the filesystem to mount on.


On 12-03-19 20:38, Emily S wrote:
> Hi All -
> 
> I'm using Yocto version rocko with a custom layer to run on the Zynq+ SoC on 
> a 
> custom board. When trying to boot I'm getting an error like:
> 
> [    4.178864] devtmpfs: error mounting -2
> 
> in the boot output. Even after rolling back to a previous working version I 
> still get this error in the boot output. After this error, the boot process 
> seems to stop, and I am directly given a terminal input, but no login, or 
> anything. The /dev and /proc folders seem to be missing as does specifically 
> /etc/network/ among others.
> 
> I'm booting from an SD card and flashing it using a wic image made with the 
> "sdimage-bootpart.wks" from yocto. This method has worked fine before now.
> 
> Are there obvious things I should check to make sure devtmpfs can be mounted 
> properly? I have not messed with bootargs or anything since the working 
> version of the OS, so I'm not sure why I am suddenly seeing this error.
> 
> A comparison output from the working OS and the bad OS can be seen below. Any 
> ideas are greatly appreciated!
> 
> Thanks,
> Emily
> 
> *Bad OS: *
> [    4.125754] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature 
> incompatibilities
> [    4.163579] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
> mode. 
> Opts: (null)
> [    4.171613] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [    4.178864] devtmpfs: error mounting -2
> [    4.182766] Freeing unused kernel memory: 640K (ffc000d2 - 
> ffc000dc)
> /bin/sh: can't access tty; job control turned off
> / #
> 
> *Working OS: *
> [    4.089697] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature 
> incompatibilities
> [    5.324662] EXT4-fs (mmcblk0p2): recovery complete
> [    5.404047] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
> mode. 
> Opts: (null)
> [    5.412083] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [    5.418084] devtmpfs: mounted
> [    5.421106] Freeing unused kernel memory: 512K (ffc000c1 - 
> ffc000c9)
> 
> ... (boot continues)
> 

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

Re: [meta-xilinx] Buildign PMU firmware in thud

[Mike Looijmans]

On 13-03-19 09:04, Mike Looijmans wrote:
> I tried to build the PMU firmware using multiconfig, but all I get is this:
> 
> ERROR: Uninative selected but not configured correctly, please set 
> UNINATIVE_CHECKSUM[x86_64]

That mail went out too quickly...

Apparently the whole "multiconfig" thing appears te be ignored. If I don't set 
a machine in local.conf or environment, it complains about the MACHINE.

I think something is missing in the instructions. I'm using the "thud" 
branches of everything and "1.40" of bitbake:

meta-oe
meta-multimedia
meta-networking
meta-python  = "HEAD:6ef9657068492d4644079c88f2adee9c3cac9543"
meta-xilinx-bsp
meta-xilinx-standalone = "HEAD:d2cccbabeceec246e92132151d71831f50f74bf1"


I created the multiconfig files:

$ cat conf/multiconfig/pmu.conf
MACHINE="zynqmp-pmu"
DISTRO="xilinx-standalone"
GCCVERSION="7.%"
TMPDIR="${TOPDIR}/pmutmp"

I added to my local.conf:

BBMULTICONFIG = "xdp7 pmu"


So what am I missing? Apparently multiconfig needs more than this, because 
running "bitbake multiconfig:pmu:pmu-firmware" completely ignores the contents 
of the pmu.conf.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] Buildign PMU firmware in thud

[Mike Looijmans]

I tried to build the PMU firmware using multiconfig, but all I get is this:

ERROR: Uninative selected but not configured correctly, please set 
UNINATIVE_CHECKSUM[x86_64]
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZCU102 boot issue

[Mike Looijmans]

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

It's where it's always been:

https://github.com/topic-embedded-products/meta-topic/tree/master/recipes-bsp/pmu-firmware/pmu-firmware

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

Re: [meta-xilinx] libmali and wayland

[Mike Looijmans]

On 20-02-19 15:22, Luca Ceresoli wrote:
> Hi Jean-Francois,
> 
> On 20/02/19 15:01, Jean-Francois Dagenais wrote:
>>
>>
>>> On Feb 20, 2019, at 06:01, Mike Looijmans >> <mailto:mike.looijm...@topic.nl>> wrote:
>>>
>>> +1 for that!
>>>
>>> (and not just on meta-xilinx, but on kernel, u-boot, and other
>>> repositories as
>>> well)
>>>
>>> These "big blob" changes are impossible to manage.
>>
>> Indeed. Here's a concrete example:
>>
>> I had to integrate the audio on our board. Our design called for the
>> xilinx_dma driver to come into play. When I started using the cyclic
>> mode with the audio I found it was (and still is I believe) completely
>> broken/non-functional. I spent a week and a half working on
>> xilinx_dma.c. I meticulously fixed the different issues I saw, cleaned
>> up a whole bunch of stuff and carefully created a nice series of commits
>> so that it could be discussed and applied.
>>
>> I was carrying this in our repo awaiting a closely upcoming release. To
>> my dismay, xilinx_dma.c had a complete overhaul appear in github's
>> linux-xlnx upon the release and to add insult to injury, the commits
>> which were finally deposited on the repo pre-dated my work!
> 
> Oh dear. I also have fixes for cyclic DMA on the 2017.x (4.9) series.
> Now I guess I will be unable to apply them on the 2018.x (4.14) series,
> just as you have. :-(

We too.

Which then results in avoiding the Xilinx DMA IP completely...
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] ZCU102 boot issue

[Mike Looijmans]

On 30-01-19 14:13, Jean-Francois Dagenais wrote:
> 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.
> 

Simplest solution here would be to just integrate that "default config" patch 
into the standard PMU firmware and then all boards will just boot. It won't 
prevent the FSBL changing the config, so that flow isn't affected negatively.

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

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

Re: [meta-xilinx] Minized support

[Mike Looijmans]

On 22-01-19 16:21, Philip Balister wrote:
> I'm looking at changing the kernel to a fitImge and building a ramdisk
> image for qspi. I'd like to boot from qspi, format the emmc and untar a
> file system (from usb) into the emmc. Finally boot from a kernel on the
> emmc. Does this sound worth upstreaming to meta-xilinx-contrib, or shold
> I just carry it locally?

99% of all our projects boot and run everything from QSPI.

Just put the bootloader, kernel, devicetree into partitions, and create a 
squashfs root filesystem and write it to a QSPI partition as well. You can 
just pass the mtd device as rootfs to the kernel and it'll happily boot with 
that.

Don't put a ramdisk in QSPI, that's just wasting memory and time. A filesystem 
mounted from QSPI flash will just copy things "on demand" into RAM, so it's 
equally fast to access but since it doesn't have to read the whole filesystem 
into RAM at boot, it's much much faster to boot, and if the pressure goes up, 
it can swap out stuff it no longer needs.

If you want a writable root, just use UBIFS instead of squash. You can even 
put kernel and DT into UBI volumes or files and have u-boot fetch them there.
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Reflash minized

[Mike Looijmans]

On 09-01-19 18:45, Philip Balister wrote:
> I've built an image for the minized from meta-xilinx-contrib successfully.
> 
> Before I start semi trial and erroring to get u-boot and the kernel into
> qspi, has anyone written this process up?

I use QSPI filesystems on the Zynq almost daily, but never wrote it down...

By far the most convenient way to write the flash is to just boot Linux 
from an SD card and use flashcp (or ubiformat or swupdate) to write the 
QSPI flash.

If you don't have any alternative to booting, start u-boot using JTAG 
(using Xilinx SDK) and then you can transfer data to memory using, for 
example, USB (dfu) and then tell u-boot to write it using "sf" commands 
on the commandline.

And if you don't have that, the Xilinx SDK can do the same using the 
FSBL, but this is slow and harder to automate/script.

> On another note, the restore to factory instructions say you can use
> Vivado 2017.1 or later. Well, 2018.3 fails with a u-boot error about
> sfprobe 0 0 0 failing. I did install 2017.1 and confirm the procedure in
> the documents does work for that version.

"sf probe 0 0 0" is an invalid command, it requests a "0 Hz" operating 
frequency. I don't know where this originated, but I've seen it a lot in 
Zynq docs. It happens to work because the QSPI driver in early days did 
not even set any clock at all, and later it just ran at the slowest 
speed possible.

The correct command is just "sf probe" without any extra arguments. 
Adding extra arguments will override the board settings and thus will 
only break things.


> I realize the program_flash utility basically uses jtag to install
> u-boot into memory and runs it, maybe we should just document this
> process and avoid depending on magic tools that fail on different Vivado
> versions.

Excellent idea...



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

Re: [meta-xilinx] Strange I2C problem after updating to Sumo

[Mike Looijmans]

goto out;

 /* Report the other error interrupts to application */
 if (id->err_status) {
 cdns_i2c_master_reset(adap);

 if (id->err_status & CDNS_I2C_IXR_NACK) {
 ret = -ENXIO;
 goto out;
 }
 ret = -EIO;
 goto out;
 }
 }
}

After debugging further I can see that it's trying to select the right
channel of the PCA9548 but the i2c controller on the Xilinx is failing
with a NAK.  So it's not even getting as far as the LTC driver.  Here
is some of my debug that shows it's the PCA9548 that is failing as
this is address 0x70 whereas the LTC is at 0x34

pca954x_select_chan: chan:4 regval:10
pca954x_reg_write: addr:70 val:10
cdns-i2c e0004000.i2c: cdns_i2c_master_xfer: id->err_status=4
cdns-i2c e0004000.i2c: cdns_i2c_master_xfer: id->p_msg->addr=70

I've done a diff between the 4.9 and 4.14 kernel but can't see any
obvious in either of these drivers.  I've checked the device tree in
this area but again can see no changes.  The second I2C interface is
working fine, I2C1.

I did a dump_stack on the i2c read that was failing
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x80/0xa0)
[] (dump_stack) from [] (cdns_i2c_master_xfer+0x2fc/0x3e4)
[] (cdns_i2c_master_xfer) from []
(_i2c_transfer+0x1cc/0x20c)
[] (_i2c_transfer) from [] (pca954x_reg_write+0x4c/0x8c)
[] (pca954x_reg_write) from []
(pca954x_select_chan+0x44/0x5c)
[] (pca954x_select_chan) from []
(_i2c_mux_master_xfer+0x28/0x64)
[] (_i2c_mux_master_xfer) from []
(_i2c_transfer+0x1cc/0x20c)
[] (_i2c_transfer) from [] (i2c_transfer+0x8c/0xac)
[] (i2c_transfer) from [] (regmap_i2c_read+0x48/0x64)
[] (regmap_i2c_read) from [] (regmap_raw_read+0x84/0xd0)
[] (_regmap_raw_read) from [] (_regmap_bus_read+0x28/0x48)
[] (_regmap_bus_read) from [] (_regmap_read+0x84/0xac)
[] (_regmap_read) from [] (regmap_read+0x40/0x58)
[] (regmap_read) from []
(regulator_get_voltage_sel_regmap+0x1c/0x50)
[] (regulator_get_voltage_sel_regmap) from []
(ltc3375_get_voltage_sel_regmap+0xc/0x4c [oina_regulator_ltc3375])
[] (ltc3375_get_voltage_sel_regmap [oina_regulator_ltc3375])
from [] (_regulator_get_voltage+0x8c/0x128)
[] (_regulator_get_voltage) from []
(regulator_register+0x3ec/0xb60)
[] (regulator_register) from []
(ltc3375_probe+0x2bc/0x394 [oina_regulator_ltc3375])
[] (ltc3375_probe [regulator_ltc3375]) from []
(i2c_device_probe+0x22c/0x244)

I'll look into the regulator_register code next but was just wondering
if anyone else has seen this or if anyone knows if there's a fix
available for this?

Any help appreciated,

Cheers,
Martin




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

Re: [meta-xilinx] macb.c and DT: detect/scan PHY address for a single mdio

[Mike Looijmans]

"0" is not a valid address for a PHY, it's the "broadcast" address on the MDIO 
bus. You should make your hardware designer who selected it hurt somewhere 
painful.


Having said that, address 0 usally happens to work if there's only one PHY on 
that bus, since it will be the only one responding to that broadcast.


Change reg = <0x3> to reg = <0x0> in the devicetree. You can optionally change 
the descriptions as well, but it's the "reg" that really matters. This might 
work on the board with address "3" because that will also respond to the 
broadcast address 0.




On 18-07-18 03:12, Oleg K Dzhimiev wrote:

Hi,

How do I keep the device tree compatible across the board revisions if phy 
addrs are different?
We got a new board revision with a different phy reg, where old rev reg == 
0x3, new rev reg == 0x0.


Here's the DT:

ps7_ethernet_0: ps7-ethernet@e000b000 {
local-mac-address = [00 0e 64 10 00 00];
phy-handle = <>;
phy-mode = "rgmii-id";
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy3: phy@3 {
                                         /* Atheros 8035 */
                                         compatible =
"ethernet-phy-id004d.d072";
/* compatible = "ethernet-phy-ieee802.3-c22";*/
device_type = "ethernet-phy";
reg = <0x3>;
};
};
};


So far, with the old revision (addr==0x3) I have tried to remove 'reg' hoping 
it would do some sort of scanning but the macb driver (macb_mii_probe) 
registers 32 phy structs then picks the first one (addr==0) and timeouts 
trying to reset it.


Thanks,

Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783  x124
Elphel, Inc.




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

Re: [meta-xilinx] 16550 linux drivers won't recognise AXI UART 16550 modules

[Mike Looijmans]

usb: e0002000.usb supply vbus not found, using dummy 
regulator

ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
i2c /dev entries driver
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR Sharp protocol handler initialized
IR MCE Keyboard/mouse protocol handler initialized
IR XMP protocol handler initialized
cdns-wdt f8005000.watchdog: Xilinx Watchdog Timer at e08f7000 with timeout 10s
device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-de...@redhat.com
EDAC MC: ECC not enabled
cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 65 KHz
cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 67 KHz
Xilinx Zynq CpuIdle Driver started
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on e010.sdhci [e010.sdhci] using ADMA
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
fpga_manager fpga0: Xilinx Zynq FPGA Manager registered
oprofile: using arm/armv7-ca9
u32 classifier
     Actions configured
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller area network core (rev 20170425 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20170425)
can: broadcast manager protocol (rev 20170425 t)
can: netlink gateway (rev 20170425) max_hops=1
Key type dns_resolver registered
Registering SWP/SWPB emulation handler
Btrfs loaded, crc32c=crc32c-generic
Key type encrypted registered
mmc0: new high speed SDHC card at address 0007
mmcblk0: mmc0:0007 SD16G 14.5 GiB
console [netcon0] enabled
  mmcblk0: p1 p2
netconsole: network logging started
hctosys: unable to open rtc device (rtc0)
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is 
recommended

EXT4-fs (mmcblk0p2): recovery complete
EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 179:2.
devtmpfs: mounted
Freeing unused kernel memory: 1024K
INIT: version 2.88 booting
Starting udev
udevd[91]: starting version 3.2.5
udevd[92]: starting eudev-3.2.5
EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
Thu Jul 12 09:21:00 UTC 2018
INIT: Entering runlevel: 5
Configuring network interfaces... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not 
ready

udhcpc: started, v1.27.2
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
udhcpc: no lease, forking to background
done.
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 2.5 zybo-zynq7 /dev/ttyPS0

zybo-zynq7 login: root
root@zybo-zynq7:~#
root@zybo-zynq7:~# dmesg | grep serial
e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 24, base_baud = 625) is 
a xuartps

root@zybo-zynq7:~# /

-


Thank you very much

Simon







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] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?

[Mike Looijmans]

With the Zynq 7 series you needed pin 8 free, because it was being used 
to feed back the clock through the IO pad. Without that configured, it 
would not work above 50MHz. In the pinmux config you had to enable this, 
and it would be used when the clock divider was set to 2 (yielding 
100MHz max.) Don't recall if the MPSoC had a similar hidden requirement.


I've run the QSPI on the ZynqMP at 150MHz (using 166MHz rated chips), 
and it did work, but that was quite a while ago that I tested it. Should 
still work on our boards though.



On 30-04-18 11:54, Martin Lund wrote:
Yeah, I see a lot of good stuff coming from you and Holden Sandlar 
trying to fix/patch the qspi-nor driver but as you state Xilinx seems to 
pay little attention to this driver. I've also applied your patches.



Surprisingly, we have just discovered that if we lower the 
spi-max-frequency from 108 MHz (default in .dts) to e.g. 50 MHz our 
read/write problem goes away?



It seems the prebuilt xilinx petalinux images run successfully at 108 
MHz so it makes me wonder exactly what they are doing differently.



Also, running up UBI/UBIFS on the qspi-nor flash with the "has-io-mode" 
flag and at 50 MHz it seems to work fine except when we run ubi-tests 
("runubitests.sh /dev/ubi0") from mtd-utils we see it crashing when 
running the *_paral tests which are sort of stress tests.







*From:* meta-xilinx-boun...@yoctoproject.org 
<meta-xilinx-boun...@yoctoproject.org> on behalf of Mike Looijmans 
<mike.looijm...@topic.nl>

*Sent:* Sunday, April 29, 2018 5:31:38 PM
*To:* meta-xilinx@yoctoproject.org
*Subject:* Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx 
layer for zcu102-zynqmp?

There were quite a few bugs in the QSPI support last year, I've sent
patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since
the ZynqMP has a different controller than the Zynq, there may some
similar leftover bugs in there as well.

The QSPI driver still has not been submitted into Linux mainline, which
indicates the poor attention the driver has been receiving.

Side note: There's no point running both flash_erase and flashcp. The
flashcp command will also erase before writing (otherwise, you wouln't
need the command...). Either use flashcp, or use flash_erase followed by dd.

On 25-04-18 09:04, Martin Lund wrote:

Hi,

Is the qspi-nor flash feature broken in the meta-xilinx layer for zcu102-zynqmp 
?

We've been trying to test and verify the qspi-nor flash feature on a ZynqMP 
zcu102 rev 1.0 development board only to find out that basic reading/writing to 
the qspi-nor flash is failing.

We are building and testing with core-image-minimal on latest rocko branch 
(commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following 
patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which prevents 
the u-boot SPL from booting:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html

This is how we test and see the qspi-flash fail:

root@zcu102-zynqmp:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0010 2000 "qspi-fsbl-uboot"
mtd1: 0050 2000 "qspi-linux"
mtd2: 0002 2000 "qspi-device-tree"
mtd3: 005e 2000 "qspi-rootfs"

root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
Erasing 8 Kibyte @ 2000 --  0 % complete [  103.966880] random: crng init done
Erasing 8 Kibyte @ 5de000 -- 100 % complete

root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096
4096+0 records in
4096+0 records out

root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
Erasing blocks: 512/512 (100%)
Writing data: 4096k/4096k (100%)
Verifying data: 10k/4096k (0%)File does not seem to match flash data. First 
mismatch at 0x-0x2800

Any ideas what might be wrong in the meta-xilinx layer that would make the 
qpsi-nor flash fail like that?

Thanks.

/Martin




--
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 <http://www.topicproducts.com>

Please consider the environment before printing this e-mail



--



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





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

Re: [meta-xilinx] Is qspi-nor flash broken in meta-xilinx layer for zcu102-zynqmp?

[Mike Looijmans]

There were quite a few bugs in the QSPI support last year, I've sent 
patches to fix the ones I found on the 'regular' Zynq to Xilinx. Since 
the ZynqMP has a different controller than the Zynq, there may some 
similar leftover bugs in there as well.


The QSPI driver still has not been submitted into Linux mainline, which 
indicates the poor attention the driver has been receiving.


Side note: There's no point running both flash_erase and flashcp. The 
flashcp command will also erase before writing (otherwise, you wouln't 
need the command...). Either use flashcp, or use flash_erase followed by dd.


On 25-04-18 09:04, Martin Lund wrote:

Hi,

Is the qspi-nor flash feature broken in the meta-xilinx layer for zcu102-zynqmp 
?

We've been trying to test and verify the qspi-nor flash feature on a ZynqMP 
zcu102 rev 1.0 development board only to find out that basic reading/writing to 
the qspi-nor flash is failing.

We are building and testing with core-image-minimal on latest rocko branch 
(commit 7935ef724c, stock/clean meta-xilinx, no petalinux) with the following 
patch/fix added to avoid the zynqmp_clk_get_periphial_rate error which prevents 
the u-boot SPL from booting:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2017-December/003464.html

This is how we test and see the qspi-flash fail:

root@zcu102-zynqmp:~# cat /proc/mtd
dev:size   erasesize  name
mtd0: 0010 2000 "qspi-fsbl-uboot"
mtd1: 0050 2000 "qspi-linux"
mtd2: 0002 2000 "qspi-device-tree"
mtd3: 005e 2000 "qspi-rootfs"

root@zcu102-zynqmp:~# flash_erase /dev/mtd3 0 0
Erasing 8 Kibyte @ 2000 --  0 % complete [  103.966880] random: crng init done
Erasing 8 Kibyte @ 5de000 -- 100 % complete

root@zcu102-zynqmp:~# dd if=/dev/urandom of=./sample.bin bs=1024 count=4096
4096+0 records in
4096+0 records out

root@zcu102-zynqmp:~# flashcp -v ./sample.bin /dev/mtd3
Erasing blocks: 512/512 (100%)
Writing data: 4096k/4096k (100%)
Verifying data: 10k/4096k (0%)File does not seem to match flash data. First 
mismatch at 0x-0x2800

Any ideas what might be wrong in the meta-xilinx layer that would make the 
qpsi-nor flash fail like that?

Thanks.

/Martin




--
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] Why no support for FSBL?

[Mike Looijmans]

There are many reasons we moved away from the FSBL flow. The *main* reason is 
that we encountered various bugs (the FSBL worked okay on the evaluation 
board, but once we made our own module with different pinouts and support 
chips, the bugs started to appear). With the FSBL being non-free software 
("free" as in "freedom", not "free beer") we could not fix these issues ourselves.


A big issue with non-free software is that in say five years a customer will 
return to us and ask "hey, can you do this small addition". Chances are that 
the tools we used will no longer run on the machines we have then, and in many 
cases, it will be impossible to revive the licenses. And we will have no way 
of fixing that, other that putting our current machines in the fridge along 
with the software.




On 30-11-17 19:57, Manjukumar Harthikote Matha wrote:

Hi Mike,

On 11/28/2017 01:09 AM, Mike Looijmans wrote:
The "open source" way is to avoid the FSBL (and in fact, all of 
meta-xilinx-tools) and use u-boot SPL instead. All functionality provided by 
the fsbl/bootgen flow is provided by u-boot SPL already.




"All functionality" would be a blanket statement, there are many driver 
support that is officially tested by Xilinx in fsbl/bootgen flow, including 
safety and security support


Thanks,
Manju



On 20-11-17 22:08, Peter Smith wrote:
Hi, I’m aware of the meta-xilinx-tools layer, but this needs you to have 
the Xilinx SDK installed (unless I’m mistaken), I was wondering ion there 
were any plans to create support in meta-xilinx for building the FSBL 
without the need for the SDK dependency. Peter


On 20 Nov 2017, at 21:05, Giordon Stark <kra...@gmail.com 
<mailto:kra...@gmail.com>> wrote:


Hi (resending from right address),

You can indeed build the FSBL + boot.bin using the meta-xilinx-tools 
layer: https://github.com/Xilinx/meta-xilinx-tools


Giordon

On Mon, Nov 20, 2017 at 3:03 PM Peter Smith <sale...@gmail.com 
<mailto:sale...@gmail.com>> wrote:


    A question, I was wondering why there is no support for building FSBL in
    a similar way to that provided by meta-xilinx for the PMU firmware, is
    there a technical reason or is it just one of those things that has not
    yet been got around to? Thanks in advance Peter.
    --


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






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 <mailto: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] QSPI Issues related to Linux 4.9

[Mike Looijmans]

On 29-11-17 09:29, Syed Syed wrote:

git-...@xilinx.com is internal to Xilinx. You should use g...@xilinx.com. It is 
still in active state. I don’t know why no-one acknowledged your patches there. 
Can you re-try? I will try to make sure it reaches right folks at Xilinx. 
Appreciate your efforts.



I resent the series, to g...@xilinx.com, with a BCC to a private e-mail account 
and verified that all three arrived safely.


If you did not receive it, please complain loudly to your IT department.



Thanks
-syed





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



-Original Message-

From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
boun...@yoctoproject.org] On Behalf Of Mike Looijmans
Sent: Wednesday, November 29, 2017 11:54 AM
To: Manjukumar Harthikote Matha <manju...@xilinx.com>; Martin
Siegumfeldt <m...@gomspace.com>; meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] QSPI Issues related to Linux 4.9

I re-sent the three patches as series to git-...@xilinx.com with a CC to you.

Mike.

On 28-11-17 19:56, Manjukumar Harthikote Matha wrote:

Hi Mike,

Thanks for your work, please send patches to git-...@xilinx.com

Thanks,
Manju





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



-Original Message-

From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
boun...@yoctoproject.org] On Behalf Of Mike Looijmans
Sent: Monday, November 27, 2017 2:57 AM
To: Martin Siegumfeldt <m...@gomspace.com>;
meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] QSPI Issues related to Linux 4.9

There are several bugs (at least 3) in the Xilinx tree relating to
QSPI, I implemented fixes in our tree and sent patches to
g...@xilinx.com (with CC to several Xilinx people).

I did not receive any feedback so far.

I get the impression that the g...@xilinx.com e-mail is no longer in use.
Better suggestions are welcome.

The QSPI code from Xilinx is not part of mainline Linux (and for good
reason it seems), so sending patches to mainline linux is pointless.

(If you're designing Zynq boards, my advice for now is to steer away
from the dual-qspi config, it's almost useless on the Zynq and forces
you to use Xilinx' tree instead of mainline)



On 24-11-17 14:02, Martin Siegumfeldt wrote:

Hi,

I recently updated the Linux kernel for a custom board based on z7k
from Xilinx

version 4.6 to 4.9, and spend a few days debugging issues related to
the QSPI flash (n25q512a13). By coincidence I stumbled upon
https://github.com/topic-embedded-


products/linux/commit/8f89736e4e4c116b442f56b3414c33b36f99bc18#diff-

49f4e70fe9e60ff773b57164b9e03dbb (thanks Mike) which resolved the
issue. It looks like this commit has been left out during the 4.9
transition. Since I am apparently not  the only one encountering this
issue I wonder if this is planned fixed upstream (upstream as in the
Xilinx fork I mean)


Thanks,
Martin





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 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] QSPI Issues related to Linux 4.9

[Mike Looijmans]

I re-sent the three patches as series to git-...@xilinx.com with a CC to you.

Mike.

On 28-11-17 19:56, Manjukumar Harthikote Matha wrote:

Hi Mike,

Thanks for your work, please send patches to git-...@xilinx.com

Thanks,
Manju





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



-Original Message-

From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
boun...@yoctoproject.org] On Behalf Of Mike Looijmans
Sent: Monday, November 27, 2017 2:57 AM
To: Martin Siegumfeldt <m...@gomspace.com>; meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] QSPI Issues related to Linux 4.9

There are several bugs (at least 3) in the Xilinx tree relating to QSPI, I
implemented fixes in our tree and sent patches to g...@xilinx.com (with CC to
several Xilinx people).

I did not receive any feedback so far.

I get the impression that the g...@xilinx.com e-mail is no longer in use.
Better suggestions are welcome.

The QSPI code from Xilinx is not part of mainline Linux (and for good reason
it seems), so sending patches to mainline linux is pointless.

(If you're designing Zynq boards, my advice for now is to steer away from the
dual-qspi config, it's almost useless on the Zynq and forces you to use
Xilinx' tree instead of mainline)



On 24-11-17 14:02, Martin Siegumfeldt wrote:

Hi,

I recently updated the Linux kernel for a custom board based on z7k from Xilinx

version 4.6 to 4.9, and spend a few days debugging issues related to the QSPI 
flash
(n25q512a13). By coincidence I stumbled upon https://github.com/topic-embedded-
products/linux/commit/8f89736e4e4c116b442f56b3414c33b36f99bc18#diff-
49f4e70fe9e60ff773b57164b9e03dbb (thanks Mike) which resolved the issue. It
looks like this commit has been left out during the 4.9 transition. Since I am
apparently not  the only one encountering this issue I wonder if this is 
planned fixed
upstream (upstream as in the Xilinx fork I mean)


Thanks,
Martin





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 mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Why no support for FSBL?

[Mike Looijmans]

The "open source" way is to avoid the FSBL (and in fact, all of 
meta-xilinx-tools) and use u-boot SPL instead. All functionality provided by 
the fsbl/bootgen flow is provided by u-boot SPL already.



On 20-11-17 22:08, Peter Smith wrote:
Hi, I’m aware of the meta-xilinx-tools layer, but this needs you to have the 
Xilinx SDK installed (unless I’m mistaken), I was wondering ion there were any 
plans to create support in meta-xilinx for building the FSBL without the need 
for the SDK dependency. Peter


On 20 Nov 2017, at 21:05, Giordon Stark <kra...@gmail.com 
<mailto:kra...@gmail.com>> wrote:


Hi (resending from right address),

You can indeed build the FSBL + boot.bin using the meta-xilinx-tools layer: 
https://github.com/Xilinx/meta-xilinx-tools


Giordon

On Mon, Nov 20, 2017 at 3:03 PM Peter Smith <sale...@gmail.com 
<mailto:sale...@gmail.com>> wrote:


A question, I was wondering why there is no support for building FSBL in
a similar way to that provided by meta-xilinx for the PMU firmware, is
there a technical reason or is it just one of those things that has not
yet been got around to? Thanks in advance Peter.
--
    


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 <mailto: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] QSPI Issues related to Linux 4.9

[Mike Looijmans]

There are several bugs (at least 3) in the Xilinx tree relating to QSPI, I 
implemented fixes in our tree and sent patches to g...@xilinx.com (with CC to 
several Xilinx people).


I did not receive any feedback so far.

I get the impression that the g...@xilinx.com e-mail is no longer in use. 
Better suggestions are welcome.


The QSPI code from Xilinx is not part of mainline Linux (and for good reason 
it seems), so sending patches to mainline linux is pointless.


(If you're designing Zynq boards, my advice for now is to steer away from the 
dual-qspi config, it's almost useless on the Zynq and forces you to use 
Xilinx' tree instead of mainline)




On 24-11-17 14:02, Martin Siegumfeldt wrote:

Hi,

I recently updated the Linux kernel for a custom board based on z7k from Xilinx 
version 4.6 to 4.9, and spend a few days debugging issues related to the QSPI 
flash (n25q512a13). By coincidence I stumbled upon 
https://github.com/topic-embedded-products/linux/commit/8f89736e4e4c116b442f56b3414c33b36f99bc18#diff-49f4e70fe9e60ff773b57164b9e03dbb
 (thanks Mike) which resolved the issue. It looks like this commit has been 
left out during the 4.9 transition. Since I am apparently not  the only one 
encountering this issue I wonder if this is planned fixed upstream (upstream as 
in the Xilinx fork I mean)

Thanks,
Martin





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] Disable U-Boot MMC?

[Mike Looijmans]

Basically boils down to disabling SD support in u-boot.

In OE/Yocto, run "bitbake -c menuconfig virtual/bootloader" and remove 
the MMC option (and whatever other options you like). Save the 
configuration as /tmp/defconfig, and exit. Copy the defconfig to the 
u-boot recipe location and add a line to the SRC_URI to apply it while 
building.


On 17-11-17 21:04, Giordon Stark wrote:
Is it possible to tell u-boot to not boot from MMC? I suspect it's a 
configuration flag -- and this is when I try to program the QSPI using 
my boot.bin and it would be beneficial to make that work.


Thanks,

Giordon





--
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] Restructuring of meta-xilinx layer

[Mike Looijmans]

To me it does not make any sense to merge them. One would use the OSS flow and 
thus only meta-xilinx, or the Xilinx SDK toolflow which is meta-petalinux and 
meta-xilinx-tools (I think). I don't see the added value in merging them, it 
will only add to the confusion, and pollute one's environment by dragging in 
"meta" layers that aren't actually active.


On 13-11-17 21:13, Manjukumar Harthikote Matha wrote:

Hi All,

We want to restructure meta-xilinx layer to encompass all the layers coming 
from Xilinx.
The proposal is the following for Rocko/master:
meta-xilinx
->meta-xilinx-bsps (current meta-xilinx)
->meta-xilinx-contrib

In the next release we will add some more layers such as meta-petalinux, 
meta-xilinx-tools, etc. It will look like
meta-xilinx
->meta-xilinx-bsps (current meta-xilinx)
->meta-petalinux
->meta-xilinx-tools
->meta-xilinx-contrib

There will be some movement of recipes from meta-xilinx-bsps to 
meta-xilinx-contrib. Patches will be sent to mailing list on any recipes 
movement.
This will provide one clone to get all the required meta layers from Xilinx for 
a complete solution, and the users can blacklist any layer which they don't 
want to use.
This will enables us to help our vendors/partners to add their reference 
designs, board definitions etc.

Please let us know your feedback. We plan to get this done no later than 11/20.

Thanks,
Manju





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 6/7] zcu102-zynqmp: Use 'rev 1.0' U-Boot config and deploy boot.bin

[Mike Looijmans]

On 09-10-17 11:23, Luca Ceresoli wrote:

Hi Nathan,

...

What's the current status of U-Boot SPL on zynqmp? Last time I checked
it appeared not yet ready for a complete Linux boot, because it cannot
pass the configuration object to the PMU firmware.

- Can U-Boot SPL boot a complete Linux without FSBL on zcu102?
- How much that applies to other zynqmp chips and boards (especially
   UltraZed)?


I worked around it by building the config object into the pmufw:

https://github.com/topic-embedded-products/meta-topic/commit/706f74c9cd5fcf398ff24ee77962ebfe23340998

The data is already there, all that's needed is a line of code that installs it.

This also gets around the licensing issue, the config object is not GPL 
compatible, so including it into u-boot code poses a challenge in itself.




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


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

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

[Mike Looijmans]

On 30-08-17 22:20, Brian Hutchinson wrote:
I too have been wrestling with generating the required images to boot the 
ZCU102 from SD Card using the Yocto + meta-xilinx + meta-xilinx-tools method.


I'm totally striking out.  And I'm working with a Xilinx FAE and striking 
out!  No problem at all doing this kind of thing for ZCU107 or Zedboard but 
ZCU102 is different beast for sure.


I have Ubuntu 16.04 box, I've tried yocto 2.2.1 (morty) and 2.3 (pyro) and I 
get the same result ... my builds die with:



...

| DEBUG: Executing shell function do_deploy
| install: cannot stat 
'/home/hutch/yocto_2.2.1-morty_zcu102/layers/poky/build/tmp/work/zcu102_zynqmp-poky-linux/pmu-firmware/2017.1+gitAUTOINC+122565ec40-r0/build/pmu-firmware/Release/pmu-firmware.elf': 
No such file or directory



Most likely the problem is that the "Release" directory was not created yet. I 
have seen this race condition several times in makefiles.

As a workaround, add a do_compile_prepend with "mkdir Release" or so.

However, this seems to happen in the "do_install" phase, so that's probably 
not the case here.


Another issue can be that actually the "compile" failed. Most of Xilinx' tools 
don't return error codes, so bitbake thinks everything went fine but it didn't 
actually produce outputs. And since do_compile was okay, it won't run again 
and install keeps failing.


Add a do_compile_append() that contains something like:
test -e Release/pmu-firmware.elf
and that would cause do_compile to fail if there's no output.


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] pmu-firmware: Create and deploy a binary firmware blob

[Mike Looijmans]

The SPL based flow needs a raw firmware image instead of an ELF executable. 
Though
probably any objcopy version can perform this, it's better to have the actual
microblaze tool do the conversion, hence its inclusion in this recipe.

With this addition, it is possible to create a bootloader for the zynqmp
platforms based op opensource tools.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bb 
b/recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bb
index 68916ad..4ae5c4e 100644
--- a/recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bb
+++ b/recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bb
@@ -80,6 +80,10 @@ do_deploy() {
install -Dm 0644 ${B}/executable.elf 
${DEPLOYDIR}/${PMU_FIRMWARE_BASE_NAME}.elf
ln -sf ${PMU_FIRMWARE_BASE_NAME}.elf ${DEPLOYDIR}/${BPN}-${MACHINE}.elf
ln -sf ${BPN}-${MACHINE}.elf ${DEPLOYDIR}/pmu-${MACHINE}.elf
+   ${OBJCOPY} -O binary ${B}/executable.elf ${B}/executable.bin
+   install -m 0644 ${B}/executable.bin 
${DEPLOYDIR}/${PMU_FIRMWARE_BASE_NAME}.bin
+   ln -sf ${PMU_FIRMWARE_BASE_NAME}.bin ${DEPLOYDIR}/${BPN}-${MACHINE}.bin
+   ln -sf ${BPN}-${MACHINE}.bin ${DEPLOYDIR}/pmu-${MACHINE}.bin
 }
 addtask deploy before do_build after do_install
 
-- 
1.9.1

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

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

[Mike Looijmans]

On 23-08-17 22:46, 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

Please consider the environment before printing this e-mail



-Original Message-

From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
boun...@yoctoproject.org] On Behalf Of Mike Looijmans
Sent: Tuesday, August 22, 2017 11:02 PM
To: Manjukumar Harthikote Matha <manju...@xilinx.com>; Giordon Stark
<kra...@gmail.com>; Jean-Francois Dagenais <jeff.dagen...@gmail.com>
Cc: meta-xilinx@yoctoproject.org
Subject: Re: [meta-xilinx] How to boot the ZynqMP?

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.1 was required. It doesn't work (any more) with the 2016
versions. I installed 2017.2 and only then the FSBL was able to load the PMU and
ATF. Apparently there's a dependency there.

So all that is left is to automate the process of generating fsbl and boot.bin.

I'm pretty sure this can be done using just u-boot, since u-boot has support 
for ATF
loading and, as I gather from various commits, the PMU as well. It can also 
create a
boot.bin without the aid of bootgen. It provides the first-stage loader as well.
However, it seems to a well-kept secret how to actually integrate the PMU. I can
generate a bootloader this way, but I don't know where to put the ATF and PMU. I
suspect they're to be stored in a FIT image.

So for now I'm stuck with the much less streamlined FSBL flow.


On 22-08-17 20:25, Manjukumar Harthikote Matha wrote:

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



So how does one use this layer to just generate the FSBL and boot.bin?


Basically on dependencies,
https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc

The dependency is to build boot.bin once this layer is included by the above 
file.
Boot.bin defines dependencies for zynqmp as
https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc#L10

Meaning boot.bin has dependencies on fsbl, bitstream (if it exists), pmu 
firmware, atf and u-boot to be built and will create a bif file according to 
these settings

Each of these BIF_PARTITION_ATTR is associated with additional attributed. For 
example :
https://github.com/Xilinx/meta-xilinx-tools/blob/master/conf/machine/include/machine-xilinx-zynqmp.inc#L14-L16
BIF_PARTITION_ATTR[fsbl] ?= "bootloader"
This defines the attrition attribute in the bif
BIF_PARTITION_IMAGE[fsbl] ?= "${DEPLOY_DIR_IMAGE}/fsbl-${MACHINE}.elf"
This defines where to find the binary generated
BIF_PARTITION_DEPENDS[fsbl] ?= "virtual/fsbl"
This defines which recipe it depends on to build the required binary

This would translate as [bootlader] fsbl.elf in the bif file at the end

Similarly we have defined the attributes required for bitstream, pmu, atf and 
u-boot

The bif file will be compiled using the bootgen  by xilinx-bootbin.bbclass
https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xilinx-bootbin.bbclass#L77

Below provides the information regarding how fsbl builds using the HDF and xsct:

bif partition attributes the need to build virtual/fsbl
virtual/fsbl is provided by 
https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/fsbl/fsbl_git.bb#L6

This recipe depends on HDF being provided and xsct in the path.

https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/fsbl/fsbl_git.bb#L8
https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctapp.bbclass#L1
https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctbase.bbclass#L48

xsctbase looks for xsct using
https://github.com/Xilinx/meta-xilinx-tools/blob/master/classes/xsctbase.bbclass#L1
similary depends on hdf
https://github.com/Xilinx/meta-xilinx-tools/blob/34e96ca0dfd2cfe101d07bc6db06fc9ae1629ce4/classes/xsctbase.bbclass#L22



If I have my own board, and my own machine.conf in my own bitbake layer, what 
do I need to do to build a "boot.bin" for that in a scripted flow?



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

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

[Mike Looijmans]

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.1 was required. It doesn't work (any more) 
with the 2016 versions. I installed 2017.2 and only then the FSBL was able to 
load the PMU and ATF. Apparently there's a dependency there.


So all that is left is to automate the process of generating fsbl and boot.bin.

I'm pretty sure this can be done using just u-boot, since u-boot has support 
for ATF loading and, as I gather from various commits, the PMU as well. It can 
also create a boot.bin without the aid of bootgen. It provides the first-stage 
loader as well.
However, it seems to a well-kept secret how to actually integrate the PMU. I 
can generate a bootloader this way, but I don't know where to put the ATF and 
PMU. I suspect they're to be stored in a FIT image.


So for now I'm stuck with the much less streamlined FSBL flow.


On 22-08-17 20:25, Manjukumar Harthikote Matha wrote:

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



So how does one use this layer to just generate the FSBL and boot.bin?


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] u-boot-xlnx: does not depend on dts, remove the dependency

[Mike Looijmans]

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

Please consider the environment before printing this e-mail



-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 on dts, remove the
dependency


Can you please add meta-xilinx-tools in the subject if it is intended for 
meta-xilinx-tools layer


I would if I could. The prefix is set by the maillist bot, not by me.



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 <mike.looijm...@topic.nl>
---
  recipes-bsp/u-boot/u-boot-xlnx_%.bbappend | 1 -
  1 file changed, 1 deletion(-)
  delete mode 100644 recipes-bsp/u-boot/u-boot-xlnx_%.bbappend

diff --git a/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend b/recipes-bsp/u-boot/u-
boot-xlnx_%.bbappend
deleted file mode 100644
index 6a2c4c4..000
--- a/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-do_compile[depends] += "virtual/dtb:do_deploy"


Virtual/dtb is provided by device-tree-generation
https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/device-tree/device-tree-generation_git.bb#L8


Maybe, but u-boot-xlnx does not have a compile-time dependency on that. Hence 
the patch.

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

[meta-xilinx] [PATCH] u-boot-xlnx: does not depend on dts, remove the dependency

[Mike Looijmans]

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 <mike.looijm...@topic.nl>
---
 recipes-bsp/u-boot/u-boot-xlnx_%.bbappend | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 recipes-bsp/u-boot/u-boot-xlnx_%.bbappend

diff --git a/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend 
b/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend
deleted file mode 100644
index 6a2c4c4..000
--- a/recipes-bsp/u-boot/u-boot-xlnx_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-do_compile[depends] += "virtual/dtb:do_deploy"
-- 
1.9.1

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

[meta-xilinx] meta-xilinx-tools fails on "device-tree-generation" script

[Mike Looijmans]

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

Loaded 2517 entries from dependency cache.
Parsing recipes: 100% 
|| Time: 0:00:00
Parsing of 1742 .bb files complete (1741 cached, 1 parsed). 2518 targets, 206 
skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "ubuntu-14.04"
TARGET_SYS= "aarch64-oe-linux"
MACHINE   = "zcu102-zynqmp"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta  = "HEAD:d11c80c9394e31c239aeeb8a9c4997642e17a020"
meta-oe
meta-python   = "HEAD:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
meta-xilinx   = "HEAD:a6121299383bd171b1a19ec019836fb6b59e6c92"
meta-xilinx-tools = "master:d300775243368ec354e9ff9fbaf2ffc0da1a9744"

Initialising tasks: 100% 
|#| Time: 0:00:03
Checking sstate mirror object availability: 100% 
|#| Time: 0:00:00

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: device-tree-generation-xilinx+gitAUTOINC+43551819a1-r0 do_compile: 
Function failed: do_compile (log file is located at 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_compile.16237)
ERROR: Logfile of failure stored in: 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_compile.16237

Log data follows:
| DEBUG: Executing shell function do_compile
| gcc: error: 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/build/device-tree-generation/system-top.dts: 
No such file or directory

| gcc: warning: ‘-x assembler-with-cpp’ after last input file has no effect
| gcc: fatal error: no input files
| compilation terminated.
| WARNING: 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/run.do_compile.16237:1 
exit 4 from 'gcc -E -nostdinc -Ulinux 
-I/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0 
-I/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/build/device-tree-generation 
-I/home/mike/projects/xilinx-platform/build/tmp-glibc/work-shared/zcu102-zynqmp/kernel-source/include 
-x assembler-with-cpp -o 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/build/device-tree-generation/zcu102-zynqmp-system.pp 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/build/device-tree-generation/system-top.dts'
| ERROR: Function failed: do_compile (log file is located at 
/home/mike/projects/xilinx-platform/build/tmp-glibc/work/zcu102_zynqmp-oe-linux/device-tree-generation/xilinx+gitAUTOINC+43551819a1-r0/temp/log.do_compile.16237)
ERROR: Task 
(/home/mike/projects/xilinx-platform/meta-xilinx-tools/recipes-bsp/device-tree/device-tree-generation_git.bb:do_compile) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 2076 tasks of which 2073 didn't need to be 
rerun and 1 failed.


Summary: 1 task failed:

/home/mike/projects/xilinx-platform/meta-xilinx-tools/recipes-bsp/device-tree/device-tree-generation_git.bb:do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.


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] How to boot the ZynqMP?

[Mike Looijmans]

On 22-08-17 02:25, Jean-Francois Dagenais 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 consider the environment before printing this e-mail



On Aug 21, 2017, at 04:20, Mike Looijmans <mike.looijm...@topic.nl> 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.



I'm not sure they removed it, the u-boot-xlnx fork is about 8 months behind on 
mainline u-boot.


Stangely, the mainline version has SPL support, an I actually can get the 
board to boot with SPL. But I can't figure out how to make it load PMU and ATF.


There have been dozens of commits from Xilinx to support the zynqmp in u-boot 
mainline. None of these are in the Xilnx fork, so I assumed that Xilinx had 
seen the light... Apparently the opposite is true.




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! ;)



At least now I understand why there's so little interest in the MPSOC. The 
licensing alone is a nightmare.

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

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

[Mike Looijmans]


On 19-08-17 03:20, Jean-Francois Dagenais 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

Please consider the environment before printing this e-mail



On Aug 18, 2017, at 08:25, Mike Looijmans <mike.looijm...@topic.nl> 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



Oh, there's another meta.



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:


...

It's generating the boot.bin where my problem is now. From there on, it's just 
u-boot and Linux again, and I'm on familiar territory again...


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.


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.


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.



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

[Mike Looijmans]

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

On 18 August 2017 at 19:22, Mike Looijmans <mike.looijm...@topic.nl> wrote:

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


On 17 August 2017 at 23:12, Mike Looijmans <mike.looijm...@topic.nl>
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

[meta-xilinx] How to boot the ZynqMP?

[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

[Mike Looijmans]

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

On 17 August 2017 at 23:12, Mike Looijmans <mike.looijm...@topic.nl> 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

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

[Mike Looijmans]

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

On 17 August 2017 at 23:12, Mike Looijmans <mike.looijm...@topic.nl> 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):
   File "/home/mike/projects/zynq-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/zynq-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/zynq-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/zynq-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/zynq-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.


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?


It's a parsing error, so it fails on one recipe, and when I remove the recipe, 
some other fails, and so on. After a dozen or so, I gave up.


There's nothing special about the config. Mainly recipes that inherit gitpkgv 
seem affected. I cannot say what triggers it exactly.




The cause is this line in zcu102-zynqmp.conf:

include conf/machine/include/zynqmp-pmu-config.inc

This breaks almost all recipes that use some kind of version control. Adding
this line to any machine's config yields the same error. Removing it results
in:
ERROR: Nothing PROVIDES 'zynqmp-pmu-pmu-firmware'


If you don't need the pmu-firmware built via the meta-xilinx layer
(e.g. you source it externally or via meta-xilinx-tools), you can
remove the include and that dependency.


Actually, at the moment I don't know how to boot the ZynqMP any more, and the 
Xilinx website isn't helpful either. I can build all the components (FSBL or 
SPL, u-boot, ATF, PMU, kernel, ...) but I have no idea as to how to fit them 
together on a card on in the QSPI flash. The README in meta-xilinx doesn't 
even mention the ZynqMP.



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] ZynqMP causes tons of recipes to fail to parse because of PMU build

[Mike Looijmans]

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):
  File "/home/mike/projects/zynq-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/zynq-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/zynq-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/zynq-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/zynq-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.




The cause is this line in zcu102-zynqmp.conf:

include conf/machine/include/zynqmp-pmu-config.inc

This breaks almost all recipes that use some kind of version control. Adding 
this line to any machine's config yields the same error. Removing it results in:

ERROR: Nothing PROVIDES 'zynqmp-pmu-pmu-firmware'


How does one build zynqmp image these days?


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] tools: app.tcl exits 0 regardless of build failure

[Mike Looijmans]

On 05-06-17 14:12, Jean-Francois Dagenais wrote:



On Jun 2, 2017, at 16:03, Manjukumar Harthikote Matha 
<manjukumar.harthikote-ma...@xilinx.com> wrote:

Yes we are aware of this issue, this will happen only if you have built the 
firmware successfully before. If it is a clean project it would fail during 
do_deploy mechanism.


This depends on a clean state, something that is not respectful of Yocto's 
normal behaviour. Plus it falsely fail at do_deploy, which is completely 
misleading.

In the short term, as Mike suggests, the compile step could start by removing 
the output from it's workdir, then test it's presence at the end. I will see 
about making a patch for this.




If the task only fails at do_deploy, then Yocto would only retry that 
step, without calling do_compile again because that did not fail, and 
keep failing at deploy over and over again until some frustrated human 
intervenes and clears the sstate cache or in some other way makes the 
compile re-run.


In other words, it really needs fixing.

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



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [meta-xilinx] tools: app.tcl exits 0 regardless of build failure

[Mike Looijmans]

On 02-06-17 21:21, Jean-Francois Dagenais wrote:

Hi guys,

Take a look at this:
https://github.com/Xilinx/meta-xilinx-tools/blob/master/scripts/app.tcl#L131

There's an "exit 0" regardless of the build success or failure! WOW.

I stubbled on this by intentionally putting an error in the workdir of
pmu-firmware's build dir. The log.do_compile does show the error and make
reports it, yet my yocto build succeeds!


This is the case for most of Xilinx's tools too, they will return a "0" 
exit status even if the bitstream generation (or whatever) failed, also 
when the tcl script errors out, the tool still returns 0.


As a workaround, I always remove any existing target files before 
starting, and then add a "test -e ..." to the do_compile to make it fail 
when the program failed to produce any output.



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



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [meta-xilinx] Boot hangs using AXI GPIO

[Mike Looijmans]

Hangup at AXI usually means the logic isn't really there. Either the address 
is wrong or you programmed the wrong FPGA image.
What happens is that the CPU send out the AXI request, but no response arrives 
and there's no timeout, thus the whole system hangs.


On a side note, I'd strongly advise to get rid of the axi-gpio block and just 
use the EMIO GPIO ports on the Zynq itself. The EMIO GPIO ports use less 
resources on both sides, and there's 64 of them.




On 22-05-17 12:45, Giulio Presazzi wrote:

Hi all,

I'm struggling to solve Linux and PL AXI GPIO issue based on Microzed board.

I've a bitstream with FPGA configuration (working fine with bare-metal
application) , and I generated the .dts file starting from HDF using the
following steps:

/hsi open_hw_design .hdf/

/hsi set_repo_path ../../../device-tree-xlnx/

/hsi create_sw_design device-tree -os device_tree -proc ps7_cortexa9_0/

/hsi generate_target -dir /



When I include the dts in my new device tree file (to support LED GPIO), the
linux booting hang on starting kernel.

The node that generate the issue is:

/axi_gpio_LED_Output: gpio@8126 {/

/   #gpio-cells = <2>;/

/   compatible =
"xlnx,xps-gpio-1.00.a";/

/   gpio-controller ;/

/   //reg = <0x8126 0x1>;/

/   xlnx,all-inputs = <0x0>;/

/   xlnx,all-inputs-2 = <0x0>;/

/   xlnx,all-outputs = <0x1>;/

/   xlnx,all-outputs-2 = <0x0>;/

/   xlnx,dout-default = 
<0x>;/

/   xlnx,dout-default-2 =
<0x>;/

/   xlnx,gpio-width = <0x4>;/

/   xlnx,gpio2-width = <0x20>;/

/   xlnx,interrupt-present = <0x0>;/

/   xlnx,is-dual = <0x0>;/

/   xlnx,tri-default = 
<0x>;/

/   xlnx,tri-default-2 =
<0x>;/

/   };/

I've tried with devmem tool as well, from working linux configuration (dts
without previous node) and it hangs after calling:

*devmem -r 0x8126*

I'm using YOCTO and meta-xilinx layer to generate the kernel, boot.ini and
rootfs. I'm working with openAMP configuration (core 0 linux + Core 1 bare 
metal).

This is the BOOT trace:

/ /

/U-Boot SPL 2016.07-dirty (May 02 2017 - 15:52:44)/

/mmc boot/

/Trying to boot from MMC1/

/reading fpga.bin/

/reading fpga.bin/

/zynq_validate_bitstream: Bitstream is not validated yet (diff 73)/

/reading system.dtb/

/spl_load_image_fat_os: error reading image system.dtb, err - -1/

/reading u-boot.img/

/reading u-boot.img/

/ /

/U-Boot 2016.07 (May 10 2017 - 07:35:46 +)/

/ /

/Model: Zynq MicroZED Board/

/Board: Xilinx Zynq/

/DRAM:  ECC disabled 1 GiB/

/MMC:   sdhci@e010: 0/

/SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total
16 MiB/

/In:serial@e0001000/

/Out:   serial@e0001000/

/Err:   serial@e0001000/

/Model: Zynq MicroZED Board/

/Board: Xilinx Zynq/

/Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id/

/eth0: ethernet@e000b000/

/reading uEnv.txt/

/245 bytes read in 10 ms (23.4 KiB/s)/

/Importing environment from SD .../

/Hit any key to stop autoboot:  0 /

/Device: sdhci@e010/

/Manufacturer ID: 3/

/OEM: 5344/

/Name: SU04G /

/Tran Speed: 5000/

/Rd Block Len: 512/

/SD version 3.0/

/High Capacity: Yes/

/Capacity: 3.7 GiB/

/Bus Width: 4-bit/

/Erase Group Size: 512 Bytes/

/reading uEnv.txt/

/245 bytes read in 10 ms (23.4 KiB/s)/

/Loaded environment from uEnv.txt/

/Importing environment from SD .../

/Running uenvcmd .../

/reading uImage/

/3781072 bytes read in 329 ms (11 MiB/s)/

/reading microzed-zynq7.dtb/

/23044 bytes read in 24 ms (937.5 KiB/s)/

/## Booting kernel from Legacy Image at 0300 .../

/   Image Name:   Linux-4.9.0-xilinx-v2017.1/

/   Image Type:   ARM Linux Kernel Image (uncompressed)/

/   Data Size:3781008 Bytes = 3.6 MiB/

/   Load Address: 1000/

/   Entry Point:  1000/

/   Verifying Checksum ... OK/

/## Flattened Device Tree blob at 02a0/

/   Booting using the fdt blob at 0x2a0/

/   Loading Kernel Image ... OK/

/   Loading Device Tree to 1fff7000, end 1a03 ... OK/

/ /

/Starting kernel .../

//

/ /

Do you have any advice or configuration I need to check ?



Thanks

Giulio Presazzi







Kind regards,

Mike Looijmans
System Expert

TOPIC Products

Re: [meta-xilinx] ZU+ mali with simple panel

[Mike Looijmans]

Here's a Linux driver for a simple panel framebuffer:
  https://github.com/topic-embedded-products/kernel-module-vdmafb

The corresponding (non free) IP supports several VGA and display outputs.

Or you can create something compatible. It uses the Xilinx VDMA controller, so 
you can also use it as an example for a VDMA based framebuffer.



On 12-05-17 15:02, Jean-Francois Dagenais wrote:

Hi all! (Bonjour Laurent!;)

Preface: This is the first time I dive into display/DRM drivers, read: 
display-newbie.

Does anyone have any pointers for a reference design of the MALI being used on 
a simple fixed resolution panel? I don't need to get the MALI working just yet, 
but I don't want to wander too far since I do need to make it work in a few 
weeks. In fact, if it's more straight forward to do it using MALI first, that's 
what I'll want to do.

We currently have our display hooked up in our PL design using the Avnet ALI3 
display kit IP components and the axi-vdma engine. We confirmed it was working 
using a standalone vivado created project which generates a color stripe 
pattern in DDR.

I have not finished my analysis on how to make the display work under linux. I was 
thinking about using xlnx,drm as a start, but already I'm having doubts as our scenario 
is so much simpler since all of the "pipeline" (video timing, encoder, 
connector) are fixed in PL and un-configurable, only the vdma is visible from the driver 
code.

Could tinydrm (from latest upstream) help simplify things here?

Since our setup looks so simple, I'm hoping not to have to write code but just 
devicetree bindings. Am I dreaming?

Here are a few relevant points:
* Ultimately, the only thing that needs to drive the display is Qt in eglfs or 
the like. (QML based app)
* console is not really required but would be nice
* We will require DP to work over the USB-C connection in our final released 
product

Cheers! And thanks in advance!
/jfd





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



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [meta-xilinx] SPI problem

[Mike Looijmans]

On 11-05-17 14:31, Arno Steffens wrote:




Gesendet: Donnerstag, 11. Mai 2017 um 07:24 Uhr
Von: "Mike Looijmans" <mike.looijm...@topic.nl>
An: "Nathan Rossi" <nat...@nathanrossi.com>, "Arno Steffens" <s...@gmx.li>
Cc: meta-xilinx@yoctoproject.org
Betreff: Re: [meta-xilinx] SPI problem

On 10-05-17 15:23, Nathan Rossi wrote:

On 10 May 2017 at 17:18, Arno Steffens <s...@gmx.li> wrote:

Thanks Mike for the feedback.
It is an OnSemi Phyton camera chip.
Unfortunately FPGA is not suitable solution for me. The layout is already fixed 
and I am not an FPGA expert.
Checking the SPI registers in Technical Manual: it seems that there is no 
separate setting for CPOL/CPH for MOSI and MISO.
The only way I see is to send address, keep CS low, change SPI mode, read.
But there is another limitation. In struct spi_ioc_transfer there is a setting: 
bits_per_word. I need 10 for doing that
as described for the first part (9 bit adress + 1 r/w bit). This returns an error 
"could not transmit data". Any value expect 8 is returning an error.
Is this a limitation by hardware or an issue in driver, which can be fixed?


For the Zynq PS SPI controllers there is a hard limit to 8-bit words
(kernel driver advertises this here:
http://elixir.free-electrons.com/linux/latest/source/drivers/spi/spi-cadence.c#L565).

If you need 10b words and you do not want to do it with an FPGA
device, you can always use the kernels spi-bitbang module. But this is
likely only good for low bandwidth control SPI, so if you are using
SPI to pull image data from the camera this is probably not what you
want. Also you could easily modify the spi-bitbang module to handle
this CPOL inversion, such that it always samples MISO on the falling
edge.


Camera chips usually only use the SPI interface for configuration, so I'd go
with Nathan's suggestion and use Linux' bit-bang SPI controller for setting
camera parameters and such. Let the kernel pinmix the pins as GPIO and assign
them via devicetree to the bitbang controller.

Kind regards,

Mike Looijmans
System Expert


In fact it is just for configuration.
Thanks, so it is clear that I can't hope to solve it without changing the 
bitstream (although remapping is not a big deal). Do you have an idea what 
frequency can be achieved by this driver?
And I am a bit afraid of negative side-effect to more "realtime" related stuff 
on ARM.


I'd expect something in the 100kHz..1MHz range for the SPI bus. Changes to 
FPGA are only needed if the component is connected through logic. In which 
case it'd be better to completely solve it in logic and put a custom SPI (ish) 
controller in the FPGA that handles this chip. If SPI is connected through MIO 
pins, no change in logic is required (or possible actually).


I'm not too worried about the impact on other stuff, the SPI bitbang task can 
probably be pre-emted by any other task. I'm always using a bitbang I2C 
controller on the Zynq (because the hardware is broken) and haven't seen any 
negative effects on timing from that either.





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



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [meta-xilinx] SPI problem

[Mike Looijmans]

It would help a lot if you'd disclose what chip you're trying to communicate 
with. (My wild guess would be a maxim ultrasound chip, am I far of the mark here?)


Are you sure this isn't just compatible with existing SPI mode/phase settings?

And you have a huge FPGA at your disposal if you have a Xilinx device of any 
kind. I'd suggest just solving this in a bit of FPGA logic instead of in 
userspace C code.




On 09-05-17 14:54, Arno Steffens wrote:

I have a rather strange SPI protocol to run: write and read use different edges 
to sample.
See image:

I configured the spi like that:

  static u8 mode_wr = 0;
  static u8 mode_rd = 1;

  ret = ioctl(file_spi0, SPI_IOC_WR_MODE, _wr);
  if (ret == -1)
  printf("can't set spi mode");

  ret = ioctl(file_spi0, SPI_IOC_RD_MODE, _rd);
  if (ret == -1)
  printf("can't get spi mode");


The transfer itself runs via:

ret = ioctl(file_spi0, SPI_IOC_MESSAGE(1), );

But it seems, that only SPI_IOC_WR_MODE has an effect for both, write and read.
Is this a limitation of hardware, bug in driver or my bug?

So I have to chose either sending correct address or receive correct data.
For only mode=1 and adress=0 it works fully (as with constant 0 sampling edge 
is not of importance).

(as in the  struct spi_ioc_transfer only bits_per_word = 8 are allowed, I use a 
4 byte transfer (32bit) for these 9+1+16=26 bit.)
From what I see in Osci this seems to be fine, although it is some bit-fiddling.

Best regards
Arno







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


Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” (Topic Projects -  Herman Kusters, 1st June 
10 AM)

Visit http://eabeurs.nl/author/612884/ for more information

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

Re: [meta-xilinx] wifi chipset adapter

[Mike Looijmans]

On 03-05-17 09:27, Sébastien bouché wrote:

Hi Mike,

Thanks for your answer. First I did enable the driver in the kernel. I could
see the driver was loaded in the boot traces.
But I could not get it working. I need to redo it to provide some log.

However, It was the only thing I've done in my layer (menuconfig). could you
please give some detail regarding "include the firmware in the rootfs
(linux-firmware)." I'm not sure I understand.


When the driver starts, it will attempt to load firmware into the device. 
It'll complain on the kernel output and tell you what it is looking for.


For OpenEmbedded builds, adding some of these packages to your machine .conf 
or some other RDEPENDS or IMAGE_INSTALL will provide the required firmware 
files on the rootfs:


linux-firmware-rtl8192ce
linux-firmware-rtl8192cu
linux-firmware-rtl8192su
linux-firmware-ralink



Thanks.


-- Sébastien

On Wed, May 3, 2017 at 7:14 AM, Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@topic.nl>> wrote:

rtl8192cu works okay with the Zynq. Actually the Zynq has nothing to do
with that.

You probably need to enable the driver in the kernel (menuconfig) and
include the firmware in the rootfs (linux-firmware).


On 02-05-17 22:22, Sébastien bouché wrote:

Hello,

I'm looking for a wifi adapter reference (nanon usb dongle) that would
easily
be supported by a Zynq.
I do have an usb dongle base on realtek rtl8192cu chipset. I can't get 
it
working using the kernel version, same thing using 2 different
alternatives
found on github.

Maybe the official Raspberry pi wifi dongle based on BCM43143?

Many thanks.

-- Sébastien





    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 <tel:%2B31%20%280%29%20499%2033%2069%2079>
E-mail: mike.looijm...@topicproducts.com
<mailto:mike.looijm...@topicproducts.com>
Website: www.topicproducts.com <http://www.topicproducts.com>

Please consider the environment before printing this e-mail










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

[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] Kernel boot error: mount rootfs before init mmc

[Mike Looijmans]

Maybe adding "rootwait" to the kernel commanline helps?

On 26-04-17 08:07, Arno Steffens wrote:

Hi,
using the Linux version 4.6.0-xilinx-v2016.3 kernel and have a problem.
My rootfs is on emmc. In general it works, but from time to time it ends up in 
a crash:
It seem it tries to mount rootfs before the emmc subsystem is initialised.
Is there any trick to get this stable working?

error case:
..
[1.233167] Registering SWP/SWPB emulation handler
[1.242996] VFS: Cannot open root device "mmcblk0gp0p1" or 
unknown-block(0,0): error -6
[1.251041] Please append a correct "root=" boot option; here are the 
available partitions:
[1.259342] 0100   32768 ram0  (driver?)
[1.263925] 0101   32768 ram1  (driver?)
[1.268525] 0102   32768 ram2  (driver?)
[1.273126] 0103   32768 ram3  (driver?)
[1.277732] 1f00 128 mtdblock0  (driver?)
[1.282761] 1f014096 mtdblock1  (driver?)
[1.287793] 1f02 512 mtdblock2 [1.287803] mmc0: new high 
speed MMC card at address 0001

[1.297155]  (driver?)
[1.298318] mmcblk0: mmc0:0001 Q1J54A 0 B
[1.303779] 1f03  64 mtdblock3  (driver?)
[1.308562] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[1.314714] 1f04  64 mtdblock4  (driver?)
[1.318780] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[1.325645] 1f053584 mtdblock5 [1.328994] mmcblk0gp0: 
mmc0:0001 Q1J54A partition 4 1.82 GiB


working case:

[1.219935] can: netlink gateway (rev 20130117) max_hops=1
[1.225585] Registering SWP/SWPB emulation handler
[1.229313] mmc0: new high speed MMC card at address 0001
[1.242033] mmcblk0: mmc0:0001 Q1J54A 0 B
[1.246281] mmcblk0boot0: mmc0:0001 Q1J54A partition 1 2.00 MiB
[1.262402] mmcblk0boot1: mmc0:0001 Q1J54A partition 2 2.00 MiB
[1.278452] mmcblk0gp0: mmc0:0001 Q1J54A partition 4 1.82 GiB
[1.294347] mmcblk0rpmb: mmc0:0001 Q1J54A partition 3 512 KiB
[1.302997]  mmcblk0gp0: p1 p2 p3
[1.309002] EXT4-fs (mmcblk0gp0p1): INFO: recovery required on readonly 
filesystem
[1.316558] EXT4-fs (mmcblk0gp0p1): write access will be enabled during 
recovery
[1.400676] EXT4-fs (mmcblk0gp0p1): recovery complete
[1.407487] EXT4-fs (mmcblk0gp0p1): mounted filesystem with ordered data 
mode. Opts: (null)
[1.415798] VFS: Mounted root (ext4 filesystem) readonly on device 179:25.
[1.423783] devtmpfs: mounted

Best regards
Arno





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] meta-xilinx-tools

[Mike Looijmans]

On 29-03-17 17:47, Manjukumar Harthikote Matha wrote:

Hi Peter,

Yes 2017.1 release branch is under EA, when it is officially released these 
will point to github. Current delivery of the release branch is April 30th


Stupid question maybe, but what's an "EA"?



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] Booting MPSoC from SD card

[Mike Looijmans]


The remaining problem I still have is that pmufw kills the SD1 card controller.

I have the SD card slot connected to SD1 (MIO46 etc). On SD0 there's an 8G 
eMMC chip.


When running an old 4.6 kernel which doesn't require pmufw, both SD0 and SD1 
work fine.


Loading pmufw and running that old kernel makes SD1 fail, the kernel reports:
  mmc1: error -110 whilst initialising MMC card

SD0 (the eMMC chip) keeps functioning okay apparently.

On the newer xilinx/master 4.9 kernel, the pmufw is required, and the SD1 
fails in the same way, preventing the system to boot from SD.



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] failure : SD to u-boot SPL to u-boot on zcu102-zynqmp

[Mike Looijmans]

On 21-03-17 10:14, Mike Looijmans wrote:

On 21-03-17 09:59, Michal Simek wrote:

On 20.3.2017 21:29, Jean-Francois Dagenais wrote:

...

Now the problem is... where the heck is version 0.3! I have not seen any
branches on the xilinx repo containing it.


I am no pmufw maintainer to tell you more about it.


Who is?

I ran into the same problem here now, having spent two days on merging the 4.9 
kernel, only to find out that I cannot boot it because of the missing pmufw...


Where's 0.3?

(Smells like "tivoisation", you can see and change source code, but cannot 
really change anything because of a critical piece of firmware missing...)



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] failure : SD to u-boot SPL to u-boot on zcu102-zynqmp

[Mike Looijmans]

On 21-03-17 09:59, Michal Simek wrote:

On 20.3.2017 21:29, Jean-Francois Dagenais wrote:

Hi guys,

I am really riding the bleeding edge here...





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





On Mar 17, 2017, at 13:37, Nathan Rossi <nat...@nathanrossi.com> wrote:


Not alternate, since given the error you have not loaded any pmu
firmware. But yes, this is only relevant because you are using
u-boot-xlnx master.

The commit that introduced the requirement is
https://github.com/Xilinx/u-boot-xlnx/commit/e047c5ad3db3cc2fa8c53a4a663ac8a256159b0e


I see the printf I was getting, but this is only when I populate the SDCard with
the "atf-uboot.ub". Without the file present, the SPL would continue on to
"reading u-boot.img" a couple of times. Is it that without this PMUFW part
happening, going along and loading u-boot.img is doomed to fail? (which is what
I am seeing)



Without pmufw fw in past this worked. Right now this is probably just
working too but I want to disable this option to run u-boot from el3. We
should be el2-ns or el1-ns. That's why this option is probably there but
it is not regularly tested and it will be removed in future.





And did you just misprint "xilinx-v2016.4 kernel" instead of "u-boot"?


Well I was not sure if you were also using the master branch of
linux-xlnx or not, but linux-xlnx master has the same requirements for
PMUFW.



Did you mean I should use u-boot (upstream) instead of u-boot-xlnx?


No you will want to use u-boot-xlnx at the moment. But Michal might be
able to give you a better status on using zcu102 with upstream u-boot.


Thanks! Hope to hear from Michal soon! I think it's a good idea to provide an
alternate path at this point. This would help us developers move along while
this very low-level stuff evolves. I'll happily volunteer to test when things
appear on the master branches of meta-xilinx, u-boot-xlnx and linux-xlnx.


You need pmufw with configuration blob in it. Or pass it. This option is
not supported now that's why it is not working.
Not sure what's the plan to fix this.
Right now I can run it because I have got some internal patches to
include configuration blob for pmufw but not sure if/when this will be
pushed out.




I'm no expert on u-boot (yet ;) but I think this smells trouble. Maybe not for
meta-xilinx supported builds, but for integrators such as myself and all the
other OEMs which will use meta-xilinx as a base.

I understand about an SPL-less build. Perhaps the Makefile could inspect
CONFIG_SPL_BUILD and fail if the psu_init_gpl files aren't found. You don't get
very far with a "psu_init"-less SPL, but much better if failure occurs at build
time. I can can attempt a patch in board/xilinx/zynqmp/Makefile unless you think
its a bad idea.


I think its probably a good idea to have it fail if the ps*_init files
are missing, this probably would apply to zynq as well. But this is
something that would best be discussed on the u-boot list? or maybe
Michal can chime in here too?



My first tries were with u-boot-xlnx (v2016.4) and the SPL almost didn't start
at all. It may be related to 7d355473f34a (mmc: sdhci: zynqmp: Add support of
SD3.0) not being there yet. I did not try exactly your idea though. I will get
to it soon if nothing else works.

Can I not change something in the defconfig to remove the extra PMUFW 
dependency?


You might be able to hack around it, but I wouldn't recommend going
down that path.

Ok, so, after fooling around a bit more, here's where I am (note: at this point
I am improvising a bit, learning a lot, but need to converge soon on something
stable for the next early phases of our development...)

I am aiming for a pmufw.bin as a binary blob for the moment. So I sourced the
Vivado 2016.4 settings64.sh. Then cloned
https://github.com/Xilinx/embeddedsw.git . Using the master branch, I generated
the pmufw "executable.elf". Using a MACHINE=ml605-qemu-microblazeel bitbake gcc"
built objcopy, I generated pmufw.bin which I injected into u-boot-xlnx-dev.bb
using:

SRC_URI += "\ file://add-pmufw-to-zcu102-defconfig.patch \
file://pmufw.bin;subdir=git/board/xilinx/zynqmp \ "

The .patch adds CONFIG_PMUFW_INIT_FILE="board/xilinx/zynqmp/pmufw.bin" to
xilinx_zynqmp_zcu102_rev1.0_defconfig . I successfully created a "boot.bin" with
the PMUFW! Yay!


Here's the output...
 Debug uart enabled

U-Boot SPL 2017.01-03253-g9c9291d-dirty (Mar 20 2017 - 15:52:02)
EL Level:   EL3
Trying to boot from MMC1
reading u-boot.bin
reading atf-uboot.ub
reading atf-uboot.ub
NOTICE:  ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000, with PMU 
firmware
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: N

Re: [meta-xilinx] gpio export from device tree

[Mike Looijmans]

On 27-02-17 22:52, Jean-Francois Dagenais wrote:
...

So my questions are:
* which clause, if any, is proper in dts to export the GPIOs preferably with 
names (like /sys/class/gpio/my_gpio_name_here). Do I need to declare a new node 
which doesn’t bind to a diver for example…


There have been a number of proposals for this in the kernel, but 
they've all been rejected. The consensus seems to be that you should 
write a driver if you want to do this kind of thing in a portable way.



* (this one may be quite available in the megabytes of documentation) how does 
the gpio numbers in the kernel map to MIOxx and EMIOxx numbers. If anyone could 
point at the right doc that would save me so much grief.


They map really weird yeah. Maybe it's on purpose to discourage using 
gpio from userspace...
Best solution I found was to open /sys/class/gpiochip*/name files and 
look for the zynq gpio controller, and then use that offset. On my 
current board the zynq GPIO starts at "906". With 54 MIO GPIO pins, the 
EMIO GPIO pins thus start at 960.



--
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] Using GPU on UltraScale+ MPSoC ZCU102 Evaluation

[Mike Looijmans]

On 23-01-17 17:35, Giordon Stark wrote:

Hi all,

As it's probably apparent, this comes with the ARM Mali GPU that would be
useful for some of our applications. I'm curious about what you need to do to
interface with this (from say C/C++ and/or Python). What recipes are needed to
compile so we can access the GPU when cross-compiling a custom-written
C-script/binary?


meta-xilinx provides a mali kernel module. Haven't tried yet, but I'd expect 
it to need some firmware 'blob' from linux-firmware too.


Then add "opengl" to your FEATURES (dunno which, machine, distro, ...)

And from there it's OpenGL "as usual". First step there would be to develop 
something that runs on your desktop Linux PC and uses the video card, it'll 
use the MALI when running on the board. That's the nice thing about an 
operating system, you don't have to target particular hardware...




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] Interrupt forwarding in AMP configuration

[Mike Looijmans]

On 23-12-16 00:38, Eric Wong wrote:

In my AMP configuration with Linux on CPU0 and an RTOS on CPU1,
interrupts being routed to CPU1 are specified in the device tree entry
for remoteproc:

app: app@0 {
compatible = "xlnx,zynq_remoteproc";
reg = < 0x1E00 0x200 >;
interrupt-parent = <_scugic_0>;
interrupts = < 0 27 4  0 29 4  0 30 4  0 31 4  0 32 4  0 34 4  0
35 4  0 37 4  0 38 4  0 39 4 >;
firmware = "app.elf";
vring0 = <15>;
vring1 = <14>;
} ;

The "4" in the interrupts line means the interrupt is active high, and
things seem to be working.  If I want an interrupt to be rising edge
triggered, I change the "4" to "1", but then when that interrupt
triggers I get "Unexpected IRQ trap at vector 00" error in Linux and
Linux freezes.  Does anyone know what that means or how to fix that
error?  I would think Linux wouldn't/shouldn't even be looking at the
interrupt(s) that are routed to CPU1.  Thanks in advance.



The devicetree only guards that other drivers won't steal your interrupts 
away. It does not cause the remoteproc driver to activate or assign them.


Your firmware has to register and activate the interrupt by itself. If Linux 
complains about your interrupt, you probably routed it to the wrong CPU.



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] uboot CONFIG_SYS_SDRAM_SIZE allocation error

[Mike Looijmans]

The RAM config in current u-boot is taken from the devicetree. Modify the 
"memory" node.


You should make a "reserved" RAM region instead of reducing the size.

On 01-12-16 08:39, Arno Steffens wrote:

I switched from an older yocto u-boot (2015.01) to recent one (2016.01). Now I 
can't boot anymore:

Zynq> boot
QSPI: Kernel/Devicetree - NFS: rootfs
SF: Detected S25FL128S_64K with page size 256 Bytes, erase size 64 KiB, total 
16 MiB
device 0 offset 0x4b, size 0x1
SF: 65536 bytes @ 0x4b Read: OK
device 0 offset 0x4c, size 0x38
SF: 3670016 bytes @ 0x4c Read: OK
## Booting kernel from Legacy Image at 0208 ...
   Image Name:   Linux-4.4.0-xilinx
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3513736 Bytes = 3.4 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0200
   Booting using the fdt blob at 0x200
   Loading Kernel Image ... OK
ERROR: Failed to allocate 0x82a5 bytes below 0x0.
device tree - allocation error
FDT creation failed! hanging...### ERROR ### Please RESET the board ###


My guess for reason of that is following, but I can't solve it.

My board (based on MicroZed) has 512MB Ram, but 16MB are used for FPGA.

I managed that before with
 #ifndef __CONFIG_ZYNQ_MICROZED_H
 #define __CONFIG_ZYNQ_MICROZED_H

-#define CONFIG_SYS_SDRAM_SIZE  (1024 * 1024 * 1024)
+#define CONFIG_SYS_SDRAM_SIZE  (496 * 1024 * 1024)

In newer Uboot I can't find this definition not in that way. Nevertheless I 
added this line.
(If not, that my last message is "Starting kernel ...")

Although digging around, I couldn't find how nowadays this is handled. This 
seems memory size is not board-specific anymore. How it is handled?

Thanks





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] Zynq TTC usage by Linux

[Mike Looijmans]

One of the TTCs used to be used for clock source. This should still be 
the case if you use dynamic clocks, because the ARM timer is fixed to 
the CPU speed and does not handle frequency changes (though I think it 
should be possible to fix this purely in software, no-one seems to care 
though). The TTC can use the prescaler to adjust the timing when the CPU 
speed changes. But if you use AMP, frequency scaling will affect both 
cores, so you probably cannot use it anyway.


For AMP, I assigned the TTC1 interrupts to the remoteproc. I also add 
GPIO "hogs" for all GPIO signals it uses. That way, the AMP firmware 
doesn't need to modify various race-condition prone registers.


On 21-10-16 06:19, Edward Wingate wrote:

It looks like Linux is aware of TTC0 at least, from dmesg:
clocksource: ttc_clocksource: mask: 0x max_cycles: 0x,
max_idle_ns: 537538477 ns
ps7-ttc #0 at 9e808000, irq=18

And it is allocated with virtual memory mapping (/proc/vmallocinfo):
0x9e808000-0x9e80a0008192 of_iomap+0x2c/0x34 phys=f8001000 ioremap

I can disable it in my device tree with:
ps7_ttc_0: ps7-ttc@f8001000 { compatible = "invalid"; }

Does anyone know what TTC0 would be used for?  Doesn't seem to be
critical as Linux stills boots and runs OK.  Thanks for your help.




On Thu, Oct 20, 2016 at 5:31 PM, Edward Wingate <edwinga...@gmail.com> wrote:

Does Linux use the Zynq's triple timer counters (TTC0/1) for anything
by default?  Running in AMP mode with Linux on CPU0, I'm trying to use
TTC0/TTC1 from CPU1, but don't seem to be able to. I don't see the
TTCs' address space in /proc/iomem though.  Thanks for any help.

Ed



--
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] How to make uImage for zynqmp

[Mike Looijmans]

With a 100+MB rootfs, you might want to consider using SD card or NFS for the 
rootfs. Would save a lot of time...



On 11-10-16 09:53, Nathan Rossi wrote:

On Tue, Oct 11, 2016 at 5:37 PM, Cai, Chuntian (GE Transportation)
<chuntian@ge.com> wrote:


Hi,



How to config yocto to include CRC information?


You are mis-reading the error, the CRC check is informing you that the
ramdisk is corrupt (aka it doesn't match the CRC). This is because
your ramdisk is 102MB, which will not fit between the memory range
0x600 to 0x700 (a 16MB segment). And when you load the dtb at
0x700 it will overwrite part of your rootfs image.

Just swap the addresses you are using for the dtb and rootfs, this
will make sure the rootfs has more than enough space to load into
memory.

Regards,
Nathan


















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





-Original Message-

From: Nathan Rossi [mailto:nat...@nathanrossi.com]
Sent: Monday, October 10, 2016 6:21 PM
To: Mike Looijmans
Cc: Cai, Chuntian (GE Transportation); meta-xilinx@yoctoproject.org
Subject: EXT: Re: [meta-xilinx] How to make uImage for zynqmp



On Mon, Oct 10, 2016 at 8:00 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:


On 10-10-16 11:44, Cai, Chuntian (GE Transportation) wrote:







Hi Nathan







I am not aware of that uImage is obsoleted for arm64, could you tell



me how to use booti command to boot linux?







What address and how to set dtb and rootfs?











Ah, now we're getting to the real question.







Just looking at the u-boot source code reveils how it's done:







https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Xilinx



_u-2Dboot-2Dxlnx_blob_master_include_configs_xilinx-5Fzynqmp.h-23L189&



d=DQIBaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=Ei3floKgst6Ph



YpovUjTVlWwDEc4CVl_t-gxqM04eQY=P2RIjgA4fo1ZTJDct27dCOVsc2iB2qKhyu6p8



ZytjAk=ErswBjlcqCrJiEJlVzG9bh4U0LNmJ6YNIMrfD-8fing=







booti $kernel_addr - $fdt_addr








Yep, works the same as the other boot* style commands. The following addresses 
should work for zynqmp:



tftpboot 0x8 Image

tftpboot 0x600 core-image-minimal-ep108-zynqmp.cpio.gz.u-boot

tftpboot 0x700 Image-zynqmp-ep108.dtb booti 0x8 0x600 0x700



Regards,

Nathan




















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























-Original Message-







From: Nathan Rossi [mailto:nat...@nathanrossi.com]



Sent: Monday, October 10, 2016 5:31 PM



To: Cai, Chuntian (GE Transportation)



Cc: meta-xilinx@yoctoproject.org; Mike Looijmans



Subject: EXT: Re: [meta-xilinx] How to make uImage for zynqmp







On Mon, Oct 10, 2016 at 3:46 PM, Mike Looijmans



<mike.looijm...@topic.nl>



wrote:







On 09-10-16 03:20, Cai, Chuntian (GE Transportation) wrote:







I using bitbake build Linux system for zcu102 board.







I issue bitbake core-image-x11 , then I can found Image file in the



deploy folder, But I could not find uImage, and I want use uImage











uImage is not a valid target for aarch64/arm64 in the kernel (like it



is for arm). This is because "uImage" is actually shorthand for



u-boot wrapped zImage. And arm64 does not have support for zImage,



thus also does not have a uImage target.







(arm targets)



https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/



arch/arm/Makefile?id=refs/tags/v4.8#n365



(arm64 targets)







https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/



arch/arm64/Makefile?id=refs/tags/v4.8#n135







---







A good question is why do you want to use uImage? If you are not



aware it is possible to boot a linux "Image" with the U-Boot "booti"



command.







However it is possible to wrap the kernel image with mkimage (or a



FIT blob if you are prepared to configure the image tree). For



wrapping with mkimage the command you will need is similar to:







mkimage -A arm64 -O linux -T kernel -C none -a 0x8 -e 0x8 -d



Image Image.ub







Also if you need mkimage, run the command using the mkimage built by



OE from the sysroot relative to the tmp/deploy/images//



directory of your build (assuming you are on a x86_64 host):







../../../sysroots/x86_64-linux/usr/bin/mkimage ...















Could you tell me how to build uImage rather than Image















Just setting KERNEL_IMAGETYPE="uImage" in 

Re: [meta-xilinx] How to make uImage for zynqmp

[Mike Looijmans]

On 10-10-16 11:44, Cai, Chuntian (GE Transportation) wrote:

Hi Nathan

I am not aware of that uImage is obsoleted for arm64, could you tell me how to 
use booti command to boot linux?

What address and how to set dtb and rootfs?


Ah, now we're getting to the real question.

Just looking at the u-boot source code reveils how it's done:

https://github.com/Xilinx/u-boot-xlnx/blob/master/include/configs/xilinx_zynqmp.h#L189

booti $kernel_addr - $fdt_addr






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





-Original Message-

From: Nathan Rossi [mailto:nat...@nathanrossi.com]
Sent: Monday, October 10, 2016 5:31 PM
To: Cai, Chuntian (GE Transportation)
Cc: meta-xilinx@yoctoproject.org; Mike Looijmans
Subject: EXT: Re: [meta-xilinx] How to make uImage for zynqmp

On Mon, Oct 10, 2016 at 3:46 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

On 09-10-16 03:20, Cai, Chuntian (GE Transportation) wrote:


I using bitbake build Linux system for zcu102 board.

I issue bitbake core-image-x11 , then I can found Image file in the
deploy folder, But I could not find uImage, and I want use uImage


uImage is not a valid target for aarch64/arm64 in the kernel (like it is for arm). This 
is because "uImage" is actually shorthand for u-boot wrapped zImage. And arm64 
does not have support for zImage, thus also does not have a uImage target.

(arm targets) 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Makefile?id=refs/tags/v4.8#n365
(arm64 targets)
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Makefile?id=refs/tags/v4.8#n135

---

A good question is why do you want to use uImage? If you are not aware it is possible to boot a 
linux "Image" with the U-Boot "booti"
command.

However it is possible to wrap the kernel image with mkimage (or a FIT blob if 
you are prepared to configure the image tree). For wrapping with mkimage the 
command you will need is similar to:

mkimage -A arm64 -O linux -T kernel -C none -a 0x8 -e 0x8 -d Image 
Image.ub

Also if you need mkimage, run the command using the mkimage built by OE from the 
sysroot relative to the tmp/deploy/images// directory of your build 
(assuming you are on a x86_64 host):

../../../sysroots/x86_64-linux/usr/bin/mkimage ...




Could you tell me how to build uImage rather than Image



Just setting KERNEL_IMAGETYPE="uImage" in the kernel recipe or machine
config would do that.

I think you can even specify multiple types in there.


You can, KERNEL_IMAGETYPES += ""

Regards,
Nathan





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 mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH] arm-trusted-firmware: Use constants for memory addresses

[Mike Looijmans]

On 29-09-16 16:22, Nathan Rossi wrote:

On Thu, Sep 29, 2016 at 7:46 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

On 28-09-16 17:20, Nathan Rossi wrote:


On Wed, Sep 28, 2016 at 10:50 AM, Manjukumar Harthikote Matha
<manjukumar.harthikote-ma...@xilinx.com> wrote:


Hi Mike,

<.>


   LD[unexport] = "1"

+ZYNQMP_ATF_MEM_BASE = "0xfffe5000"
+ZYNQMP_ATF_MEM_SIZE ="0x16000"


Maybe reading the load address from elf might help. I think MEM_BASE
address might change going forward.

For example:
https://github.com/Xilinx/arm-trusted-firmware/commit/eb4fa652d424b895
7a927c6137e2ae3652b0b1bb



This patch was to accommodate that. The current version will load it at
the wrong
location.


I am looking to see if we can read from the generated elf and populate
the MEM_BASE and MEM_SIZE
With the current patch, I think it will be maintenance burden every
release, trying to mitigate it if possible.



The generated bl31.elf is populated with the correct entry point address:
Entry point address:   0xfffe5000

Which is pointing to bl31_entrypoint,

https://github.com/Xilinx/arm-trusted-firmware/blob/eb4fa652d424b8957a927c6137e2ae3652b0b1bb/bl31/bl31.ld.S#L35

Which could be used as an alternate source of the address:
 625: fffe5000   212 FUNCGLOBAL DEFAULT1
bl31_entrypoint

My only query is whether the ZYNQ_ATF_MEM_* variables make sense as
overrides? Essentially if there is a potential use case when bl31
needs to be built to execute in an older/newer environment that
differs from the default values (of the current version used)?



What I really wanted is the opposite, get the address from the binary. That
would solve the "magic number" that you have to put in the recipe. I
couldn't find a way to do that, so I did the opposite, make sure that both
code and recipe share the same magic number.

I had no intention of making this "configurable" or so, I just wanted it
consistent.




That makes it simpler then :). I have a sent a patch that does the
dynamic reading from the elf to solve this. If you could please give
it a test and let me know that it works as you expect.


Looks fine, and a lot better than what I came up with. Probably won't be able 
to test today though.


M.



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] arm-trusted-firmware: Use constants for memory addresses

[Mike Looijmans]

On 28-09-16 17:20, Nathan Rossi wrote:

On Wed, Sep 28, 2016 at 10:50 AM, Manjukumar Harthikote Matha
<manjukumar.harthikote-ma...@xilinx.com> wrote:

Hi Mike,

<.>

  LD[unexport] = "1"

+ZYNQMP_ATF_MEM_BASE = "0xfffe5000"
+ZYNQMP_ATF_MEM_SIZE ="0x16000"

Maybe reading the load address from elf might help. I think MEM_BASE
address might change going forward.

For example:
https://github.com/Xilinx/arm-trusted-firmware/commit/eb4fa652d424b895
7a927c6137e2ae3652b0b1bb



This patch was to accommodate that. The current version will load it at the 
wrong
location.


I am looking to see if we can read from the generated elf and populate the 
MEM_BASE and MEM_SIZE
With the current patch, I think it will be maintenance burden every release, 
trying to mitigate it if possible.


The generated bl31.elf is populated with the correct entry point address:
   Entry point address:   0xfffe5000

Which is pointing to bl31_entrypoint,
https://github.com/Xilinx/arm-trusted-firmware/blob/eb4fa652d424b8957a927c6137e2ae3652b0b1bb/bl31/bl31.ld.S#L35

Which could be used as an alternate source of the address:
625: fffe5000   212 FUNCGLOBAL DEFAULT1 bl31_entrypoint

My only query is whether the ZYNQ_ATF_MEM_* variables make sense as
overrides? Essentially if there is a potential use case when bl31
needs to be built to execute in an older/newer environment that
differs from the default values (of the current version used)?



What I really wanted is the opposite, get the address from the binary. That 
would solve the "magic number" that you have to put in the recipe. I couldn't 
find a way to do that, so I did the opposite, make sure that both code and 
recipe share the same magic number.


I had no intention of making this "configurable" or so, I just wanted it 
consistent.







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] Warnings that items did not make it into the final kernel configuration

[Mike Looijmans]

On 05-09-16 08:05, Mike Looijmans wrote:

On 02-09-16 12:42, Mike Looijmans wrote:
 > On 02-09-16 12:12, Nathan Rossi wrote:
 >  > On Fri, Sep 2, 2016 at 8:02 PM, Mike Looijmans <mike.looijm...@topic.nl>
wrote:
 >  >>
 >  >> On 01-09-16 08:53, Nathan Rossi wrote:
 >  >>> On Thu, Sep 1, 2016 at 3:12 AM, Peter Smith <sale...@gmail.com> wrote:
 >  >>>> Glad its not just me. Do you think it could be related to my use of the
 >  >>>> master branch rather than a released version?
 >  >>>>
 >  >>>> On 31 August 2016 at 15:00, Mike Looijmans <mike.looijm...@topic.nl>
wrote:
 >  >>>>>
 >  >>>>> On 31-08-16 15:40, SMITH Peter T wrote:
 >  >>>>>>
 >  >>>>>> Hi,
 >  >>>>>>
 >  >>>>>> I am trying to build core image minimal for the ZCU102 using the 
master
 >  >>>>>> branches poky and meta-xilinx and I am receiving lots of warnings 
about
 >  >>>>>> kernel
 >  >>>>>> configurations not making it into the final kernel configurations. Is
 >  >>>>>> this
 >  >>>>>> normal or I have I done something wrong?
 >  >>>>>
 >  >>>>>
 >  >>>>> Well I noticed that the kernel config doesn't quite work as expected 
on
 >  >>>>> that particular board but I'm still investigating the "why" myself.
 >  >>>
 >  >>> Found the bug, it relates to a change in oe-core/kernel-yocto.bbclass
 >  >>> that was made recently 0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3. The
 >  >>> values for KCONFIG_MODE changed, such that it is defaulting to
 >  >>> "allnoconfig". This only applies to zcu102-zynqmp because its the only
 >  >>> machine that uses a KBUILD_DEFCONFIG as the base.
 >  >>>
 >  >>> I've staged the following patch
 >  >>>
 >
https://github.com/nathanrossi/meta-xilinx/commit/34e08e9f6635d4365058a96ea13bf8286d9930a8.
 >  >>> Could one of you confirm that it resolves the issue and that the built
 >  >>> kernel works?
 >  >>
 >  >> Hmm, it seems to break my build:
 >  >>
 >  >> | [INFO] Configuring target/machine combo: "alldefconfig/--reconfig"
 >  >> | No build dir specified. Use "-o" to specify one.
 >  >> | config of "alldefconfig/--reconfig" failed
 >  >>
 >  >> so apparently this is for a newer OE master?
 >  >
 >  > Yes the oe change was committed ~2.5 weeks ago, specifically on
 >  > 2016-08-18 08:27:13 (GMT). But it is odd that you are seeing issues
 >  > with configs before this patch was applied to master, maybe a separate
 >  > issue with the configs?
 >
 > So far the problem I was having was that in the "dev" kernel the "defconfig"
 > from the kernel itself would be mostly ignored, so almost no drivers were
 > selected. I worked around that by copying most of the kernel 4.6 defconfig
 > into the zynqmp.cfg files.
 >
 > I'm re-building with today's OE master to see if that issue is related.

Not related.

If I build the "dev" kernel (current master of linux-xlnx), the "defconfig"
for the ZynqMP doesn't actually get parsed somehow, and I end up with a kernel
that won't compile due to conflicting defines (for example
"CONFIG_SOC_XILINX_ZYNQMP" is not set, causing
drivers/soc/xilinx/zynqmp/tap_delays.c, which somehow still triggers to be
compiled, to fail because the header contains blank implementations.

What does work is manually copy the defconfig contents into a cfg file. But
that's not how it's supposed to work I guess.



Found the issue, "xilinx_zynqmp_defconfig" in the xilinx kernel repo is just 
broken. It's missing lots of standard options like "USB" and "BLOCK", so all 
the needfull things get ignored.


I'l send a fixup patch to 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

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacancy/topic-zoekt-technische-software-engineers/


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

[meta-xilinx] [PATCH] arm-trusted-firmware: Use constants for memory addresses

[Mike Looijmans]

Define ZYNQMP_ATF_MEM_BASE and ZYNQMP_ATF_MEM_SIZE and pass these through
to the compiler and image tool. This ensures that the code and the image
use the same values.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_git.bb | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_git.bb 
b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_git.bb
index f384f5b..7254e4a 100644
--- a/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_git.bb
+++ b/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_git.bb
@@ -31,12 +31,15 @@ LDFLAGS[unexport] = "1"
 AS[unexport] = "1"
 LD[unexport] = "1"
 
+ZYNQMP_ATF_MEM_BASE = "0xfffe5000"
+ZYNQMP_ATF_MEM_SIZE ="0x16000"
+
 do_configure() {
:
 }
 
 do_compile() {
-   oe_runmake PLAT=${PLATFORM} RESET_TO_BL31=1 bl31
+   oe_runmake ZYNQMP_ATF_MEM_BASE=${ZYNQMP_ATF_MEM_BASE} 
ZYNQMP_ATF_MEM_SIZE=${ZYNQMP_ATF_MEM_SIZE} ERROR_DEPRECATED=1 PLAT=${PLATFORM} 
RESET_TO_BL31=1 bl31
 }
 
 do_install() {
@@ -47,6 +50,6 @@ do_deploy() {
install -d ${DEPLOYDIR}
install -m 0644 ${S}/build/${PLATFORM}/release/bl31/bl31.elf 
${DEPLOYDIR}/bl31-${MACHINE}.elf
install -m 0644 ${S}/build/${PLATFORM}/release/bl31.bin 
${DEPLOYDIR}/bl31-${MACHINE}.bin
-   mkimage -A arm64 -O linux -T kernel -C none -a 0xfffe5000 -e 0xfffe5000 
-d ${S}/build/${PLATFORM}/release/bl31.bin ${DEPLOYDIR}/atf.ub
+   mkimage -A arm64 -O linux -T kernel -C none -a ${ZYNQMP_ATF_MEM_BASE} 
-e ${ZYNQMP_ATF_MEM_BASE} -d ${S}/build/${PLATFORM}/release/bl31.bin 
${DEPLOYDIR}/atf.ub
 }
 addtask deploy before do_build after do_compile
-- 
1.9.1

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

Re: [meta-xilinx] Xilinx SDK projects in Yocto

[Mike Looijmans]

On 31-08-16 07:19, Edward Wingate wrote:> Is it possible to use Yocto to compile a Xilinx SDK project?  Would II'm experimenting with that. A recipe like this may be used to compile an existing SDK project using Eclipse (work in progress, I happen to be doing the same thing):SUMMARY = "ARM firmware for second CPU"LICENSE = "CLOSED"SRC_URI = "git://${HOME}/projects/amp-blink"SRCREV = "${AUTOREV}"inherit gitpkgvPV = "0+${SRCPV}"PKGV = "0+${GITPKGV}"S = "${WORKDIR}/git"# Using toolchain from Xilinx, so no dependency on libc or gcc.INHIBIT_DEFAULT_DEPS = "1"XILINX_SDK_VERSION = "2016.2"XILINX_SDK_PATH = "/opt/Xilinx/SDK/${XILINX_SDK_VERSION}"ECLIPSE = "${XILINX_SDK_PATH}/eclipse/lnx64.o/eclipse"VM = "${XILINX_SDK_PATH}/tps/lnx64/jre/bin"WSPACE = "${S}/workspace"TARGET = "blink/Release/blink.elf"# Magic Xilinx eclipse build command, see:# http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_2/SDK_Doc/concepts/sdk_c_headless_mode.htm# Since (like all Xilinx tools) you don't get a sensible return value, check# for presence of the output file on completion to trigger a compile error.do_compile() { ${ECLIPSE} -vm ${VM} -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -build all -data ${WSPACE} -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole test -e "${TARGET}"}FILES_${PN} = "/lib/firmware"do_install() { install -d ${D}/lib/firmware install -m 644 ${S}/${TARGET} ${D}/lib/firmware/}> use the Linux version of Xilinx SDK, or could/would I use some other> toolchain that's more command-line oriented?  Could I furthermoreXilinx SDK is actually just Eclipse, and that isn't very commandline friendly as it seems. I've virtually no experience with it.My biggest problem is that XSDK creates about a hundred files, and it's unclear how to store them in version control. Answers from Xilinx like these:http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/SDK_Doc/reference/sdk_u_cvs.htmare just plain wrong, if you commit the files listed there and clone it elsewhere, it won't even see the project and build nothing.For the Zynq, one could use the OE toolchain to build the AMP firmware, since they are the same CPU. Haven't tried that yet, but it would nicely solve the issues with the SDK toolchain that requires manual installation of various host system packages because it's a 32-bit program.On the MPSOC, the R5 cores don't have the same instruction set as the A53 cores, so you need a different "tune" for those. To build with the OE chain, you'd have to define a machine for them. OE is currently working on a multi-config feature that might be able to build such a system in one call.> build a BOOT.BIN from, say, a Xilinx SDK-based FSBL and a Yocto> generated u-boot.elf?  Can anyone point me to or provide example> recipes that accomplish some of these things?  Thanks for any help.In meta-topic I have made recipes that build a Vivado project, export the resulting 'hardware' into the sysroot (including ps7_init.c) and then use that to build u-boot SPL. Other recipes can use the hardware output as they see fit too. You can call bootgen from the build of course, just like other Xilinx tools.I abandoned that route because of the bugs and limitations in Vivado's PS configuration, currently I just let Vivado generate a "draft" script and then manually patch that. With kernel 4.x the pinmuxing can be done in the kernel, so the bootloader can be quite generic (only needs to configure boot devices).
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC
  Products

   

   
  

  Materiaalweg
  4

   

   
  

  5681
  RJ Best

  T:

  +31 (0) 499 33
  69 69
  

  Postbus
  440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK
  Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the environment before printing this
e-mailTopic zoekt gedreven (embedded) software specialisten!



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

Re: [meta-xilinx] [PATCH] zcu102-zynqmp.conf: Add parameters for UBI filesystem creation

[Mike Looijmans]

On 17-08-16 15:51, Nathan Rossi wrote:> On Tue, Aug 16, 2016 at 7:13 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:>> Provide the data that the UBI tools need to create filesystems for>> the zcu102 board.>>>> (Note that the QSPI drivers for the Zynq and the ZynqMP do not work>> properly when in parallel mode, so the resulting filesystem cannot>> actually be mounted yet.)>>>> Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>>> --->>   conf/machine/zcu102-zynqmp.conf | 6 ++>>   1 file changed, 6 insertions(+)>>>> diff --git a/conf/machine/zcu102-zynqmp.conf b/conf/machine/zcu102-zynqmp.conf>> index b2bb9dc..c0f8196 100644>> --- a/conf/machine/zcu102-zynqmp.conf>> +++ b/conf/machine/zcu102-zynqmp.conf>> @@ -24,3 +24,9 @@ EXTRA_IMAGEDEPENDS += "\>>>>   # The xczu9eg has a MALI GPU>>   MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-mali">> +>> +# Use QSPI flash with 128k sector size>> +MKUBIFS_ARGS = "-m 1 -e 131200 -c 952">> "-e 128KiB" is valid with mkfs.ubifs.I don't know, would that yield the same result? 128KiB = 131072Hmm, something is goofy here, I would have expected 131072-128 = 130944>> +UBINIZE_ARGS = "-m 1 -p 128KiB">> +UBI_VOLNAME = "qspi-rootfs">> Is the custom volname set for a specific reason? if yes this patch> should probably use the multiubi type with the name "qspi" to allow> for ubifs use with other flash devices on the board?No particular reason for anything, I just ran some ubi commands on the target and copied the results into the recipe like always.At least, I think I did. Apparently not, because the mkfs args are plain wrong...
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC
  Products

   

   
  

  Materiaalweg
  4

   

   
  

  5681
  RJ Best

  T:

  +31 (0) 499 33
  69 69
  

  Postbus
  440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK
  Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the environment before printing this
e-mailTopic zoekt gedreven (embedded) software specialisten!



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

[meta-xilinx] [PATCH] Rename "mali-modules.bb" to "kernel-module-mali.bb"

[Mike Looijmans]

Since the recipe only actually produces a package called "kernel-module-mali",
it's logical to just name it "kernel-module-mali.bb". This gets rid of the
empty "mali-modules" package and the "PROVIDES" workaround.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 recipes-graphics/mali/kernel-module-mali.bb| 35 
 .../mali/kernel-module-mali/Makefile.patch | 36 +
 recipes-graphics/mali/mali-modules.bb  | 37 --
 recipes-graphics/mali/mali-modules/Makefile.patch  | 36 -
 4 files changed, 71 insertions(+), 73 deletions(-)
 create mode 100644 recipes-graphics/mali/kernel-module-mali.bb
 create mode 100644 recipes-graphics/mali/kernel-module-mali/Makefile.patch
 delete mode 100644 recipes-graphics/mali/mali-modules.bb
 delete mode 100644 recipes-graphics/mali/mali-modules/Makefile.patch

diff --git a/recipes-graphics/mali/kernel-module-mali.bb 
b/recipes-graphics/mali/kernel-module-mali.bb
new file mode 100644
index 000..c809243
--- /dev/null
+++ b/recipes-graphics/mali/kernel-module-mali.bb
@@ -0,0 +1,35 @@
+SUMMARY = "A Mali 400 Linux Kernel module"
+SECTION = "kernel/modules"
+
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = " \
+   
file://linux/license/gpl/mali_kernel_license.h;md5=68c66513a9dacef77a52c3d6c5e6afd5
 \
+   "
+
+PV = "r5p1-01rel0"
+
+SRC_URI = " \
+   
http://malideveloper.arm.com/downloads/drivers/DX910/${PV}/DX910-SW-99002-${PV}.tgz
 \
+   file://Makefile.patch \
+   "
+SRC_URI[md5sum] = "9c85c113e4d41ae992e45ba27287d1ab"
+SRC_URI[sha256sum] = 
"86209c99c36a7622402b016b6f764c212b738ccdec9cdc6d6f16758c013957a0"
+
+inherit module
+
+do_make_scripts[depends] += "virtual/kernel:do_unpack"
+
+S = "${WORKDIR}/driver/src/devicedrv/mali"
+
+COMPATIBLE_MACHINE = "^$"
+COMPATIBLE_MACHINE_zynqmp = "zynqmp"
+
+EXTRA_OEMAKE = 'KDIR="${STAGING_KERNEL_DIR}" \
+   ARCH="${ARCH}" \
+   BUILD=release \
+   MALI_PLATFORM="arm" \
+   USING_DT=1 \
+   MALI_SHARED_INTERRUPTS=1 \
+   CROSS_COMPILE="${TARGET_PREFIX}" \
+   O=${STAGING_KERNEL_BUILDDIR} \
+   '
diff --git a/recipes-graphics/mali/kernel-module-mali/Makefile.patch 
b/recipes-graphics/mali/kernel-module-mali/Makefile.patch
new file mode 100644
index 000..0f05687
--- /dev/null
+++ b/recipes-graphics/mali/kernel-module-mali/Makefile.patch
@@ -0,0 +1,36 @@
+Change Makefile to be compatible with Yocto
+
+Signed-off-by: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
+Upstream Status: Pending
+--- driver/src/devicedrv/mali/Makefile 2015-03-29 20:38:45.0 -0700
 b/Makefile 2016-01-26 20:13:56.053436042 -0800
+@@ -85,7 +85,11 @@
+ # Define host system directory
+ KDIR-$(shell uname -m):=/lib/modules/$(shell uname -r)/build
+ 
+-include $(KDIR)/.config
++ifeq ($(O),)
++  include $(KDIR)/.config
++else
++  include $(O)/.config
++endif
+ 
+ ifeq ($(ARCH), arm)
+ # when compiling for ARM we're cross compiling
+@@ -170,10 +174,15 @@
+ EXTRA_DEFINES += -DPROFILING_SKIP_PP_JOBS=1 -DPROFILING_SKIP_GP_JOBS=1
+ endif
+ 
++EXTRA_DEFINES += -Wno-error=date-time
++
+ all: $(UMP_SYMVERS_FILE)
+-  $(MAKE) ARCH=$(ARCH) -C $(KDIR) M=$(CURDIR) modules
++  $(MAKE) ARCH=$(ARCH) -C $(KDIR) M=$(CURDIR) O=$(O) modules
+   @rm $(FILES_PREFIX)__malidrv_build_info.c 
$(FILES_PREFIX)__malidrv_build_info.o
+ 
++modules_install:
++  $(MAKE) ARCH=$(ARCH) -C $(KDIR) M=$(CURDIR) modules_install
++
+ clean:
+   $(MAKE) ARCH=$(ARCH) -C $(KDIR) M=$(CURDIR) clean
+ 
diff --git a/recipes-graphics/mali/mali-modules.bb 
b/recipes-graphics/mali/mali-modules.bb
deleted file mode 100644
index 20f9d41..000
--- a/recipes-graphics/mali/mali-modules.bb
+++ /dev/null
@@ -1,37 +0,0 @@
-SUMMARY = "A Mali 400 Linux Kernel module"
-SECTION = "kernel/modules"
-
-PROVIDES += "kernel-module-mali"
-
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = " \
-   
file://linux/license/gpl/mali_kernel_license.h;md5=68c66513a9dacef77a52c3d6c5e6afd5
 \
-   "
-
-PV = "r5p1-01rel0"
-
-SRC_URI = " \
-   
http://malideveloper.arm.com/downloads/drivers/DX910/${PV}/DX910-SW-99002-${PV}.tgz
 \
-   file://Makefile.patch \
-   "
-SRC_URI[md5sum] = "9c85c113e4d41ae992e45ba27287d1ab"
-SRC_URI[sha256sum] = 
"86209c99c36a7622402b016b6f764c212b738ccdec9cdc6d6f16758c013957a0"
-
-inherit module
-
-do_make_scripts[depends] += "virtual/kernel:do_unpack"
-
-S = "${WORKDIR}/driver/src/devicedrv/mali"
-
-COMPATIBLE_MACHINE = "^$"
-COMPATIBLE_MACHINE_zynqmp = "zynqmp"
-
-EXTRA_OEMAKE = 'KDIR="${STAGING_KERNEL

[meta-xilinx] [PATCH] machine-xilinx-default.inc: Fix misspelled "kernel-module-mali"

[Mike Looijmans]

The kernel module is named "kernel-module-mali", not 
"kernel-module-mali-modules"
Fix this in machine-xilinx-default.inc.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 conf/machine/include/machine-xilinx-default.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/machine-xilinx-default.inc 
b/conf/machine/include/machine-xilinx-default.inc
index 02fa077..04f8558 100644
--- a/conf/machine/include/machine-xilinx-default.inc
+++ b/conf/machine/include/machine-xilinx-default.inc
@@ -36,5 +36,5 @@ UBOOT_ELF ?= "u-boot"
 UBOOT_ELF_aarch64 ?= "u-boot.elf"
 
 # kernel modules for ZynqMP
-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS_append_zynqmp = " 
kernel-module-mali-modules"
+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS_append_zynqmp = " kernel-module-mali"
 
-- 
1.9.1

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

Re: [meta-xilinx] What kernel for MPSoC?

[Mike Looijmans]

On 22-07-16 15:31, Nathan Rossi wrote:> On Fri, Jul 22, 2016 at 3:25 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:>>>> If I modify the devicetree and disable the 'psci' part, the system boots fine>> but doesn't wake the other three cores.>> By default ZynqMP machines are setup to use PSCI for cpu bringup (QEMU> has a PSCI implementation in-built), which means you will have to load> some firmware before the kernel to handle PSCI calls, etc. ARM Trusted> Firmware is what Xilinx recommends and they provide support for.>> The u-boot post regarding SPL> (http://lists.denx.de/pipermail/u-boot/2016-May/254902.html) has info> for booting atf. By default meta-xilinx will build an ATF binary for> ZynqMP targets.Please explain, it seems to build a package "arm-trusted-firmware" but it doesn't seem to make its way into the image or deployment area?
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC 
  Products

   

   
  

  Materiaalweg 
4

   

   
  

  5681 
  RJ Best

  T:

  +31 (0) 499 33 69 
  69
  

  Postbus 440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK 
Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the 
environment before printing this e-mailTopic zoekt gedreven (embedded) software specialisten!



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

Re: [meta-xilinx] SPL on ZynqMP ZCU102 evaluation board

[Mike Looijmans]

On 20-07-16 12:52, Michal Simek wrote:> On 20.7.2016 07:43, Mike Looijmans wrote:>> On 19-07-16 23:03, Philip Balister wrote:>>   > On 07/19/2016 11:15 AM, Michal Simek wrote:>> ...>>   >> SPL support for this board will be merged to xilinx u-boot tree pretty>>   >> soon. I have already added all psu_init files to the tree.>>   >> Just wait couple of days and then you can use it.>>   >>>>   >> But still keep in your mind SPL is not officially supported boot flow.>>   >>>   > Who are the right people to talk to about this? It always good to remind>>   > people in official Xilinx positions how much we value SPL support.>>>> +1 to that.>> Philip: You will have a chance to talk to that people soon.>> I have just pushed new branch based on the latest u-boot tree.> https://github.com/Xilinx/u-boot-xlnx>> You should be able to get spl up and running on zcu102 board directly.And I noticed that QSPI still isn't supported with SPL.I think it could be provided in a simple way: When the SPL starts the QSPI is still in memory mapped mode. So one could just memcpy the u-boot.img part from that range into DDR and boot.Would that work?(One could even boot a self-extracting kernel directly from that mapped location if it fits in the first 16MB.)
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC 
  Products

   

   
  

  Materiaalweg 
4

   

   
  

  5681 
  RJ Best

  T:

  +31 (0) 499 33 69 
  69
  

  Postbus 440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK 
Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the 
environment before printing this e-mailTopic zoekt gedreven (embedded) software specialisten!



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

Re: [meta-xilinx] SPL on ZynqMP ZCU102 evaluation board

[Mike Looijmans]

On 20-07-16 12:52, Michal Simek wrote:> On 20.7.2016 07:43, Mike Looijmans wrote:>> On 19-07-16 23:03, Philip Balister wrote:>>   > On 07/19/2016 11:15 AM, Michal Simek wrote:>> ...>>   >> SPL support for this board will be merged to xilinx u-boot tree pretty>>   >> soon. I have already added all psu_init files to the tree.>>   >> Just wait couple of days and then you can use it.>>   >>>>   >> But still keep in your mind SPL is not officially supported boot flow.>>   >>>   > Who are the right people to talk to about this? It always good to remind>>   > people in official Xilinx positions how much we value SPL support.>>>> +1 to that.>> Philip: You will have a chance to talk to that people soon.>> I have just pushed new branch based on the latest u-boot tree.> https://github.com/Xilinx/u-boot-xlnx>> You should be able to get spl up and running on zcu102 board directly. Debug uart enabledU-Boot SPL 2016.07 (Jul 20 2016 - 13:40:30)EL Level:   EL3Trying to boot from MMC1reading u-boot.binreading atf.ubspl_load_image_fat: error reading image atf.ub, err - -1reading u-boot.imgspl_load_image_fat: error reading image u-boot.img, err - -1SPL: failed to boot from all boot devices### ERROR ### Please RESET the board ###The build did produce u-boot.bin, but I have no idea what the "atf.ub" and "u-boot.img" files are supposed to do.
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC 
  Products

   

   
  

  Materiaalweg 
4

   

   
  

  5681 
  RJ Best

  T:

  +31 (0) 499 33 69 
  69
  

  Postbus 440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK 
Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the 
environment before printing this e-mailTopic zoekt gedreven (embedded) software specialisten!



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

Re: [meta-xilinx] zcu102: Does not build boot.bin

[Mike Looijmans]

On 19-07-16 10:51, Nathan Rossi wrote:> On Tue, Jul 19, 2016 at 6:05 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:>>>> Set MACHINE to zcu102-zynqmp and built a test image.>>>> However, the bootloader seems to only build a secondstage u-boot, the first>> stage is missing. The README suggests it would be there, so what's missing?>>>> Hi Mike,>> I am not 100% sure of the state of u-boot-spl for zynqmp (whats> functional, etc.). But boot.bin support for zynqmp was added in u-boot> v2016.07, so meta-xilinx does not yet deploy zynqmp SPL by default.Okay, so what do I have to do to boot the board? Just upgrade u-boot to the denx master? Or is there still stuff in u-boot-xlnx that we need?(I'd prefer to have SPL of course. It's probably possible to build an FSBL with Vivado, but that's rather useless if you want to have automated builds.)
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC 
  Products

   

   
  

  Materiaalweg 
4

   

   
  

  5681 
  RJ Best

  T:

  +31 (0) 499 33 69 
  69
  

  Postbus 440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK 
Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the 
environment before printing this e-mailTopic zoekt gedreven (embedded) software specialisten!



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

[meta-xilinx] zcu102: Does not build boot.bin

[Mike Looijmans]

Set MACHINE to zcu102-zynqmp and built a test image.However, the bootloader seems to only build a secondstage u-boot, the first stage is missing. The README suggests it would be there, so what's missing?
 
Kind regards,
 
Mike Looijmans
System Expert
 





  
  

  TOPIC 
  Products

   

   
  

  Materiaalweg 
4

   

   
  

  5681 
  RJ Best

  T:

  +31 (0) 499 33 69 
  69
  

  Postbus 440

  E:

  mike.looijm...@topicproducts.com
  

  5680 AK 
Best

  W:

  www.topicproducts.com
  
The Netherlands



 Please consider the 
environment before printing this e-mailTopic zoekt gedreven (embedded) software specialisten!



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

Re: [meta-xilinx] [RFC] machine-xilinx-default.inc: Include kernel modules

[Mike Looijmans]

That looks like too much of a simplistic approach, as this will dump each and 
every built module into any image.


The proper solution would be to explicitly list the modules that are really 
required.



On 04-05-16 08:04, Manjukumar Matha wrote:

Include kernel modules for ZynqMP. Kernel modules will be needed when including
mali modules.

Signed-off-by: Manjukumar Matha <manjukumar.harthikote-ma...@xilinx.com>
---
  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 2df8f4d..ad5465d 100644
--- a/conf/machine/include/machine-xilinx-default.inc
+++ b/conf/machine/include/machine-xilinx-default.inc
@@ -32,3 +32,4 @@ UBOOT_BINARY ?= "u-boot${UBOOT_OFEMBED}.${UBOOT_SUFFIX}"
  UBOOT_ELF ?= "u-boot"
  UBOOT_ELF_aarch64 ?= "u-boot.elf"

+MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS_zynqmp = "kernel-modules"





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] Fwd: PS I2C access by CPU1

[Mike Looijmans]

On 16-04-16 07:25, Edward Wingate wrote:

On Thu, Apr 14, 2016 at 10:43 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:

One would normally add a status="disabled"; instead of changing the
compatible.

You can also completely remove the node using:

/delete-node/ _i2c_0;


Neither disabled nor delete-node seem to work. CPU1 can't access the
ps7_i2c_0 unless the node is entirely defined in the device tree.
Until I figure out how to do it the right way, I'll have to leave it
like that so that it at least works, though that opens up the
possibility that something in Linux may try to access it.


The kernel "knows" about most of the clock tree in the Zynq, and it will turn 
off any path that wasn't claimed by a driver (even if that clock was already 
running at boot).


This leads to a 'race' with the second CPU, even if the code for that turns 
the clock on at some point, the Linux kernel may still disable it later on.


Most likely the I2C clock is disabled by the kernel.


As for the clock, it just does not seem right to force-enable all clocks.


I just did this to test if it had any effect when using "incompatible"
(and "disabled" and "delete-node").


I would instantiate a "dummy" platform driver that doesn't really do
anything, but manages the resources that the FreeRTOS part needs, such as
clocks and memory ranges. That ensures that other drivers won't access it.


How would this dummy driver ensure other Linux drivers won't access
things without also locking out CPU1 from using, say, the ps7 i2c
controller?


The driver just "registers" and enables the clocks (and power supplies, memory 
ranges or whatever) the second CPU needs, and doesn't actually use them. So it 
registers a memory range, some clocks, and enables these clocks. The driver 
would only have a "probe" method that does this and nothing else.


If there's overlap in memory ranges for example, the kernel will complain 
loudly about that.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] PS I2C access by CPU1

[Mike Looijmans]

One would normally add a status="disabled"; instead of changing the compatible.

You can also completely remove the node using:

/delete-node/ _i2c_0;

I stopped using the PS7 I2C controller, it's just broken and doesn't work 
reliably if you need to transmit more than a few bytes. Use one in logic or 
just bitbang the lines.


As for the clock, it just does not seem right to force-enable all clocks.

I would instantiate a "dummy" platform driver that doesn't really do anything, 
but manages the resources that the FreeRTOS part needs, such as clocks and 
memory ranges. That ensures that other drivers won't access it.



On 14-04-16 18:59, Edward Wingate wrote:

I'm using Zynq 7020 AMP config with Linux on CPU0 and FreeRTOS on
CPU1.  ps7_i2c_0 is to be used by CPU1.  What is the proper device
tree setting to use for ps7_i2c_0 in this case?

1) ps7_i2c_0: ps7-i2c@e0004000 { compatible = "invalid"; };
or
2) ps7_i2c_0: ps7-i2c@e0004000 {
 bus-id = <0>;
 clocks = < 38>;
 compatible = "cdns,i2c-r1p10", "xlnx,ps7-i2c-1.00.a";
 interrupt-parent = <_scugic_0>;
 interrupts = <0 25 4>;
 reg = <0xe0004000 0x1000>;
 i2c-clk = <40>;
 #address-cells = <1>;
 #size-cells = <0>;} ;

It seems if I use #1, the i2c port does not respond to CPU1, even
though I am using "clk_ignore_unused" kernel parameter to ensure i2c
clock is not disabled.

If I use #2, i2c port responds to CPU1, but then I would need to be
vigilant that nothing on Linux is trying to use that i2c port?

I am using #2 since #1 doesn't work, but is there a more proper way to
do this so that Linux/CPU0 doesn't have access to the i2c port?

Thanks for your help.

Ed





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] Current kernel 4.4 has broken timer implementation

[Mike Looijmans]

On 10-03-16 18:48, Moritz Fischer wrote:

Hi Mike,

On Thu, Mar 10, 2016 at 3:01 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

On 10-03-16 11:17, Nathan Rossi wrote:


On Thu, Mar 10, 2016 at 7:29 PM, Mike Looijmans <mike.looijm...@topic.nl>
wrote:


After migrating to the current 4.4 kernel, I noticed that the internal
timer
no longer works correctly.

When the CPU frequency scaling sets the CPU speed to 333MHz, the "wall
clock" time also slows down to half the normal rate (e.g. a "sleep 1"
will
actually take 2 seconds).

This wasn't the case on the 4.0 kernels.



Is this only on linux-xlnx kernels? or linux-yocto and or mainline kernels
too?



It's quite easy to test on ANY kernel, just set the CPU to 333MHz,
typically:

echo 33 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

and then check how long "sleep 1" really takes.

(Most boards default to "userspace" governor, setting the governor to
"ondemand" will also reduce the speed)


This is a known issue with Zynq. Stuff also horribly breaks if you run
speedgrade 3 devices with cpufreq,
as the prescaler hack goes horribly wrong for these. The issue is that
the cadence ttc's clock depends on
the cpu clock ... which changes ...


The 'prescaler hack' is apparently still present in the 4.4 kernel code. The 
problem is that it no longer works, not even on the speedgrade 1 devices (with 
only 333 and 666 MHz setpoints).


The frequency scaling saves about 40mA CPU current so I would really like to 
keep it, even in its limited form.



I just turn off cpufreq on my Zynq targets since it breaks the timers
for non speedgrade 1 devices and
use the arm global timer instead.


I'm confused by that last remark. What do you mean by "use the arm global 
timer instead"?




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] u-boot Commit 81ec69066b270c62a6468662314728cc8b7008f9 breaks SPL

[Mike Looijmans]

On 19-01-16 10:16, Nathan Rossi wrote:

On Tue, Jan 19, 2016 at 7:05 PM, Michal Simek <michal.si...@xilinx.com> wrote:

On 19.1.2016 09:07, Mike Looijmans wrote:

On 19-01-16 08:46, Michal Simek wrote:

On 18.1.2016 13:59, Mike Looijmans wrote:

On 18-01-16 13:51, Nathan Rossi wrote:

On Mon, Jan 18, 2016 at 9:45 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:

On 18-01-16 11:59, Nathan Rossi wrote:


On Mon, Jan 18, 2016 at 8:43 PM, Mike Looijmans
<mike.looijm...@topic.nl>
wrote:


I just tried with current xilinx/master u-boot.

QSPI support is still broken.

This makes the current bootloader useless, we ALWAYS boot from QSPI.


Any news on this front? Anything we can do?



Try u-boot mainline master, it has fixes for QSPI booting. I have it
working well on the Zybo, but the fixes were not specific to that
board.



That's what I did. QSPI works, but it's broken in SPL.

So you can boot from SD and access the QSPI flash, but you cannot
boot from
QSPI flash.


Ok, so I am a little confused, is it that SPL does not boot when using
QSPI (aka SPL never starts)? or is the issue that QSPI does not work
from within SPL aka it fails to load the image(s) from the flash?


The latter. It loads the SPL code, and then bails out with "invalid boot
mode" because it cannot read the QSPI from within the SPL.


Also which board are you using out of curiosity?


topic-miami

It's not in your list, but the QSPI is connected in the same way as the
Zed.


you wouldn't happen
to be using the zedboard? I just noticed that it is missing the
u-boot,dm-pre-reloc for the qspi node in the device tree in u-boot,
which is needed (see
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynq-zybo.dts;h=fbbb8911910bcd1905f60811aa582966f16b3133;hb=HEAD


vs
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynq-zed.dts;h=5ec59e2b4c6fdcf5deec58bd4d04effa2c094704;hb=HEAD).




Ah, wait... You're talking about u-boot from denx.de. I didn't know that
the Xilinx code had already merged into that. I was looking at the
u-boot-xlnx repository.

In that case, no I haven't tried current master yet. Will do.

I might want to put some effort into mainlining our u-boot code for the
board then.


Xilinx tree is not that far from mainline.



Okay, just to get things clear:


SHOULD u-boot SPL be able to boot from QSPI with current master on the
u-boot-xlnx repo? In other words, does it work with other boards?


I mean, is there something that I missed in my code and should I fix it
myself, of is the SPL support for QSPI still broken as it was after the
aforementioned commit?



I don't think it is working. But it should work when I push upgrade to
2016.01


Note though that 2016.01 does not include the SPL_DM_ALIAS patches
which are needed for QSPI flash.

http://git.denx.de/?p=u-boot.git;a=commit;h=4f627c5a59f4f69df156c199d6238849f26fe9af
http://git.denx.de/?p=u-boot.git;a=commit;h=5c9b1d735ea782c2d0ad97496d74cb1fdd27c2d9



I'm currently attempting at using the "master" and these two are already in 
there.

However, I cannot get it to compile, I get this:

drivers/serial/serial-uclass.c:27:2: error: #error "Serial is required before 
relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"



Looking at what other boards do, adding "CONFIG_SYS_MALLOC_F_LEN=0x2000" to my 
defconfig might satisfy that, but apparently doesn't because that doesn't even 
make the error go away.


Strangely, defining it in the board's config.h does make the error go away. 
But no other board does it like that.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] u-boot Commit 81ec69066b270c62a6468662314728cc8b7008f9 breaks SPL

[Mike Looijmans]

On 19-01-16 10:30, Mike Looijmans wrote:

On 19-01-16 10:16, Nathan Rossi wrote:

On Tue, Jan 19, 2016 at 7:05 PM, Michal Simek <michal.si...@xilinx.com> wrote:

On 19.1.2016 09:07, Mike Looijmans wrote:

On 19-01-16 08:46, Michal Simek wrote:

On 18.1.2016 13:59, Mike Looijmans wrote:

On 18-01-16 13:51, Nathan Rossi wrote:

On Mon, Jan 18, 2016 at 9:45 PM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:

On 18-01-16 11:59, Nathan Rossi wrote:


On Mon, Jan 18, 2016 at 8:43 PM, Mike Looijmans
<mike.looijm...@topic.nl>
wrote:


I just tried with current xilinx/master u-boot.

QSPI support is still broken.

This makes the current bootloader useless, we ALWAYS boot from QSPI.


Any news on this front? Anything we can do?



Try u-boot mainline master, it has fixes for QSPI booting. I have it
working well on the Zybo, but the fixes were not specific to that
board.



That's what I did. QSPI works, but it's broken in SPL.

So you can boot from SD and access the QSPI flash, but you cannot
boot from
QSPI flash.


Ok, so I am a little confused, is it that SPL does not boot when using
QSPI (aka SPL never starts)? or is the issue that QSPI does not work
from within SPL aka it fails to load the image(s) from the flash?


The latter. It loads the SPL code, and then bails out with "invalid boot
mode" because it cannot read the QSPI from within the SPL.


Also which board are you using out of curiosity?


topic-miami

It's not in your list, but the QSPI is connected in the same way as the
Zed.


you wouldn't happen
to be using the zedboard? I just noticed that it is missing the
u-boot,dm-pre-reloc for the qspi node in the device tree in u-boot,
which is needed (see
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynq-zybo.dts;h=fbbb8911910bcd1905f60811aa582966f16b3133;hb=HEAD



vs
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynq-zed.dts;h=5ec59e2b4c6fdcf5deec58bd4d04effa2c094704;hb=HEAD).





Ah, wait... You're talking about u-boot from denx.de. I didn't know that
the Xilinx code had already merged into that. I was looking at the
u-boot-xlnx repository.

In that case, no I haven't tried current master yet. Will do.

I might want to put some effort into mainlining our u-boot code for the
board then.


Xilinx tree is not that far from mainline.



Okay, just to get things clear:


SHOULD u-boot SPL be able to boot from QSPI with current master on the
u-boot-xlnx repo? In other words, does it work with other boards?


I mean, is there something that I missed in my code and should I fix it
myself, of is the SPL support for QSPI still broken as it was after the
aforementioned commit?



I don't think it is working. But it should work when I push upgrade to
2016.01


Note though that 2016.01 does not include the SPL_DM_ALIAS patches
which are needed for QSPI flash.

http://git.denx.de/?p=u-boot.git;a=commit;h=4f627c5a59f4f69df156c199d6238849f26fe9af

http://git.denx.de/?p=u-boot.git;a=commit;h=5c9b1d735ea782c2d0ad97496d74cb1fdd27c2d9




I'm currently attempting at using the "master" and these two are already in
there.

However, I cannot get it to compile, I get this:

drivers/serial/serial-uclass.c:27:2: error: #error "Serial is required before
relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"


Looking at what other boards do, adding "CONFIG_SYS_MALLOC_F_LEN=0x2000" to my
defconfig might satisfy that, but apparently doesn't because that doesn't even
make the error go away.

Strangely, defining it in the board's config.h does make the error go away.
But no other board does it like that.



This did deliver a "boot.bin" and "u-boot.img" (current master u-boot). Put 
them on a card, and the SPL part seems to work (it got a LOT bigger though) 
but the second part is a no-go, all I get is:


U-Boot SPL 2016.01 (Jan 19 2016 - 11:47:48)
mmc boot
Trying to boot from MMC
reading u-boot.img
reading u-boot.img


So it looks like I got all the SPL bits in place. Something is not quite right 
for the second stage though...


The boot.bin is now >64k and because the previous versions were only 45k in 
size, I only reserved 64k for it, so I can't test it on QSPI until I've 
trimmed it down a bit.




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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] u-boot Commit 81ec69066b270c62a6468662314728cc8b7008f9 breaks SPL

[Mike Looijmans]

On 18-01-16 11:59, Nathan Rossi wrote:

On Mon, Jan 18, 2016 at 8:43 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

I just tried with current xilinx/master u-boot.

QSPI support is still broken.

This makes the current bootloader useless, we ALWAYS boot from QSPI.


Any news on this front? Anything we can do?


Try u-boot mainline master, it has fixes for QSPI booting. I have it
working well on the Zybo, but the fixes were not specific to that
board.


That's what I did. QSPI works, but it's broken in SPL.

So you can boot from SD and access the QSPI flash, but you cannot boot from 
QSPI flash.




Regards,
Nathan




On 23-11-15 11:43, Nathan Rossi wrote:


On Fri, Nov 20, 2015 at 11:53 PM, Michal Simek <michal.si...@xilinx.com>
wrote:


On 20.11.2015 14:23, Philip Balister wrote:


On 11/20/2015 04:31 AM, Michal Simek wrote:


Hi Mike,

SPL is officially unsupported flow that's why it is not tested and it
is
fixed only when developers have time to fix it.



I've been focusing my efforts on upstream u-boot for Zynq and
MicroBlaze, and Zynq SPL seems to be functional there. Note: there is
a QSPI driver available upstream but I have not tested it myself.



Any suggestions who we should talk to about getting unsupported things
supported? I realize you are doing the best you can, but it is really
annoying that really useful things like SPL do not receive the proper
attention.



Marketing.



Last I heard of 'Marketing' responsible for Linux/U-Boot it was in a
tail spin, have you got a contact that Xilinx customers can correspond
with on this area specifically? might be useful to get them looped in
on this list or at least let them know of the discussions that are
being had.

Regards,
Nathan



Thanks,
Michal

--



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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








Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH 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 mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] [PATCH 0/5] Updates to u-boot-xlnx

[Mike Looijmans]

On 17-01-16 09:59, Nathan Rossi wrote:

On Sat, Jan 16, 2016 at 4:19 AM, andrey <and...@elphel.com> wrote:

Hello Nathan,

We are now starting production of our Zynq-based product and are trying to
update a 2-year old software to the current state of Yocto. We do not use
Vivado to manage the project, for the FPGA development we use alternative
Eclipse-based integration that remotely launches specific Vivado tools. We
had to replace some of the Xilinx primitives models (such as
https://github.com/Elphel/gtxe2_gpl )  to be able to simulate the complete
project (it is now above 80% utilization) with the GPL-ed tools
(Icarus+GTKWave). In 2013 we made  a replacement for Xilinx FSBL that at
that time was violating the GNU GPL of the U-Boot. Later Xilinx had to
comply with GPL and modified the license for the generated files, but we
would still like to avoid Vivado for FSBL generation - it is extra work for
us and is inconvenient to learn new GUI, re-enter the project data just to
be able to generate boot loader.


It was you guys that got the ball rolling for the ps7_init_gpl files,
thanks for that :).

At the moment I do not think it is possible to completely avoid Vivado
for generating SPL/FSBL. Essentially the way that the upstream U-Boot
handles the FSBL equivalent parts is by relying on the
ps7_init_gpl.[ch] files that Vivado generates from a Zynq design. For
some specific boards the ps7_init files are in the U-Boot source repo,
this is what allows for generating those bootloaders without needing
Vivado.

I suppose if you changed nothing on the PS you could do the same for
your board, have static ps7_init_gpl files stored in your source
control. Although keep in mind that it is only the Zynq configuration
that is needed by Vivado to generate the ps7_init files, so it might
be possible to write a tcl script of some such to automate Vivado to
generate the ps7_init files without needing to have your actual design
in Vivado.



The question is - does the current upstream U-Boot have all what is needed
to create an alternative bootloader for Zynq (by updating our
https://github.com/Elphel/meta-ezynq ) or there are still some important
functionality (common to all boards, not specific to particular ones and/or
Vivado releases) in u-boot-xlnx that is not yet in available in the
upstream?


Apart from the ps7_init stuff, everything else is pretty much there in
U-Boot to have SPL start in local ram, call ps7_init and then load the
full U-Boot from any device (or 'falcon' boot the kernel directly).

However my understanding is that ezynq doesn't need the ps7_init files
from Vivado, and has its own configuration/setup for those values. I
imagine if there is nothing against updating the ezynq codebase to be
a replacement for the ps7_init code?, it would be a great way to go if
the Vivado route is not reasonable. I have always been curious as to
how much of the early register setup could be done by U-Boot itself as
well as additional device tree properties at different levels
(U-Boot/Kernel) via e.g. pinmuxing. Unfortunately since ps7_init files
got GPL'd that has been the easiest solution.


Pinmuxing works just fine in the 4.x kernel. I used it to do a combined 
NOR/NAND boot. U-boot loads from QSPI flash and loads the kernel from 
QSPI as well. When the kernel boots, it re-muxes the pins for the QSPI 
and activates the NAND pins, so it can load the rootfs from NAND flash. 
All you need is to fill in the devicetree, no coding required.
(In theory it should be possible to make the kernel do runtime switches 
between the two on demand. But that would require quite some coding.)


As for the ps7_init files, I tend to hand-craft them. Vivado is too 
limited (and too buggy) to get it right.


This can be taken further by having u-boot only set the barest 
necessities, that is, only pinmux devices that it might want to boot 
from, and leave the rest for the kernel to configure. That also makes 
for a much more sensible flow.


I haven't checked recently, but SPL boot was broken last year for QSPI, 
so I stuck with a slightly older version.


As for the ezynq, I tried but couldn't really get that code path to work 
properly. Which is a pity, because that just filled in the register 
table data that the ROM would directly apply, making for a quicker and 
more efficient boot than the method the ps7_init appears to use.


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