[meta-xilinx] Notes on implementing SPL booting on zynqmp (loading PMU cfg obj at runtime)

[Luca Ceresoli]

Hi,

a few months ago I developed the possibility of loading the PMU
Configuration object on ZynqMP devices from U-Boot SPL. This work is in
mainline U-Boot since v2019.10.

Previously SPL was unable to load a config object, thus the best known
way to boot ZynqMP using U-Boot SPL was to use a patch to hardcode the
config object in the PMUFW code. Since 2019.10, U-Boot SPL can do the
loading at runtime, just like FSBL.

When using this feature, the config object *in binary format* is linked
into SPL. However the Xilinx tools produce it as a C source file, so I
also implemented a script to convert it to a binary. The script is also
in mainline U-Boot (tools/zynqmp_pm_cfg_obj_convert.py).

This is all described in more detail in this blog post:
https://lucaceresoli.net/zynqmp-uboot-spl-pmufw-cfg-load/

In my plan the next step would have been adding support in meta-xilinx
and Buildroot for using the new flow. However I am now unable to
continue that work, so I have been asked suggestions on how to proceed
so that someone else can continue from where I left it.

Here's how the flow in meta-xilinx-bsp should look like in my view:

 1. some recipe (let's call it hdl.bb) fetches the pm_cfg_obj.c
file as produced by XSDK
 2. the u-boot recipe:
a. depends on hdl.bb to access pm_Cfg_obj.c and uses
   tools/zynqmp_pm_cfg_obj_convert.py to convert it to
   pm_cfg_obj.bin
b. in do_configure_append, modifies the configuration as:
   echo "CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE=\"${CFG_OBJ_BIN}\"" \
>>${B}/.config

This way U-Boot SPL will be built with an embedded config object and
will load it at runtime before jumping to U-Boot proper.

Point 1 is a bit vague, I'm not sure how it should be implemented in
meta-xilinx-bsp. I think ideally there should be a recipe collecting all
the HDL-related files for a specific project (hardware + FPGA design)
and make them available to recipes needing it. At least it's how I
implemented it in a internal project, and it solved my needs very well.
The platform-init recipe looks somewhat similar to what I have in mind:
it could evolve to contain ps?_init_gpl.c and pm_cfg_obj.c, which
describe different aspects of the same HDL design, so naturally they
could be shipped together. However I have never used that recipe nor the
u-boot-xlnx ones, so I cannot go in more detail.

I hope this helps, just ask if anything is not clear.

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

Re: [meta-xilinx] Zedboard - I'm not eble to set i2c on PS

[Luca Ceresoli]

Hi Jek,

On 27/06/19 17:18, Jek F. wrote:
> Hi, and thanks for your answer.
> 
> Using the oscilloscope I verified that the line is always low, i
> inserted the pull-ups but there is no data transfer and the error remains.
> I realized that until now I didn't know i had to insert the ps7 files
> into the project.

Definitely needed.

> So i tried to create a custom layer in which i recreated the meta-xilinx
> structure (meta-xilinx/meta-xilinx-bsp/platform-init):
> ex:
> 
> meta-mylayer/recipes-bsp/platform-init/files/zedboard-zinq7/ps7init_gpl.h
> meta-mylayer/recipes-bsp/platform-init/files/zedboard-zinq7/ps7init_gpl.c

zinq7 -> zynq7

> generated by SDK.
> 
> In the meta-mylayer/recipes-bsp/platform-init/platform-init.bbappend
> file i inserted:
> 
> COMPATIBLE_MACHINE = "$^"
> COMPATIBLE_MACHINE_zedboard-zynq7 = "zedboard-zynq7"
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> SYSROOT_DIRS += "${PLATFORM_INIT_DIR}"
> 
> SRC_URI += "file://zedboard-zynq7/ps7_init_gpl.c"
> SRC_URI += "file://zedboard-zynq7/ps7_init_gpl.h"
> 
> do_compile() {
>      :
> }
> 
> do_install_append() {
> install -d ${D}${PLATFORM_INIT_DIR}
> install –m 06444 ${THISDIR}/files/zedboard-zynq7/ps7_init_gpl.c
> ${D}${PLATFORM_INIT_DIR}/
> install –m 06444 ${THISDIR}/files/zedboard-zynq7/ps7_init_gpl.h
> ${D}${PLATFORM_INIT_DIR}/
> }

I don't know the platform-init, but I'd do the usual yocto debugging
steps: 'bitbake -e platform-init' to see if yout variables are correctly
parsed; check the logs in tmp/work/zedboard-zynq7*/platform-init/*/temp;
check if the correct files (with the correct content) have been copied
in tmp/work/zedboard-zynq7*/platform-init/*/ etc.

Also I think your bbappend file above contains too much. Most of if
should come from the .bb file, you should add almost nothing, possibly
not even SRC_URI. But as I said I don't know that recipe, other people
here will probably know better. Or you can track on your own what the
recipe does: the ps7_init files have to reach the U-Boot source code and
get built in its SPL.

> Thanks.
> 
> Il giorno mar 25 giu 2019 alle ore 12:49 Luca Ceresoli
> mailto:l...@lucaceresoli.net>> ha scritto:
> 
> Hi Jek,
> 
> On 25/06/19 11:00, Jek F. wrote:
> > Hi, i'm a beginner and an autodidact. This is my first post here.
> > I'm trying to address i2c on Zedboard PS without luck, using
> Vivado, SDK
> > and Yocto Project.
> >
> > My current situation is:
> >
> > With Vivado:
> >
> > 1) Create Project -> RTL Project
> >
> > 2) Create block design -> Add IP -> ZYNQ7 Processing System
> >
> > 3) Run Block Automation
> >
> > 4) In "MIO Configuration" i enabled i2c0 on "MIO 10 11" and i2c1
> on "MIO
> > 12 13", i clicked on "Create HDL Wrapper..." and then i generated the
> > bitstream
> >
> > 5) File -> Export -> Export Hardware -> Include bitstream ->
> Launch SDK
> >     - then i converted the bitstream .bit in .bin (fpga.bin) with an
> > external tool
> >
> > 6) In SDK i generate new board support package
> >     - File -> New -> Board Support Package -> device tree (for this i
> > downloaded a plugin to generate DTS)
> >     - Then i choose kernel 2018.3.
> >     - This generated these files: pcw.dtsi, skeleton.dtsi, system.dts,
> > system-top.dts, zynq-7000.dtsi
> >
> > With yocto:
> >
> > 1)I've cloned yocto project (poky 2.6.2 thud)
> >
> > 2)I've cloned layer meta-openembedded and meta-xilinx.
> >
> > I've modified then file bblayers.conf adding in it:
> >     /home/jksandek/poky/meta-openembedded/meta-oe \
> >     /home/jksandek/poky/meta-xilinx/meta-xilinx-bsp \
> >
> > 3) I've added the file local.conf
> >     MACHINE ??= "zedboard-zynq7"
> >     ...
> >     IMAGE_INSTALL_append = " rsync"
> >     IMAGE_INSTALL_append = " busybox"
> >     IMAGE_INSTALL_append = " openssh"
> >     IMAGE_INSTALL_append = " nano"
> >     IMAGE_INSTALL_append = " i2c-tools"
> >     ENABLE_I2C = "1"
> >     INHERIT += "rm_work"
> >
> > 4) Then i have created a new layer "meta-dts" with the following
> folder
> > tree

Re: [meta-xilinx] Zedboard - I'm not eble to set i2c on PS

[Luca Ceresoli]

Hi Jek,

On 25/06/19 11:00, Jek F. wrote:
> Hi, i'm a beginner and an autodidact. This is my first post here.
> I'm trying to address i2c on Zedboard PS without luck, using Vivado, SDK
> and Yocto Project.
> 
> My current situation is:
> 
> With Vivado:
> 
> 1) Create Project -> RTL Project
> 
> 2) Create block design -> Add IP -> ZYNQ7 Processing System
> 
> 3) Run Block Automation
> 
> 4) In "MIO Configuration" i enabled i2c0 on "MIO 10 11" and i2c1 on "MIO
> 12 13", i clicked on "Create HDL Wrapper..." and then i generated the
> bitstream
> 
> 5) File -> Export -> Export Hardware -> Include bitstream -> Launch SDK
>     - then i converted the bitstream .bit in .bin (fpga.bin) with an
> external tool
> 
> 6) In SDK i generate new board support package
>     - File -> New -> Board Support Package -> device tree (for this i
> downloaded a plugin to generate DTS)
>     - Then i choose kernel 2018.3.
>     - This generated these files: pcw.dtsi, skeleton.dtsi, system.dts,
> system-top.dts, zynq-7000.dtsi
> 
> With yocto:
> 
> 1)I've cloned yocto project (poky 2.6.2 thud)
> 
> 2)I've cloned layer meta-openembedded and meta-xilinx.
> 
> I've modified then file bblayers.conf adding in it:
>     /home/jksandek/poky/meta-openembedded/meta-oe \
>     /home/jksandek/poky/meta-xilinx/meta-xilinx-bsp \
> 
> 3) I've added the file local.conf
>     MACHINE ??= "zedboard-zynq7"
>     ...
>     IMAGE_INSTALL_append = " rsync"
>     IMAGE_INSTALL_append = " busybox"
>     IMAGE_INSTALL_append = " openssh"
>     IMAGE_INSTALL_append = " nano"
>     IMAGE_INSTALL_append = " i2c-tools"
>     ENABLE_I2C = "1"
>     INHERIT += "rm_work"
> 
> 4) Then i have created a new layer "meta-dts" with the following folder
> tree:
> 
>     meta-dts
>     ├── conf
>     │     └── layer.conf
>     ├── COPYING.MIT
>     └── recipes-kernel
>            └── linux
>                    ├── linux-xlnx
>                    │      ├── myconfig.cfg
>                    │      └── zedboard-zynq7
>                    │            ├── pcw.dtsi
>                    │            ├── skeleton.dtsi
>                    │            ├── system.dts
>                    │            ├── system-top.dts
>                    │            └── zynq-7000.dtsi
>                    └── linux-xlnx_%.bbappend
>    
>     -in "linux-xlnx_%.bbappend" i inserted:
>    
>     SRC_URI += "file://system-top.dts;subdir=git/arch/${ARCH}/boot/dts"
>     SRC_URI += "file://pcw.dtsi;subdir=git/arch/${ARCH}/boot/dts"
>     SRC_URI += "file://zynq-7000.dtsi;subdir=git/arch/${ARCH}/boot/dts"
>     SRC_URI_append += "file://myconfig.cfg"
> 
>     -in "myconfig.cfg" i inserted:
>    
>     CONFIG_I2C_XILINX=y
>     XILINX_I2C=y
>     I2C_CADENCE=y
>     CONFIG_I2C=y
> 
> 5) Then i added this layer in bblayers.conf
> 
> 6) Start bitbake with:
>     - bitbake core-image-minimal
> 
> 7) At the end of the bitbake i've added the following files in the SD
> BOOT partition
>     - boot.bin
>     - fpga.bin
>     - system-top.dtb
>     - u-boot.img
>     - uImage
>     - uEnv.txt
> 
> 8) In the rootfs partition i've added and unzipped the following file:
>     - core-image-minimal-zedboard-zynq7.tar.gz
> 
> 9) At the end i started the zedboard and once i logged in i've typed:
>     - i2cdetect -r -y 0
> 
> 
>     but this return something like:
> 
>     root@zynq:~# i2cdetect -y -r 0
>     0 1 2 3 4 5 6 7 8 9 a b c d e f
>     00: cdns-i2c e0004000.ps7-i2c: timeout waiting on completion
>     -- cdns-i2c e0004000.ps7-i2c: timeout waiting on completion

On the software side Linux knows about your controller, this looks good.
But does the hardware (including FPGA) do what you expect?

First things first: check that the i2c controller really exists in FPGA.
devmem2 is the simplest tool to do it: try to read registers at
0xe0004000 + the offsets in the i2c controller datasheet. Do you read
the values expected according to the datasheet?

"timeout waiting on completion" suggests nobody is pulling the line
high. What is connected on the MIO 10 and 11 pins? Is there a pull-up
resistor there?

Then check if the lines are actually at the intended electrical levels:
 - SCL+SDA high when idle (a multimeter is enough here)
 - change low/high when in use, at the expected frequency (possibly
   with an oscilloscope, but a logical analyzer is quite OK as well)
 - have reasonably steep rising edges when in use (with an oscilloscope)

I hope it helps,
-- 
Luca
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

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

[Luca Ceresoli]

Hi,

On 04/06/19 23:09, Jean-Francois Dagenais wrote:
> That is great news!
> 
>> On Jun 3, 2019, at 14:07, Manjukumar Harthikote Matha  
>> wrote:
>>
>> Hi All,
>>
>> We plan to release warrior by end of month. 
>> We also want to see if we can backport patches of u-boot from Luca to enable 
>> cleaner SPL flow for PMU config objects.
>> If we cannot do it by 6/30, we want to make sure we can add it after the 
>> release branch is cut.
>> Please see: 
>> https://lucaceresoli.net/zynqmp-uboot-spl-pmufw-cfg-load/
>> or
>> https://www.linkedin.com/pulse/booting-u-boot-spl-zynqmp-step-forward-luca-ceresoli/
> 
> Thanks again Luca. Hey, here's my question from the post comment, and a bonus 
> one:

And then I'll pretty much replicate the answers I gave there. :)

> * Does this mean we should switch to mainline u-boot or does xilinx/u-boot 
> closely tracks that mainline?

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.

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

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

[Luca Ceresoli]

Hi Mike,

On 04/06/19 15:08, Mike Looijmans wrote:
> 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 >>>> 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?

AFAIK there are boards (Ultra96 IIRC) that need to move some PMU-owned
GPIOs very early for proper voltage or clock, otherwise they won't boot.
But I've never used any. For those boards XSDK puts some code in the
pm_cfg_obj.c "GPO SECTION" to move those GPIOs. A "enable-all" config
won't have that code.

That said, I think zcu106 should not need that, thus perhaps this is not
your problem. But I always start from a XSDK-generate config object and
never had any issue with them.

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

Does meta-xilinx provide any pm_cfg_obj.c file?

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

If you have a Vivado project open, it's rather simple:
 - in Vivado
   - file -> export -> hardware
   - file -> launch SDK
 - in XSDK
   - file -> new -> other
   - xilinx -> BSP -> next
   - finish
   - in "BSP settings" -> supported libraries -> enable "xilpm"
   - ok

Then use 'find' to, well, find your pm_cfg_obj.c.

> Do you think
> it'd make a difference?

As said, probably not in our case, but it's a safe starting point. If
that still fails, you have a different problem.

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

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

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

[Luca Ceresoli]

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

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

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

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

[Luca Ceresoli]

Hi Jean-Francois,

On 04/06/19 04:43, Jean-Francois Dagenais wrote:
> Thanks for the comeback Luca.
> 
>> On Jun 3, 2019, at 03:47, Luca Ceresoli  wrote:
>>
>> Not really I'm afraid, but I tried building a pmufw now without
>> multiconfig and it succeeds in master, thud and the shiny new
>> rel-v2019.01 branch on xilinx's github and they all succeed.
>>
>> Which commit are you using?
> v2019.1

Do you mean the "rel-v2019.1" branch of meta-xilinx? Or the
"xilinx-v2019.1" tag of embeddedsw? Or the "release-2019.1" branch
branch of embeddedsw?

In other words, can you describe the exact steps to have a setup that
reproduces your problem? Or try from scratch by adding the needed layers
and do a build without changes? I suspect there's something
"non-standard" in your setup. Except for being non-multiconfig, my
working setup is very basic.

>> Does a non-multiconfig setup work?
> Will try this tomorrow.
> 
> In the mean time, I inspected copy_bsp.sh more carefully and it seems that 
> commit 6aa787afce5ae454ce0a072fbf93e47e3960ada1 (and 
> ae0d2a0989e3855d2044ab55dabc78ff35e38137 ??? ) removes 
> lib/sw_services/xilsecure/src/xsecure_sha2_pmu.a so I am really wondering how 
> this: 
> https://github.com/Xilinx/embeddedsw/blob/86e2a1940f997f291ea5c1628f3c8a945133f100/lib/sw_apps/zynqmp_pmufw/misc/copy_bsp.sh#L93
>  would work for anyone!
> 
> Luca, you say it works for you on 2019.1

I had tried branch rel-v2019.1 of meta-xilinx, with whatever
pmu-firmware commit it uses. I didn't look into the embeddedsw git repo.

> have you tried with a really clean workdir for pmu-firmware (bitbake 
> pmu-firmware -c cleanall)? (Just to be sure)

Done that now. It keeps on building succeessfully.

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

I just had a look. Indeed the tag and the branch have as many as 5700
files changed (!), but 99% are only whitespace and newline changes.
Finding the real differences between them is very frustrating.

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

Indeed. Good to have the source code, but its current status is confusing.

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

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

[Luca Ceresoli]

Hi Jean-Francois,

On 31/05/19 20:36, Jean-Francois Dagenais wrote:
> Hi guys,
> 
> I'm trying to switch from meta-xilinx-tools' pmu-firmware to 
> meta-xilinx-standalone.
> 
> I've setup my multiconfig as per README.building.md and am trying to build. 
> Pmu-firmware fails the copy_bsp.sh 
> 
> BSP directory already exists
> Standalone directory already exists
> csudma directory already exists
> uartps directory already exists
> ipipsu directory already exists
> ttcps directory already exists
> emacps directory already exists
> iicps directory already exists
> sdps directory already exists
> qspipsu directory already exists
> gpiops directory already exists
> usbpsu directory already exists
> wdtps directory already exists
> sysmonpsu directory already exists
> cpu directory already exists
> mv: cannot stat 
> '../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilsecure/src/xsecure_sha2_pmu.a': 
> No such file or directory
> mv: cannot stat 
> '/builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/git/lib/sw_apps/zynqmp_pmufw/src/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src/interface/zynqmp/*':
>  No such file or directory
> WARNING: 
> /builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/temp/run.do_configure.11740:1
>  exit 1 from 'mv 
> /builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/git/lib/sw_apps/zynqmp_pmufw/src/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src/interface/zynqmp/*
>  
> /builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/git/lib/sw_apps/zynqmp_pmufw/src/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src'
> ERROR: Function failed: do_configure (log file is located at 
> /builds/yocto/mymachine/pmutmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2019.1+gitAUTOINC+26c14d9861-r0/temp/log.do_configure.11740)
> 
> I vaguely remember from my relatively short time spent on the xsdk (both in 
> eclipse and through meta-xilinx-tools) that the BSP was a separate build 
> project. How would this work here? Who would build the BSP in a bitbake build.

The pmu-firmware recipe in meta-xilinx-standalone depends on very few
recipes that build a standalone toolchain: only libgcc, libgloss, newlib
and a few dozen native ones.

> standalone's pmu-firmware defines:
> BSP_DIR ?= "${S}/../misc/zynqmp_pmufw_bsp"
> BSP_TARGETS_DIR ?= "${BSP_DIR}/psu_pmu_0/libsrc"
> Is there some dependency missing? Or maybe a step for the BSP prior to 
> pmu-firmware:do_configure ? Or maybe some black magic from meta-petalinux 
> (which I currently don't use)?
> 
> I am a bit clueless here, there's definitely a gap in the 
> meta-xilinx/.../READMEs.
> 
> Any clues anyone?

Not really I'm afraid, but I tried building a pmufw now without
multiconfig and it succeeds in master, thud and the shiny new
rel-v2019.01 branch on xilinx's github and they all succeed.

Which commit are you using?
Does a non-multiconfig setup work?

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

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

[Luca Ceresoli]

Hi Jean-Francois,

On 01/05/19 21:59, Jean-Francois Dagenais wrote:
> 
> 
>> On Apr 30, 2019, at 03:14, Luca Ceresoli  wrote:
>>
>>> EXTRA_OEMAKE_zynqmp_append = "${@' ZYNQMP_CONSOLE=${ATF_CONSOLE}' if 
>>> d.getVar('ATF_CONSOLE', True) != '' else ''}"
>>> +EXTRA_OEMAKE_append_versal = "${@' VERSAL_CONSOLE=${ATF_CONSOLE}' if 
>>> d.getVar('ATF_CONSOLE', True) != '' else ''}"
>>
>> Not related to your addition, but the zynqmp line before this has
>> swapped "append" and "zynqmp" with respect to the usual syntax. It looks
>> like it works anyway, but perhaps it's worth cleaning it up in a
>> separate patch.
> 
> Yes, this current form means that "EXTRA_OEMAKE" has an override for zynqmp, 
> onto which we append stuff.
> 
> Whereas the other form:
> 
> EXTRA_OEMAKE_append_zynqmp = "..."
> 
> Means: on the standard EXTRA_OEMAKE append, in the case of of zynqmp, the 
> following stuff.
> 
> So the first form completely replaces the base EXTRA_OEMAKE whereas the 
> second form appends on the base EXTRA_OEMAKE in case of "zynqmp".
> 
> One of those many yocto "gotchas" I'v been bitten by in the past. Thought it 
> might be good to add my 2 cents here.

Thanks, that's a useful clarification.

It all sounds so obvious... now! :)

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

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

[Luca Ceresoli]

Hi Manjukumar,

a minor nit below.

On 29/04/19 20:24, Manjukumar Matha wrote:
> Add support to build ATF for versal devices
> 
> Signed-off-by: Manjukumar Matha 
> ---
>  .../arm-trusted-firmware/arm-trusted-firmware.inc  | 14 
> --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc 
> b/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> index d64fad9..1b42819 100644
> --- 
> a/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> +++ 
> b/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> @@ -25,9 +25,12 @@ SRC_URI = "${REPO};${BRANCHARG}"
>  ATF_BASE_NAME ?= "${PN}-${PKGE}-${PKGV}-${PKGR}-${DATETIME}"
>  ATF_BASE_NAME[vardepsexclude] = "DATETIME"
>  
> -COMPATIBLE_MACHINE = "zynqmp"
> -PLATFORM_zynqmp = "zynqmp"
> +COMPATIBLE_MACHINE ?= "^$"
> +COMPATIBLE_MACHINE_zynqmp = ".*"
> +COMPATIBLE_MACHINE_versal = ".*"
>  
> +PLATFORM_zynqmp = "zynqmp"
> +PLATFORM_versal = "versal"
>  
>  # requires CROSS_COMPILE set by hand as there is no configure script
>  export CROSS_COMPILE="${TARGET_PREFIX}"
> @@ -40,9 +43,13 @@ LD[unexport] = "1"
>  
>  ATF_CONSOLE ?= ""
>  ATF_CONSOLE_zynqmp = "cadence"
> +ATF_CONSOLE_versal ?= "pl011"
>  
>  DEBUG ?= ""
> +DEBUG_versal ?= "1"
> +
>  EXTRA_OEMAKE_zynqmp_append = "${@' ZYNQMP_CONSOLE=${ATF_CONSOLE}' if 
> d.getVar('ATF_CONSOLE', True) != '' else ''}"
> +EXTRA_OEMAKE_append_versal = "${@' VERSAL_CONSOLE=${ATF_CONSOLE}' if 
> d.getVar('ATF_CONSOLE', True) != '' else ''}"

Not related to your addition, but the zynqmp line before this has
swapped "append" and "zynqmp" with respect to the usual syntax. It looks
like it works anyway, but perhaps it's worth cleaning it up in a
separate patch.

> @@ -53,6 +60,9 @@ ATF_MEM_SIZE ?= ""
>  EXTRA_OEMAKE_zynqmp_append = "${@' ZYNQMP_ATF_MEM_BASE=${ATF_MEM_BASE}' if 
> d.getVar('ATF_MEM_BASE', True) != '' else ''}"
>  EXTRA_OEMAKE_zynqmp_append = "${@' ZYNQMP_ATF_MEM_SIZE=${ATF_MEM_SIZE}' if 
> d.getVar('ATF_MEM_SIZE', True) != '' else ''}"

Same comment here.

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

Re: [meta-xilinx] u-boot fpga command silently fails on zcu102 SD boot

[Luca Ceresoli]

Hi Manjukumar,

On 24/04/19 18:26, Manjukumar Harthikote Matha wrote:
> 
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Wednesday, April 24, 2019 8:53 AM
>> To: Monaghan, Michael L. (GSFC-5870) ;
>> meta-xilinx@yoctoproject.org
>> Cc: Andreas Galauner ; Manjukumar Harthikote Matha
>> ; Mounika Akula 
>> Subject: Re: [meta-xilinx] u-boot fpga command silently fails on zcu102 SD 
>> boot
>>
>> Hi Michael,
>>
>> On 24/04/19 01:51, Monaghan, Michael L. (GSFC-5870) wrote:
>>> Hello all,
>>>
>>> When booting from SD on the zcu102, the u-boot `fpga` command appears
>> silently fails to configure the PL. The done led does not illuminate and the
>> command returns 1.
>>
>> PMUFW version? 2018.3?
>>
>> Since 2018.3, the build instructions for pmu firmware are broken. The
>> copy_bsp.sh script does not copy the FPGA loading files, which results is a
>> successful build of a PMUFW *without* the FPGA loading feature.
>>
>> Andreas reported the problem and sent a patch to fix it:
>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004184.html
>>
>> The patch is in meta-xilinx master, but has not been backported to thud, so 
>> you
>> should try that.
>>
> 
> I have backported to thud 

Thanks, tested and working here.

>> Manjukumar, Mounika, this issue is still hurting people. I'd like to renew my
>> appeal to really fix 
>> it:https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-
>> January/004190.html
>>
> 
> Will follow up and keep you posted

Thanks, I appreciate that.

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

Re: [meta-xilinx] u-boot fpga command silently fails on zcu102 SD boot

[Luca Ceresoli]

Hi Michael,

On 24/04/19 01:51, Monaghan, Michael L. (GSFC-5870) wrote:
> Hello all,
> 
> When booting from SD on the zcu102, the u-boot `fpga` command appears 
> silently fails to configure the PL. The done led does not illuminate and the 
> command returns 1.

PMUFW version? 2018.3?

Since 2018.3, the build instructions for pmu firmware are broken. The
copy_bsp.sh script does not copy the FPGA loading files, which results
is a successful build of a PMUFW *without* the FPGA loading feature.

Andreas reported the problem and sent a patch to fix it:
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004184.html

The patch is in meta-xilinx master, but has not been backported to thud,
so you should try that.

Additionally, a patch has been merged in U-Boot 2019.04 to always print
an error message when FPGA loading fails, you might want that one as well:
https://git.denx.de/?p=u-boot.git;a=commit;h=8df324a20b45f3a15a166797a2d5a5d447337891

Hope it helps.


Manjukumar, Mounika, this issue is still hurting people. I'd like to
renew my appeal to really fix
it:https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004190.html

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

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

[Luca Ceresoli]

Hi,

On 17/04/19 09:14, Luca Ceresoli wrote:
> Hi Jean-Francois,
> 
> On 10/04/19 17:02, Jean-Francois Dagenais wrote:
>> Normally, when the colon ':' separator is on the right, the assignment
>> is meant to be prepended to the variable. Using the "_append" override
>> with both colon and spaces is an incoherent use of the FILESEXTRAPATH
>> variable:
>> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-FILESEXTRAPATHS
>>
>> Also removed the r8p0... path as it doesn't exist.
>>
>> Signed-off-by: Jean-Francois Dagenais 
> 
> Acked-bu: Luca Ceresoli 
> 

Oops, typo! :)

Acked-by: Luca Ceresoli 

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

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

[Luca Ceresoli]

Hi Jean-Francois,

On 10/04/19 17:02, Jean-Francois Dagenais wrote:
> Normally, when the colon ':' separator is on the right, the assignment
> is meant to be prepended to the variable. Using the "_append" override
> with both colon and spaces is an incoherent use of the FILESEXTRAPATH
> variable:
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-FILESEXTRAPATHS
> 
> Also removed the r8p0... path as it doesn't exist.
> 
> Signed-off-by: Jean-Francois Dagenais 

Acked-bu: Luca Ceresoli 

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

Re: [meta-xilinx] meta-xilinx-tools shell function parsed as python function

[Luca Ceresoli]

Hi Michael,

On 16/04/19 21:57, Monaghan, Michael L. (GSFC-5870) wrote:
> Hello all,
> 
>  
> 
> Thank you in advance for your time. I’m new to the Yocto Project and
> OpenEmbedded.
> 
>  
> 
> I am trying to add the meta-xilinx-tools layer to a working Yocto/OE
> build for the zcu102 board, but bitbake subsequently fails to parse
> meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb. Here
> are some snippets from the console.
> 
>  
> 
> WARNING:
> /yocto/projects/yocto-zcu102/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb:
> Error during finalise of
> /yocto/projects/yocto-zcu102/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
> 
> …
> 
> ERROR: Unable to parse
> /yocto/projects/yocto-zcu102/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb:20:23
> 
> Traceback (most recent call last):
> 
> …
> 
> File "/yocto/projects/yocto-zcu102/bitbake/lib/bb/codeparser.py", line
> 327, in PythonParser.parse_python(node="\n\t[ -e
> ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts\n   
> bb.build.exec_func('devicetree_do_compile', d)\n", lineno=1,
> filename='autogenerated'):
> 
>  code = compile(check_indent(str(node)), filename, "exec",
> 
>     >   ast.PyCF_ONLY_AST)
> 
>    
> 
>   File "autogenerated", line 2
> 
>     [ -e ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts
> 
>  ^
> 
> SyntaxError: invalid syntax
> 
>    
> 
>    
> 
> Summary: There were 10 WARNING messages shown.
> 
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> 
>  
> 
> I found the offending function at
> meta-xilinx-tools/recipes-bsp/device-tree/device-tree.bbappend:71
> 
>  
> 
> do_compile_prepend() {
> 
>     [ -e ${DTS_FILES_PATH}/system.dts ] &&
> rm ${DTS_FILES_PATH}/system.dts
> 
> }
> 
>  
> 
> And it appears to ultimately override this python function at
> openembedded-core/meta/classes/devicetree.bbclass:119
> 
>  
> 
> python devicetree_do_compile() {
> 
>   …
> 
> }
> 
>  
> 
> devicetree.bbappend:do_compile_prepend() is clearly a shell script, but
> the “SyntaxError: invalid syntax” message indicates that *it is being
> parsed as a python function!* It looks like this could be a problem with
> bitbake or yocto/oe but I thought I would reach out to the community
> here first. Has anyone here encountered this?

append and prepend functions must use the same language as the function
being appended/prepended. Either all python or all shell, no mixing
allowed. That's because bitbake simply concatenates the prepends, base
functions and appends and then parses the result as a whole.

For the problem you're facing a patch has been sent by Jean-Francois,
check it out:

https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004205.html

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

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

[Luca Ceresoli]

Hi,

On 14/03/19 14:20, Jean-Francois Dagenais wrote:
> Hi guys,
> 
> Thanks for your work on this...
> 
>> On Mar 13, 2019, at 14:26, Manjukumar Matha 
>>  wrote:
>>
>> From: Alejandro Enedino Hernandez Samaniego 
>>
>> libmali provides GL backends based on x11, fbdev and wayland,
>> we should be able to switch between them at runtime since it is
>> the same ABI, it should only be a matter of loading the correct
>> shared library by the interpreter (dynamic linker).
>>
>> Use the update-alternatives class, to provide a way for the user
>> to choose the desired backend at runtime, do this by setting
>> priorities, the package with the highest priority will be chosen
>> as default at build time, but it can easily be changed at runtime
>> afterwards.
>> This change implies that the libmali package will install all
> 
> Nitpicking: missing line between above paragraph separation.
> 
>> backends regardless of which one was chosen, but it will only use
>> one as default.
>>
>> Use the x11 backend by default at build time; given that it is
>> the same ABI, applications which depend on libmali, can build
>> regardless of the chosen backend at build time.
> 
> Mh. Since it doesn't make a difference at build time, perhaps using the
> "headless" backend would be the better, lowest dependency, choice.
> 
>>
>> Update-alternatives uses a set of commands on the postinst
>> scripts when creating the root filesystem, which basically create
>> the soft link between the chosen alternative and the binary/library.
>> This usually works seamlessly (for binaries), but it does not in the
>> case of libraries, because ldconfig is run at the end of the
>> do_rootfs task, and it removes the link that was just created,
>> it is important to note that this is simply normal ldconfig behavior
>> and its not something we can fix, so we defer execution of
>> update-alternatives until the first boot, hence avoiding the link
>> removal by ldconfig.
>>
>> Switching backends at build time will also help to avoid longer
>> build times, since it will only invalidate the do_package task,
>> rebuilding an image after switching a backend (at build time)
>> should only execute the do_package task along with the do_rootfs
>> task.
> 
> Hooray!
> 
>>
>> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
>> Signed-off-by: Manjukumar Matha 
>> ---
>> .../recipes-graphics/libgles/libmali-xlnx.bb   | 101 
>> ++---
>> 1 file changed, 67 insertions(+), 34 deletions(-)
>>
>> diff --git a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb 
>> b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> index 504ea6d..7191c25 100644
>> --- a/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> +++ b/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb
>> @@ -4,9 +4,9 @@ LICENSE = "Proprietary"
>> LICENSE_FLAGS = "xilinx"
>> LIC_FILES_CHKSUM = "file://README.md;md5=d5750ae6496dd931669b454b5aaae2cd"
>>
>> -inherit distro_features_check
>> +inherit distro_features_check update-alternatives
>>
>> -ANY_OF_DISTRO_FEATURES = "fbdev x11"
>> +REQUIRED_DISTRO_FEATURES = "x11 fbdev wayland"
>>
>> PROVIDES += "virtual/libgles1 virtual/libgles2 virtual/egl virtual/libgbm"
>>
>> @@ -40,22 +40,14 @@ PACKAGE_ARCH = "${SOC_FAMILY}"
>>
>> S = "${WORKDIR}/git"
>>
>> -X11RDEPENDS = "libxdamage libxext libx11 libdrm libxfixes"
>> -X11DEPENDS = "libxdamage libxext virtual/libx11 libdrm libxfixes"
>> +# If were switching at runtime, we need all RDEPENDS needed for all 
>> backends available
>> +RDEPENDS_${PN} = " kernel-module-mali libxdamage libxext libx11 libdrm 
>> libxfixes"
> 
> I believe this will install x11 libs in images even if one doesn't have "x11" 
> in
> DISTRO_FEATURES. This is my case and I would not use the recipe like this.

I completely agree with Jean-Francois. I need only one backend in my
embedded system, I don't want to build lots of unneeded packages. Having
them on the target is not even considered.

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

Re: [meta-xilinx] ZCU104 U-boot SPL bootflow / PL programming

[Luca Ceresoli]

Hi Samuel,

On 06/03/19 05:45, Samuel Berezhinskiy wrote:
> I have checked to make sure the pm_cfg_obj.c is the one generated from
> my project, as well as the psu_init_gp.c. I have booted into Linux but
> fail any read/writes into the fabric. When performing the fpga loading
> from U-boot I am passing in the .bit file using “fpga loadb 0 
> ” and I get a readout that confirms the loading of the bitstream.

I don't know whether that command does any check to say it has been
written correctly, but if it does this means your PL is powered up.

> I also added some LED output to my fabric design to see if it comes up
> after programming,

Good idea.

> and the LEDs fail to light up… Which leads me to
> question what is responsible for powering up the PL island?

I don't remember having ever written a single line of code to power it
up. I guess it's done by the psu_init code...

Try to validate your FPGA design by sending it directly from Vivado to
the board via USB. No U-Boot, no Linux, no software at all. Does the LED
light up that way?

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

Re: [meta-xilinx] ZCU104 U-boot SPL bootflow / PL programming

[Luca Ceresoli]

Hi Samuel,

On 04/03/19 21:37, Samuel Berezhinskiy wrote:
> Hi,
> 
>  
> 
> I’ve brought up the board in the sense that I can boot the SPL and make
> it into U-Boot as well as being able to come up in Linux. But I seem to
> have hit a major wall. After programming the FPGA from U-boot using the
> typical command of “fpga loadb 0  ”  I’m unable to access
> any of the AXI devices within the PL from U-boot or Linux, I seem to
> just lock up the device, as if the PL is still either powered down or
> Isolation is still enabled.

Here are a few more checks that might be helpful.

Did you rebuild your pmufw and U-Boot SPL with the pm_cfg_obj.c and
psu_init_gpl.c specific for your FPGA design?

Try disabling every PL peripheral in your device tree so Linux boots
without hanging, then use devmem2 to access a register in your PL
devices. Can you read/write registers?

Also, are you pairing the right bitstream format with the right U-Boot
command? 'fpga load' wants a .bin converted by [0] while (I think) 'fpga
loadb' wants the bitstream file produced by Vivado.

[0]
https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-bit-to-bin/fpga-bit-to-bin.py

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

Re: [meta-xilinx] [meta-xilinx-tools][RFC] device-tree.bbappend: Changes needed to use upstream devicetree class

[Luca Ceresoli]

Hi Manjukumar, Jaewon,

On 26/02/19 04:07, Manjukumar Matha wrote:
> From: Jaewon Lee 
> 
> These are some changes needed to use upstream devicetree class. There
> are some variable name changes as well as switching some script to
> python from bash.
> 
> Signed-off-by: Jaewon Lee 
> Signed-off-by: Manjukumar Matha 
> ---
>  recipes-bsp/device-tree/device-tree.bbappend | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/recipes-bsp/device-tree/device-tree.bbappend 
> b/recipes-bsp/device-tree/device-tree.bbappend
> index e077955..118688c 100644
> --- a/recipes-bsp/device-tree/device-tree.bbappend
> +++ b/recipes-bsp/device-tree/device-tree.bbappend
> @@ -44,10 +44,10 @@ YAML_DT_BOARD_FLAGS_zcu104-zynqmp ?= "{BOARD zcu104-revc}"
>  YAML_DT_BOARD_FLAGS_zcu111-zynqmp ?= "{BOARD zcu111-reva}"
>  YAML_DT_BOARD_FLAGS_zc1275-zynqmp ?= "{BOARD zc1275-revb}"
>  
> -DTS_FILES_PATH = "${XSCTH_WS}/${XSCTH_PROJ}"
> -DTS_INCLUDE_append = " ${WORKDIR}"
> +DT_FILES_PATH = "${XSCTH_WS}/${XSCTH_PROJ}"
> +DT_INCLUDE_append = " ${WORKDIR}"
>  DT_PADDING_SIZE = "0x1000"
> -KERNEL_DTS_INCLUDE_append = " ${STAGING_KERNEL_DIR}/include"
> +KERNEL_INCLUDE_append = " ${STAGING_KERNEL_DIR}/include"
>  
>  COMPATIBLE_MACHINE_zynq = ".*"
>  COMPATIBLE_MACHINE_zynqmp = ".*"
> @@ -57,21 +57,20 @@ SRC_URI_append_ultra96-zynqmp = 
> "${@bb.utils.contains('MACHINE_FEATURES', 'mipi'
>  
>  do_configure_append_ultra96-zynqmp() {
>  if [ -e ${WORKDIR}/mipi-support-ultra96.dtsi ]; then
> -   cp ${WORKDIR}/mipi-support-ultra96.dtsi 
> ${DTS_FILES_PATH}/mipi-support-ultra96.dtsi
> -   echo '/include/ "mipi-support-ultra96.dtsi"' >> 
> ${DTS_FILES_PATH}/system-top.dts
> +   cp ${WORKDIR}/mipi-support-ultra96.dtsi 
> ${DT_FILES_PATH}/mipi-support-ultra96.dtsi
> +   echo '/include/ "mipi-support-ultra96.dtsi"' >> 
> ${DT_FILES_PATH}/system-top.dts
>  fi
>  }
>  
> -
> -do_compile_prepend_kc705-microblazeel() {
> - cp ${WORKDIR}/system-conf.dtsi ${DTS_FILES_PATH}
> - cp ${WORKDIR}/kc705-microblazeel.dts ${DTS_FILES_PATH}
> -}

The log message does not explain why this change it is needed. It also
looks unrelated to the rest of the changes so it might be worth a
separate commit.

>  do_compile_prepend() {
> - [ -e ${DTS_FILES_PATH}/system.dts ] && rm ${DTS_FILES_PATH}/system.dts
> +listpath = d.getVar("DT_FILES_PATH")
> +try:
> +os.remove(os.path.join(listpath, "system.dts"))
> +except OSError:
> +pass

Oh dear, Python is usually very concise but there are clearly
exceptions. Any python expert knows a more concise way to do 'rm -f
$FILE' in python? Otherwise of course this code is OK.

>  }
>  
> +

Empty line.

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

Re: [meta-xilinx] libmali and wayland

[Luca Ceresoli]

Hi Jean-Francois,

On 20/02/19 15:01, Jean-Francois Dagenais wrote:
> 
> 
>> On Feb 20, 2019, at 06:01, Mike Looijmans > > 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. :-(

> And please, PLEASE, if Xilinx wants more help and freebies, let's use
> the issues and pull request mechanisms instead of the clunky patches! Or
> gitlab.com 's merge requests (We're gitlab here).
> Patch management is completely un-natural and discourages MANY
> developers to get involved. Basically, all these companies combing
> through Xilinx's code are a gold mine of contributions and bug fixes.
> One would think that Xilinx would make it SUPER easy for them to report
> and even fix things. No real changes can go in without Xilinx admins
> going through a full review and adjustment process anyway... so what's
> the obstacle? It's available and free (right?), if not on github then on
> gitlab.

I'm fine with patches, I'll be OK with any system that works. What's
important is that development happens in a public place.

> Anyway, I fully appreciate that Xilinx has come a long way with
> open-source and seeing all the love and care Manju, Michal, Kwon, and
> many other Xilinx employees are putting into this I am confident that
> things will continue to improve.

I totally agree. There have been many improvements, there are many more
to go, they should happen more quickly.

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

Re: [meta-xilinx] libmali and wayland

[Luca Ceresoli]

Hi Jean-Francois,

On 19/02/19 17:03, Jean-Francois Dagenais wrote:
> There is a discussion started here:
> https://github.com/Xilinx/meta-xilinx/pull/11/commits/2a00ba8b3e052732eb1c714bebc6f247aa474628#r258102571
> about the new conflicts around libwayland-egl being provided/installed by 
> both the libmali-xlnx recipe and the default wayland recipe from poky.
> 
> It would be nice to continue the discussion and the proposed patches on 
> github directly... as teams do in 2019... wink wink! :P
> 
> Is Xilinx working on this?
> 
> Another suggestion: it would help if Xilinx could push --force to say a 
> "master-next" branch so we can detect whether we should hack things on our 
> own or if Xilinx is working on some of the issues we experience between 
> releases.

Yes!!

"Release early, release often" would make working with the Xilinx code
more productive.

The current workflow is that at some discrete points in time Xilinx
pushes a big pile of patches, so I have to plan some relevant time to:
stop my regular work, rebase on the new Xilinx branches, see what broke
in my code, fix or workaround or redo it, test, repeat, and finally get
back to work a few days/weeks later.

Discussing patches in a public place would even more allow people here
to improve the code before it goes on master, as opposed to fixing it
after the facts. It has been done in the past for some patches, it
should be done on a regular basis.

My 2c,
-- 
Luca
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards

[Luca Ceresoli]

Hi Scott,

On 23/01/19 17:06, Scott Ellis wrote:
> Hi Luca,
> 
> What you describe is how I understand things.
> 
> And I do have a booting system using the patch to the pmu-firmware and a
> pm_cfg_obj.c the customer provided.
> 
> And I have also used a boot.bin produced by the xilinx tools by the
> customer with fsbl, pmu, etc... embedded. And that works fine too.
> 
> I think I get the gist of things.
> 
> What I am confused about is the usefulness of the meta-xilinx-standalone
> layer and the pmu-firmware in particular without patches.
> 
> I don't think the license on the xilinx tool generated pm_cfg_obj.c
> matters too much.
> 
> I wasn't suggesting the pm_cfg_obj.c be included in the layer since
> every board probably needs it's own version anyway.
> 
> I was just asking about the patch to pm_binding.c to load an internal
> config object. Shouldn't this be included?
> 
> I think it was you that suggested that the pmu-firmware recipe or
> another new recipe could go out and fetch the pm_cfg_obj.c file from
> somewhere else before the pmu-firmware compile step.

Yes, this kind of workflow used to work fine before
meta-xilinx-standalone was introduced. One could have a recipe in its
own user layer providing a different pm_cfg_obj.c for each MACHINE plus
a bbappend to tell pmu-firmware how to fetch that file. Now it is not
quite possible anymore. This was discussed in this mailing list, in the
end [0] Manjukumar proposed a workaround (one pmutmp per board/config)
which might help somewhat.

> That seemed like a reasonable idea to me.
> 
> The pmu-firmware recipe as is doesn't seem too useful without these two
> items.

...without those two items _or_ a runtime cfg_obj loading system.

> But again I am new to these boards, maybe there is a bare-metal use for
> the PMU firmware that does not require a config object.

I don't think you can do anything with these SoCs without configuring
the PMU.

> But the multiconfig instructions imply that the layers should just work.

I also think following a readme should lead to a booting image. But it
doesn't seem to be the case here.

> As for u-boot SPL unable to load a cfg object to the PMU, I started to
> look at implementing that. SPL does already talk to the PMU, it
> retrieves the PMU fw version for example.
> 
> But I stopped since it seems silly.
> 
> If I have the cfg object at build time, why not just build it into the
> pmu-firmware as you do with the patch and skip the runtime loading at
> every boot.

I'm not advocating for any of the two methods, but also runtime loading
has advantages, and doesn't perceivably increase boot time.

[0]
https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004182.html

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

Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards

[Luca Ceresoli]

Hi Scott,

On 23/01/19 11:12, Scott Ellis wrote:
> Hi Manju,
> 
> Thanks for answering.
> 
> I will look at the meta-xilinx-tools layer. I think I finally understand
> what is required to boot.
> 
> But I am still not clear on the meta-xilinx multiconfig...

Just to make sure we are on the same page, there are mainly two
workflows with respect to booting on ZynqMP: using the Xilinx-specific
bootloader (FSBL) and tools (meta-xilinx-tools layer), OR using U-Boot
SPL and a more standard yocto setup. A few more details in section
"Booting" here [0].

I suggest you first choose the workflow that is best for your needs.

> The meta-xilinx-bsp/README.building.md has no mention that a patch is
> required to the pmu-firmware which is confusing.
> 
> Is this just an omission?
> 
> Is the pmu-firmware recipe useful without the patch?

Short answer: only with the Xilinx workflow.

Long answer:

The pmufw needs a "configuration object" to know what it should do, and
it expects to receive it at runtime.

In the Xilinx workflow the FSBL has a file called pm_cfg_obj.c built
into itself. It is the PMUFW configuration object, and FSBL passes it to
PMUFW at runtime.

With the U-Boot SPL workflow there's no FSBL, and there are two problems:
 1) passing a cfg obj to pmufw is just not implemented in U-Boot
 2) the pm_cfg_obj.c file is generated by the Xilinx XSDK and its
license is not compatible with the GPL license of U-Boot

Clearly problem 2 prevents from fixing problem 1. :(

To work around this problem a small patch has been developed so that
pm_cfg_obj.c is linked into pmufw and loaded directly, without waiting
for it from the outside. Find the original patch on the meta-topic layer
[1] and the patch updated for pmufw 2018.x here [2].

> Excuse the dumb questions.

As you might guess from the reply, that was clearly not dumb at all! :)

Hope it helps.

[0]
https://archive.fosdem.org/2018/schedule/event/arm64_and_fpga/attachments/slides/2564/export/events/attachments/arm64_and_fpga/slides/2564/zynqmp_linux.pdf

[1]
https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware_2017.%25.bbappend

[2]
https://github.com/lucaceresoli/zynqmp-pmufw-builder/blob/master/0001-Load-XPm_ConfigObject-at-boot.patch

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

Re: [meta-xilinx] [PATCH] Fix pmu-firmware build to include backend code for ZynqMP FPGA configuration

[Luca Ceresoli]

Hi Andreas, Mounika,

[Cc-ing the main committer of lib/sw_apps/zynqmp_pmufw/misc/copy_bsp.sh]

On 05/01/19 00:01, Andreas Galauner wrote:
> Move the appropriate backend code for the ZynqMP FPGA configuration from the
> interface subdirectory of the xilfpga library into the src directory so that
> the files are picked up by the Makefile. Otherwise the FPGA configuration code
> is non-functional.
> 
> Signed-off-by: Andreas Galauner 
> ---
>  .../recipes-standalone/pmu-firmware/pmu-firmware_2018.3.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/meta-xilinx-standalone/recipes-standalone/pmu-firmware/pmu-firmware_2018.3.bb
>  
> b/meta-xilinx-standalone/recipes-standalone/pmu-firmware/pmu-firmware_2018.3.bb
> index 847e071..3432c1f 100644
> --- 
> a/meta-xilinx-standalone/recipes-standalone/pmu-firmware/pmu-firmware_2018.3.bb
> +++ 
> b/meta-xilinx-standalone/recipes-standalone/pmu-firmware/pmu-firmware_2018.3.bb
> @@ -23,6 +23,9 @@ do_configure() {
>  # manually do the copy_bsp step first, so as to be able to fix up use of
>  # mb-* commands
>  ${S}/../misc/copy_bsp.sh
> +
> +# fix xilfpga to include the zynqmp backend
> +mv 
> ${S}/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src/interface/zynqmp/* 
> ${S}/../misc/zynqmp_pmufw_bsp/psu_pmu_0/libsrc/xilfpga/src

I confirm the problem exists and your patch solves it. Thanks for sharing.

Considering this as a temporary, urgent fix:
Reviewed-by: Luca Ceresoli 
Tested-by: Luca Ceresoli 

However in the long term copy_bsp.h should be fixed to copy the files in
the proper place IMO.

It would be even better if no file were ever copied around, but just
used where it is. When copying files, the files that are actually built
are unversioned copies of the git-versioned files, so:
 * if you run copy_bsp.sh, all changes to the working files are lost!
 * git grep finds files that are not really unused
 * if the working files are edited git diff won't show the differences
 * it's confusing for both programmers and programs like ctags and grep

Mounika, do you think the file copy could be removed? Or at least fixed?

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

Re: [meta-xilinx] Reflash minized

[Luca Ceresoli]

Hi Philip,

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

I also ran into trouble with 'fs probe' deadlocking, but that's on
zynqmp platform (UltraZed EV), so maybe it's unrelated. It happens with
U-Boot version xilinx-v2018.3, but QSPI used to be working in my older
setup based on xilinx-v2017.3.

After a painful compare and trial and error I found the following two
config options are now needed for dual parallel QSPI:

  CONFIG_SPI_GENERIC=y
  CONFIG_SF_DUAL_FLASH=y

Without these options the 2017.3 version used to work, but not 2018.3.

Hope it helps,
-- 
Luca
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] PMUFW built by meta-xilinx-standalone currently doesn't allow FPGA configuration

[Luca Ceresoli]

Hi,

On 04/01/19 22:29, Andreas Galauner wrote:
> Hi all,
> 
> I just tried the current version of meta-xilinx on my Ultrazed and found
> that FPGA configuration didn't work. I tried Linux and u-boot and got
> failures all the time.
> 
> I then built a PMU firmware using the Xilinx SDK which worked to my
> surprise. After a lot of diffing which didn't yield any differences, a
> lot of swearing and wondering what's up I copied directories from the
> working XSDK project into the embeddedsw folder and when I arrived at
> the xilfpga the PMUFW started working. I diffed the code again and it
> was completely the same. The only difference was the directory structure.
> 
> It turns out that the files responsible for the actual ZynqMP FPGA
> configuration in interface/zynqmp[1] are not picked up by the Makefile
> and are never compiled. This leads to a missing backend for FPGA
> configuration. It works in the XSDK, because the project creation magic
> copies these two backend files into the src directory where they are
> picked up and are compiled properly.
> 
> The copy_bsp.sh[2] script doesn't do that. The firmware compiles fine,
> but you can't load the FPGA during runtime.
> 
> This took me a *long* time to find. I'd like to spare other people the
> experience. Enabling debug output in the PMUFW should've given me a
> proper error message, but I wasn't able to enable it for whatever
> reason. I never got debug output to work.

If I remember correctly, last time I needed it I just added '@define
PM_LOG_LEVEL 4' in lib/sw_apps/zynqmp_pmufw/src/pm_common.h and got
debug output working.

Hope it will help.

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

Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

[Luca Ceresoli]

Hi Manjukumar,

On 28/12/18 20:47, Manjukumar Harthikote Matha wrote:
> Hi Luca,
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Thursday, December 20, 2018 2:44 AM
>> To: Manjukumar Harthikote Matha ; Alejandro Enedino
>> Hernandez Samaniego ; meta-xilinx@yoctoproject.org
>> Cc: Mike Looijmans 
>> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, 
>> distro
>> and machine to build standalone components
>>
>> Hi Manjukumar, Alejandro,
>>
>> On 19/12/18 04:28, Manjukumar Harthikote Matha wrote:
>>> Hi Luca,
>>>
>>>> -Original Message-
>>>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>>>> Sent: Tuesday, December 18, 2018 7:26 AM
>>>> To: Alejandro Enedino Hernandez Samaniego ; meta-
>>>> xil...@yoctoproject.org
>>>> Cc: Mike Looijmans ; Manjukumar Harthikote Matha
>>>> 
>>>> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create 
>>>> layer,
>> distro
>>>> and machine to build standalone components
>>>>
>>>> Hi Alejandro, Manju,
>>>>
>>>> On 11/12/18 23:16, Alejandro Enedino Hernandez Samaniego wrote:
>>>>> Hey Luca,
>>>>>
>>>>>
>>>>> On 12/11/2018 07:41 AM, Luca Ceresoli wrote:
>>>>>> Hi Alejandro,
>>>>>>
>>>>>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>>>>>> This layer is meant to augment Yocto/OE functionality to provide a
>>>>>>> toolchain to build standalone components for Xilinx architectures.
>>>>>>>
>>>>>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>>>>>> 
>>>>>>> Signed-off-by: Manjukumar Matha
>>>>>>> 
>>>>>>> ---
>>>>>>>   meta-xilinx-standalone/README.md   | 56
>>>>>>> ++
>>>>>>>   .../conf/distro/xilinx-standalone.conf | 12 +
>>>>>>>   meta-xilinx-standalone/conf/layer.conf | 14 ++
>>>>>>>   .../conf/machine/zynqmp-pmu.conf   | 11 +
>>>>>>>   4 files changed, 93 insertions(+)
>>>>>>>   create mode 100644 meta-xilinx-standalone/README.md
>>>>>>>   create mode 100644
>>>>>>> meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
>>>>>>>   create mode 100644 meta-xilinx-standalone/conf/layer.conf
>>>>>>>   create mode 100644
>>>>>>> meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
>>>>>>>
>>>>>>> diff --git a/meta-xilinx-standalone/README.md
>>>>>>> b/meta-xilinx-standalone/README.md
>>>>>>> new file mode 100644
>>>>>>> index 000..da7f4e1
>>>>>>> --- /dev/null
>>>>>>> +++ b/meta-xilinx-standalone/README.md
>>>>>>> @@ -0,0 +1,56 @@
>>>>>>> +meta-xilinx-standalone
>>>>>>> +=
>>>>>> Nitpick: there should be an extra '='.
>>>>>>
>>>>>> [...]
>>>>>>> +Dependencies
>>>>>>> +
>>>>>>> +
>>>>>>> +This layer depends on:
>>>>>>> +
>>>>>>> + URI: git://git.yoctoproject.org/poky
>>>>>>> +
>>>>>>> + URI: git://git.yoctoproject.org/meta-xilinx
>>>>>> That's the repo, not the layer. Maybe clarify as:
>>>>>>
>>>>>>    URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp
>>>>>> layer
>>>>> True
>>>>>
>>>>>>
>>>>>>> +Usage
>>>>>>> +=
>>>>>>> +
>>>>>>> +1.- Clone this layer along with the specified layers
>>>>>>> +
>>>>>>> +2.- $ source oe-init-build-env
>>>>>>> +
>>>>>>> +3.- Add this layer to BBLAYERS on conf/bblayers.conf
>>>>>>> +
>>>>>>> +4.- Add the following to your conf/local.conf to build for the
>>>>>>> microblaze architecture:
>

Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

[Luca Ceresoli]

Hi Manjukumar, Alejandro,

On 19/12/18 04:28, Manjukumar Harthikote Matha wrote:
> Hi Luca,
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Tuesday, December 18, 2018 7:26 AM
>> To: Alejandro Enedino Hernandez Samaniego ; meta-
>> xil...@yoctoproject.org
>> Cc: Mike Looijmans ; Manjukumar Harthikote Matha
>> 
>> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, 
>> distro
>> and machine to build standalone components
>>
>> Hi Alejandro, Manju,
>>
>> On 11/12/18 23:16, Alejandro Enedino Hernandez Samaniego wrote:
>>> Hey Luca,
>>>
>>>
>>> On 12/11/2018 07:41 AM, Luca Ceresoli wrote:
>>>> Hi Alejandro,
>>>>
>>>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>>>> This layer is meant to augment Yocto/OE functionality to provide a
>>>>> toolchain to build standalone components for Xilinx architectures.
>>>>>
>>>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>>>> 
>>>>> Signed-off-by: Manjukumar Matha
>>>>> 
>>>>> ---
>>>>>   meta-xilinx-standalone/README.md   | 56
>>>>> ++
>>>>>   .../conf/distro/xilinx-standalone.conf | 12 +
>>>>>   meta-xilinx-standalone/conf/layer.conf | 14 ++
>>>>>   .../conf/machine/zynqmp-pmu.conf   | 11 +
>>>>>   4 files changed, 93 insertions(+)
>>>>>   create mode 100644 meta-xilinx-standalone/README.md
>>>>>   create mode 100644
>>>>> meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
>>>>>   create mode 100644 meta-xilinx-standalone/conf/layer.conf
>>>>>   create mode 100644
>>>>> meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
>>>>>
>>>>> diff --git a/meta-xilinx-standalone/README.md
>>>>> b/meta-xilinx-standalone/README.md
>>>>> new file mode 100644
>>>>> index 000..da7f4e1
>>>>> --- /dev/null
>>>>> +++ b/meta-xilinx-standalone/README.md
>>>>> @@ -0,0 +1,56 @@
>>>>> +meta-xilinx-standalone
>>>>> +=
>>>> Nitpick: there should be an extra '='.
>>>>
>>>> [...]
>>>>> +Dependencies
>>>>> +
>>>>> +
>>>>> +This layer depends on:
>>>>> +
>>>>> + URI: git://git.yoctoproject.org/poky
>>>>> +
>>>>> + URI: git://git.yoctoproject.org/meta-xilinx
>>>> That's the repo, not the layer. Maybe clarify as:
>>>>
>>>>    URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp
>>>> layer
>>> True
>>>
>>>>
>>>>> +Usage
>>>>> +=
>>>>> +
>>>>> +1.- Clone this layer along with the specified layers
>>>>> +
>>>>> +2.- $ source oe-init-build-env
>>>>> +
>>>>> +3.- Add this layer to BBLAYERS on conf/bblayers.conf
>>>>> +
>>>>> +4.- Add the following to your conf/local.conf to build for the
>>>>> microblaze architecture:
>>>>> +
>>>>> +DISTRO="xilinx-standalone"
>>>>> +
>>>>> +MACHINE="zynqmp-pmu"
>>>> To the best of my knowledge, to use U-Boot SPL people link the
>>>> pm_cfg_obj.c file in the pmufw binary and then patch the pmufw code
>>>> to load that config object instead of getting it via smc calls [0].
>>>> This makes pmufw binary machine-specfic.
>>>>
>>>> How do you think the same goal should be obtained with the new
>>>> "zynqmp-pmu" machine?
>>> Unless I'm not understanding this correctly, using MACHINEOVERRIDES
>>> should do it
>>
>> I don't think this can be done with MACHINEOVERRIDES. Let me explain better 
>> what
>> I mean.
>>
>> In my current rocko setup, there are multiple machines defined in my layer. 
>> Let's call
>> then "foo" and "bar":
>>
>>   $ ls meta-mylayer/conf/machine/
>>   foo-zynqmp.conf
>>   bar-zynqmp.conf
>>   $
>>
>> Then there is a recipe (say my-hdl.bb) that copies pm_cfg_obj.c in t

Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

[Luca Ceresoli]

Hi Alejandro, Manju,

On 11/12/18 23:16, Alejandro Enedino Hernandez Samaniego wrote:
> Hey Luca,
> 
> 
> On 12/11/2018 07:41 AM, Luca Ceresoli wrote:
>> Hi Alejandro,
>>
>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>> This layer is meant to augment Yocto/OE functionality to provide a
>>> toolchain to build standalone components for Xilinx architectures.
>>>
>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>> 
>>> Signed-off-by: Manjukumar Matha 
>>> ---
>>>   meta-xilinx-standalone/README.md   | 56
>>> ++
>>>   .../conf/distro/xilinx-standalone.conf | 12 +
>>>   meta-xilinx-standalone/conf/layer.conf | 14 ++
>>>   .../conf/machine/zynqmp-pmu.conf   | 11 +
>>>   4 files changed, 93 insertions(+)
>>>   create mode 100644 meta-xilinx-standalone/README.md
>>>   create mode 100644
>>> meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
>>>   create mode 100644 meta-xilinx-standalone/conf/layer.conf
>>>   create mode 100644 meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
>>>
>>> diff --git a/meta-xilinx-standalone/README.md
>>> b/meta-xilinx-standalone/README.md
>>> new file mode 100644
>>> index 000..da7f4e1
>>> --- /dev/null
>>> +++ b/meta-xilinx-standalone/README.md
>>> @@ -0,0 +1,56 @@
>>> +meta-xilinx-standalone
>>> +=
>> Nitpick: there should be an extra '='.
>>
>> [...]
>>> +Dependencies
>>> +
>>> +
>>> +This layer depends on:
>>> +
>>> + URI: git://git.yoctoproject.org/poky
>>> +
>>> + URI: git://git.yoctoproject.org/meta-xilinx
>> That's the repo, not the layer. Maybe clarify as:
>>
>>    URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp layer
> True
> 
>>
>>> +Usage
>>> +=
>>> +
>>> +1.- Clone this layer along with the specified layers
>>> +
>>> +2.- $ source oe-init-build-env
>>> +
>>> +3.- Add this layer to BBLAYERS on conf/bblayers.conf
>>> +
>>> +4.- Add the following to your conf/local.conf to build for the
>>> microblaze architecture:
>>> +
>>> +DISTRO="xilinx-standalone"
>>> +
>>> +MACHINE="zynqmp-pmu"
>> To the best of my knowledge, to use U-Boot SPL people link the
>> pm_cfg_obj.c file in the pmufw binary and then patch the pmufw code to
>> load that config object instead of getting it via smc calls [0]. This
>> makes pmufw binary machine-specfic.
>>
>> How do you think the same goal should be obtained with the new
>> "zynqmp-pmu" machine?
> Unless I'm not understanding this correctly, using MACHINEOVERRIDES
> should do it

I don't think this can be done with MACHINEOVERRIDES. Let me explain
better what I mean.

In my current rocko setup, there are multiple machines defined in my
layer. Let's call then "foo" and "bar":

  $ ls meta-mylayer/conf/machine/
  foo-zynqmp.conf
  bar-zynqmp.conf
  $

Then there is a recipe (say my-hdl.bb) that copies pm_cfg_obj.c in the
sysroot. The copied file is different file for each MACHINE. This recipe
has PACKAGE_ARCH = "${MACHINE_ARCH}", so different cfg objects go in
different directories.

Finally I have a pmu-firmware_%.bbappend that is similar to Mike's [0],
with the difference that it takes the pm_cfg_obj.c file from staging
where my-hdl.bb has copied it:

  do_configure[depends] = "my-hdl:do_populate_sysroot"
  do_configure_append() {
sed
's!"pm_defs.h"!"../../../sw_services/xilpm/src/common/pm_defs.h"!' \


${STAGING_DIR_TARGET}/usr/share/my-hdl/pm_cfg_obj.c \
> pm_cfg_obj.c

  }



This way a different pmufw is build for each MACHINE, each with a
hard-coded pm_cfg_obj.c specific for that machine (note that
pmu-firmware is also PACKAGE_ARCH = "${MACHINE_ARCH}").


With the new multiconfig setup, the pmu-firmware is always built for the
"zynqmp-pmu" MACHINE. And since the applied MACHINEOVERRIDES depend on
the MACHINE, in the xilinx-standalone layer you can not differentiate
foo and bar based on the MACHINE. For the same reason PACKAGE_ARCH =
"${MACHINE_ARCH}" does not help.

I did some experiments adding to pmu-firmware_2018.3.bbappend the line:

  do_configure[mcdepends] = \
"multiconfig:pmu:foo:my-hdl:do_populate_sysroot"

And now pmu:pmu-firmware depends on my-hdl, but I'm still unable to get
different pmu-firmwares built for e.g. foo and bar.

I still hope there is a solution and my understanding is just limited...


Can you suggest how to differentiate the binary pmu-firmware? Otherwise
how would you handle different boards with different pmu configs? And,
ultimately, how would you pass the pmu config to the pmufw with an
U-Boot SPL workflow?

Thanks.


[0]
https://github.com/topic-embedded-products/meta-topic/blob/706f74c9cd5fcf398ff24ee77962ebfe23340998/recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bbappend

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

Re: [meta-xilinx] Thud release update

[Luca Ceresoli]

Hi Manjukumar,

On 13/12/18 00:04, Manjukumar Harthikote Matha wrote:
> 
> 
>> -Original Message-
>> From: Manjukumar Harthikote Matha
>> Sent: Wednesday, December 12, 2018 11:42 AM
>> To: Luca Ceresoli ; meta-xilinx@yoctoproject.org
>> Subject: RE: [meta-xilinx] Thud release update
>>
>> Hi Luca,
>>
>>> -Original Message-
>>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>>> Sent: Wednesday, December 12, 2018 8:31 AM
>>> To: Manjukumar Harthikote Matha ; meta-
>>> xil...@yoctoproject.org
>>> Subject: Re: [meta-xilinx] Thud release update
>>>
>>> Hi Manjukumar,
>>>
>>> On 29/11/18 18:07, Manjukumar Harthikote Matha wrote:
>>>> Hi All,
>>>>
>>>> Thud release branch is under-testing as of now, we will start sending 
>>>> patches
>> next
>>> week and start merging to master:
>>>> Please check the tree here:
>>>> https://github.com/Xilinx/meta-xilinx/commits/master-next
>>>>
>>>> Major changes:
>>>> meta-xilinx-standalone layer to support building toolchain for MB and pmu-
>>> firmware
>>>> Proposal was sent here:
>>>> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-
>> September/004051.html
>>>>
>>>> There are two ways to build pmu-firmware: One using multiconfig and other 
>>>> as
>>> two separate distros
>>>>
>>>> 1) multiconfig way:
>>>>- You need to add the dependency in the image file, for example in core-
>>> image-minimal you will need
>>>>do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-
>>> firmware:do_deploy"
>>>>
>>>>
>>>>- Add conf/multiconfig in the build directory and create pmu.conf and
>>> zcu102.conf under conf/multiconfig
>>>>pmu.conf  consists of
>>>>MACHINE="zynqmp-pmu"
>>>>DISTRO="xilinx-standalone"
>>>>GCCVERSION="7.%"
>>>>TMPDIR="${TOPDIR}/pmutmp"
>>>>
>>>>zcu102.conf consists of
>>>>MACHINE="zcu102-zynqmp"
>>>>DISTRO="poky"
>>>>- In local.conf multiconfig is enabled by: BBMULTICONFIG ?= 
>>>> "zcu102
>>> pmu"
>>>>- bitbake multiconfig:zcu102:core-image-minimal
>>>>
>>>> This will build pmu-firmware in   build/pmutmp and all the linux images in
>> build/tmp
>>>
>>> [Disclaimer: I did not double-check everything I state below since it
>>> takes hours for each test]
>>>
>>> I tried this setup and building u-boot-xlnx fails:
>>>
>>>   $ bitbake multiconfig:zcu102:core-image-minimal
>>>   [...]
>>>   Cannot read
>>> ../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-
>> pmu.bin
>>>
>>> This can be reproduced with the attached script.
>>>
>>
>> From script it seems you are missing do_image[mcdepends] =
>> "multiconfig:zcu102:pmu:pmu-firmware:do_deploy" in your image file?
>> I think you could also add in local.conf
>>
> 
> Spoke too soon :)
> 
> You need both, we are looking into why both lines will be required.
> In Local.conf
> do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"
> In u-boot-xlnx
> do_compile[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"

I confirm adding *both* lines let me finish my first multiconfig build.

I also don't understand the need for the do_image[mcdepends] line: it
should be implied by the fact that the image depends on u-boot-xlnx,
which in turn depends on pmu-firmware:do_deploy.

Since I have no zcu102 to runtime test, I tried building for zcu106. It
doesn't build as is, do you have plans to support it?

To let it build I had to change (copying from zcu102):


--- a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
+++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
@@ -24,7 +24,6 @@ PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-xlnx"
 EXTRA_IMAGEDEPENDS += " \
u-boot-zynq-uenv \
arm-trusted-firmware \
-   virtual/pmu-firmware \
virtual/boot-bin \
virtual/bootloader \
"
@@ -35,3 +34,10 @@ IMAGE_BOOT_FILES += " \
"

 MACHINE_HWCODECS = "libomxil-xlnx"
+
+# PMU instance args
+PMU_FIRMWARE_DEPLOY_DIR ?= "${TOPDIR}/pmutmp/deploy/images/zynqmp-pmu"
+PMU_FIRMWARE_IMAGE_NAME ?= "pmu-firmware-zynqmp-pmu"
+
+do_write_qemuboot_conf[depends] += "u-boot-zynq-uenv:do_deploy"


Note that the PMU_* variables should probably be shared among all zynqmp
boards.

And of course I had to add:


--- a/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2018.3.bb
+++ b/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2018.3.bb
@@ -30,3 +30,4 @@ HAS_PLATFORM_INIT ?= " \
"

 do_compile[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"
+do_compile[mcdepends] = "multiconfig:zcu106:pmu:pmu-firmware:do_deploy"


This is clearly not nicely scaling to many boards, but at least I got a
core-image-minimal built for zcu106.

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

Re: [meta-xilinx] Thud release update

[Luca Ceresoli]

Hi Manjukumar,

On 29/11/18 18:07, Manjukumar Harthikote Matha wrote:
> Hi All,
> 
> Thud release branch is under-testing as of now, we will start sending patches 
> next week and start merging to master:
> Please check the tree here: 
> https://github.com/Xilinx/meta-xilinx/commits/master-next
> 
> Major changes:
> meta-xilinx-standalone layer to support building toolchain for MB and 
> pmu-firmware
> Proposal was sent here: 
> https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-September/004051.html
> 
> There are two ways to build pmu-firmware: One using multiconfig and other as 
> two separate distros
> 
> 1) multiconfig way:
>   - You need to add the dependency in the image file, for example in 
> core-image-minimal you will need
>   do_image[mcdepends] = "multiconfig:zcu102:pmu:pmu-firmware:do_deploy"
> 
> 
>   - Add conf/multiconfig in the build directory and create pmu.conf and 
> zcu102.conf under conf/multiconfig
>pmu.conf  consists of 
>   MACHINE="zynqmp-pmu"
>   DISTRO="xilinx-standalone"
>   GCCVERSION="7.%"
>   TMPDIR="${TOPDIR}/pmutmp"
> 
>   zcu102.conf consists of
>   MACHINE="zcu102-zynqmp"
>   DISTRO="poky"   
>- In local.conf multiconfig is enabled by: BBMULTICONFIG ?= 
> "zcu102 pmu"
>   - bitbake multiconfig:zcu102:core-image-minimal
> 
> This will build pmu-firmware in   build/pmutmp and all the linux images in 
> build/tmp

[Disclaimer: I did not double-check everything I state below since it
takes hours for each test]

I tried this setup and building u-boot-xlnx fails:

  $ bitbake multiconfig:zcu102:core-image-minimal
  [...]
  Cannot read
../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-pmu.bin

This can be reproduced with the attached script.

However the above command succeeds if 'bitbake -c deploy
multiconfig:pmu:pmu-firmware' is run before that.

I fixed this issue by adding the following line to
meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2018.3.bb:

  do_compile[mcdepends] = \
"multiconfig:zcu102:pmu:pmu-firmware:do_deploy"

Now 'bitbake multiconfig:zcu102:u-boot-xlnx' succeeds without manually
building pmu-firmware before it.

Then retrying 'bitbake multiconfig:zcu102:core-image-minimal' I get
immediately:

---8<---

ERROR: An uncaught exception occurred in runqueue
Traceback (most recent call last):
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 1479, in RunQueue.execute_runqueue():
 try:
>return self._execute_runqueue()
 except bb.runqueue.TaskFailure:
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 1399, in RunQueue._execute_runqueue():
 [43,
967, 4, 3, 1, 5, 3, 7, 13, 1, 2, 1, 1, 246, 35, 1, 38, 1, 35, 2, 338,
204, 142, 3, 3, 37, 244])
>if self.rqdata.prepare() == 0:
 self.state = runQueueComplete
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 636, in RunQueueData.prepare():
 if 'mcdepends' in task_deps and taskname in
task_deps['mcdepends']:
>add_mc_dependencies(mc, tid)

  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 614, in add_mc_dependencies(mc='zcu102',
tid='multiconfig:zcu102:/home/ceresoli/temp/test-mc-xilinx-2/poky/build/../meta-xilinx/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx_2018.3.bb:do_compile'):
 if mc == frommc:
>fn = taskData[mcdep].build_targets[pn][0]
 newdep = '%s:%s' % (fn,deptask)
KeyError: 'pmu-firmware'

ERROR: Running idle function
Traceback (most recent call last):
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/cooker.py",
line 1415, in buildTargetsIdle(server=, rq=, abort=False):
 try:
>retval = rq.execute_runqueue()
 except runqueue.TaskFailure as exc:
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 1479, in RunQueue.execute_runqueue():
 try:
>return self._execute_runqueue()
 except bb.runqueue.TaskFailure:
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 1399, in RunQueue._execute_runqueue():
 [43,
967, 4, 3, 1, 5, 3, 7, 13, 1, 2, 1, 1, 246, 35, 1, 38, 1, 35, 2, 338,
204, 142, 3, 3, 37, 244])
>if self.rqdata.prepare() == 0:
 self.state = runQueueComplete
  File
"/home/ceresoli/temp/test-mc-xilinx-2/poky/bitbake/lib/bb/runqueue.py",
line 636, in RunQueueData.prepare():
 if 'mcdepends' in task_deps and taskname in
task_deps['mcdepends']:
>add_mc_dependencies(mc, tid)

  File
"/hom

Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe

[Luca Ceresoli]

Hi Alejandro, Manjukumar,

On 11/12/18 23:06, Alejandro Enedino Hernandez Samaniego wrote:
> Hey Luca,
> 
> 
> On 12/11/2018 08:33 AM, Luca Ceresoli wrote:
>> Hi Manjukumar,
>>
>> On 11/12/18 17:21, Manjukumar Harthikote Matha wrote:
>>> Hi Luca,
>>>
>>>> -Original Message-
>>>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>>>> Sent: Tuesday, December 11, 2018 8:15 AM
>>>> To: Manjukumar Harthikote Matha ; Alejandro
>>>> Enedino
>>>> Hernandez Samaniego ; meta-xilinx@yoctoproject.org
>>>> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port
>>>> pmu-firmware recipe
>>>>
>>>> Hi Manjukumar,
>>>>
>>>> On 11/12/18 17:07, Manjukumar Harthikote Matha wrote:
>>>>> Hi Luca,
>>>>>
>>>>>> -Original Message-
>>>>>> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>>>>>> boun...@yoctoproject.org] On Behalf Of Luca Ceresoli
>>>>>> Sent: Tuesday, December 11, 2018 7:45 AM
>>>>>> To: Alejandro Enedino Hernandez Samaniego ;
>>>>>> meta- xil...@yoctoproject.org
>>>>>> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port
>>>>>> pmu-firmware recipe
>>>>>>
>>>>>> Hi Alejandro,
>>>>>>
>>>>>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>>>>>> This patch ports the pmu-firmware recipe from meta-xilinx-bsp to be
>>>>>>> used with the standalone/baremetal toolchain and also upgrades it to
>>>>>>> the latest release at this point.
>>>>>>>
>>>>>>> The recipe was trimmed down, and a few changes had to be made to
>>>>>>> make it compatible with the baremetal layer, DEPENDS, pass include
>>>>>>> dir, license and such.
>>>>>>>
>>>>>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>>>>>> 
>>>>>>> Signed-off-by: Manjukumar Matha
>>>>>>> 
>>>>>> I tried to test your entire patch series but with bad luck. Well,
>>>>>> indeed I tested the patches from the github meta-xilinx repo up to
>>>>>> [0], not sure whether the repo is more up to date than the patches
>>>>>> here.
>>>>>>
>>>>>> The first issue is that xilinx-standalone is compatible with thud,
>>>>>> but on the mentioned commit (as well as on master) the
>>>>>> mete-xilinx-bsp layer is compatible with sumo only. I solved by
>>>>>> cherry-picking [1].
>>>>>>
>>>>>> Then I followed the instructions in README.md and 'bitbake newlib'
>>>>>> ran
>>>> successfully.
>>>>>> But 'bitbake pmu-firmware' gives:
>>>>>>
>>>>>> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift
>>>>>> -mxl-pattern-compare  - mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul
>>>>>> -mxl-soft-div --
>>>>>> sysroot=/home/ceresoli/temp/prova-thud-
>>>>>> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
>>>>>> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot
>>>>>> -o executable.elf  pm_master.o  pm_api.o  xpfw_error_manager.o
>>>>>> xpfw_restart.o pm_config.o  xpfw_mod_legacy.o  pm_requirement.o
>>>>>> pm_node_reset.o  pm_core.o pm_system.o  pm_common.o  xpfw_xpu.o
>>>>>> pm_gic_proxy.o  xpfw_aib.o xpfw_events.o  pm_binding.o
>>>>>> pm_mmio_access.o  xpfw_scheduler.o  pm_slave.o xpfw_mod_pm.o
>>>>>> pm_ddr.o pm_qspi.o  pm_sram.o  xpfw_mod_sched.o xpfw_mod_rtc.o
>>>>>> pm_usb.o pm_extern.o  xpfw_user_startup.o xpfw_rom_interface.o
>>>>>> xpfw_mod_wdt.o pm_proc.o  pm_reset.o  pm_callbacks.o xpfw_mod_stl.o
>>>>>> idle_hooks.o xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o
>>>>>> xpfw_mod_dap.o xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o
>>>>>> xpfw_module.o pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o
>>>>>> pm_gpp.o pm_power.o xpfw_mod_em.o  pm_pll.o  pm_clock.o
>>>>>> pm_notifier.o  xpfw_start.o  - MMD -MP -Wl,--build-id=none
>>>>>> -I/home/ceresoli/temp/prova-thud-
>>>>>>

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

[Luca Ceresoli]

Hi Alejandro,

On 11/12/18 23:00, Alejandro Enedino Hernandez Samaniego wrote:
> Hey Luca,
> 
> 
> On 12/11/2018 07:42 AM, Luca Ceresoli wrote:
>> Hi Alejandro,
>>
>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>> 
>>> Signed-off-by: Manjukumar Matha 
>>> ---
>>>   .../recipes-standalone/gcc/gcc-cross_%.bbappend | 17
>>> +
>>>   1 file changed, 17 insertions(+)
>>>   create mode 100644
>>> meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
>>>
>>> diff --git
>>> a/meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
>>> b/meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
>>> new file mode 100644
>>> index 000..13ae02a
>>> --- /dev/null
>>> +++ b/meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
>>> @@ -0,0 +1,17 @@
>>> +# By using tclibc-baremetal we loose sysroot functionality due to
>>> some append/override behavior
>>> +# We need to get that back , the following append overrides
>>> everything on EXTRA_OECONF for gcc cross target
>>> +# it avoids overlapping with crt0 because of --enable-linker-id from
>>> EXTRA_OECONF
> 
> Since we are cross compiling using Yocto, and it was designed to build a
> Linux OS, some assumptions are made by default, with the addition of
> TCLIBC=newlib (or baremetal in any case), we get rid of those
> assumptions, and in the process we get rid of the default configuration
> parameters, the problem is that we only want to get rid of a few, so
> basically we want to get the ones that we want back from the defaults.

Thanks, it's much clearer now. You might add part of this explanation as
a comment in that file to help future readers.

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

Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe

[Luca Ceresoli]

Hi Manjukumar,

On 11/12/18 17:21, Manjukumar Harthikote Matha wrote:
> Hi Luca,
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Tuesday, December 11, 2018 8:15 AM
>> To: Manjukumar Harthikote Matha ; Alejandro Enedino
>> Hernandez Samaniego ; meta-xilinx@yoctoproject.org
>> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe
>>
>> Hi Manjukumar,
>>
>> On 11/12/18 17:07, Manjukumar Harthikote Matha wrote:
>>> Hi Luca,
>>>
>>>> -Original Message-
>>>> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>>>> boun...@yoctoproject.org] On Behalf Of Luca Ceresoli
>>>> Sent: Tuesday, December 11, 2018 7:45 AM
>>>> To: Alejandro Enedino Hernandez Samaniego ;
>>>> meta- xil...@yoctoproject.org
>>>> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port
>>>> pmu-firmware recipe
>>>>
>>>> Hi Alejandro,
>>>>
>>>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>>>> This patch ports the pmu-firmware recipe from meta-xilinx-bsp to be
>>>>> used with the standalone/baremetal toolchain and also upgrades it to
>>>>> the latest release at this point.
>>>>>
>>>>> The recipe was trimmed down, and a few changes had to be made to
>>>>> make it compatible with the baremetal layer, DEPENDS, pass include
>>>>> dir, license and such.
>>>>>
>>>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>>>> 
>>>>> Signed-off-by: Manjukumar Matha
>>>>> 
>>>>
>>>> I tried to test your entire patch series but with bad luck. Well,
>>>> indeed I tested the patches from the github meta-xilinx repo up to
>>>> [0], not sure whether the repo is more up to date than the patches here.
>>>>
>>>> The first issue is that xilinx-standalone is compatible with thud,
>>>> but on the mentioned commit (as well as on master) the
>>>> mete-xilinx-bsp layer is compatible with sumo only. I solved by 
>>>> cherry-picking [1].
>>>>
>>>> Then I followed the instructions in README.md and 'bitbake newlib' ran
>> successfully.
>>>> But 'bitbake pmu-firmware' gives:
>>>>
>>>> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift
>>>> -mxl-pattern-compare  - mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul
>>>> -mxl-soft-div --
>>>> sysroot=/home/ceresoli/temp/prova-thud-
>>>> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
>>>> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot
>>>> -o executable.elf  pm_master.o  pm_api.o  xpfw_error_manager.o
>>>> xpfw_restart.o pm_config.o  xpfw_mod_legacy.o  pm_requirement.o
>>>> pm_node_reset.o  pm_core.o pm_system.o  pm_common.o  xpfw_xpu.o
>>>> pm_gic_proxy.o  xpfw_aib.o xpfw_events.o  pm_binding.o
>>>> pm_mmio_access.o  xpfw_scheduler.o  pm_slave.o xpfw_mod_pm.o
>>>> pm_ddr.o pm_qspi.o  pm_sram.o  xpfw_mod_sched.o xpfw_mod_rtc.o
>>>> pm_usb.o pm_extern.o  xpfw_user_startup.o xpfw_rom_interface.o
>>>> xpfw_mod_wdt.o pm_proc.o  pm_reset.o  pm_callbacks.o xpfw_mod_stl.o
>>>> idle_hooks.o xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o
>>>> xpfw_mod_dap.o xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o
>>>> xpfw_module.o pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o
>>>> pm_gpp.o pm_power.o xpfw_mod_em.o  pm_pll.o  pm_clock.o
>>>> pm_notifier.o  xpfw_start.o  - MMD -MP -Wl,--build-id=none
>>>> -I/home/ceresoli/temp/prova-thud-
>>>> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
>>>> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot/usr/include
>>>> -Os -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
>>>> -Wl,--start-group,-lxilfpga,-lxilsecure,-lxil,-lgcc,-lc,--end-group
>>>> -nostartfiles -Wl,--gc-sections
>>>> -L../misc/zynqmp_pmufw_bsp/psu_pmu_0/lib
>>>> -Tlscript.ld
>>>> lto1: fatal error: multiple prevailing defs for 'XUsbPsu_DisableIntr'
>>>> compilation terminated.
>>>> lto-wrapper: fatal error: microblazeel-xilinx-elf-gcc returned 1 exit
>>>> status compilation terminated.
>>>> /home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazee
>>>> l-v9.2

Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe

[Luca Ceresoli]

Hi Manjukumar,

On 11/12/18 17:07, Manjukumar Harthikote Matha wrote:
> Hi Luca,
> 
>> -Original Message-
>> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>> boun...@yoctoproject.org] On Behalf Of Luca Ceresoli
>> Sent: Tuesday, December 11, 2018 7:45 AM
>> To: Alejandro Enedino Hernandez Samaniego ; meta-
>> xil...@yoctoproject.org
>> Subject: Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe
>>
>> Hi Alejandro,
>>
>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
>>> This patch ports the pmu-firmware recipe from meta-xilinx-bsp to be
>>> used with the standalone/baremetal toolchain and also upgrades it to
>>> the latest release at this point.
>>>
>>> The recipe was trimmed down, and a few changes had to be made to make
>>> it compatible with the baremetal layer, DEPENDS, pass include dir,
>>> license and such.
>>>
>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego
>>> 
>>> Signed-off-by: Manjukumar Matha
>>> 
>>
>> I tried to test your entire patch series but with bad luck. Well, indeed I 
>> tested the
>> patches from the github meta-xilinx repo up to [0], not sure whether the 
>> repo is
>> more up to date than the patches here.
>>
>> The first issue is that xilinx-standalone is compatible with thud, but on 
>> the mentioned
>> commit (as well as on master) the mete-xilinx-bsp layer is compatible with 
>> sumo
>> only. I solved by cherry-picking [1].
>>
>> Then I followed the instructions in README.md and 'bitbake newlib' ran 
>> successfully.
>> But 'bitbake pmu-firmware' gives:
>>
>> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift 
>> -mxl-pattern-compare  -
>> mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul -mxl-soft-div --
>> sysroot=/home/ceresoli/temp/prova-thud-
>> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
>> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot
>> -o executable.elf  pm_master.o  pm_api.o  xpfw_error_manager.o xpfw_restart.o
>> pm_config.o  xpfw_mod_legacy.o  pm_requirement.o pm_node_reset.o  pm_core.o
>> pm_system.o  pm_common.o  xpfw_xpu.o pm_gic_proxy.o  xpfw_aib.o
>> xpfw_events.o  pm_binding.o pm_mmio_access.o  xpfw_scheduler.o  pm_slave.o
>> xpfw_mod_pm.o  pm_ddr.o pm_qspi.o  pm_sram.o  xpfw_mod_sched.o
>> xpfw_mod_rtc.o  pm_usb.o pm_extern.o  xpfw_user_startup.o
>> xpfw_rom_interface.o  xpfw_mod_wdt.o pm_proc.o  pm_reset.o  pm_callbacks.o
>> xpfw_mod_stl.o  idle_hooks.o xpfw_crc.o  xpfw_ipi_manager.o  
>> xpfw_interrupts.o
>> xpfw_mod_dap.o xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o
>> xpfw_module.o pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o  pm_gpp.o
>> pm_power.o xpfw_mod_em.o  pm_pll.o  pm_clock.o  pm_notifier.o  xpfw_start.o  
>> -
>> MMD -MP -Wl,--build-id=none -I/home/ceresoli/temp/prova-thud-
>> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
>> firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot/usr/include
>> -Os -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
>> -Wl,--start-group,-lxilfpga,-lxilsecure,-lxil,-lgcc,-lc,--end-group
>> -nostartfiles -Wl,--gc-sections -L../misc/zynqmp_pmufw_bsp/psu_pmu_0/lib
>> -Tlscript.ld
>> lto1: fatal error: multiple prevailing defs for 'XUsbPsu_DisableIntr'
>> compilation terminated.
>> lto-wrapper: fatal error: microblazeel-xilinx-elf-gcc returned 1 exit status
>> compilation terminated.
>> /home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-
>> cmp-xilinx-elf/pmu-firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot-
>> native/usr/bin/microblazeel-xilinx-elf/../../libexec/microblazeel-xilinx-
>> elf/gcc/microblazeel-xilinx-elf/8.2.0/ld:
>> error: lto-wrapper failed
>> collect2: error: ld returned 1 exit status
>> Makefile:28: recipe for target 'executable.elf' failed
>> make: *** [executable.elf] Error 1
>>
>> I then tried with current master-next [2] and got:
>>
>> microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift 
>> -mxl-pattern-compare  -
>> mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul -mxl-soft-div --
>> sysroot=/home/ceresoli/temp/prova-thud-
>> xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-
>> firmware/v2018.3+gitAUTOINC+56f3da2afb-r0/recipe-sysroot
>> -o executable.elf  pm_master.o  xpfw_error_manager.o  xpfw_restart.o
>> pm_notifier.o  xpfw_mod_legacy.o  pm_requirement.o  pm_node_reset.o
>> pm_core.o  pm

Re: [meta-xilinx] [PATCH 7/9] pmu-firmware: Port pmu-firmware recipe

[Luca Ceresoli]

Hi Alejandro,

On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> This patch ports the pmu-firmware recipe from meta-xilinx-bsp to be used
> with the standalone/baremetal toolchain and also upgrades it to the
> latest release at this point.
> 
> The recipe was trimmed down, and a few changes had to be made to make it
> compatible with the baremetal layer, DEPENDS, pass include dir, license
> and such.
> 
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> Signed-off-by: Manjukumar Matha 

I tried to test your entire patch series but with bad luck. Well, indeed
I tested the patches from the github meta-xilinx repo up to [0], not
sure whether the repo is more up to date than the patches here.

The first issue is that xilinx-standalone is compatible with thud, but
on the mentioned commit (as well as on master) the mete-xilinx-bsp layer
is compatible with sumo only. I solved by cherry-picking [1].

Then I followed the instructions in README.md and 'bitbake newlib' ran
successfully. But 'bitbake pmu-firmware' gives:

microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift
-mxl-pattern-compare  -mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul
-mxl-soft-div
--sysroot=/home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot
-o executable.elf  pm_master.o  pm_api.o  xpfw_error_manager.o
xpfw_restart.o  pm_config.o  xpfw_mod_legacy.o  pm_requirement.o
pm_node_reset.o  pm_core.o  pm_system.o  pm_common.o  xpfw_xpu.o
pm_gic_proxy.o  xpfw_aib.o  xpfw_events.o  pm_binding.o
pm_mmio_access.o  xpfw_scheduler.o  pm_slave.o  xpfw_mod_pm.o  pm_ddr.o
pm_qspi.o  pm_sram.o  xpfw_mod_sched.o  xpfw_mod_rtc.o  pm_usb.o
pm_extern.o  xpfw_user_startup.o  xpfw_rom_interface.o  xpfw_mod_wdt.o
pm_proc.o  pm_reset.o  pm_callbacks.o  xpfw_mod_stl.o  idle_hooks.o
xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o  xpfw_mod_dap.o
xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o  xpfw_module.o
pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o  pm_gpp.o  pm_power.o
xpfw_mod_em.o  pm_pll.o  pm_clock.o  pm_notifier.o  xpfw_start.o  -MMD
-MP -Wl,--build-id=none
-I/home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot/usr/include
-Os -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
-Wl,--start-group,-lxilfpga,-lxilsecure,-lxil,-lgcc,-lc,--end-group
-nostartfiles -Wl,--gc-sections -L../misc/zynqmp_pmufw_bsp/psu_pmu_0/lib
-Tlscript.ld
lto1: fatal error: multiple prevailing defs for 'XUsbPsu_DisableIntr'
compilation terminated.
lto-wrapper: fatal error: microblazeel-xilinx-elf-gcc returned 1 exit status
compilation terminated.
/home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2018.2+gitAUTOINC+0c6cd096c8-r0/recipe-sysroot-native/usr/bin/microblazeel-xilinx-elf/../../libexec/microblazeel-xilinx-elf/gcc/microblazeel-xilinx-elf/8.2.0/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:28: recipe for target 'executable.elf' failed
make: *** [executable.elf] Error 1

I then tried with current master-next [2] and got:

microblazeel-xilinx-elf-gcc  -mlittle-endian -mxl-barrel-shift
-mxl-pattern-compare  -mno-xl-reorder -mcpu=v9.2 -mxl-soft-mul
-mxl-soft-div
--sysroot=/home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2018.3+gitAUTOINC+56f3da2afb-r0/recipe-sysroot
-o executable.elf  pm_master.o  xpfw_error_manager.o  xpfw_restart.o
pm_notifier.o  xpfw_mod_legacy.o  pm_requirement.o  pm_node_reset.o
pm_core.o  pm_system.o  pm_config.o  xpfw_xpu.o  pm_gic_proxy.o
xpfw_aib.o  xpfw_events.o  pm_binding.o  pm_mmio_access.o
xpfw_scheduler.o  pm_slave.o  pm_pinctrl.o  xpfw_mod_pm.o  pm_ddr.o
pm_qspi.o  pm_sram.o  xpfw_mod_sched.o  xpfw_mod_rtc.o  pm_usb.o
pm_extern.o  xpfw_user_startup.o  xpfw_rom_interface.o  xpfw_mod_wdt.o
pm_proc.o  pm_reset.o  pm_callbacks.o  xpfw_mod_stl.o  idle_hooks.o
xpfw_crc.o  xpfw_ipi_manager.o  xpfw_interrupts.o  xpfw_mod_dap.o
xpfw_platform.o  pm_node.o  xpfw_core.o  xpfw_resets.o  xpfw_module.o
pm_periph.o  xpfw_util.o  xpfw_main.o  pm_hooks.o  pm_gpp.o  pm_power.o
xpfw_mod_em.o  pm_pll.o  pm_clock.o  xpfw_start.o  -MMD -MP
-Wl,--build-id=none
-I/home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2018.3+gitAUTOINC+56f3da2afb-r0/recipe-sysroot/usr/include
-Os -Wl,--start-group,-lxil,-lgcc,-lc,--end-group
-Wl,--start-group,-lxilfpga,-lxilsecure,-lxilskey,-lxil,-lgcc,-lc,--end-group
-nostartfiles -Wl,--gc-sections -L../misc/zynqmp_pmufw_bsp/psu_pmu_0/lib
-Tlscript.ld
/home/ceresoli/temp/prova-thud-xilinx/poky/build/tmp/work/microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/v2018.3+gitAUTOINC+56f3da2afb-r0/recipe-sysroot-native/usr/bin/microblazeel-xilinx-elf/../../lib/microblazeel-xilinx-elf/gcc/../../../libexec/microblazee

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

[Luca Ceresoli]

Hi Alejandro,

On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> The zynqmp-pmu class was being used to build standalone components (PMU)
> for several devices, with the introduction of the meta-xilinx-standalone
> layer and the xilinx-standalone distro, this is not necessary anymore.
> 
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> Signed-off-by: Manjukumar Matha 

I appreciate the effort in building pmu-firmware without hacks! (even
though the alternative does not seem to come at a cheap cost)

Reviewed-by: Luca Ceresoli 

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

Re: [meta-xilinx] [PATCH 5/9] libgloss: Copy libgloss as libxil to avoid linking issues

[Luca Ceresoli]

Hi Alejandro,

On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> Upstream gcc expects to have libxil available when linking, we can get
> the required symbols (weak) from libgloss.
> 
> We copy libgloss as libxil to comply with upstream behavior and avoid
> linking errors.

I suggest moving or copying this explanation...

> diff --git 
> a/meta-xilinx-standalone/recipes-standalone/newlib/libgloss_3.0.0.bbappend 
> b/meta-xilinx-standalone/recipes-standalone/newlib/libgloss_3.0.0.bbappend
> new file mode 100644
> index 000..c2af4f9
> --- /dev/null
> +++ b/meta-xilinx-standalone/recipes-standalone/newlib/libgloss_3.0.0.bbappend
> @@ -0,0 +1,4 @@
> +# We use libgloss as if it was libxil, to avoid linking issues

...here, so it is visible close to the code without need to dig in the
git archives.

> +do_install_append_zynqmp-pmu(){
> +  cp ${D}/${libdir}/libgloss.a ${D}/${libdir}/libxil.a

A symlink should be enough here.

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

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

[Luca Ceresoli]

Hi Alejandro,

On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> Signed-off-by: Manjukumar Matha 
> ---
>  .../recipes-standalone/gcc/gcc-cross_%.bbappend | 17 
> +
>  1 file changed, 17 insertions(+)
>  create mode 100644 
> meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
> 
> diff --git 
> a/meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend 
> b/meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
> new file mode 100644
> index 000..13ae02a
> --- /dev/null
> +++ b/meta-xilinx-standalone/recipes-standalone/gcc/gcc-cross_%.bbappend
> @@ -0,0 +1,17 @@
> +# By using tclibc-baremetal we loose sysroot functionality due to some 
> append/override behavior
> +# We need to get that back , the following append overrides everything on 
> EXTRA_OECONF for gcc cross target 
> +# it avoids overlapping with crt0 because of --enable-linker-id from 
> EXTRA_OECONF

I'm afraid I did not understand the problem, perhaps because I'm no
toolchain expert. Do you think there's a way to briefly clarify to
non-experts what issue is being fixed? It would be nice to have.

And, joining Jean-François in the nitpickers club... :)
Not sure what's the coding style convention in the Yocto world, but I'd
rather wrap lines at 80 chars and remove space-before-comma.

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

Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

[Luca Ceresoli]

Hi Alejandro,

On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> This layer is meant to augment Yocto/OE functionality to provide a
> toolchain to build standalone components for Xilinx architectures.
> 
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> Signed-off-by: Manjukumar Matha 
> ---
>  meta-xilinx-standalone/README.md   | 56 
> ++
>  .../conf/distro/xilinx-standalone.conf | 12 +
>  meta-xilinx-standalone/conf/layer.conf | 14 ++
>  .../conf/machine/zynqmp-pmu.conf   | 11 +
>  4 files changed, 93 insertions(+)
>  create mode 100644 meta-xilinx-standalone/README.md
>  create mode 100644 meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
>  create mode 100644 meta-xilinx-standalone/conf/layer.conf
>  create mode 100644 meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
> 
> diff --git a/meta-xilinx-standalone/README.md 
> b/meta-xilinx-standalone/README.md
> new file mode 100644
> index 000..da7f4e1
> --- /dev/null
> +++ b/meta-xilinx-standalone/README.md
> @@ -0,0 +1,56 @@
> +meta-xilinx-standalone
> +=

Nitpick: there should be an extra '='.

[...]
> +Dependencies
> +
> +
> +This layer depends on:
> +
> + URI: git://git.yoctoproject.org/poky
> +
> + URI: git://git.yoctoproject.org/meta-xilinx

That's the repo, not the layer. Maybe clarify as:

  URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp layer

> +Usage
> +=
> +
> +1.- Clone this layer along with the specified layers
> +
> +2.- $ source oe-init-build-env
> +
> +3.- Add this layer to BBLAYERS on conf/bblayers.conf
> +
> +4.- Add the following to your conf/local.conf to build for the microblaze 
> architecture:
> +
> +DISTRO="xilinx-standalone"
> +
> +MACHINE="zynqmp-pmu"

To the best of my knowledge, to use U-Boot SPL people link the
pm_cfg_obj.c file in the pmufw binary and then patch the pmufw code to
load that config object instead of getting it via smc calls [0]. This
makes pmufw binary machine-specfic.

How do you think the same goal should be obtained with the new
"zynqmp-pmu" machine?

> diff --git a/meta-xilinx-standalone/conf/distro/xilinx-standalone.conf 
> b/meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
> new file mode 100644
> index 000..b90b113
> --- /dev/null
> +++ b/meta-xilinx-standalone/conf/distro/xilinx-standalone.conf
> @@ -0,0 +1,12 @@
> +DISTRO = "xilinx-standalone"
> +DISTRO_NAME = "Xilinx Standalone Distro"
> +DISTRO_VERSION = "1.0"
> +TARGET_VENDOR = "-xilinx"
> +
> +TCLIBC = "newlib"
> +TCLIBCAPPEND =""
> +
> +# Change SDK name
> +SDK_VERSION = "xilinx-standalone"
> +
> +BB_DANGLINGAPPENDS_WARNONLY = "1"

Why?

> diff --git a/meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf 
> b/meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
> new file mode 100644
> index 000..2f692db
> --- /dev/null
> +++ b/meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf
> @@ -0,0 +1,11 @@
> +DEFAULTTUNE ?= "microblaze"
> +
> +require conf/machine/include/microblaze/arch-microblaze.inc
> +
> +# Endianess, multiplier, barrel shift, pattern compare, floating point 
> double or single, are the possibilities
> +AVAILTUNES += "microblaze"
> +TUNE_FEATURES_tune-microblaze = "microblaze v9.2 barrel-shift 
> pattern-compare"

The above comment is not clear to a non-MB expert as I am. Does it refer
to AVAILTUNES or to TUNE_FEATURES? Also I'd put in the comment the
verbatim strings that can be put in variables, as in:

# TUNE_FEATURES can contain zero or more of:
# - multiplier
# - barrel-shift
# - pattern-compare
# - etc...

which is probably wrong, but should illustrate what I mean.


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

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

Re: [meta-xilinx] [PATCH 2/9] newlib: Remove recipes because they are on oe-core

[Luca Ceresoli]

Hi Alejandro,

On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote:
> Signed-off-by: Alejandro Enedino Hernandez Samaniego 
> Signed-off-by: Manjukumar Matha 

Reviewed-by: Luca Ceresoli 
Tested-by: Luca Ceresoli 

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

Re: [meta-xilinx] meta-xilinx git location ?

[Luca Ceresoli]

Hi Arno,

On 29/11/18 08:31, Arno Steffens wrote:
> Hello, I am a bit confused to see that in GIT (linked in Yocto 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/ ->
> git://git.yoctoproject.org/meta-xilinx ) there are no commits since August.

As far as I can understand, the repo on git.yoctoproject.org is the
"yocto-official" repository, which contains master and a branch for each
yocto release (rocko, sumo,...). It uses the open-source community workflow.

The "other" repo is at https://github.com/Xilinx/meta-xilinx, which has
the same branches and additionally has:
 - master-next, which is what you can expect to see in a while on the
   master branch of both repos
 - xilinx-*, the fork branches that xilinx uses to release their own
   reference designs. They implement the Xilinx workflow, and are in
   sync with their development tools (Vivado, Petalinux...)

Look at the github one for bleeding-edge development and xilinx-specific
code.

More info about the two workflows in [0], slides 11-13.

> But in this mailing list I can see commits (especially regarding thud).

Commits are not notified in this list. What you see are patches, which
don't always get accepted. There have been patches to bump to thud in
November 5, but they have not been accepted.

However, since yesterday the master-next branch has this commit:

  17a5f3321f83 layer.conf: Add thud as LAYERSERIES_COMPAT

so it looks like thud support is coming soon.

[0] http://lucaceresoli.net/wp-content/uploads/zynqmp-linux.pdf

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

Re: [meta-xilinx] A query on the AES-ZU7EV-1-SK-G 's Yocto support for the Xilinx's ZCU106's VCU TRD.

[Luca Ceresoli]

Hi Dennis,

On 15/11/18 16:26, Dennis Mungai wrote:
> Hello there,
> 
> I'm currently in possession of the aforementioned device, the
> AES-ZU7EV-1-SK-G, link:
> https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-zu7ev-1-sk-g-3074457345634251668/
> 
> According to AVNET, its' based on the ZCU106 platform, see:
> https://www.xilinx.com/products/boards-and-kits/zcu106.html#hardware
> 
> With that in mind, I went ahead and built a Yocto image for the 2018.2
> TRD, here:
> https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842038/Zynq+UltraScale+MPSoC+VCU+TRD+2018.2+-+Design+Module+3

The TRD for ZCU106 will not work on a different board. The SoC is
similar, but not equal, and the rest of the hardware is totally different.

You can reuse most of the principles from the TRD, but you have to
reimplement it on your own hardware, unless Avnet provides a working
configuration. At the very least you'll need to use the proper
part/board in your Vivado project and a devicetree for the Avnet board
(the zedboard.org site has some support files for that).

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

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

[Luca Ceresoli]

Hi Emily,

On 12/07/2018 17:12, Emily Smith wrote:
> Hi Everyone - 
> 
> 
> I'm using poky and bitbake to build an OS for the Xilinx ZCU102 board,
> and I'm having trouble with the Mali Kernel Module here: 
> 
> https://github.com/Xilinx/meta-xilinx/tree/master/meta-xilinx-bsp/recipes-graphics/mali
>  
> 
> 
> I thought it should be built with the  /meta-xilinx/meta-xilinx-bsp
> layer added in bitbake, but  I'm not seeing a .ko file anywhere that's
> produced, or on the board once I boot it.  Nothing was showing up
> with lsmod either. Do I need to enable anything, or set any variables
> for this to be built in the first place? 
> 
> 
> Any information you can give me would be very helpful. 

kernel-module-mali is pulled in by libmali-xlnx:

  $ git grep -B1 kernel-module-mali
  .../libmali-xlnx.bb-RDEPENDS_${PN} = " \
  .../libmali-xlnx.bb:   kernel-module-mali \

Is libmali-xlnx built?

A few things to check, in top-bottom order:
 1. your machine conf should have something like
PREFERRED_PROVIDER_virtual/libgles2 = "libmali-xlnx"
PREFERRED_PROVIDER_virtual/egl  = "libmali-xlnx"
 2. libmali-xlnx should then be built
 3. libmali-xlnx RDEPENDS on kernel-module-mali, so it should
be built as well

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

Re: [meta-xilinx] Generation of psu_init files

[Luca Ceresoli]

Hi Martin,

On 14/06/2018 21:40, Martin Siegumfeldt wrote:
> Thanks Luca,
> 
> 
> Michal, Manju I appreciate if you could provide some insight into the
> plan forward here. On the zcu102 board we are seeing a much improved
> QSPI NOR / UBI stack from what is planned to go into the Sumo release.
> Unfortunately we can not integrate the init code for our custom board as
> exported by any current Vivado version. Is this new structure exported
> by an upcoming Vivado release, or how do you expect us to handle this?

Strange. I just tried to build the xilinx_zynqmp_zcu106_revA_defconfig
config on a mainline U-Boot (v2018.07-rc1-132-g606fddd76c7a), using the
psu_init_gpl files from [0] and they built fine. I tried both the latest
files (2018.2) and the 2017.1 version.

I tried also on current u-boot-xlnx master, it works too.

This is expected since the "new format" is nothing but the "old format",
which I would rather call the "format produced by Vivado", stripped down
of unneeded things such as comments, unused function definitions etc.

Can you give some more detail on what you are doing and what happens?
What error message do you obtain? Which version of U-Boot? Can you
provide your psu_ini_gpl.* files? Your defconfig?

[0] https://github.com/Xilinx/hdf-examples

Regards,
-- 
Luca

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

Re: [meta-xilinx] Generation of psu_init files

[Luca Ceresoli]

Hi Martin,

On 04/06/2018 21:45, Martin Siegumfeldt wrote:
> Hi,
> 
> Since 
> https://github.com/Xilinx/u-boot-xlnx/commit/a38ad86e46b940dd53cb328ed19761dbb084d6e5#diff-ff33c47fd7e88097b7ebeba1d14fe072
>  / 
> https://github.com/Xilinx/u-boot-xlnx/commit/9fd6056f5329d2d1178ef675f53641461c2e183d#diff-7f268ae597d9cb8d64ad0d46931fdb1b
>  the psu_init files have changed format. AFAICS, Vivado 2018.1 still outputs 
> the old format which is also the case for 
> https://github.com/Xilinx/hdf-examples. What is the process for generating 
> the files in the new format?

I added in Cc Michal Simek who did the commits you mentioned. I think he
has a script to convert the "old format" (generated by Vivado) to the
"new format", which is basically the same file, with comments and other
unneeded code removed.

Michal, do you think that script could be published, maybe in mainline
U-Boot?

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Luca Ceresoli]

Hi Manjukumar,

On 31/05/2018 02:52, Manjukumar Harthikote Matha wrote:
> 
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Wednesday, May 30, 2018 2:33 AM
>> To: Manjukumar Harthikote Matha ; meta-
>> xil...@yoctoproject.org
>> Cc: Devarsh Thakkar ; Devarsh Thakkar
>> 
>> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2] zcu106-zynqmp.conf: 
>> Add
>> support for ZCU106 Evaluation Kit
>>
>> Hi Manjukumar, Devarsh,
>>
>> On 29/05/2018 04:04, Manjukumar Matha wrote:
>>> From: Devarsh Thakkar 
>>>
>>> The ZCU106 Evaluation Kit enables designers to jumpstart designs for
>>> video conferencing, surveillance, Advanced Driver Assisted Systems
>>> (ADAS) and streaming and encoding applications. This kit features a
>>> Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
>>> and interfaces, enabling development for a wide range of applications.
>>> The included ZU7EV device is equipped with a quad-core ARM® Cortex™-A53
>>> applications processor, dual-core Cortex-R5 real-time processor,
>>> Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265 video
>>> codec, and 16nm FinFET+ programmable logic.
>>>
>>> This patch adds machine configuration file for ZCU106 Evaluation Kit
>>> with required setting of board specific yocto variables needed for
>>> compilation of bootloader, kernel and device-tree.
>>>
>>> - linux-xlnx is the kernel provider
>>> - u-boot-xlnx is the u-boot provider which will also generate SPL boot.bin
>>> - hwcodec is provided by libomxil-xlnx recipe, this will pull in
>>>   additional dependencies of VCU kernel modules, control software,
>>>   firmware binaries
>>>
>>> Depending on the application need you may want to pass the appropriate
>>> CMA size in bootargs or set CONFIG_CMA_SIZE_MBYTES in kernel.
>>>
>>> While using SPL flow, you may need to provide additional hack to pass
>>> the PMU config object. This is similar to all ZU+ boards, due to gap in
>>> SPL flow unable to load PMU config object.
>>
>> Thanks for the added comments.
>>
>>> Signed-off-by: Devarsh Thakkar 
>>> Tested-by: Maulik Desai 
>>> Signed-off-by: Manjukumar Matha > ma...@xilinx.com>
>>> ---
>>> Changelog:
>>> v2: Add commit message to describe the providers and state of SPL boot.
>>> Also add the requirement of CMA size required based on appliction
>>>
>>>  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf| 33
>> ++
>>>  .../recipes-bsp/u-boot/u-boot-xlnx_2018.1.bb   |  1 +
>>>  2 files changed, 34 insertions(+)
>>>  create mode 100644 meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
>>>
>>> diff --git a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf b/meta-xilinx-
>> bsp/conf/machine/zcu106-zynqmp.conf
>>> new file mode 100644
>>> index 000..42ac479
>>> --- /dev/null
>>> +++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
>>> @@ -0,0 +1,33 @@
>>> +#@TYPE: Machine
>>> +#@NAME: zcu106-zynqmp
>>> +#@DESCRIPTION: Machine support for ZCU106 Evaluation Board.
>>> +
>>> +require conf/machine/include/tune-zynqmp.inc
>>> +require conf/machine/include/machine-xilinx-default.inc
>>> +require conf/machine/include/machine-xilinx-board.inc
>>> +include conf/machine/include/zynqmp-pmu-config.inc
>>> +
>>> +MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
>>> +
>>> +UBOOT_MACHINE = "xilinx_zynqmp_zcu106_revA_defconfig"
>>> +SPL_BINARY = "spl/boot.bin"
>>> +
>>> +SERIAL_CONSOLE = "115200 ttyPS0"
>>
>> SERIAL_CONSOLE is deprecated, I think this should become SERIAL_CONSOLES.
>>
> 
> I will merge this as is and send out another patch for all machines to use
> SERIAL_CONSOLES

That's fine, thanks.

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH v2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Luca Ceresoli]

Hi Manjukumar, Devarsh,

On 29/05/2018 04:04, Manjukumar Matha wrote:
> From: Devarsh Thakkar 
> 
> The ZCU106 Evaluation Kit enables designers to jumpstart designs for
> video conferencing, surveillance, Advanced Driver Assisted Systems
> (ADAS) and streaming and encoding applications. This kit features a
> Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
> and interfaces, enabling development for a wide range of applications.
> The included ZU7EV device is equipped with a quad-core ARM® Cortex™-A53
> applications processor, dual-core Cortex-R5 real-time processor,
> Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265 video
> codec, and 16nm FinFET+ programmable logic.
> 
> This patch adds machine configuration file for ZCU106 Evaluation Kit
> with required setting of board specific yocto variables needed for
> compilation of bootloader, kernel and device-tree.
> 
> - linux-xlnx is the kernel provider
> - u-boot-xlnx is the u-boot provider which will also generate SPL boot.bin
> - hwcodec is provided by libomxil-xlnx recipe, this will pull in
>   additional dependencies of VCU kernel modules, control software,
>   firmware binaries
> 
> Depending on the application need you may want to pass the appropriate
> CMA size in bootargs or set CONFIG_CMA_SIZE_MBYTES in kernel.
> 
> While using SPL flow, you may need to provide additional hack to pass
> the PMU config object. This is similar to all ZU+ boards, due to gap in
> SPL flow unable to load PMU config object.

Thanks for the added comments.

> Signed-off-by: Devarsh Thakkar 
> Tested-by: Maulik Desai 
> Signed-off-by: Manjukumar Matha 
> ---
> Changelog:
> v2: Add commit message to describe the providers and state of SPL boot.
> Also add the requirement of CMA size required based on appliction
> 
>  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf| 33 
> ++
>  .../recipes-bsp/u-boot/u-boot-xlnx_2018.1.bb   |  1 +
>  2 files changed, 34 insertions(+)
>  create mode 100644 meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> 
> diff --git a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf 
> b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> new file mode 100644
> index 000..42ac479
> --- /dev/null
> +++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> @@ -0,0 +1,33 @@
> +#@TYPE: Machine
> +#@NAME: zcu106-zynqmp
> +#@DESCRIPTION: Machine support for ZCU106 Evaluation Board.
> +
> +require conf/machine/include/tune-zynqmp.inc
> +require conf/machine/include/machine-xilinx-default.inc
> +require conf/machine/include/machine-xilinx-board.inc
> +include conf/machine/include/zynqmp-pmu-config.inc
> +
> +MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
> +
> +UBOOT_MACHINE = "xilinx_zynqmp_zcu106_revA_defconfig"
> +SPL_BINARY = "spl/boot.bin"
> +
> +SERIAL_CONSOLE = "115200 ttyPS0"

SERIAL_CONSOLE is deprecated, I think this should become SERIAL_CONSOLES.

Other than than, looks good.

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Luca Ceresoli]

Hi,

On 29/05/2018 04:12, Manjukumar Harthikote Matha wrote:
[...]
> One more thing, with the workaround from meta-topic I was able to boot it on 
> hardware using SPL flow.
> 
> I have seen an implementation by you in buildroot, include pmufw.bin to 
> boot.bin 
> https://github.com/lucaceresoli/buildroot/commit/382c22bcb059b08b0398d5f1faa6a17abc31dd26
> 
> Are you planning to push this upstream to u-boot? 

There's nothing there to be pushed upstream to u-boot, because there are
no patches to u-boot there. There are basically two commits concerning
u-boot: one to build with the user psu_init, the other to link the PMUFW
+ SPL in boot.bin.

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Luca Ceresoli]

Hi,

On 28/05/2018 20:03, Manjukumar Harthikote Matha wrote:
> Hi Luca,
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Monday, May 28, 2018 10:38 AM
>> To: Manjukumar Harthikote Matha ; meta-
>> xil...@yoctoproject.org
>> Cc: Devarsh Thakkar ; Devarsh Thakkar
>> 
>> Subject: Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf: 
>> Add
>> support for ZCU106 Evaluation Kit
>>
>> Hi Manjukumar, Devarsh,
>>
>> I'm glad to see zcu106 support coming! However I have a few questions about 
>> this
>> patch, see below.
>>
>> On 28/05/2018 09:40, Manjukumar Matha wrote:
>>> From: Devarsh Thakkar 
>>>
>>> The ZCU106 Evaluation Kit enables designers to jumpstart designs for
>>> video conferencing, surveillance, Advanced Driver Assisted Systems
>>> (ADAS) and streaming and encoding applications. This kit features a
>>> Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
>>> and interfaces, enabling development for a wide range of applications.
>>> The included ZU7EV device is equipped with a quad-core ARM®
>>> Cortex™-A53 applications processor, dual-core Cortex-R5 real-time
>>> processor,
>>> Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265
>>> video codec, and 16nm FinFET+ programmable logic.
>>
>> I find this marketing-style paragraph rather useless in this context.
> 
> It's better to have a description of board capabilities.
> 
>> Why not replacing it with a short, technical description of how the board 
>> boots
>> (U-Boot SPL, ATF etc), which device drivers are enabled etc?
>>
> 
> I can edit some info to commit message

Thanks.

>>> This patch adds machine configuration file for ZCU106 Evaluation Kit
>>> with required setting of board specific yocto variables needed for
>>> compilation of bootloader, kernel and device-tree
>>>
>>> Signed-off-by: Devarsh Thakkar 
>>> Tested-by: Maulik Desai 
>>> Signed-off-by: Manjukumar Matha
>>> 
>>> ---
>>>  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf | 33
>>> +
>>>  1 file changed, 33 insertions(+)
>>>  create mode 100644 meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
>>>
>>> diff --git a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
>>> b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
>>> new file mode 100644
>>> index 000..42ac479
>>> --- /dev/null
>>> +++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
>>> @@ -0,0 +1,33 @@
>>> +#@TYPE: Machine
>>> +#@NAME: zcu106-zynqmp
>>> +#@DESCRIPTION: Machine support for ZCU106 Evaluation Board.
>>> +
>>> +require conf/machine/include/tune-zynqmp.inc
>>> +require conf/machine/include/machine-xilinx-default.inc
>>> +require conf/machine/include/machine-xilinx-board.inc
>>> +include conf/machine/include/zynqmp-pmu-config.inc
>>> +
>>> +MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
>>> +
>>> +UBOOT_MACHINE = "xilinx_zynqmp_zcu106_revA_defconfig"
>>> +SPL_BINARY = "spl/boot.bin"
>>> +
>>> +SERIAL_CONSOLE = "115200 ttyPS0"
>>> +SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
>>> +
>>> +KERNEL_DEVICETREE = "xilinx/zynqmp-zcu106-revA.dtb"
>>> +
>>> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx"
>>> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-xlnx"
>>> +PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware"
>>> +
>>> +EXTRA_IMAGEDEPENDS += " \
>>> +   u-boot-zynq-uenv \
>>> +   arm-trusted-firmware \
>>> +   virtual/pmu-firmware \
>>> +   virtual/boot-bin \
>>> +   "
>>> +
>>> +IMAGE_BOOT_FILES += "uEnv.txt atf-uboot.ub ${KERNEL_IMAGETYPE}-zynqmp-
>> zcu106-revA.dtb"
>>> +
>>> +MACHINE_HWCODECS = "libomxil-xlnx"
>>
>> Is this machine configuration supposed to boot with this patch?
>> How is the configuration object passed to the PMUFW?
>>
> 
> SPL flow still have a gap on PMUFW config object load AFAIK. This would be 
> similar to existing zcu102. The only workaround I am aware is of Mike's patch 
> in meta-topic

Mee too.

>> If this patch is not yet enough to boot, I think it's worth mentioning it in 
>> the
>> commit message.
>>
> 
> SPL gap for SDboot for all MPSoC devices is a known fact. 

I don't think it's known by newcomers. It would if it were documented.
Is it documented anywhere? The Xilinx Wiki says "U-Boot SPL cannot be
used on ZynqMP devices"
(http://www.wiki.xilinx.com/U-Boot+Secondary+Program+Loader)

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

Re: [meta-xilinx] [meta-xilinx-bsp][PATCH 1/2] zcu106-zynqmp.conf: Add support for ZCU106 Evaluation Kit

[Luca Ceresoli]

Hi Manjukumar, Devarsh,

I'm glad to see zcu106 support coming! However I have a few questions
about this patch, see below.

On 28/05/2018 09:40, Manjukumar Matha wrote:
> From: Devarsh Thakkar 
> 
> The ZCU106 Evaluation Kit enables designers to jumpstart designs for
> video conferencing, surveillance, Advanced Driver Assisted Systems
> (ADAS) and streaming and encoding applications. This kit features a
> Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
> and interfaces, enabling development for a wide range of applications.
> The included ZU7EV device is equipped with a quad-core ARM® Cortex™-A53
> applications processor, dual-core Cortex-R5 real-time processor,
> Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265 video
> codec, and 16nm FinFET+ programmable logic.

I find this marketing-style paragraph rather useless in this context.
Why not replacing it with a short, technical description of how the
board boots (U-Boot SPL, ATF etc), which device drivers are enabled etc?

> This patch adds machine configuration file for ZCU106 Evaluation Kit
> with required setting of board specific yocto variables needed for
> compilation of bootloader, kernel and device-tree
>
> Signed-off-by: Devarsh Thakkar 
> Tested-by: Maulik Desai 
> Signed-off-by: Manjukumar Matha 
> ---
>  meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf | 33 
> +
>  1 file changed, 33 insertions(+)
>  create mode 100644 meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> 
> diff --git a/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf 
> b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> new file mode 100644
> index 000..42ac479
> --- /dev/null
> +++ b/meta-xilinx-bsp/conf/machine/zcu106-zynqmp.conf
> @@ -0,0 +1,33 @@
> +#@TYPE: Machine
> +#@NAME: zcu106-zynqmp
> +#@DESCRIPTION: Machine support for ZCU106 Evaluation Board.
> +
> +require conf/machine/include/tune-zynqmp.inc
> +require conf/machine/include/machine-xilinx-default.inc
> +require conf/machine/include/machine-xilinx-board.inc
> +include conf/machine/include/zynqmp-pmu-config.inc
> +
> +MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
> +
> +UBOOT_MACHINE = "xilinx_zynqmp_zcu106_revA_defconfig"
> +SPL_BINARY = "spl/boot.bin"
> +
> +SERIAL_CONSOLE = "115200 ttyPS0"
> +SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
> +
> +KERNEL_DEVICETREE = "xilinx/zynqmp-zcu106-revA.dtb"
> +
> +PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx"
> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-xlnx"
> +PREFERRED_PROVIDER_virtual/pmu-firmware ?= "zynqmp-pmu-pmu-firmware"
> +
> +EXTRA_IMAGEDEPENDS += " \
> + u-boot-zynq-uenv \
> + arm-trusted-firmware \
> + virtual/pmu-firmware \
> + virtual/boot-bin \
> + "
> +
> +IMAGE_BOOT_FILES += "uEnv.txt atf-uboot.ub 
> ${KERNEL_IMAGETYPE}-zynqmp-zcu106-revA.dtb"
> +
> +MACHINE_HWCODECS = "libomxil-xlnx"

Is this machine configuration supposed to boot with this patch?
How is the configuration object passed to the PMUFW?

If this patch is not yet enough to boot, I think it's worth mentioning
it in the commit message.

Also, this patch won't build without patch 2 of this series. The two
patches should be squashed together if we want a bisectable commit. To
me, the two patches together implement a single change: add zcu106 support.

Thanks,
-- 
Luca

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

Re: [meta-xilinx] Yoctoproject vs Github

[Luca Ceresoli]

Hi Richard,

On 16/05/2018 14:38, richard-bai...@sti-limited.com wrote:
> Hi,
> 
>  
> 
> I was just wondering how the yoctoproject.org meta-xilinx relates to the
> github hosted version.
> 
> Is it a mirror or are there some changes? Is it updated immediately? Are
> there any advantages to using either?

The repo on yoctoproject.org contains development done by the open
source community and is developed as close as possible to the yocto
standards.

The github repo is a fork by Xilinx. The branches on that repo start
from a commit from yoctoproject.org and add some features. But in the
practice it will work in a different workflow involving Petalinux, xsct
and other Xilinx proprietary tools. The branches there are not supposed
to be merged into yoctoproject.org, they will keep on diverging.

Thus you should first choose your workflow:

 * The Community workflow: use yoctoproject.org, standard open source
   tools, boot using U-Boot SPL
 * The Xilinx workflow: use the github xilinx fork, follow the Xilinx
   procedures, boot with Xilinx FSBL etc.

A few more details on the two approaches in this talk:
https://fosdem.org/2018/schedule/event/arm64_and_fpga/

Hope that helps,
-- 
Luca
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

Re: [meta-xilinx] rel-v2018.1 / zcu102-zynqmp: U-boot crashes with error "fdt_root: FDT_ERR_BADMAGIC"

[Luca Ceresoli]

Hi,

On 07/05/2018 15:43, Martin Lund wrote:
>  
>> Inspired by your last post I tried adding an #undef CONFIG_ARM64 in
> arch/arm/lib/spl.c to force it to jump to the ATF without dropping to
> EL2 first. That is, to try to mimic the old hacky way of booting the ATF.
>>
>> Unfortunately this hack seems to be insufficient as it gets stuck at
> address 0xfffea928 so I assume the ATF has crashed ending up in a reset
> vector - probably because some preconditions not being fulfilled.
>>
>> In the end, perhaps the best way forward is to try use the new ATF
> framework in u-boot but as you point out the information is sparse on
> that point.
>>
>> Hopefully someone out there can provide us with the missing
> information so that we can get the zynqmp booting without using the
> horrible xilinx toolchain.
> 
> 
> Short follow up  - I tried enabling the new u-boot SPL ATF framework in
> u-boot-xlnx (xilinx-v2018.1) by enabling CONFIG_SPL_ATF and I also
> applied the following patch to meta-xilinx to produce a valid
> atf-boot.ub of type "AArch64 ARM Trusted Firmware Kernel Image
> (uncompressed)":
> 
> diff --git
> a/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> b/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> index 7f13507..2f1343e 100644
> ---
> a/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> +++Bye
> b/meta-xilinx-bsp/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware.inc
> @@ -59,7 +59,7 @@ do_deploy() {
> 
>     # Get the entry point address from the elf.
>     BL31_BASE_ADDR=$(${READELF} -h ${OUTPUT_DIR}/bl31/bl31.elf |
> egrep -m 1 -i "entry point.*?0x" | sed -r 's/.*?(0x.*?)/\1/g')
> -   mkimage -A arm64 -O linux -T kernel -C none \
> +   mkimage -A arm64 -O arm-trusted-firmware -C none \
>     -a $BL31_BASE_ADDR -e $BL31_BASE_ADDR \
>     -d ${OUTPUT_DIR}/bl31.bin ${DEPLOYDIR}/${ATF_BASE_NAME}.ub
>     ln -sf ${ATF_BASE_NAME}.ub ${DEPLOYDIR}/${PN}.ub
> 
> 
> However, using the new SPL ATF framework, it crashes in the exact same
> way as with my attempt trying to boot it the old hacky way.
> 
> The last thing I see with u-boot debug enabled is:
> "Jumping to U-Boot via ARM Trusted Firmware"
> 
> and then it gets stuck at the same reset vector:
> 
> xsct%
> stop  
>   
>  
> Info: Cortex-A53 #0 (target 9) Stopped at 0xfffea928 (External Debug
> Request)
> 
> xsct%
> rrd   
>   
>  made it
>   r0: ff34    r1: 0001
>   r2: 0001    r3: ff30
>   r4: 000c    r5: ff990400
>   r6: ff9905d8    r7: 0188
>   r8: 7c90    r9: fffea09c
>  r10: 08e8   r11: 0006
>  r12: 0001869f   r13: 000c
>  r14: 000a   r15: 
>  r16: 280c860380080c00   r17: 07b8
>  r18: 0004   r19: e000
>  r20: 6b98   r21: 6c08
>  r22: 26a0   r23: 0002
>  r24: fffda84e   r25: fffe
>  r26: deadbeef   r27: 81cf122302800303
>  r28: 82019000260d0c12   r29: 6b30
>  r30: fffecf94    sp: 6b30
>   pc: fffea928  cpsr: 02cc
>  vfp sys  
> acpu_gic  
> 
> xsct%
> bt
>   
>  
>     0  0xfffea928
>     1  0xfffecf94
>     2  0xfffed0b4
>     3  0xfffeb364
>     4  0x05d0
>     5  0xfffea2a8
>     6  0xfffea0a8
>     7  0x6000
> 
> I suspect it might be an issue with the atf-uboot.ub but I'm not sure.
> 
> 
> Recently Xilinx have been working on enabling the new u-boot ATF
> framework as they have signed-off on this patch:
> https://github.com/Xilinx/u-boot-xlnx/commit/949e5cb9a736bac32ea8886e3953da55bdd30754#diff-96969e0a4f8df761977a2ba066314ed3

I noticed this thread only now...

The patch was originally for zcu106, Michal Simek (Xilinx) later applied
it for all boards.

> I assume Xilinx tested this feature - it would be great if Xilinx could
> disclose the details on how to get the new u-boot SPL ATF framework
> working with the xilinx v2018.1 release on the zcu102 board. Perhaps we
> are missing some important detail or patch.

As per the commit message, you need to pass '-O arm-trusted-firmware' or
it won't trigger the ATF boot path. And yes, this avoids the need for
the Falcon mode hack.

I definitely tested it on zcu106 and it works. I assume Xilinx tested it
internally on the ot

Re: [meta-xilinx] Rocko with meta-xilinx doesn't boot on ZynqMP zynqmp_clk_get_periphial_rate

[Luca Ceresoli]

Hi,

On 05/12/2017 02:37, Manjukumar Harthikote Matha wrote:
> 
> 
>> -Original Message-
>> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
>> boun...@yoctoproject.org] On Behalf Of Alistair Francis
>> Sent: Monday, December 04, 2017 9:20 AM
>> To: Forstmayr, Franz 
>> Cc: meta-xilinx@yoctoproject.org
>> Subject: Re: [meta-xilinx] Rocko with meta-xilinx doesn't boot on ZynqMP
>> zynqmp_clk_get_periphial_rate
>>
>> On Mon, Dec 4, 2017 at 6:34 AM, Forstmayr, Franz
>> mailto:franz.forstm...@rosenberger.com> >
>> wrote:
>>
>>
>>  Hey,
>>
>>
>>
>>  I just cloned the rocko branch of yocto and the master branch of 
>> meta-xilinx
>> and wanted to build a core-image-minimal first.
>>
>>
>>
>>  Parsing recipes: 100%
>> |###
>> 
>> #| Time: 0:00:33
>>
>>  Parsing of 841 .bb files complete (0 cached, 841 parsed). 2154 targets, 
>> 226
>> skipped, 0 masked, 0 errors.
>>
>>  NOTE: Resolving any missing task queue dependencies
>>
>>
>>
>>  Build Configuration:
>>
>>  BB_VERSION= "1.36.0"
>>
>>  BUILD_SYS = "x86_64-linux"
>>
>>  NATIVELSBSTRING   = "ubuntu-16.04"
>>
>>  TARGET_SYS= "aarch64-poky-linux"
>>
>>  MACHINE   = "zcu102-zynqmp"
>>
>>  DISTRO= "poky"
>>
>>  DISTRO_VERSION= "2.4"
>>
>>  TUNE_FEATURES = "aarch64"
>>
>>  TARGET_FPU= ""
>>
>>  meta
>>
>>  meta-poky
>>
>>  meta-yocto-bsp= "rocko:f7b90ab3eaf832bd81f3efc1dab4dcf6863ac284"
>>
>>  meta-xilinx   = "master:82ac762e83e37e45db3fbe38ad1e21114a3426b6"
>>
>>
>>
>>  Initialising tasks: 100%
>> |###
>> 
>> ##| Time: 0:00:03
>>
>>  NOTE: Executing SetScene Tasks
>>
>>  NOTE: Executing RunQueue Tasks
>>
>>  WARNING: core-image-minimal-1.0-r0 do_rootfs: [log_check] core-image-
>> minimal: found 1 warning message in the logfile:
>>
>>  [log_check] warning: %post(sysvinit-inittab-2.88dsf-r10.zcu102_zynqmp)
>> scriptlet failed, exit status 1
>>
>>
>>
>>  NOTE: Tasks Summary: Attempted 2792 tasks of which 6 didn't need to be
>> rerun and all succeeded.
>>
>>
>>
>>  Summary: There was 1 WARNING message shown.
>>
>>
>>
>>  After copying the relevant files to my sd, I get following output.
>>
>>
>>
>>  U-Boot SPL 
>> 201fsbl_bsp/psu_cortexa53_0/libsrc/xilpm_v2_1/src/pm_cfg_obj.c7.01 (Dec 04 
>> 2017 - 14:49:28)
>>  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 v4/RTL5.1 at 0xfffea000, with
>> PMU firmware
>>  NOTICE:  BL31: Secure code at 0x0
>>  NOTICE:  BL31: Non secure code at 0x800
>>  NOTICE:  BL31: v1.3(release):f9b244b
>>  NOTICE:  BL31: Built : 13:59:16, Dec  4 2017
>>  PMUFW:  v0.3
>>  zynqmp_clk_get_peripheral_rate mio read fail
>>  failed to get rate
>>  zynqmp_clk_get_peripheral_rate mio read fail
>>  failed to get rate
>>
>>
>>
>>  Is there something wrong with my setup? I have no modifications so far.
>>
>>
>> It looks like the PMU FW config data hasn't been loaded. I'm not too sure 
>> how to do
>> that from SPL though.
>>
>>
> 
> Yes this is not documented and I am not sure how it works through SPL either. 
> Any inputs?
> Is there a manual step to get PMU firmware in SPL boot.bin?

U-Boot SPL is currently unable to load a PMU FW config object AFAIK. The
current best hack to boot with U-Boot SPL is to let PMU FW load a
hard-coded cfg object. This is implemented in [0].

But you need a configuration object of course. You can obtain one by
generating an FSBL with Xilinx XSDK, it will be in a path similar to
fsbl_bsp/psu_cortexa53_0/libsrc/xilpm_v2_1/src/pm_cfg_obj.c

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

Bye,
-- 
Luca
-- 
___
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

[Luca Ceresoli]

Hi Mike, Nathan,

On 09/10/2017 12:43, Mike Looijmans wrote:
> 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.

Interesting, thanks! It's really a small patch, I will certainly test it.

On which board/silicon did you test 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.

Sure. And I agree with Nathan it seems a good solution also from a
technical point of view.

Bye,
-- 
Luca
-- 
___
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

[Luca Ceresoli]

Hi Nathan,

On 07/10/2017 11:57, Nathan Rossi wrote:
> Build the rev 1.0 version of U-Boot and setup the deployment of
> boot.bin.
> 
> Signed-off-by: Nathan Rossi 
> ---
>  conf/machine/zcu102-zynqmp.conf | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/conf/machine/zcu102-zynqmp.conf b/conf/machine/zcu102-zynqmp.conf
> index e6d66cd948..ee243454aa 100644
> --- a/conf/machine/zcu102-zynqmp.conf
> +++ b/conf/machine/zcu102-zynqmp.conf
> @@ -10,7 +10,8 @@ include conf/machine/include/zynqmp-pmu-config.inc
>  
>  MACHINE_FEATURES = "rtc ext2 ext3 vfat usbhost"
>  
> -UBOOT_MACHINE = "xilinx_zynqmp_zcu102_revB_defconfig"
> +UBOOT_MACHINE = "xilinx_zynqmp_zcu102_rev1_0_defconfig"
> +SPL_BINARY = "spl/boot.bin"

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

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

Re: [meta-xilinx] [PATCH] kernel-module-mali.bb: Update source location

[Luca Ceresoli]

Hi,

On 10/07/2017 20:39, Manjukumar Matha wrote:
> From: Bhargava Sreekantappa Gayathri 
> 
> 
> MALI kernel sources seems to have been moved, update recipe to download
> source from a new location
> 
> Signed-off-by: Bhargava Sreekantappa Gayathri 
> 
> Signed-off-by: Manjukumar Matha 
> ---
>  recipes-graphics/mali/kernel-module-mali.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-graphics/mali/kernel-module-mali.bb 
> b/recipes-graphics/mali/kernel-module-mali.bb
> index 0ad1a49..6674071 100644
> --- a/recipes-graphics/mali/kernel-module-mali.bb
> +++ b/recipes-graphics/mali/kernel-module-mali.bb
> @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = " \
>  PV = "r7p0-00rel0"
>  
>  SRC_URI = " \
> - 
> http://malideveloper.arm.com/downloads/drivers/DX910/${PV}/DX910-SW-99002-${PV}.tgz
>  \
> + 
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-utgard-gpu/DX910-SW-99002-${PV}.tgz
>  \

Thanks for the quick response.

Reviewed-by: Luca Ceresoli 
Tested-by: Luca Ceresoli 
-- 
Luca
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] kernel-module-mali fetcher failure

[Luca Ceresoli]

Hi,

since a few days the kernel-module-mali recipe [0] fails to download its
tarball.

Looks like the file has been moved to
https://armkeil.blob.core.windows.net/developer//sitecore/shell/-/media/Files/downloads/mali-drivers/kernel/mali-utgard-gpu/DX910-SW-99002-${PV}.tgz
(at least for PV = r7p0-00rel0 and r7p0-00rel1).

Is this new URL official, and supposed to be stable?

Thanks.

[0]
https://github.com/Xilinx/meta-xilinx/blob/rel-v2017.1/recipes-graphics/mali/kernel-module-mali.bb

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

Re: [meta-xilinx] libmali-xlnx fetch from unknown host gitenterprise.xilinx.com

[Luca Ceresoli]

Hi Manjukumar,

On 08/06/2017 18:02, Manjukumar Harthikote Matha wrote:
> 
> 
>> -Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Thursday, June 08, 2017 7:17 AM
>> To: meta-xilinx@yoctoproject.org
>> Cc: Madhurkiran Harikrishnan ; Manjukumar Harthikote
>> Matha 
>> Subject: libmali-xlnx fetch from unknown host gitenterprise.xilinx.com
>>
>> Hi,
>>
>> I have an issue downloading the Mali 400 userspace libraries for ZynqMP.
>>
>> I'm using the rel-v2017.1 branch of the meta-xilinx layer (from github [0]). 
>> The
>> libmali-xlnx recipe [1] tries to fetch from gitenterprise.xilinx.com, but 
>> this host name
>> cannot be resolved so the fetch step fails.
>>
>> The documented at [2] has a link to a web page where a tarball can be 
>> downloaded.
>> That tarball contains instructions to extract a second tarball and put a 
>> third tarball a
>> directory, then configure bitbake to locate it as if it had been downloaded 
>> normally.
>> This works but needs several manual steps, which must be repeated on any
>> development host.
>> Moreover it requires using SOURCE_MIRROR_URL, which thus cannot be used for
>> other purposes.
>>
>> I'm currently writing a script to partially automate it, but it's a waste of 
>> time for me
>> and everybody else wanting to just use this package. I also expect it to 
>> break as soon
>> as a new version of the tarball is released and the meta-xilinx recipe 
>> updated.
>>
>> It is desirable that libmali-xlnx can download its files without any human
>> intervention, just like any other recipe. Is there a plan to achieve that?
>>
> Agreed it is pain, but the restriction is due to ARM licensing. We are 
> working to get it resolved with ARM

Many thanks for the prompt reply!

I suspected some licensing restriction issue... I hope they can be
resolved soon.

I noticed the Mali libraries for other projects are downloadable without
troubles, so I hope the same can be done for Xilinx as well:

 * https://github.com/linux-sunxi/sunxi-mali-proprietary
 * https://github.com/mdrjr/c2_mali

Best regards,
-- 
Luca
-- 
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx

[meta-xilinx] libmali-xlnx fetch from unknown host gitenterprise.xilinx.com

[Luca Ceresoli]

Hi,

I have an issue downloading the Mali 400 userspace libraries for ZynqMP.

I'm using the rel-v2017.1 branch of the meta-xilinx layer (from github
[0]). The libmali-xlnx recipe [1] tries to fetch from
gitenterprise.xilinx.com, but this host name cannot be resolved so the
fetch step fails.

The documented at [2] has a link to a web page where a tarball can be
downloaded. That tarball contains instructions to extract a second
tarball and put a third tarball a directory, then configure bitbake to
locate it as if it had been downloaded normally. This works but needs
several manual steps, which must be repeated on any development host.
Moreover it requires using SOURCE_MIRROR_URL, which thus cannot be used
for other purposes.

I'm currently writing a script to partially automate it, but it's a
waste of time for me and everybody else wanting to just use this
package. I also expect it to break as soon as a new version of the
tarball is released and the meta-xilinx recipe updated.

It is desirable that libmali-xlnx can download its files without any
human intervention, just like any other recipe. Is there a plan to
achieve that?

Thanks in advance!

[0] https://github.com/Xilinx/meta-xilinx

[1]
https://github.com/Xilinx/meta-xilinx/blob/33014f8bdcbc8991088/recipes-graphics/libgles/libmali-xlnx_git.bb#L16

[2]
https://github.com/Xilinx/meta-xilinx/blob/33014f8bdcbc8991088/docs/MALI-binaries

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