![]() Cortex®-A53 is used for SW application on a baremetal environment. I'm involved in a project using ZYNQ UltraScale + MPSoC architecture. (read the original article at /zynqmp-uboot-spl-pmufw-cfg-load/) Together these two patches will allow a better booting process for ZynqMP users wanting to use U-Boot SPL, automating the whole building process in their buildsystem from mainline U-Boot and their pm_cfg_obj.c file to bootable images. U boot spl Patch#A patch adding this tool to U-Boot has been accepted together with the first one. In order to convert the file to the proper format I also wrote a tool that automates the process. The C file produced by the Xilinx tools is not directly usable by U-Boot SPL. However note that the configuration object file must be in binary format. Leaving the variable empty will leave the old behavior, which can still be used as before. It will be automatically linked in U-Boot SPL and loaded during board initialization. ![]() Using this new booting process is simple: just set the ZYNQMP_SPL_PM_CFG_OBJ_FILE configuration variable to the location of your configuration object. It should be merged in mainline U-Boot version 2019.10. It took a few iterations to have it in a good shape, and finally the maintainer Michal Simek accepted it at its fifth iterations a few days ago. I sent a patch with this new feature to the U-Boot mailing list. Patching the PMU firmware to hard-code its configuration will not be needed anymore. Only U-Boot SPL will need to be rebuilt to use a different configuration object. A single PMU firmware binary image can be used to boot any ZynqMP board. With this feature in U-Boot SPL there is no more need for a different PMU firmware binary for each different board configuration. With these changes U-Boot SPL now behaves like FSBL. SPL then uses the mailbox in board_init() to send the configuration object to the PMU firmware. U boot spl code#I studied the protocol mostly in the FSBL and ARM Trusted Firmware source code and came up with a simple implementation that is enough for the SPL needs. The communication between the ARM core where SPL runs and the PMU happens via a mailbox. These increasing difficulties triggered me to try and solve the problem at its very root: the inability of U-Boot SPL to load the configuration object into the PMU firmware at runtime, like the FSBL does.Īnd it turned out not to be that complex in the end. This has been a good cleanup, but with an unwanted side-effect: now it is impossible to build two different PMU firmware binaries for two different MACHINEs. Now there are two different configurations: a Microblaze one to build the PMU firmware and an ARM64 one to build all the rest. That hack has been removed from meta-xilinx Thud and replaced with a multiconfig-based setup. In previous versions there was a hack to build a (Microblaze) PMU firmware within an ARM64 build. ![]() The problem got worse with the Yocto 2.6 (Thud) version of meta-xilinx. They have had a hard time in discovering they need to patch the pmu-firmware in their own layer to be able to boot. Many newcomers of ZynqMP have downloaded meta-xilinx, followed its instructions and come up with a non-booting board. ![]() The mentioned patch has never been included in the meta-xilinx Yocto layer. ![]() It also makes it impossible to change the configuration after boot. This approach works but has drawbacks: among others, it forces to use a different PMUFW binary for each hardware and hardware configuration. The best workaround for U-Boot SPL users is to apply a patch to the PMUFW itself to have the configuration object built-in and self-load it. FSBL is generated with a built-in configuration object, and passes it to the PMUFW at runtime before jumping to ATF and U-Boot proper. When using the workflow supported by Xilinx, the Xilinx FSBL (First Stage Bootloader) has a role similar to the U-Boot SPL: initializing DDR an other low-level setups, then loading ATF and U-Boot proper. It is design-specific, so it has to be regenerated when the design is modified. U boot spl how to#The Platform Management Unit (PMU) needs a configuration object to know how to operate the SoC: which power domains to enable, which peripherals should be accessible by each CPU core, etc.Ī configuration object is produced by the Xilinx tools in the form of a C file (pm_cfg_obj.c), which contains values to be passed at runtime to the PMU firmware. A recent patch to U-Boot addresses the problem at its root. A long-standing issue in the ZynqMP users community has been the loading of a PMU firmware configuration object when U-Boot SPL is used. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |