[meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards

[Scott Ellis]

Hi Luca,

What you describe is how I understand things.

And I do have a booting system using the patch to the pmu-firmware and a
pm_cfg_obj.c the customer provided.

And I have also used a boot.bin produced by the xilinx tools by the
customer with fsbl, pmu, etc... embedded. And that works fine too.

I think I get the gist of things.

What I am confused about is the usefulness of the meta-xilinx-standalone
layer and the pmu-firmware in particular without patches.

I don't think the license on the xilinx tool generated pm_cfg_obj.c
matters too much.

I wasn't suggesting the pm_cfg_obj.c be included in the layer since
every board probably needs it's own version anyway.

I was just asking about the patch to pm_binding.c to load an internal
config object. Shouldn't this be included?

I think it was you that suggested that the pmu-firmware recipe or
another new recipe could go out and fetch the pm_cfg_obj.c file from
somewhere else before the pmu-firmware compile step.

That seemed like a reasonable idea to me.

The pmu-firmware recipe as is doesn't seem too useful without these two
items.

But again I am new to these boards, maybe there is a bare-metal use for
the PMU firmware that does not require a config object.

But the multiconfig instructions imply that the layers should just work.

As for u-boot SPL unable to load a cfg object to the PMU, I started to
look at implementing that. SPL does already talk to the PMU, it
retrieves the PMU fw version for example.

But I stopped since it seems silly.

If I have the cfg object at build time, why not just build it into the
pmu-firmware as you do with the patch and skip the runtime loading at
every boot.

Regards,
Scott