Hi Grant,
On Fri, Oct 14, 2011 at 10:46 PM, Grant Likely
<grant.lik...@secretlab.ca> wrote:
> On Thu, Oct 13, 2011 at 3:50 PM, Stephen Warren <swar...@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 <swar...@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.
Oh dear that sounds bad. The difficultly is in figuring out the
arguments to objcopy (architecture and oformat). But we do need it to
work reliably, so I will move back to the original approach for now.
Regards,
Simon
>
> g.
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
