| Message ID | 20200922180350.46636-1-xypron.glpk@gmx.de |
|---|---|
| State | Superseded, archived |
| Delegated to: | Tom Rini |
| Headers | show |
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).
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>
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.
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
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(-) -- 2.28.0