Hi Scott, On 23/01/19 17:06, Scott Ellis wrote: > 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.
Yes, this kind of workflow used to work fine before meta-xilinx-standalone was introduced. One could have a recipe in its own user layer providing a different pm_cfg_obj.c for each MACHINE plus a bbappend to tell pmu-firmware how to fetch that file. Now it is not quite possible anymore. This was discussed in this mailing list, in the end [0] Manjukumar proposed a workaround (one pmutmp per board/config) which might help somewhat. > That seemed like a reasonable idea to me. > > The pmu-firmware recipe as is doesn't seem too useful without these two > items. ...without those two items _or_ a runtime cfg_obj loading system. > 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. I don't think you can do anything with these SoCs without configuring the PMU. > But the multiconfig instructions imply that the layers should just work. I also think following a readme should lead to a booting image. But it doesn't seem to be the case here. > 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. I'm not advocating for any of the two methods, but also runtime loading has advantages, and doesn't perceivably increase boot time. [0] https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004182.html Regards, -- Luca -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
