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

Simon Glass sjg at chromium.org
Wed Jan 21 17:17:49 CET 2015


HI Hans,

On 21 January 2015 at 06:18, Hans de Goede <hdegoede at redhat.com> 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.

Quite possibly. My objective was to sort out the global_data stuff in
SPL which we weren't able to resolve in the last merge window. This
will unblock driver model in SPL.

>
>> 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.
>

I have a few sunxi boards, I believe I tested this with pcduino3 only,
but I don't have my notes in front of me. Also I would not have
noticed the down-stream side-effects you refer to below.

I want to thank Tom for digging into this and figuring it out. Sorry
that I broke things on sunxi, but there is still plenty of time to fix
it, and please let me know if I can help.

> 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 don't think doing things twice on boot is a good idea. If you want
to do SPL init in U-Boot proper then how about adding a CONFIG option
to enable this, for development/debugging purposes only?

Also you are double the test cases for people, by adding a new supported flow.

>
> I'll look into fixing things up to work again properly with the recent
> changes Simon made.

Thanks, it's all in a good cause.

- Simon

[snip]


More information about the U-Boot mailing list