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

Jean-Francois Dagenais jeff.dagenais at gmail.com
Mon Mar 20 13:29:06 PDT 2017

Hi guys,

I am really riding the bleeding edge here...

> On Mar 17, 2017, at 13:37, Nathan Rossi <nathan at nathanrossi.com> wrote:
> Not alternate, since given the error you have not loaded any pmu
> firmware. But yes, this is only relevant because you are using
> u-boot-xlnx master.
> The commit that introduced the requirement is
> https://github.com/Xilinx/u-boot-xlnx/commit/e047c5ad3db3cc2fa8c53a4a663ac8a256159b0e

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

>> And did you just misprint "xilinx-v2016.4 kernel" instead of "u-boot"?
> Well I was not sure if you were also using the master branch of
> linux-xlnx or not, but linux-xlnx master has the same requirements for
>> Did you mean I should use u-boot (upstream) instead of u-boot-xlnx?
> No you will want to use u-boot-xlnx at the moment. But Michal might be
> able to give you a better status on using zcu102 with upstream u-boot.

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

>> I'm no expert on u-boot (yet ;) but I think this smells trouble. Maybe not for
>> meta-xilinx supported builds, but for integrators such as myself and all the
>> other OEMs which will use meta-xilinx as a base.
>> I understand about an SPL-less build. Perhaps the Makefile could inspect
>> CONFIG_SPL_BUILD and fail if the psu_init_gpl files aren't found. You don't get
>> very far with a "psu_init"-less SPL, but much better if failure occurs at build
>> time. I can can attempt a patch in board/xilinx/zynqmp/Makefile unless you think
>> its a bad idea.
> I think its probably a good idea to have it fail if the ps*_init files
> are missing, this probably would apply to zynq as well. But this is
> something that would best be discussed on the u-boot list? or maybe
> Michal can chime in here too?
>> My first tries were with u-boot-xlnx (v2016.4) and the SPL almost didn't start
>> at all. It may be related to 7d355473f34a (mmc: sdhci: zynqmp: Add support of
>> SD3.0) not being there yet. I did not try exactly your idea though. I will get
>> to it soon if nothing else works.
>> Can I not change something in the defconfig to remove the extra PMUFW dependency?
> You might be able to hack around it, but I wouldn't recommend going
> down that path.
Ok, so, after fooling around a bit more, here's where I am (note: at this point
I am improvising a bit, learning a lot, but need to converge soon on something
stable for the next early phases of our development...)

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

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

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

Here's the output...
<debug_uart> Debug uart enabled

U-Boot SPL 2017.01-03253-g9c9291d-dirty (Mar 20 2017 - 15:52:02)
EL Level:	EL3
Trying to boot from MMC1
reading u-boot.bin
reading atf-uboot.ub
reading atf-uboot.ub
NOTICE:  ATF running on XCZU9EG/silicon v3/RTL5.1 at 0xfffea000, with PMU firmware
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.2(release):a9e3716
NOTICE:  BL31: Built : 16:41:21, Mar  9 2017
PMUFW: PmGetApiVersion: version 0.2
PMUFW:	v0.2
PMUFW version error. Expected: v0.3

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

So I am happy that it's no longer my fault! ;) But not much farther in terms of
the boot process.

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

Basically, we have incoherent repo progress here.

So please advise, I was under the impression that I needed recent commits in
u-boot-xlnx related to SD for booting on it. Should I use another specific
version of u-boot-xlnx? Again, just want to get past all that and execute the
kernel so the rest of the teams can progress.

Thanks for the help!

More information about the meta-xilinx mailing list