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

Michal Simek michal.simek at xilinx.com
Tue Mar 21 01:59:45 PDT 2017

On 20.3.2017 21:29, Jean-Francois Dagenais wrote:
> 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)

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

>>> And did you just misprint "xilinx-v2016.4 kernel" instead of "u-boot"?
>> Well I was not sure if you were also using the master branch of
>> linux-xlnx or not, but linux-xlnx master has the same requirements for
>>> Did you mean I should use u-boot (upstream) instead of u-boot-xlnx?
>> No you will want to use u-boot-xlnx at the moment. But Michal might be
>> able to give you a better status on using zcu102 with upstream u-boot.
> Thanks! Hope to hear from Michal soon! I think it's a good idea to provide an
> alternate path at this point. This would help us developers move along while
> this very low-level stuff evolves. I'll happily volunteer to test when things
> appear on the master branches of meta-xilinx, u-boot-xlnx and linux-xlnx.

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

>>> I'm no expert on u-boot (yet ;) but I think this smells trouble. Maybe not for
>>> meta-xilinx supported builds, but for integrators such as myself and all the
>>> other OEMs which will use meta-xilinx as a base.
>>> I understand about an SPL-less build. Perhaps the Makefile could inspect
>>> CONFIG_SPL_BUILD and fail if the psu_init_gpl files aren't found. You don't get
>>> very far with a "psu_init"-less SPL, but much better if failure occurs at build
>>> time. I can can attempt a patch in board/xilinx/zynqmp/Makefile unless you think
>>> its a bad idea.
>> I think its probably a good idea to have it fail if the ps*_init files
>> are missing, this probably would apply to zynq as well. But this is
>> something that would best be discussed on the u-boot list? or maybe
>> Michal can chime in here too?
>>> My first tries were with u-boot-xlnx (v2016.4) and the SPL almost didn't start
>>> at all. It may be related to 7d355473f34a (mmc: sdhci: zynqmp: Add support of
>>> SD3.0) not being there yet. I did not try exactly your idea though. I will get
>>> to it soon if nothing else works.
>>> Can I not change something in the defconfig to remove the extra PMUFW dependency?
>> You might be able to hack around it, but I wouldn't recommend going
>> down that path.
> Ok, so, after fooling around a bit more, here's where I am (note: at this point
> I am improvising a bit, learning a lot, but need to converge soon on something
> stable for the next early phases of our development...)
> I am aiming for a pmufw.bin as a binary blob for the moment. So I sourced the
> Vivado 2016.4 settings64.sh. Then cloned
> https://github.com/Xilinx/embeddedsw.git . Using the master branch, I generated
> the pmufw "executable.elf". Using a MACHINE=ml605-qemu-microblazeel bitbake gcc"
> built objcopy, I generated pmufw.bin which I injected into u-boot-xlnx-dev.bb
> using:
> SRC_URI += "\ file://add-pmufw-to-zcu102-defconfig.patch \
> file://pmufw.bin;subdir=git/board/xilinx/zynqmp \ "
> The .patch adds CONFIG_PMUFW_INIT_FILE="board/xilinx/zynqmp/pmufw.bin" to
> xilinx_zynqmp_zcu102_rev1.0_defconfig . I successfully created a "boot.bin" with
> the PMUFW! Yay!
> Here's the output...
> <debug_uart> 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.

I am no pmufw maintainer to tell you more about 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.

It was my decision to check pmufw version because so many people were
using older/ancient pmufw which missed a lot of important features
that's why we enforced version checking.

You should use fsbl which contain all stuff you need. SPL is not
officially supported boot solution.


More information about the meta-xilinx mailing list