Hello guys,

On 6/3/2019 7:43 PM, Jean-Francois Dagenais wrote:
Thanks for the comeback Luca.

On Jun 3, 2019, at 03:47, Luca Ceresoli <[email protected]> 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
Does a non-multiconfig setup work?
Will try this tomorrow.

Multiconfig should not have anything to do with this,

I'm not exactly sure what you are running into, since I'm not able to reproduce 
it

but I don't see why those directories would exist, I would try cleaning as well 
and that will probably fix it.


Also, once we release the warrior branch, pmu-firmware should work with master 
and warrior (from oe-core) just fine,
and there will be a small change on the way multiconfig is setup to make it 
faster.

Cheers,

Alejandro


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, have you tried with a really clean 
workdir for pmu-firmware (bitbake pmu-firmware -c cleanall)? (Just to be sure)

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

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.

Cheers and thanks for the help guys!
/jfd
-- 
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx

Reply via email to