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

Luca Ceresoli luca at lucaceresoli.net
Wed Nov 20 08:00:49 PST 2019


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


More information about the meta-xilinx mailing list