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