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. g. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot