[U-Boot] [PATCH] sunxi: Only compile board.o for CONFIG_SPL_BUILD

[Tom Rini <trini@ti.com>]

On Wed, Jan 21, 2015 at 02:18:12PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 20-01-15 22:40, Tom Rini wrote:
> >All of the code in arch/arm/cpu/armv7/sunxi/board.c was under a check
> >for CONFIG_SPL_BUILD so instead only build for SPL.
> 
> That is not true, the #ifdef SPL block ends at the end of board_init_f
> as things currently stand in master, and even that is only the case
> since the very recently merged "sunxi: Move SPL s_init() code to board_init_f()"
> patch from Simon. Completely not building board.c would break the "reset"
> command as well as break network booting.
> 
> Moreover I believe the changes by Simon are less then optimal.
> 
> >This lets us drop a hunk of code that was never enabled.
> 
> As for that hunk of code never being enabled, it was moved to a place
> where it indeed no longer is ever enabled by the same commit from Simon,
> before when it was sitting in s_init, would get called from both normal
> u-boot execution and from SPL, and then it would run in the normal
> u-boot call.
> 
> I realize that Simon's patches have posted quite a while back, and I
> seem to have missed them, sorry about that. But I would have appreciated
> a ping on this rather then merging them without any input from me.

Sorry, I thought since Ian had commented and Simon had tested on some
sunxi board.

> This turns the cp15 mangling needed to get the caches going on sun6i
> and later into a nop, meaning we will boot the kernel without any
> caches enabling causing just the kernel extracting itself to take 5
> seconds or so.
> 
> But that is not the biggest problem, the biggest problem is that on
> sunxi the SPL and u-boot.bin are two separate pieces, where the second
> may very will be used standalone, that is actually how we bring most
> new SoC's up, first do a standalone u-boot.bin using Allwinner's
> boot0 binary as SPL, and then later add SPL support. So we want
> u-boot.bin to be able to work standalone, and thus it should not rely
> on things like gpio setup already being done by whatever came before
> it.
> 
> I'll look into fixing things up to work again properly with the recent
> changes Simon made.

OK, thanks!

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