public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f()
@ 2013-11-27 17:22 Tom Rini
  2013-11-28  1:38 ` Masahiro Yamada
  2014-02-13  8:57 ` Albert ARIBAUD
  0 siblings, 2 replies; 6+ messages in thread
From: Tom Rini @ 2013-11-27 17:22 UTC (permalink / raw)
  To: u-boot

Some code in board_init_f that dates back to the initial relocation
support had if/else for PRELOADER (which became SPL_BUILD) about setting
the stack pointer.  But, board.c is never built for CONFIG_SPL_BUILD
now, so this really makes no sense.  Drop this section.

Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Signed-off-by: Tom Rini <trini@ti.com>
---
 arch/arm/lib/board.c |    5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 34f50b0..3c519a8 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -377,7 +377,6 @@ void board_init_f(ulong bootflag)
 
 	debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, addr);
 
-#ifndef CONFIG_SPL_BUILD
 	/*
 	 * reserve memory for malloc() arena
 	 */
@@ -431,10 +430,6 @@ void board_init_f(ulong bootflag)
 
 	/* 8-byte alignment for ABI compliance */
 	addr_sp &= ~0x07;
-#else
-	addr_sp += 128;	/* leave 32 words for abort-stack   */
-	gd->irq_sp = addr_sp;
-#endif
 	interrupt_init();
 
 	debug("New Stack Pointer is: %08lx\n", addr_sp);
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f()
  2013-11-27 17:22 [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f() Tom Rini
@ 2013-11-28  1:38 ` Masahiro Yamada
  2013-11-28  1:41   ` Simon Glass
  2013-11-28  2:21   ` Tom Rini
  2014-02-13  8:57 ` Albert ARIBAUD
  1 sibling, 2 replies; 6+ messages in thread
From: Masahiro Yamada @ 2013-11-28  1:38 UTC (permalink / raw)
  To: u-boot

Hello Tom, Albert.
(I'm CCing Simon)

> Some code in board_init_f that dates back to the initial relocation
> support had if/else for PRELOADER (which became SPL_BUILD) about setting
> the stack pointer.  But, board.c is never built for CONFIG_SPL_BUILD
> now, so this really makes no sense.  Drop this section.
> 
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> Signed-off-by: Tom Rini <trini@ti.com>

Do you have any idea  when ARM architecture can completely
switch to the generic board?

If the generic board has the same behavior as arch/arm/lib/board.c,
how about deleting arch/arm/lib/board.c rather than maintaining it.


Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f()
  2013-11-28  1:38 ` Masahiro Yamada
@ 2013-11-28  1:41   ` Simon Glass
  2013-11-28  7:44     ` Masahiro Yamada
  2013-11-28  2:21   ` Tom Rini
  1 sibling, 1 reply; 6+ messages in thread
From: Simon Glass @ 2013-11-28  1:41 UTC (permalink / raw)
  To: u-boot

Hi,

On 27 November 2013 18:38, Masahiro Yamada <yamada.m@jp.panasonic.com>wrote:

> Hello Tom, Albert.
> (I'm CCing Simon)
>
> > Some code in board_init_f that dates back to the initial relocation
> > support had if/else for PRELOADER (which became SPL_BUILD) about setting
> > the stack pointer.  But, board.c is never built for CONFIG_SPL_BUILD
> > now, so this really makes no sense.  Drop this section.
> >
> > Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> > Signed-off-by: Tom Rini <trini@ti.com>
>
> Do you have any idea  when ARM architecture can completely
> switch to the generic board?
>
> If the generic board has the same behavior as arch/arm/lib/board.c,
> how about deleting arch/arm/lib/board.c rather than maintaining it.
>

We need to test a few more board types I think. Perhaps in the interim we
could print a warning message that the old board.c is going away in 6
months?

Regards,
Simon


>
>
> Best Regards
> Masahiro Yamada
>
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f()
  2013-11-28  1:38 ` Masahiro Yamada
  2013-11-28  1:41   ` Simon Glass
@ 2013-11-28  2:21   ` Tom Rini
  1 sibling, 0 replies; 6+ messages in thread
From: Tom Rini @ 2013-11-28  2:21 UTC (permalink / raw)
  To: u-boot

On Thu, Nov 28, 2013 at 10:38:31AM +0900, Masahiro Yamada wrote:
> Hello Tom, Albert.
> (I'm CCing Simon)
> 
> > Some code in board_init_f that dates back to the initial relocation
> > support had if/else for PRELOADER (which became SPL_BUILD) about setting
> > the stack pointer.  But, board.c is never built for CONFIG_SPL_BUILD
> > now, so this really makes no sense.  Drop this section.
> > 
> > Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> > Signed-off-by: Tom Rini <trini@ti.com>
> 
> Do you have any idea  when ARM architecture can completely
> switch to the generic board?
> 
> If the generic board has the same behavior as arch/arm/lib/board.c,
> how about deleting arch/arm/lib/board.c rather than maintaining it.

I don't see a problem with doing it sometime in 2014.  I did a test on
am335x a while back and it all seemed to be just fine.

What I would like to see around then, and isn't trivial but should be
doable, is making ARM's relocate_code take 3 args like everyone else
does.  It feels like it's just a matter of shifting a few lines of
crt0.S's code into relocate.S and dealing with args being passed in.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131127/e0f8fc47/attachment.pgp>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f()
  2013-11-28  1:41   ` Simon Glass
@ 2013-11-28  7:44     ` Masahiro Yamada
  0 siblings, 0 replies; 6+ messages in thread
From: Masahiro Yamada @ 2013-11-28  7:44 UTC (permalink / raw)
  To: u-boot

Hello Simon.


> > Do you have any idea  when ARM architecture can completely
> > switch to the generic board?
> >
> > If the generic board has the same behavior as arch/arm/lib/board.c,
> > how about deleting arch/arm/lib/board.c rather than maintaining it.
> >
> 
> We need to test a few more board types I think. Perhaps in the interim we
> could print a warning message that the old board.c is going away in 6
> months?

Sounds good to me.


Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f()
  2013-11-27 17:22 [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f() Tom Rini
  2013-11-28  1:38 ` Masahiro Yamada
@ 2014-02-13  8:57 ` Albert ARIBAUD
  1 sibling, 0 replies; 6+ messages in thread
From: Albert ARIBAUD @ 2014-02-13  8:57 UTC (permalink / raw)
  To: u-boot

Hi Tom,

On Wed, 27 Nov 2013 12:22:05 -0500, Tom Rini <trini@ti.com> wrote:

> Some code in board_init_f that dates back to the initial relocation
> support had if/else for PRELOADER (which became SPL_BUILD) about setting
> the stack pointer.  But, board.c is never built for CONFIG_SPL_BUILD
> now, so this really makes no sense.  Drop this section.
> 
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> Signed-off-by: Tom Rini <trini@ti.com>
> ---
>  arch/arm/lib/board.c |    5 -----
>  1 file changed, 5 deletions(-)

This does not seem to apply cleanly, probably due to aarch64 rework.
Can you please post a rebased v2?

Amicalement,
-- 
Albert.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-02-13  8:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-27 17:22 [U-Boot] [PATCH] arm: Remove unused !CONFIG_SPL_BUILD code in board_init_f() Tom Rini
2013-11-28  1:38 ` Masahiro Yamada
2013-11-28  1:41   ` Simon Glass
2013-11-28  7:44     ` Masahiro Yamada
2013-11-28  2:21   ` Tom Rini
2014-02-13  8:57 ` Albert ARIBAUD

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox