On Wed, Mar 21, 2012 at 5:54 PM, Tom Rini trini@ti.com wrote:
On Wed, Mar 21, 2012 at 05:46:38PM -0400, jonsmirl@gmail.com wrote:
On Wed, Mar 21, 2012 at 5:38 PM, Tom Rini trini@ti.com wrote:
On Wed, Mar 21, 2012 at 10:32:39AM -0400, jonsmirl@gmail.com wrote:
If you make u-boot.img it doesn't also make in the SPL directory. Can this get fixed before the next release?
Can you elaborate? ?This is working fine for folks as far as we can tell. ?If doing a brand new (sub)arch you may need things similar to arch/arm/cpu/armv7/omap3/config.mk
Nothing is broken, it is just inconvenient.
Do 'make' it builds u-boot.bin and spl/u-boot-spl.bin
Do 'make u-boot.img' it builds u-boot.bin and u-boot.img, but not spl/u-boot-spl.bin
In our case we are concatenating spl/u-boot-spl.bin and u-boot.img and we need the img header to know the length of the attached u-boot.
Maybe just add u-boot.img to the default make targets? Otherwise I need to teach people to do 'make u-boot.img spl/u-boot-spl.bin'.
That is not the behavior I see right now with omap3_beagle, for example. It gives me u-boot.img and MLO (along with u-boot.bin and spl/u-boot-spl.bin), both with and without O=. That's why I suggested looking at the file I said because that's what controls making u-boot.img be an always built target, for omap3 boards with SPL.
I get it now. I added this to my config.mk. Thanks for the tip.
ifndef CONFIG_SPL_BUILD ALL-y += $(obj)u-boot.img endif