![]() ![]() 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.Ĭommunity workflow booting, so far: the configuration object is hard-coded in the PMUFW 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. 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. Besides the ones I showed, one can also perform U-Boot update or write sophisticated scripts to decide how to perform the boot process, which is especially handy during development.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. To sum up, U-Boot gives a lot of options to boot the RPi. Scripts themselves can also be downloaded via tftp: usb start $ mkimage -A arm -O linux -T script -C none -n update.scr -d update.scr $ mkimage -A arm -O linux -T script -C none -n boot.scr -d boot.scr In order to boot Linux, the following needs to be done: mmc dev 0įatload mmc 0:1 $ Interrupting the autoboot will give access to command line interface. After that it will either search for a start script or try to setup network interfaces and boot from network. U-Boot waits 3 seconds for the user to interrupt the autoboot. ** Unable to read "uboot.env" from mmc0:1 ** Powering up the RPi with serial console attached gives this result: U-Boot 2016.01 (14:55:52 +0200) Also, in config.txt, which is also on the boot partition, change: kernel=zImage Now the SD card needs to be mounted and the U-Boot binary should be copied to boot partition. After exiting config, run: $ make allĪfter compiling, Buildroot puts u-boot.bin in output/images. U-Boot board name shows up, and needs to be set to rpi. Use Buildroot to compile U-Boot: $ make nconfig I will use U-Boot, and show how to step by step migrate to a more customizable bootloader.Ĭheck how to start with Buildroot and Raspberry Pi first. Although, there is a possibility to have the root file system booted from network with the stock firmware (actually the kernel allows that), lets look at an interesting alternative. The GPU executes bootcode.bin, the second bootloader, which in the end runs the kernel. The first one resides in built-in ROM and is responsible for starting the GPU. Raspberry Pi has a fairly complicated boot process with two bootloaders. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |