[U-Boot] [PATCH 01/14] arm, omap3: Define save_boot_params in lowlevel_init.S for SPL only

[Tom Rini]

On Wed, Feb 29, 2012 at 10:37:06PM +0100, Marek Vasut wrote:
> > On Tue, Feb 28, 2012 at 9:25 AM, Pali Roh?r <pali.rohar at gmail.com> wrote:
> > > On Tuesday 24 January 2012 15:27:58 Pali Roh?r wrote:
> > >> * Hide function save_boot_params if CONFIG_SPL_BUILD is not defined
> > >> (function do nothing)
> > >> 
> > >> * Same behaviour as in file arch/arm/cpu/armv7/omap4/lowlevel_init.S
> > >> * This allow to implement board specified function save_boot_params in
> > >> board code
> > >> 
> > >> Signed-off-by: Pali Roh?r <pali.rohar at gmail.com>
> > >> ---
> > >> Changes since original version:
> > >>    - Fixed commit message
> > >> 
> > >>  arch/arm/cpu/armv7/omap3/lowlevel_init.S |    4 ++--
> > >>  1 files changed, 2 insertions(+), 2 deletions(-)
> > >> 
> > >> diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
> > >> b/arch/arm/cpu/armv7/omap3/lowlevel_init.S index 2f6930b..c42c5dd 100644
> > >> --- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S
> > >> +++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S
> > >> @@ -35,15 +35,15 @@
> > >>  _TEXT_BASE:
> > >>       .word   CONFIG_SYS_TEXT_BASE    /* sdram load addr from config.mk
> > >> */
> > >> 
> > >> +#ifdef CONFIG_SPL_BUILD
> > >>  .global save_boot_params
> > >>  save_boot_params:
> > >> -#ifdef CONFIG_SPL_BUILD
> > >>       ldr     r4, =omap3_boot_device
> > >>       ldr     r5, [r0, #0x4]
> > >>       and     r5, r5, #0xff
> > >>       str     r5, [r4]
> > >> -#endif
> > >>       bx      lr
> > >> +#endif
> > >> 
> > >>  .global omap3_gp_romcode_call
> > > 
> > >>  omap3_gp_romcode_call:
> > > Now I see that somebody commited this patch to u-boot:
> > > http://git.denx.de/?p=u-
> > > boot.git;a=commit;h=204705111ca10f52f62e1a02ba567d8fc33a6d1e
> > > 
> > > So I will not include it in new version.
> > > 
> > > Please, can you inform me when somebody commit my patches to git master?
> > 
> > I did: http://patchwork.ozlabs.org/patch/137559/ :)
> 
> Do we really want this hack-around? Maybe generating such bootargs by uboot in 
> the first place (or the ability to actually source bootargs and adjust env 
> accordingly) won't be too bad of a solution?

IMHO, yes.  There is value in being able to use u-boot as a useful shim
when we don't control 100% of the sequence.

-- 
Tom