Move this control into the common area of the main Makefile, so it applies to non-build rules as well. This allows 'make mrproper' to handle python files as it should.

This should be squashed into:

65a33eba10d Allow Python packages to be dropped

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v7: - Add new fixup patch to move python control earlier in Makefile

Makefile | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile index 264f31bfe473..efbaf434df48 100644 --- a/Makefile +++ b/Makefile @@ -485,6 +485,15 @@ export RCS_FIND_IGNORE := ( -name SCCS -o -name BitKeeper -o -name .svn -o \ export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \ --exclude CVS --exclude .pc --exclude .hg --exclude .git

+export PYTHON_ENABLE + +# This is y if U-Boot should not build any Python tools or libraries. Typically +# you would need to set this if those tools/libraries (typically binman and +# pylibfdt) cannot be built by your environment and are provided separately. +ifeq ($(NO_PYTHON),) +PYTHON_ENABLE=y +endif + # =========================================================================== # Rules shared between *config targets and build targets

@@ -646,20 +655,12 @@ export CFLAGS_NON_EFI # Compiler flags to remove when building EFI app export EFI_TARGET # binutils target if EFI is natively supported

export LTO_ENABLE -export PYTHON_ENABLE

# This is y if LTO is enabled for this build. See NO_LTO=1 to disable LTO ifeq ($(NO_LTO),) LTO_ENABLE=$(if $(CONFIG_LTO),y) endif

-# This is y if U-Boot should not build any Python tools or libraries. Typically -# you would need to set this if those tools/libraries (typically binman and -# pylibfdt) cannot be built by your environment and are provided separately. -ifeq ($(NO_PYTHON),) -PYTHON_ENABLE=y -endif - # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use # that (or fail if absent). Otherwise, search for a linker script in a # standard location.

This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired.

Drop this code so that it is possible to choose whether to init USB or not.

Use the existing USE_PREBOOT mechanism instead.

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v7: - Add docs about how USB keyboard works on coreboot

Changes in v5: - Make use of the uSE_PREBOOT mechanism

arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 4 ---- doc/board/coreboot/coreboot.rst | 7 +++++++ 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE + imply USE_PREBOOT select BINMAN if X86_64

endif diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index da43d66e95d7..82fe4c71cd27 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -86,10 +86,6 @@ static int last_stage_init(void) if (IS_ENABLED(CONFIG_SPL_BUILD)) return 0;

- /* start usb so that usb keyboard can be used as input device */ - if (IS_ENABLED(CONFIG_USB_KEYBOARD)) - usb_init(); - board_final_init();

return 0; diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 10ef78bb5ada..10a251c2b64f 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -85,6 +85,13 @@ build in `$CBDIR`:: This allows booting and installing various distros, many of which are 64-bit-only, so cannot work with the 32-bit 'coreboot' build.

+USB keyboard +------------ + +The `CONFIG_USE_PREBOOT` option is enabled by default, meaning that USB starts +up just before the command-line starts. This allows user interaction on +non-laptop devices which use a USB keyboard. + CBFS access -----------

Refresh the summary information so it is more up-to-date. Add links to the coreboot and slimbootloader docs.

Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---

Changes in v7: - Drop patches previously applied - Rebase to x86/next

Changes in v2: - Add new patch - Add new patch

doc/arch/x86/x86.rst | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/doc/arch/x86/x86.rst b/doc/arch/x86/x86.rst index 3525ae8e27af..f67216d6ce02 100644 --- a/doc/arch/x86/x86.rst +++ b/doc/arch/x86/x86.rst @@ -11,9 +11,9 @@ including supported boards, build instructions, todo list, etc. Status ------ U-Boot supports running as a `coreboot`_ payload on x86. So far only Link -(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should -work with minimal adjustments on other x86 boards since coreboot deals with -most of the low-level details. +(Chromebook Pixel), Brya (Alder Lake Chromebook) and `QEMU`_ x86 targets have +been tested, but it should work with minimal adjustments on other x86 boards +since coreboot deals with most of the low-level details.

U-Boot is a main bootloader on Intel Edison board.

@@ -32,12 +32,14 @@ are supported: - Link (Ivy Bridge - Chromebook Pixel) - Minnowboard MAX - Samus (Broadwell - Chromebook Pixel 2015) + - Coral (Apollo Lake Chromebooks circa 2017) - QEMU x86 (32-bit & 64-bit)

As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks -for more details. +for more details. Finally, U-Boot can boot Linux distributions with a UEFI +interface.

Build Instructions for U-Boot as BIOS replacement (bare mode) ------------------------------------------------------------- @@ -438,9 +440,10 @@ for details of EFI support in U-Boot.

Chain-loading ------------- -U-Boot can be chain-loaded from another bootloader, such as coreboot or -Slim Bootloader. Typically this is done by building for targets 'coreboot' or -'slimbootloader'. +U-Boot can be chain-loaded from another bootloader, such as +:doc:`../../board/coreboot/index` coreboot or +:doc:`../../board/intel/slimbootloader`. Typically this is done by building for +targets 'coreboot' or 'slimbootloader'.

For example, at present we have a 'coreboot' target but this runs very different code from the bare-metal targets, such as coral. There is very little