HI Hans, On 21 January 2015 at 06:18, Hans de Goede <hdego...@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] _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
