Dear McClintock Matthew-B29882,
In message BANLkTikgy1nw8rwrk=ex6N9oVSfAfhEgZQ@mail.gmail.com you 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).
I doubt you always need all these images. If you need u-boot-sd.bin, then just type "make u-boot-sd.bin".
We choose these targets by adding a config line in boards.cfg. We don't build them unless we do a make BOARD_{NAND,SDCARD,SPIFLASH}. We
Ok, so you do run individual builds for one selected image type each. This is IMHO OK.
could optionally just require the user to type out the target manually
What's the difference? Writing "make BOARD_{NAND,SDCARD,SPIFLASH}" is typing out the target manually, isn't it?
or do what I mentioned above however, I strongly believe these images should always be built as we don't want end user confusion about which image to program.
In which way would that prevent any confusion? In any case you have to know which image you want to program. It's poretty much the same to me if I have to select a name from a list of images that resault from a "make" run, or if I select a name from a list of possible make target names. Actually, the latter seems more logical to me.
+NAND_SPL_OBJS-y += $(obj)nand_spl/u-boot-spl-16k.bin +NAND_SPL_OBJS-$(CONFIG_BOOTSTRAP) += $(obj)u-boot-bootstrap.bin +NAND_SPL_OBJS-y += $(obj)u-boot.bin
This looks pretty much board specific to me. I doubt all boards can use u-boot-spl-16k.bin here.
This u-boot-spl-16k.bin reference has been here before this patch. It
Yes, I know.
is typically just the u-boot-nand image to be used and not actually required to be 16k. It could probably be updated to just be u-boot-spl.bin except that for some boards this is not the right image. Usually the 16k one points at the right image.
In general, it's wrong and should be fixed.
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.
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.
instead, but it seemed easier to programmatically do this so one target can build another target. This combined with the previous patch lets one build invoke another build (then we can add an additional option via EXTRA_OPTS from the previous patch)
All this is way too obscure to me. I fail to see what you are trying to acchieve.
Best regards,
Wolfgang Denk