[PATCH 1/1] examples: make examples customizable
Most users don't need the standalone API examples. Distributions like Suse do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application. --- Kconfig | 8 ++++++++ examples/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Kconfig b/Kconfig index 883e3f71d0..d0eae2ceba 100644 --- a/Kconfig +++ b/Kconfig @@ -422,6 +422,14 @@ config SYS_SRAM_SIZE default 0x10000 if TARGET_TRICORDER default 0x0
+config EXAMPLES + bool "Compile API examples" + depends on !SANDBOX + default y + help + U-Boot provides an API for standalone applications. Examples are + provided in directory examples/. + endmenu # General setup
menu "Boot images" diff --git a/examples/Makefile b/examples/Makefile index d440bc5655..bf518bd221 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+
-ifndef CONFIG_SANDBOX +ifdef CONFIG_EXAMPLES
ifdef FTRACE subdir-ccflags-y += -finstrument-functions -DFTRACE -- 2.28.0
Most users don't need the standalone API examples. Distributions like Suse do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application. --- Kconfig | 8 ++++++++ examples/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Kconfig b/Kconfig index 883e3f71d0..d0eae2ceba 100644 --- a/Kconfig +++ b/Kconfig @@ -422,6 +422,14 @@ config SYS_SRAM_SIZE default 0x10000 if TARGET_TRICORDER default 0x0
+config EXAMPLES + bool "Compile API examples" + depends on !SANDBOX + default y + help + U-Boot provides an API for standalone applications. Examples are + provided in directory examples/. + endmenu # General setup
menu "Boot images" diff --git a/examples/Makefile b/examples/Makefile index d440bc5655..bf518bd221 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+
-ifndef CONFIG_SANDBOX +ifdef CONFIG_EXAMPLES
ifdef FTRACE subdir-ccflags-y += -finstrument-functions -DFTRACE -- 2.28.0
On 22/09/2020 20:03, Heinrich Schuchardt wrote:
Most users don't need the standalone API examples. Distributions like Suse
Nit: It's SUSE not Suse
Regards, Matthias
do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application.
Kconfig | 8 ++++++++ examples/Makefile | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Kconfig b/Kconfig index 883e3f71d0..d0eae2ceba 100644 --- a/Kconfig +++ b/Kconfig @@ -422,6 +422,14 @@ config SYS_SRAM_SIZE default 0x10000 if TARGET_TRICORDER default 0x0
+config EXAMPLES
bool "Compile API examples"
depends on !SANDBOX
default y
help
U-Boot provides an API for standalone applications. Examples areprovided in directory examples/.endmenu # General setup
menu "Boot images"
diff --git a/examples/Makefile b/examples/Makefile index d440bc5655..bf518bd221 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0+
-ifndef CONFIG_SANDBOX +ifdef CONFIG_EXAMPLES
ifdef FTRACE subdir-ccflags-y += -finstrument-functions -DFTRACE -- 2.28.0
On Tue, Sep 22, 2020 at 08:03:49PM +0200, Heinrich Schuchardt wrote:
Most users don't need the standalone API examples. Distributions like Suse do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
In this case we should not make it "default y" but instead enable it in some specific cases that go through CI. Probably once per arch/ directory on the QEMU / virtual target for that arch.
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application.
I'm certainly in favor of NOT adding support there for new architectures. I don't believe however we can drop it for existing architectures without some fairly large notice, and only then when UEFI is available as a reasonable replacement (ARM? Yes. MIPS? No idea).
On 9/22/20 8:42 PM, Tom Rini wrote:
On Tue, Sep 22, 2020 at 08:03:49PM +0200, Heinrich Schuchardt wrote:
Most users don't need the standalone API examples. Distributions like Suse do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
In this case we should not make it "default y" but instead enable it in some specific cases that go through CI. Probably once per arch/ directory on the QEMU / virtual target for that arch.
default y if ARCH_QEMU would compile it
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application.
I'm certainly in favor of NOT adding support there for new architectures. I don't believe however we can drop it for existing architectures without some fairly large notice, and only then when UEFI is available as a reasonable replacement (ARM? Yes. MIPS? No idea).
UEFI is low endian only.
Best regards
Heinrich
On Tue, Sep 22, 2020 at 08:49:20PM +0200, Heinrich Schuchardt wrote:
On 9/22/20 8:42 PM, Tom Rini wrote:
On Tue, Sep 22, 2020 at 08:03:49PM +0200, Heinrich Schuchardt wrote:
Most users don't need the standalone API examples. Distributions like Suse do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
In this case we should not make it "default y" but instead enable it in some specific cases that go through CI. Probably once per arch/ directory on the QEMU / virtual target for that arch.
default y if ARCH_QEMU would compile it
OK, lets do that in v2 please.
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application.
I'm certainly in favor of NOT adding support there for new architectures. I don't believe however we can drop it for existing architectures without some fairly large notice, and only then when UEFI is available as a reasonable replacement (ARM? Yes. MIPS? No idea).
UEFI is low endian only.
Right, so we can't just remove the standalone API but we can encourage new architectures to see if UEFI is right for them.
Hi Heinrich,
On Tue, 22 Sep 2020 at 12:04, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Most users don't need the standalone API examples. Distributions like Suse do not supply libgcc for cross-compiling and we cannot do without on ARMv8 for building examples/.
Make examples customizable via symbol CONFIG_EXAMPLES. It only defaults to yes to ensure that we compile it on Gitlab CI.
Cc: Matthias Brugger mbrugger@suse.com Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
I wonder if we should not completely drop the standalone API. The UEFI API has enough to run a standalone application.
I am not sure. I don't like UEFI at all and it doesn't expose U-Boot devices, etc.
Reviewed-by: Simon Glass sjg@chromium.org
participants (4)
-
Heinrich Schuchardt -
Matthias Brugger -
Simon Glass -
Tom Rini