Dear Scott Wood,
On 02/25/2013 03:10:35 PM, Marek Vasut wrote:
Dear Scott Wood,
On 02/25/2013 12:19:54 PM, Marek Vasut wrote:
+$(obj)u-boot.nand: $(obj)u-boot.bin depend
if [ "X$(CONFIG_NAND_TRG_PATH)X" = "XX" ] ;then \
echo "This CPU does not support u-boot.nandtarget!" ; \
exit 1; \
fi$(MAKE) -C $(CONFIG_NAND_TRG_PATH) $(obj)u-boot.nandWe already have CONFIG_SPL_TARGET. Why do we need a new mechanism specific to NAND, with ifdefs in the main Makefile?
This board doesn't use SPL at all.
So maybe we need a more general (but optional) CONFIG_BUILD_TARGET.
Can you elaborate?
If we do have something specific to NAND, it should be
u-boot-nand.bin
to match what nand_spl produced, and it should just be a generic
rule
that links to what CONFIG_SPL_TARGET produced, if the right CONFIG symbol is set by the board config to say that this is a NAND SPL.
Or
is someone going to say that they want to generate multiple
different
SPL images from the same build? :-P
I'd like to generate a bootable NAND image on mx53 and on mx23/28,
From the same build, or just in general?
What do you mean by 'from the same build' ? From a build for the particular board running the SOC=mxs .
thus I need generic target. And I need it flexible enough, since on mx23/28 it munges u- boot.sb into the resulting image while on mx53 it munges u-boot.imx into the resulting image.
So each one would set the appropriate CONFIG_BUILD_TARGET for whatever needs to get built, and then something like CONFIG_NAND_IMAGE could hold the image name that should be linked to produce a standard u-boot-nand.bin output.
Yea, sounds reasonable. But why call it CONFIG_ , it can't be stored in the board.h files, it has to be somewhere in the Makefile hierarchy.
-Scott
Best regards, Marek Vasut