Dear 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.ro...@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.ro...@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.
Well ... I won't argue, it's your start.S that's gonne be bloated ;-) Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
