[Buildroot] [PATCH v3] Add support for Flattened Image Trees

Yegor Yefremov yegorslists at googlemail.com
Mon Sep 22 12:56:57 UTC 2014


On Thu, Sep 18, 2014 at 10:44 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Dear Yegor Yefremov,
>
> On Thu, 18 Sep 2014 22:13:44 +0200, Yegor Yefremov wrote:
>
>> +config BR2_FIT_PATH
>> +     string "Flattened Image Tree source file path"
>> +     help
>> +       Path to the image tree source files.
>
> Which files will typically be listed here? Apparently your code assumes
> those files must all be located in $(BINARIES_DIR), right? If that's
> the case, it should be mentioned here.

*.its files can be anywhere, but will be copied to $(BINARIES_DIR) to
overcome mkimage/dtb compiler path issues (mkimage invokes dtb
compiler at *.its location, so working directory changes).

> Also, I'm worried about ordering: there is no ordering guarantee
> between filesystem image types. So if your FIT filesystem image logic
> depends on another filesystem image to be generated, this might be an
> issue.

This is the crucial moment. For me there are basically following cases:

1.  create an image consisting of zImage + DTB and install it to boot
- in this case FIT must be invoked before file system packaging
2. create an image having cpio inside - in this case FIT must be the
last action taken in fs stuff or at least after cpio archive is
packaged
3. create an image with appended cpio as initramfs - in this case FIT
must be invoked after cpio is embedded into kernel

What would be the best strategy to implement these cases?

> Also you say "files" in the description, but your code doesn't seem to
> handle multiple "files". Can you explain?

See v4

>> +ifeq ($(BR2_FIT_INSTALL_TARGET),y)
>> +define ROOTFS_FIT_CMD
>> +     cp $(BR2_FIT_PATH) $(BINARIES_DIR) && \
>> +     $(HOST_DIR)/usr/bin/mkimage -f $(BINARIES_DIR)/$(notdir $(call qstrip,$(BR2_FIT_PATH))) $(BINARIES_DIR)/$(basename $(notdir $(call qstrip,$(BR2_FIT_PATH)))).itb && \
>> +     mkdir -p $(TARGET_DIR)/boot/ && \
>> +     cp $(BINARIES_DIR)/$(basename $(notdir $(call qstrip,$(BR2_FIT_PATH)))).itb $(TARGET_DIR)/boot/
>> +endef
>> +else
>> +define ROOTFS_FIT_CMD
>> +     cp $(BR2_FIT_PATH) $(BINARIES_DIR) && \
>> +     $(HOST_DIR)/usr/bin/mkimage -f $(BINARIES_DIR)/$(notdir $(call qstrip,$(BR2_FIT_PATH))) $(BINARIES_DIR)/$(basename $(notdir $(call qstrip,$(BR2_FIT_PATH)))).itb
>> +endef
>> +endif
>
> Avoid duplication:
>
> ROOTFS_FIT_FILE = $(BINARIES_DIR)/$(notdir $(call qstrip,$(BR2_FIT_PATH)))
> ROOTFS_FIT_ITB_PATH = $(ROOTFS_FIT_FILE).itb
>
> ifeq ($(BR2_FIT_INSTALL_TARGET),y)
> define ROOTFS_FIT_INSTALL_TARGET
>         mkdir -p $(TARGET_DIR)/boot && cp $(ROOTFS_FIT_ITB_PATH) $(TARGET_DIR)/boot
> endef
> else
> define ROOTFS_FIT_INSTALL_TARGET
>         true
> endef
> endif
>
> define ROOTFS_FIT_CMD
>         cp $(BR2_FIT_PATH) $(BINARIES_DIR) && \
>         $(HOST_DIR)/usr/bin/mkimage -f $(ROOTFS_FILE_FILE) $(ROOTFS_FIT_ITB_PATH) && \
>         $(ROOTFS_FIT_INSTALL_TARGET)
> endef

Fixed so far in v4.

> But maybe we should change the ROOTFS_TARGET infrastructure to support
> multiple commands. There's also maybe the ROOTFS_xyz_POST_TARGETS
> mechanism that could be used (I haven't looked whether it applies
> properly here).
>
> Can you give an example for the various Config.in options, so that
> others could test this and understand better how it's typically used?

I think now the approach is straight forward: you specify one or more
*.its files and you get *.itb files. The only option so far is to
install *.itbs into /boot/ or not.

Yegor



More information about the buildroot mailing list