[U-Boot] [PATCH 3/4] nand_spl/spiboot/sdboot: Add ability to have smaller middle loader

[McClintock Matthew-B29882]

On Tue, Jun 7, 2011 at 3:19 PM, Wolfgang Denk <wd at 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?