On Tue, Jun 7, 2011 at 3:19 PM, Wolfgang Denk <w...@denx.de> wrote: >> Perhaps having a CONFIG_TARGET_IMAGE available and having just one >> generic TARGET available? >> >> ifdef CONFIG_TARGET_IMAGE >> ALL += $(CONFIG_TARGET_IMAGE) >> endif >> >> TARGET_IMAGE_OBJS-y += various.bin >> TARGET_IMAGE_OBJS-y += required.bin >> TARGET_IMAGE_OBJS-y += blobs.bin >> >> $(obj)$(CONFIG_TARGET_IMAGE): $(TARGET_IMAGE_OBJS-y) >> cat $(TARGET_IMAGE_OBJS-y) > $(obj)$(CONFIG_TARGET_IMAGE) > > THis will probably not work, as different images may require different > levels of alignment / padding. Also, some architectures require more > fancy image building capabilities (provided for example by the mkimage > tool).
It works for the images in the Makefile currently, but in the future more complicated and board specific targets could live in board/arch/cpu specific files that are included into the top level makefile. sinclude $(obj)arch/$(ARCH)/Makefile.targets sinclude $(obj)arch/$(ARCH)/cpu/$(CPU)/Makefile.targets In fact we could move all image creation (besides u-boot.bin) out to the files and clean out the top level makefile. > >> > Do we really need all this in the top level Makefile? >> >> I'm not sure there is a great way around this. I played around with >> trying to include them in the config.mk or a board/cpu/arch Makefile >> (I'll admit my lack of Makefile mastery here) but what seems to work >> best is something like this to add "other" targets that don't need to >> reside in the top level Makefile. This is best because targets depend >> on things in the toplevel Makefile. > > I think we should step back a bit. Assume I forgot everything I've > read so far, and try to explain me in simple words (completely > independent from your suggested implementation) what exactly you want > to do. I think my other reply to your email on patch 2/4 should provide a good summary on what I am trying to accomplish. > >> >> cat << EOF >> config.h >> >> +#define CONFIG_BOARD_NAME $BOARD_NAME >> >> #define CONFIG_BOARDDIR board/$BOARDDIR >> >> #include <config_cmd_defaults.h> >> >> #include <config_defaults.h> >> > >> > NAK. This breaks existing code, also it should not be needed. >> >> How does this break existing code? Because a specific board might also >> defined this? I can drop it and add it to the board config file > > Not might, bot actually does. Still not sure how this is breaking anything. Can you point me at a build that fails? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
