[U-Boot] [PATCH v3 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

[Grant Likely]

On Thu, Oct 13, 2011 at 3:50 PM, Stephen Warren <swarren at nvidia.com> wrote:
> Simon Glass wrote at Thursday, October 13, 2011 3:25 PM:
>> Hi Stephen,
>>
>> On Thu, Oct 13, 2011 at 2:21 PM, Stephen Warren <swarren at nvidia.com> wrote:
>> > Simon Glass wrote at Tuesday, October 11, 2011 4:26 PM:
>> >> This new option allows U-Boot to embed a binary device tree into its image
>> >> to allow run-time control of peripherals. This device tree is for U-Boot's
>> >> own use and is not necessarily the same one as is passed to the kernel.
>> >>
>> >> The device tree compiler output should be placed in the $(obj)
>> >> rooted tree. Since $(OBJCOPY) insists on adding the path to the
>> >> generated symbol names, to ensure consistency it should be
>> >> invoked from the directory where the .dtb file is located and
>> >> given the input file name without the path.
>> > ...
>> >> +process_lds = \
>> >> +     $(1) | sed -r -n 's/^OUTPUT_$(2)[ ("]*([^")]*).*/\1/p'
>> >> +
>> >> +# Run the compiler and get the link script from the linker
>> >> +GET_LDS = $(CC) $(CFLAGS) $(LDFLAGS) -Wl,--verbose 2>&1
>> >> +
>> >> +$(obj)dt.o: $(DT_BIN)
>> >> +     # We want the output format and arch.
>> >> +     # We also hope to win a prize for ugliest Makefile / shell interaction
>> >> +     # We look in the LDSCRIPT first.
>> >> +     # Then try the linker which should give us the answer.
>> >> +     # Then check it worked.
>> >> +     oformat=`$(call process_lds,cat $(LDSCRIPT),FORMAT)` ;\
>> >> +     oarch=`$(call process_lds,cat $(LDSCRIPT),ARCH)` ;\
>> >> +     \
>> >> +     [ -z $${oformat} ] && \
>> >> +             oformat=`$(call process_lds,$(GET_LDS),FORMAT)` ;\
>> >> +     [ -z $${oarch} ] && \
>> >> +             oarch=`$(call process_lds,$(GET_LDS),ARCH)` ;\
>> >> +     \
>> >> +     [ -z $${oformat} ] && \
>> >> +             echo "Cannot read OUTPUT_FORMAT from lds file $(LDSCRIPT)" && \
>> >> +             exit 1 || true ;\
>> >> +     [ -z $${oarch} ] && \
>> >> +             echo "Cannot read OUTPUT_ARCH from lds file $(LDSCRIPT)" && \
>> >> +             exit 1 || true ;\
>> >> +     \
>> >> +     cd $(dir ${DT_BIN}) && \
>> >> +     $(OBJCOPY) -I binary -O $${oformat} -B $${oarch} \
>> >> +             $(notdir ${DT_BIN}) $@
>> >> +     rm $(DT_BIN)
>> >
>> > Instead of all that, can't you just run a trivial script to generate a .c
>> > file containing the data from DTB_BIN, and then use the compiler to compile
>> > that, i.e. spit out something like:
>> >
>> > const unsigned char dtb[] = {
>> >  0xaa, 0x55, ......
>> > };
>> >
>> > That'd certainly drastically simplify the makefile, although waste a little
>> > more time and temp disk space.
>>
>> What, and withdraw my Makefile contest entry? :-)
>
> :-)
>
>> I feel that objcopy is designed to do exactly this, and generating C
>> code is a roundabout way of producing an object file with data in it.
>> The difficulty of finding out the output format/architecture is
>> something we might clean up in U-Boot generally at some point (e.g.
>> figure it out as part of the original 'make ..._config') in which case
>> this would all go away.
>>
>> Thoughts?
>
> Looking some more, dtc has option "-O asm" which writes directly to a text
> file that can be assembled; there'd be no extra temp files or conversions
> if you used that.

I recommend *not* using the asm output option.  It's not nearly as
well tested and it is likely to have some big-endian-isms in it that
don't work well.  I prefer the objcopy approach myself.  That's what
it is for.

g.