[meta-xilinx] failure : SD to u-boot SPL to u-boot on zcu102-zynqmp

Thu Mar 23 09:28:46 PDT 2017

Hi guys,

Thanks for sticking around.

I have dug more in xilinx docs, the SDK, u-boot-xlnx source. My position right now is that we are vested in the workflow presented by the zedboard supported in meta-xilinx. We are building everything through CI scripts and docker images. It is much harder at this point for me to start integrating Xilinx tools in docker images in order to get my final images built properly.

Point is, AT THIS STAGE of our development, we have NO interest in ATF, PMUFW, power management, etc. All I want to do is get into my linux kernel and boot my rootfs, ideally without xilinx tools.

We already have part of the build process under CI (not docker) and the output from the PL team is a hdf file (with fpga bitstream and psu_init stuff). I already integrate my psu_init stuff from yocto into u-boot SPL. This was my zedboard prototyping heritage. Worked great!

Now for our zynqmp development, I see 3 paths to achieve my short term goal (in preferred order):

1. using meta-xilinx and u-boot-xlnx-dev by removing the pmufw 0.3 check (I don't use ethernet if that matters) and hope I can get away with it for my scenario... for a while.
2. using meta-xilinx and u-boot-xlnx (2016.4) and figuring out what's failing. I reported earlier that I wasn't seing anything on the output, I am no longer seing this behaviour. As suggested by Nathan, I ported the psu_init_gpl files from boards/xilinx/zynqmp/zynqmp-zcu102-rev1.0 -> 2016.4/boards/xilinx/zynqmp/xilinx_zynqmp_zcu102. Without this patch, I get similar output. Here's with the newer psu_init files:
=========================================================================
<debug_uart> Debug uart enabled

U-Boot SPL 2016.07 (Mar 23 2017 - 10:31:34)
EL Level:	EL3
Invalid Boot Mode:0xe
Trying to boot from RAM
"Synchronous Abort" handler, esr 0x02000000
ELR:     8000000
LR:      fffc5adc
x0 : 0000000008000000 x1 : 0000000000000000
x2 : 0000000000000011 x3 : 0000000000000020
x4 : 00000000ffffffff x5 : 0000000000000000
x6 : ffffff80ffffffc8 x7 : 000000000000000f
x8 : 00000000ffff7cb0 x9 : 0000000000000080
x10: 00000000ffff7514 x11: 0000000000000000
x12: 00000000ffffffff x13: 00000000ffffffff
x14: 00000000ffff7d7c x15: 00000000fffd05f0
x16: 00000000fd40ec40 x17: 1107993141004008
x18: 00000000ffff7e80 x19: 0000000000000000
x20: 00000000fffd7d18 x21: 0000000000000000
x22: 00000000fffd7cc8 x23: 0000000000000000
x24: 00000000deadbeef x25: 0000000000000000
x26: 0000000000000000 x27: 518c0322c9520041
x28: 08600122e0820a09 x29: 00000000ffff7de0

Resetting CPU ...

resetting ...
"Synchronous Abort" handler, esr 0x5e000000
ELR:     fffc1510
LR:      ffff7a80
x0 : 0000000084000009 x1 : 00000000ffff7aa0
x2 : 00000000fffcc72c x3 : 00000000ffff7ac0

Full output here: http://pastebin.ca/3784921
==========================================================================

3. Use xilinx tools to create a naked FSBL.elf with ONLY the hdf as an input (i.e. no file coming from yocto). This FSBL would load u-boot.img from the SD card first partition and boot would continue on using only yocto made artifacts. I just don't have clear instructions on how to do this. The xilinx wiki suggests that the u-boot.img, device tree and kernel image be bundled into the boot.bin using bootgen tool. This would create a circular flow of build artifacts and is not viable for me. If you could please use detailed instructions/cmd-line examples, specific versions, etc.  I am confused enough already! ;-P

> On Mar 21, 2017, at 11:33, Michal Simek <michal.simek at xilinx.com> wrote:
> 
> the latest pmufw requires configuration object to be passed. This blob
> is generated based on configuration data. Default object is not the part
> of pmufw and not sure when this will be there.

Do you agree that we need support for current zcu102 users? Anything to get us to linux until this low level stuff is worked out.

> 
> If meta-xilinx is using SPL then I expect yes it is broken.

This is quite disturbing in the community. As I just worded above, we need to fill the gap while things are repaired. And I don't know how to fix it!

> 
> I have it for sure. Unfortunately the whole things I have are based on
> unofficial trees and I don't know what it is inside and what can be
> shared. SPL is not the part of xilinx support that's why I don't think
> you are able to get this via any early-access license, version or so.

If I can't get away without 0.3, can you send something (a temporary branch, or sent to me personnally if that's possible) as a quick fix, even if not fully working, so I/we can get unstuck?

Regards!
/jfd