Hi Jagan,
On Thu, Aug 24, 2017 at 12:25:24PM +0530, Jagan Teki wrote:
On Wed, Aug 23, 2017 at 5:11 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
U-Boot itself might need to identify the boot device, for example to be able to tell where to load the kernel from when several options are possible.
Remove the guard preventing it from being compiled.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
arch/arm/mach-sunxi/board.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 65b1ebd83787..f5e977b4183d 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -14,9 +14,7 @@ #include <mmc.h> #include <i2c.h> #include <serial.h> -#ifdef CONFIG_SPL_BUILD #include <spl.h> -#endif #include <asm/gpio.h> #include <asm/io.h> #include <asm/arch/clock.h> @@ -210,7 +208,6 @@ void s_init(void) eth_init_board(); }
-#ifdef CONFIG_SPL_BUILD DECLARE_GLOBAL_DATA_PTR;
/* The sunxi internal brom will try to loader external bootloader @@ -261,6 +258,7 @@ u32 spl_boot_mode(const u32 boot_device) return MMCSD_MODE_RAW; }
+#ifdef CONFIG_SPL_BUILD
Based on this, 3/4 is reusing for finding boot device, reusing spl core functions in u-boot proper is not good approach. Better to have some separate function that determine boot source and reuse the same in spl and U-Boot proper.
I'm not sure what you mean here, do you want something like
int sunxi_boot_device() { .... }
#ifdef CONFIG_SPL_BUILD int spl_boot_device() { return sunxi_boot_device(); } #endif
I mean, I could do that, but I don't see the difference. Can you elaborate?
Thanks, Maxime