ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
ALL-$(CONFIG_MMC_U_BOOT) += $(obj)mmc_spl/u-boot-mmc-spl.bin
ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
+ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
all: $(ALL-y) $(SUBDIR_EXAMPLES)
+$(obj)u-boot.dtb: $(obj)u-boot
+ $(MAKE) -C dts binary
+ mv $(obj)dts/dt.dtb $@
+
+$(obj)u-boot-dtb.bin: $(obj)u-boot.bin $(obj)u-boot.dtb
+ cat $^ >$@
+
$(obj)u-boot.hex: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O ihex $< $@
experimental and only available on a few boards. The device
tree is available in the global data as gd->fdt_blob.
- U-Boot needs to get its device tree from somewhere. At present
- the only way is to embed it in the image with CONFIG_OF_EMBED.
+ U-Boot needs to get its device tree from somewhere. This can
+ be done using one of the two options below:
CONFIG_OF_EMBED
If this variable is defined, U-Boot will embed a device tree
is then picked up in board_init_f() and made available through
the global data structure as gd->blob.
+ CONFIG_OF_SEPARATE
+ If this variable is defined, U-Boot will build a device tree
+ binary. It will be called u-boot.dtb. Architecture-specific
+ code will locate it at run-time. Generally this works by:
+
+ cat u-boot.bin u-boot.dtb >image.bin
+
+ and in fact, U-Boot does this for you, creating a file called
+ u-boot-dtb.bin which is useful in the common case. You can
+ still use the individual files if you need something more
+ exotic.
+
- Watchdog:
CONFIG_WATCHDOG
If this variable is defined, it enables watchdog