You can see that we’ve added a load/entry address to the device tree sub-image to ensure that it is aligned correctly. You can find more information about the supported properties and nodes here. kernel, flat_dt, ramdisk), information on the compression used (so that U-Boot can decompress) and hash information (such that U-Boot can perform verification). Each of the ‘images’ sub-nodes have some common properties including a type (e.g. The sub-nodes of the ‘images’ node describes the individual binaries and make use of the /incbin/ directive to include those binaries. Let’s try this out by creating an image tree source file (.its): /dts-v1/ ĭescription = "Nitrogen8M i.MX8M FIT Image" ĭata = /incbin/("imx8mq-nitrogen8m.dtb") ĭata = /incbin/("") Īs you can see we use a tree-like structure to describe the binaries that are to be contained in our FIT image. To create a FIT image you create an ‘Image Tree Source’ file (akin to a DTS file) – and pass this to the mkimage command which internally uses the dtc to construct a FIT image (akin to a DTB). Rather than reinvent the wheel the FIT format makes use of the libfdt library and the device tree compiler (dtc) – essentially a FIT image is a device tree blob (DTB) with your binaries embedded inside – but represented in a structure that allows you to provide additional information. This is an example of the lack of flexibility offered by IH_TYPE_MULTI images which resulted in the Flattened uImage Tree (FIT) format being born. In fact, our boot was only successful because we tweaked the address of where we TFTP’d the uImage to until the device tree address inside it lined up. A requirement of ARM64 platforms is that the device tree must be located on an 8 byte boundary – unfortunately IH_TYPE_MULTI images don’t provide any support for specifying a load address or alignment constraints. Unfortunately this approach doesn’t quite provide the flexibility we need. One additional benefit to this approach is that there is now checksum validation for our entire uImage. We now have a single multi-file uImage encapsulating all of our boot binaries. # Flattened Device Tree from multi component Image at 43000004īooting using the fdt at 0x0000000044ff5df0ĮRROR: reserving fdt memory region failed (addr=b8000000 size=400000) # Loading init Ramdisk from multi component Legacy Image at 43000004. # Booting kernel from Legacy Image at 43000004. Notice how we provided multiple binaries separated by colons in the ‘-d’ argument and set the image type as ‘multi’. Image Type: AArch64 Linux Multi-File Image (uncompressed)ĭata Size: 33569915 Bytes = 32783.12 KiB = 32.01 MiB Let’s use the mkimage utility to create an multi-file uImage: $ mkimage -C none -A arm64 -O linux -T multi -a 0x40480000 -e 0x40480000 -d Image.u-boot:imx8mq-nitrogen8m.dtb mImage It’s a little inconvenient and easy to make a mistake.įortunately, the U-Boot community extended their uImage format (typically used for wrapping kernels and ram disks with a header so that U-Boot knew what to do with it) so that it could support multiple binaries ( IH_TYPE_MULTI) in a single uImage. ![]() You’ll also need to make similar considerations if you have an update mechanism or store the binaries in raw flash. With this approach you have to explicitly determine a load address for each component and ensure the binaries don’t overlap in memory. ![]() Let’s start with the typical steps required to TFTP boot Linux on a Nitrogen8M i.MX8M reference board with an initrd. However there is a much better way – in this post we’re going to explore Flattened Image Tree (FIT) Images and show you the benefits of using them. You then invoke a command such as bootm or booti with arguments providing memory addresses for the binaries you’ve just loaded. You’re probably familiar with the steps required to boot Linux from U-Boot: you first load several binaries into memory, perhaps a device tree, a kernel, maybe even an initrd.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |