On Mon, 06 Jun 2016 12:16:33 -0500 Scott Wood oss@buserror.net wrote:
On Sat, 2016-06-04 at 13:06 +0200, Boris Brezillon wrote:
On Sat, 04 Jun 2016 02:14:09 -0500 Scott Wood oss@buserror.net wrote:
On Sat, 2016-06-04 at 08:06 +0200, Boris Brezillon wrote:
On Fri, 03 Jun 2016 20:08:49 -0500 Scott Wood oss@buserror.net wrote:
This doesn't work. CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined when SPL is defined, and the user will be forced to enter a value before kconfig will continue (or kconfig will error out in an automated build).
Yes, CONFIG_SPL_NAND_U_BOOT_OFFS will always be defined, but won't be used if CONFIG_SYS_NAND_U_BOOT_OFFS is defined in the config header file. And for the "user will forced to enter a value before Kconfig continue" comment, we could just have
config SPL_NAND_U_BOOT_OFFS hex "Location in NAND to read U-Boot from" default 0x8000 if NAND_SUNXI default 0x0 ...
If you do that, then that zero will override CONFIG_SYS_NAND_U_BOOT_OFFS from the header.
Nope, because the condition is
#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS #endif
and not
#ifdef CONFIG_SPL_NAND_U_BOOT_OFFS #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS #endif
So CONFIG_SYS_NAND_U_BOOT_OFFS is always preferred over CONFIG_SPL_NAND_U_BOOT_OFFS if it's defined.
Ah, right. Still, I think it would be less confusing to not have two different names for the same thing, both of which would be present (albeit only one is used) in the legacy case -- especially if we start adding references directly to the SPL name in some drivers. The bool could eventually be reversed so that only the legacy targets need it.
I posted a new version with the extra bool option this morning ;).