The GPU also handles the “bootargs” (kernel command line arguments), which is an amalgamation of the contents in cmdline.txt and board-specific settings. Even if U-Boot could do the same (which, at the time of writing, it can’t), that would be doubling up on the effort. However, on the Raspberry we don’t really want to do this, since the GPU has already loaded not just the main DTB, but also fragments from HATs and/or other fragments specified in the config.txt file. U-Boot also has built-in support for loading FDTs, or rather DTBs (Device Tree Blobs) which are the binary versions of the FDTs. It’s a pretty simple concept, though the implementation details can get a bit fiddly. If the system is rebooted again, the U-Boot boot script then makes the decision whether to keep booting the new version, or whether to fall back to the previous version. The boot loader, U-Boot in this case, is then responsible for picking that partition (and kernel) next time, and also note whether it was successful, based on some chosen metric.
#U BOOT BOOTARGS UPGRADE#
During an upgrade the new version gets written to the inactive partition, and a flag is set for the boot loader to indicate that this partition should be attempted at the next boot. In the typical case the system has two OS partitions, A & B, each of which can boot & run the system but only one is “active”. The latter is of tremendous importance for unattended systems to support safe remote upgrades. On a Pi the GPU already takes care of the necessary low-level hardware initialisation, but it does not provide a way to implement conditional boot selection. It’s quite commonly used in embedded systems, both for initial hardware setup and for choosing which kernel/partition to boot. So, FDT is a really good thing.Īnother really useful thing is the U-Boot boot loader.
#U BOOT BOOTARGS DRIVER#
This is especially handy when using HATs, since they can have an FDT fragment stored in their eeprom which is then overlaid onto the main FDT, effectively providing automatic driver configuration. The main benefit of using FDT is that it allows for easy addition or changing of hardware, without having to try to load every possible driver under the sun. FDT isn’t a new thing as such, having been around as part of the Open Firmware specification for quite some time. With the introduction of the Raspberry Pi HATs (Hardware Attached on Top) there has been a push to support FDT (Flattened Device Tree) on the Pi for describing the actual hardware configuration.
0 kommentar(er)
