> On Mar 17, 2017, at 03:16, Nathan Rossi <[email protected]> wrote: > > On 17 March 2017 at 05:27, Jean-Francois Dagenais > <[email protected]> wrote: >> >> >> Is it ok for me not to care about the PMU FW or ATF at this point of our >> development? > > For PMU Firmware, sure you can probably ignore it and use the > xilinx-v2016.4 kernel and u-boot. ATF is needed though since a psci > implementation is needed that can handle cpu bringup.
Ok, help me make sure I understand from having read your whole answer. I only need to provide an alternate (TBD) PMU FW because I am using u-boot-xlnx/master and something was added since u-boot xilinx-v2016.4 that requires it? And did you just misprint "xilinx-v2016.4 kernel" instead of "u-boot"? Did you mean I should use u-boot (upstream) instead of u-boot-xlnx? You can tell I am confused! It'll get better within a few weeks! ;) Until then, please put more info that's not too much trouble. :) > It is ok for the U-Boot build to succeed without a psu_init_gpl, since > it is common to use FSBL as a loader. Which is normally just loading > the full U-Boot so SPL is not needed in that case. But the meta-xilinx > layer does have a hard fail (for zynq at least, but will be for zynqmp > too) if you try to build/deploy SPL (SPL_BINARY = "spl/boot.bin" is > set) and nothing is providing the ps*_init_gpl files. 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. > > On a side note, you should be able to just copy the psu_init_gpl files > from master u-boot-xlnx and use them in the xilinx-v2016.4 version > (which doesn't have the pmufw requirements). 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? > >> >> At this point of our early development, all I want is a command line in >> linux... >> ASAP in order to unlock my hardware department. >> >> I will deal with optimizing the boot and improving the power management, >> secure >> boot and all these low-level subjects later. >> >> Like even the PMU FW, I have the Vivado suite running, I did follow blindly >> some >> instructions to generate the default PMU FW a few weeks ago. If I could hack >> this as a binary blob into my bitbake at this point I would be happy. >> >> What do you recommend? > > If your just trying to bring up a system for development/testing, do > what ever you need to get it working. Since its likely this stuff will > change and or be more polished by the time you need to set it up > properly. Thing is I have no idea what to do next! SD/eMMC support in meta-xilinx seems so rough on zynqmp... I guess I need to fall back to the documentation in order to better understand the whole ATF/PMUFW/Low-level boot process. Thanks for all the help! -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
