efi_laoder: Add travis test coverage
Subsystems (3)
v2 cover efi_laoder: Add travis test coverage
Now that we have Travis-CI support in U-Boot as well as a simple hello world efi binary test case, we can make use of the two and verify that efi_loader support still works on every commit.
This patch set enables network as well as basic efi_loader test coverage once the uboot-test-hooks pull request at
https://github.com/swarren/uboot-test-hooks/pull/9
is accepted.
---
v1 -> v2:
- Make the tests actually work
- New patch: Travis: Expose build dir as variable
- New patch: Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
Alexander Graf (6):
tests: net: Offset downloads to 4MB
Travis: Expose build dir as variable
travis: Add python path for environments
tests: Add efi_loader hello world test
efi_loader: Allow to compile helloworld.efi w/o bundling it
Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
.travis.yml | 7 +- arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 + test/py/tests/test_efi_loader.py | 158 +++++++++++++++++++++++++++++++ test/py/tests/test_net.py | 4 +- 9 files changed, 186 insertions(+), 8 deletions(-) create mode 100644 test/py/tests/test_efi_loader.py
Signature · 1 line
1.8.5.6
PATCH v2 1/6 tests: net: Offset downloads to 4MB
The network test currently downloads files at 0MB offset of RAM start. This works for most ARM systems, but x86 has weird memory layout constraints on the first MB of RAM.
To not get caught into any of these, let's add a 4MB pad from start of RAM to the default memory offset.
--- test/py/tests/test_net.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
test/py/tests/test_net.py +2 -2
@@ -147,7 +147,7 @@ def test_net_tftpboot(u_boot_console): addr = f.get('addr', None) if not addr: - addr = u_boot_utils.find_ram_base(u_boot_console) + addr = u_boot_utils.find_ram_base(u_boot_console) + (1024 * 1024 * 4) fn = f['fn'] output = u_boot_console.run_command('tftpboot %x %s' % (addr, fn))
@@ -187,7 +187,7 @@ def test_net_nfs(u_boot_console): addr = f.get('addr', None) if not addr: - addr = u_boot_utils.find_ram_base(u_boot_console) + addr = u_boot_utils.find_ram_base(u_boot_console) + (1024 * 1024 * 4) fn = f['fn'] output = u_boot_console.run_command('nfs %x %s' % (addr, fn))
Signature · 1 line
1.8.5.6
PATCH v2 1/6 tests: net: Offset downloads to 4MB
Quoted 11 lines · Alexander Graf
The network test currently downloads files at 0MB offset of RAM start. This works for most ARM systems, but x86 has weird memory layout constraints on the first MB of RAM.
To not get caught into any of these, let's add a 4MB pad from start of RAM to the default memory offset.
Signed-off-by Alexander Graf <[email protected]>--- test/py/tests/test_net.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
PATCH v2 1/6 tests: net: Offset downloads to 4MB
In reply to Alexander GrafQuoted 8 lines · Alexander Graf
The network test currently downloads files at 0MB offset of RAM start. This works for most ARM systems, but x86 has weird memory layout constraints on the first MB of RAM.
To not get caught into any of these, let's add a 4MB pad from start of RAM to the default memory offset.
Signed-off-by Alexander Graf <[email protected]>
I've been fixing this locally by setting an address as needed in board files. But this is probably still a good idea, so:
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161121/671b97cc/attachment.sig>
PATCH v2 1/6 tests: net: Offset downloads to 4MB
In reply to Alexander GrafQuoted 10 lines · Alexander Graf
The network test currently downloads files at 0MB offset of RAM start. This works for most ARM systems, but x86 has weird memory layout constraints on the first MB of RAM.
To not get caught into any of these, let's add a 4MB pad from start of RAM to the default memory offset.
Signed-off-by Alexander Graf <[email protected]>Reviewed-by Simon Glass <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161127/a986cfcc/attachment.sig>
PATCH v2 2/6 Travis: Expose build dir as variable
In reply to Alexander GrafSome travis QEMU tests can transfer files between the build directory and the guest U-Boot instance. For that to work, both need to have access to the same directory.
This patch puts the current build path into an environment variable, so that the environment generating python scripts can extract it from there and read the respective files.
--- .travis.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
.travis.yml +3 -2
@@ -86,10 +86,11 @@ script: # never prevent any test from running. That way, we can always pass # "-k something" even when $TEST_PY_TEST_SPEC doesnt need a custom # value. - - if [[ "${TEST_PY_BD}" != "" ]]; then + - export UBOOT_TRAVIS_BUILD_DIR=`cd .. && pwd`/.bm-work/${TEST_PY_BD}; + if [[ "${TEST_PY_BD}" != "" ]]; then ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID} -k "${TEST_PY_TEST_SPEC:-not a_test_which_does_not_exist}" - --build-dir `cd .. && pwd`/.bm-work/${TEST_PY_BD}; + --build-dir "$UBOOT_TRAVIS_BUILD_DIR"; fi matrix:
Signature · 1 line
1.8.5.6
PATCH v2 2/6 Travis: Expose build dir as variable
Quoted 9 lines · Alexander Graf
Some travis QEMU tests can transfer files between the build directory and the guest U-Boot instance. For that to work, both need to have access to the same directory.
This patch puts the current build path into an environment variable, so that the environment generating python scripts can extract it from there and read the respective files.
Signed-off-by Alexander Graf <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161121/fa0f3788/attachment.sig>
PATCH v2 2/6 Travis: Expose build dir as variable
In reply to Alexander GrafQuoted 10 lines · Alexander Graf
Some travis QEMU tests can transfer files between the build directory and the guest U-Boot instance. For that to work, both need to have access to the same directory.
This patch puts the current build path into an environment variable, so that the environment generating python scripts can extract it from there and read the respective files.
Signed-off-by Alexander Graf <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161127/12426cfc/attachment.sig>
PATCH v2 3/6 travis: Add python path for environments
In reply to Alexander GrafWhen running in travis-ci, we want to pass environment configuration to the tests. These reside in a path available through PYTHONPATH, so let's define that one to point to the unit test repo.
--- .travis.yml | 1 + 1 file changed, 1 insertion(+)
.travis.yml +1 -0
@@ -49,6 +49,7 @@ install: env: global: - PATH=/tmp/dtc:/tmp/uboot-test-hooks/bin:$PATH + - PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci - BUILD_DIR=build - HOSTCC="cc" - HOSTCXX="c++"
Signature · 1 line
1.8.5.6
PATCH v2 3/6 travis: Add python path for environments
Quoted 5 lines · Alexander Graf
When running in travis-ci, we want to pass environment configuration to the tests. These reside in a path available through PYTHONPATH, so let's define that one to point to the unit test repo.
Signed-off-by Alexander Graf <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161121/94777b2c/attachment.sig>
PATCH v2 3/6 travis: Add python path for environments
In reply to Alexander GrafQuoted 6 lines · Alexander Graf
When running in travis-ci, we want to pass environment configuration to the tests. These reside in a path available through PYTHONPATH, so let's define that one to point to the unit test repo.
Signed-off-by Alexander Graf <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161127/0a9681bf/attachment.sig>
PATCH v2 4/6 tests: Add efi_loader hello world test
In reply to Alexander GrafNow that we have working network tests and a hello world efi application built inside our tree, we can automatically test that efi binary running inside of U-Boot.
--- test/py/tests/test_efi_loader.py | 158 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 158 insertions(+) create mode 100644 test/py/tests/test_efi_loader.py
test/py/tests/test_efi_loader.py new file +158 -0
@@ -0,0 +1,158 @@ +# Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved. +# Copyright (c) 2016, Alexander Graf <[email protected]> +# +# based on test_net.py. +# +# SPDX-License-Identifier: GPL-2.0 + +# Test efi loader implementation + +import pytest +import u_boot_utils + +""" +Note: This test relies on boardenv_* containing configuration values to define +which the network environment available for testing. Without this, the parts +that rely on network will be automatically skipped. + +For example: + +# Boolean indicating whether the Ethernet device is attached to USB, and hence +# USB enumeration needs to be performed prior to network tests. +# This variable may be omitted if its value is False. +env__net_uses_usb = False + +# Boolean indicating whether the Ethernet device is attached to PCI, and hence +# PCI enumeration needs to be performed prior to network tests. +# This variable may be omitted if its value is False. +env__net_uses_pci = True + +# True if a DHCP server is attached to the network, and should be tested. +# If DHCP testing is not possible or desired, this variable may be omitted or +# set to False. +env__net_dhcp_server = True + +# A list of environment variables that should be set in order to configure a +# static IP. If solely relying on DHCP, this variable may be omitted or set to +# an empty list. +env__net_static_env_vars = [ + ("ipaddr", "10.0.0.100"), + ("netmask", "255.255.255.0"), + ("serverip", "10.0.0.1"), +] + +# Details regarding a file that may be read from a TFTP server. This variable +# may be omitted or set to None if TFTP testing is not possible or desired. +env__efi_loader_helloworld_file = { + "fn": "lib/efi_loader/helloworld.efi", + "size": 5058624, + "crc32": "c2244b26", +} +""" + +net_set_up = False + +def test_efi_pre_commands(u_boot_console): + """Execute any commands required to enable network hardware. + + These commands are provided by the boardenv_* file; see the comment at the + beginning of this file. + """ + + init_usb = u_boot_console.config.env.get('env__net_uses_usb', False) + if init_usb: + u_boot_console.run_command('usb start') + + init_pci = u_boot_console.config.env.get('env__net_uses_pci', False) + if init_pci: + u_boot_console.run_command('pci enum') + + at pytest.mark.buildconfigspec('cmd_dhcp') +def test_efi_dhcp(u_boot_console): + """Test the dhcp command. + + The boardenv_* file may be used to enable/disable this test; see the + comment at the beginning of this file. + """ + + test_dhcp = u_boot_console.config.env.get('env__net_dhcp_server', False) + if not test_dhcp: + pytest.skip('No DHCP server available') + + u_boot_console.run_command('setenv autoload no') + output = u_boot_console.run_command('dhcp') + assert 'DHCP client bound to address ' in output + + global net_set_up + net_set_up = True + + at pytest.mark.buildconfigspec('net') +def test_efi_setup_static(u_boot_console): + """Set up a static IP configuration. + + The configuration is provided by the boardenv_* file; see the comment at + the beginning of this file. + """ + + env_vars = u_boot_console.config.env.get('env__net_static_env_vars', None) + if not env_vars: + pytest.skip('No static network configuration is defined') + + for (var, val) in env_vars: + u_boot_console.run_command('setenv %s %s' % (var, val)) + + global net_set_up + net_set_up = True + + at pytest.mark.buildconfigspec('cmd_bootefi_hello') +def test_efi_helloworld_net(u_boot_console): + """Run the helloworld.efi binary via TFTP. + + The helloworld.efi file is downloaded from the TFTP server and gets + executed. + """ + + if not net_set_up: + pytest.skip('Network not initialized') + + f = u_boot_console.config.env.get('env__efi_loader_helloworld_file', None) + if not f: + pytest.skip('No hello world binary specified in environment') + + addr = f.get('addr', None) + if not addr: + addr = u_boot_utils.find_ram_base(u_boot_console) + (1024 * 1024 * 4) + + fn = f['fn'] + output = u_boot_console.run_command('tftpboot %x %s' % (addr, fn)) + expected_text = 'Bytes transferred = ' + sz = f.get('size', None) + if sz: + expected_text += '%d' % sz + assert expected_text in output + + expected_crc = f.get('crc32', None) + if not expected_crc: + return + + if u_boot_console.config.buildconfig.get('config_cmd_crc32', 'n') != 'y': + return + + output = u_boot_console.run_command('crc32 %x $filesize' % addr) + assert expected_crc in output + + output = u_boot_console.run_command('bootefi %x' % addr) + expected_text = 'Hello, world' + assert expected_text in output + + at pytest.mark.buildconfigspec('cmd_bootefi_hello') +def test_efi_helloworld_builtin(u_boot_console): + """Run the builtin helloworld.efi binary. + + The helloworld.efi file is included in U-Boot, execute it using the + special "bootefi hello" command. + """ + + output = u_boot_console.run_command('bootefi hello') + expected_text = 'Hello, world' + assert expected_text in output
Signature · 1 line
1.8.5.6
PATCH v2 4/6 tests: Add efi_loader hello world test
Hi Alex,
Quoted 9 lines · Alexander Graf
Now that we have working network tests and a hello world efi application built inside our tree, we can automatically test that efi binary running inside of U-Boot.
Signed-off-by Alexander Graf <[email protected]>--- test/py/tests/test_efi_loader.py | 158 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 158 insertions(+) create mode 100644 test/py/tests/test_efi_loader.py
For test_efi_helloworld_builtin():
I wonder if you should separate these two tests into different patches?
Regards,
Simon
PATCH v2 4/6 tests: Add efi_loader hello world test
In reply to Alexander GrafQuoted 5 lines · Alexander Graf
Now that we have working network tests and a hello world efi application built inside our tree, we can automatically test that efi binary running inside of U-Boot.
Signed-off-by Alexander Graf <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161121/9906cc45/attachment.sig>
PATCH v2 4/6 tests: Add efi_loader hello world test
In reply to Alexander GrafQuoted 7 lines · Alexander Graf
Now that we have working network tests and a hello world efi application built inside our tree, we can automatically test that efi binary running inside of U-Boot.
Signed-off-by Alexander Graf <[email protected]>Reviewed-by Simon Glass <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161127/ad7bbe12/attachment.sig>
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
In reply to Alexander GrafToday we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the efi_loader test case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.
--- arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)
arch/arm/lib/Makefile +1 -1
@@ -100,5 +100,5 @@ CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI) CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI) CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI) -extra-$(CONFIG_CMD_BOOTEFI_HELLO) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC) extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
arch/x86/config.mk +1 -1
@@ -66,7 +66,7 @@ LDFLAGS_FINAL += --gc-sections -pie endif -ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO),) +ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),) ifneq ($(CONFIG_EFI_STUB_64BIT),) EFI_LDS := elf_x86_64_efi.lds
arch/x86/lib/Makefile +1 -1
@@ -64,6 +64,6 @@ extra-$(CONFIG_EFI_STUB_64BIT) += crt0_x86_64_efi.o reloc_x86_64_efi.o endif -ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO),) +ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),) extra-y += $(EFI_CRT0) $(EFI_RELOC) endif
cmd/Kconfig +14 -1
@@ -181,9 +181,22 @@ config CMD_BOOTEFI help Boot an EFI image from memory. +config CMD_BOOTEFI_HELLO_COMPILE + bool "Compile a standard EFI hello world binary for testing" + depends on CMD_BOOTEFI && (ARM || X86) + default y + help + This compiles a standard EFI hello world application with U-Boot so + that it can be used with the test/py testing framework. This is useful + for testing that EFI is working at a basic level, and for bringing + up EFI support on a new architecture. + + No additional space will be required in the resulting U-Boot binary + when this option is enabled. + config CMD_BOOTEFI_HELLO bool "Allow booting a standard EFI hello world for testing" - depends on CMD_BOOTEFI && (ARM || X86) + depends on CMD_BOOTEFI_HELLO_COMPILE help This adds a standard EFI hello world application to U-Boot so that it can be used with the 'bootefi hello' command. This is useful
configs/qemu-x86_efi_payload64_defconfig +1 -0
@@ -52,3 +52,4 @@ CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_STUB_64BIT=y +# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set
lib/efi_loader/Makefile +3 -0
@@ -10,6 +10,9 @@ CFLAGS_helloworld.o := $(CFLAGS_EFI) CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI) +efiprogs-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += helloworld.efi +always := $(efiprogs-y) + obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o obj-y += efi_memory.o
test/py/tests/test_efi_loader.py +1 -1
@@ -104,7 +104,7 @@ def test_efi_setup_static(u_boot_console): global net_set_up net_set_up = True - at pytest.mark.buildconfigspec('cmd_bootefi_hello') + at pytest.mark.buildconfigspec('cmd_bootefi_hello_compile') def test_efi_helloworld_net(u_boot_console): """Run the helloworld.efi binary via TFTP.
Signature · 1 line
1.8.5.6
PATCH v3 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the efi_loader test case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.
---
v2 -> v3:
- disable hello world on stm32f429
--- arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + configs/stm32f429-discovery_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 8 files changed, 23 insertions(+), 5 deletions(-)
arch/arm/lib/Makefile +1 -1
@@ -100,5 +100,5 @@ CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI) CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI) CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI) -extra-$(CONFIG_CMD_BOOTEFI_HELLO) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC) extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
arch/x86/config.mk +1 -1
@@ -66,7 +66,7 @@ LDFLAGS_FINAL += --gc-sections -pie endif -ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO),) +ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),) ifneq ($(CONFIG_EFI_STUB_64BIT),) EFI_LDS := elf_x86_64_efi.lds
arch/x86/lib/Makefile +1 -1
@@ -64,6 +64,6 @@ extra-$(CONFIG_EFI_STUB_64BIT) += crt0_x86_64_efi.o reloc_x86_64_efi.o endif -ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO),) +ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),) extra-y += $(EFI_CRT0) $(EFI_RELOC) endif
cmd/Kconfig +14 -1
@@ -181,9 +181,22 @@ config CMD_BOOTEFI help Boot an EFI image from memory. +config CMD_BOOTEFI_HELLO_COMPILE + bool "Compile a standard EFI hello world binary for testing" + depends on CMD_BOOTEFI && (ARM || X86) + default y + help + This compiles a standard EFI hello world application with U-Boot so + that it can be used with the test/py testing framework. This is useful + for testing that EFI is working at a basic level, and for bringing + up EFI support on a new architecture. + + No additional space will be required in the resulting U-Boot binary + when this option is enabled. + config CMD_BOOTEFI_HELLO bool "Allow booting a standard EFI hello world for testing" - depends on CMD_BOOTEFI && (ARM || X86) + depends on CMD_BOOTEFI_HELLO_COMPILE help This adds a standard EFI hello world application to U-Boot so that it can be used with the 'bootefi hello' command. This is useful
configs/qemu-x86_efi_payload64_defconfig +1 -0
@@ -52,3 +52,4 @@ CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_STUB_64BIT=y +# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set
configs/stm32f429-discovery_defconfig +1 -0
@@ -10,3 +10,4 @@ CONFIG_SYS_PROMPT="U-Boot > " # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIMER=y CONFIG_OF_LIBFDT=y +# CONFIG_CMD_BOOTEFI_HELLO_COMPILE is not set
lib/efi_loader/Makefile +3 -0
@@ -10,6 +10,9 @@ CFLAGS_helloworld.o := $(CFLAGS_EFI) CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI) +efiprogs-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += helloworld.efi +always := $(efiprogs-y) + obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o obj-y += efi_memory.o
test/py/tests/test_efi_loader.py +1 -1
@@ -104,7 +104,7 @@ def test_efi_setup_static(u_boot_console): global net_set_up net_set_up = True - at pytest.mark.buildconfigspec('cmd_bootefi_hello') + at pytest.mark.buildconfigspec('cmd_bootefi_hello_compile') def test_efi_helloworld_net(u_boot_console): """Run the helloworld.efi binary via TFTP.
Signature · 1 line
1.8.5.6
PATCH v3 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Quoted 6 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
Quoted 8 lines
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161121/5ef5ed64/attachment.sig>
PATCH v3 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
In reply to Alexander GrafQuoted 6 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
Quoted 8 lines
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161127/2fdfdae0/attachment.sig>
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
In reply to Alexander GrafHi Alex,
Quoted 13 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>
Quoted 9 lines
--- arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Regards,
Simon
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Quoted 26 lines · Simon Glass
Hi Alex,
Quoted 13 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>Quoted 9 lines
--- arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)
Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Alex
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Hi Alex,
Quoted 37 lines · Alexander Graf
Quoted 29 lines · Simon Glass
Hi Alex,
Quoted 14 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>Quoted 9 lines
--- arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Quoted 6 lines
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root directory of the build, perhaps? It just seems like a lot of extra stuff for a file that is already built.
Regards,
Simon
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Quoted 48 lines
Am 19.11.2016 um 21:02 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 42 lines · Alexander Graf
Quoted 32 lines · Simon Glass
Hi Alex,
Quoted 16 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>---
Quoted 8 lines
arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
Quoted 6 lines
Quoted 2 lines
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root directory of the build, perhaps? It just seems like a lot of extra stuff for a file that is already built.
I want to make sure that by default we never compile the hello world efi example into the u-boot binary, but still have the file build tested and available for travis.
Alex
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Hi Alex,
Quoted 48 lines · Alexander Graf
Quoted 48 lines
Am 19.11.2016 um 21:02 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 42 lines · Alexander Graf
Quoted 32 lines · Simon Glass
Hi Alex,
Quoted 16 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>---
Quoted 8 lines
arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root directory of the build, perhaps? It just seems like a lot of extra stuff for a file that is already built.
I want to make sure that by default we never compile the hello world efi example into the u-boot binary, but still have the file build tested and available for travis.
So how about just having two cases:
1. Compile hello world and produce it as an output
2. As 1 but also build it into the U-Boot binary
The first one could be controlled by EFI_LOADER, the second with the existing option for the 'bootefi hello' command.
Regards,
Simon
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Quoted 62 lines
Am 20.11.2016 um 00:56 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 56 lines · Alexander Graf
Quoted 54 lines
Am 19.11.2016 um 21:02 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 38 lines · Alexander Graf
Quoted 32 lines · Simon Glass
Hi Alex,
Quoted 16 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>---
Quoted 8 lines
arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Quoted 6 lines
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root directory of the build, perhaps? It just seems like a lot of extra stuff for a file that is already built.
Quoted 6 lines
Quoted 1 line
I want to make sure that by default we never compile the hello world efi example into the u-boot binary, but still have the file build tested and available for travis.
So how about just having two cases:
1. Compile hello world and produce it as an output
2. As 1 but also build it into the U-Boot binary
Yes, that's precisely what this patch does :). I'm glad we agree.
Quoted 2 lines
The first one could be controlled by
EFI_LOADER,
Unfortunately the hello world binary doesn't build on stm32 while there is no reason to disable EFI_LOADER on that platform, so I want to keep the options separately.
Also, if someone comes in and enables a new architecture, I would like to make the bar as low as I can for that. For that reason too, I would prefer to keep it as a separate config option.
Quoted 2 lines
the second with the
existing option for the 'bootefi hello' command.
Yes, that too is what the patch does :).
Alex
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Hi Alex,
Quoted 62 lines · Alexander Graf
Quoted 62 lines
Am 20.11.2016 um 00:56 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 56 lines · Alexander Graf
Quoted 54 lines
Am 19.11.2016 um 21:02 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 38 lines · Alexander Graf
Quoted 32 lines · Simon Glass
Hi Alex,
Quoted 16 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>---
Quoted 8 lines
arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Quoted 6 lines
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root directory of the build, perhaps? It just seems like a lot of extra stuff for a file that is already built.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
I want to make sure that by default we never compile the hello world efi example into the u-boot binary, but still have the file build tested and available for travis.
So how about just having two cases:
1. Compile hello world and produce it as an output
2. As 1 but also build it into the U-Boot binaryYes, that's precisely what this patch does :). I'm glad we agree.
Except that I don't think we need the extra CONFIG.
Quoted 5 lines
Quoted 3 lines
The first one could be controlled by
EFI_LOADER,Unfortunately the hello world binary doesn't build on stm32 while there is no reason to disable
EFI_LOADERon that platform, so I want to keep the options separately.
Well if no one can compile for stm32 then it is unlikely to work anyway. Does anyone actually use Thumb 1 with EFI?
Quoted 2 lines
Also, if someone comes in and enables a new architecture, I would like to make the bar as low as I can for that. For that reason too, I would prefer to keep it as a separate config option.
I think you might have it backwards. As someone who just enabled a new architecture (x86) I can tell you that the best approach by far was to use the embedded hello world test. In fact that is why I wrote it. It provides a fast and easy to test to allow things to be brought up. Using something like grub is so much more painful.
Quoted 5 lines
Quoted 3 lines
the second with the
existing option for the 'bootefi hello' command.Yes, that too is what the patch does :).
So I think we should disable the one stm32 board until someone actually gets it working, at least with the hello world test.
Regards,
Simon
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Quoted 3 lines · Simon Glass
Hi Alex,
On 19 November 2016 at 17:13, Alexander Graf <[email protected]> wrote:
[snip]
Quoted 4 lines
Quoted 1 line
Unfortunately the hello world binary doesn't build on stm32 while there is no reason to disable
EFI_LOADERon that platform, so I want to keep the options separately.Well if no one can compile for stm32 then it is unlikely to work anyway. Does anyone actually use Thumb 1 with EFI?
On just this point, maybe the right answer is to say we turn off EFI for STM32 as no, that sounds a bit overkill.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161122/3f6efe20/attachment.sig>
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
Quoted 8 lines
Am 22.11.2016 um 19:27 schrieb Tom Rini <[email protected]>:
Quoted 4 lines · Simon Glass
Hi Alex,
On 19 November 2016 at 17:13, Alexander Graf <[email protected]> wrote:
Quoted 8 lines
[snip]
Quoted 4 lines
Quoted 1 line
Unfortunately the hello world binary doesn't build on stm32 while there is no reason to disable
EFI_LOADERon that platform, so I want to keep the options separately.Well if no one can compile for stm32 then it is unlikely to work anyway. Does anyone actually use Thumb 1 with EFI?
On just this point, maybe the right answer is to say we turn off EFI for STM32 as no, that sounds a bit overkill.
EFI support should work just fine with Thumb 1. the hello world crt0 is what's breaking.
Alex
Quoted 3 lines
Signature · 2 lines
-- Tom
PATCH v2 5/6 efi_loader: Allow to compile helloworld.efi w/o bundling it
In reply to Simon GlassQuoted 67 lines · Simon Glass
Hi Alex,
Quoted 64 lines · Alexander Graf
Quoted 64 lines
Am 20.11.2016 um 00:56 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 57 lines · Alexander Graf
Quoted 48 lines
Am 19.11.2016 um 21:02 schrieb Simon Glass <[email protected]>:
Hi Alex,
Quoted 42 lines · Alexander Graf
Quoted 32 lines · Simon Glass
Hi Alex,
Quoted 16 lines · Alexander Graf
Today we can compile a self-contained hello world efi test binary that allows us to quickly verify whether the EFI loader framwork works.
We can use that binary outside of the self-contained test case though, by providing it to a to-be-tested system via tftp.
This patch separates compilation of the helloworld.efi file from including it in the u-boot binary for "bootefi hello". It also modifies the
efi_loadertest case to enable travis to pick up the compiled file. Because we're now no longer bloating the resulting u-boot binary, we can enable compilation always, giving us good travis test coverage.Signed-off-by Alexander Graf <[email protected]>---
Quoted 8 lines
arch/arm/lib/Makefile | 2 +- arch/x86/config.mk | 2 +- arch/x86/lib/Makefile | 2 +- cmd/Kconfig | 15 ++++++++++++++- configs/qemu-x86_efi_payload64_defconfig | 1 + lib/efi_loader/Makefile | 3 +++ test/py/tests/test_efi_loader.py | 2 +- 7 files changed, 22 insertions(+), 5 deletions(-)Quoted 3 lines
Ick.
Can you not achieve the same effect just by copying the file somewhere?
Sure, we could. But the file is only defined inside the env of the particular test case. So if you want to test against non-travis, you can copy it wherever you like.
Quoted 6 lines
Quoted 2 lines
This way the travis description simplifies a lot, because we can just expose the build directory as tftp root.
Or use .PRECIOUS on the existing file? You could copy it into the root directory of the build, perhaps? It just seems like a lot of extra stuff for a file that is already built.
I want to make sure that by default we never compile the hello world efi example into the u-boot binary, but still have the file build tested and available for travis.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
So how about just having two cases:
1. Compile hello world and produce it as an output
2. As 1 but also build it into the U-Boot binaryYes, that's precisely what this patch does :). I'm glad we agree.
Except that I don't think we need the extra CONFIG.
If that's the only disagreement we have, then let's have the extra CONFIG. Having more usually shouldn't hurt.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
The first one could be controlled by
EFI_LOADER,Unfortunately the hello world binary doesn't build on stm32 while there is no reason to disable
EFI_LOADERon that platform, so I want to keep the options separately.Well if no one can compile for stm32 then it is unlikely to work anyway. Does anyone actually use Thumb 1 with EFI?
I've verified thumb 1 back in the day when I did the setjmp/longjmp implementation, yeah.
Quoted 7 lines
Quoted 1 line
Also, if someone comes in and enables a new architecture, I would like to make the bar as low as I can for that. For that reason too, I would prefer to keep it as a separate config option.
I think you might have it backwards. As someone who just enabled a new architecture (x86) I can tell you that the best approach by far was to use the embedded hello world test. In fact that is why I wrote it. It provides a fast and easy to test to allow things to be brought up. Using something like grub is so much more painful.
I think you might have it backwards :). Different people have different approaches to problems. If someone wants to port the hello world example first, I'm more than happy to have them do it. But if their flow is different, I'm not going to be the one standing in their way.
My goal is to have EFI support enabled and working well for as many devices as we can. The path to get there doesn't matter that much to me.
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
the second with the
existing option for the 'bootefi hello' command.Yes, that too is what the patch does :).
So I think we should disable the one stm32 board until someone actually gets it working, at least with the hello world test.
Can you prove that it doesn't work? So far the only thing that breaks is your new hello world test code.
Alex
PATCH v2 6/6 Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
In reply to Alexander GrafMost of the time when running the sleep test in Travis for the integratorcp_cm926ejs target I get errors like this:
E assert 2.999901056289673 >= 3
The deviation is tiny, but fails the overall build result. Since the sleep test is not terribly important as gate keeper for travis tests, let's just exclude it for this board.
--- .travis.yml | 1 + 1 file changed, 1 insertion(+)
.travis.yml +1 -0
@@ -244,6 +244,7 @@ matrix: BUILDMAN="^vexpress_ca9x4$" - env: - TEST_PY_BD="integratorcp_cm926ejs" + TEST_PY_TEST_SPEC="not sleep" TEST_PY_ID="--id qemu" BUILDMAN="^integratorcp_cm926ejs$" - env:
Signature · 1 line
1.8.5.6
PATCH v2 6/6 Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
Quoted 10 lines · Alexander Graf
Most of the time when running the sleep test in Travis for the
integratorcp_cm926ejstarget I get errors like this:E assert 2.999901056289673 >= 3
The deviation is tiny, but fails the overall build result. Since the sleep test is not terribly important as gate keeper for travis tests, let's just exclude it for this board.
Signed-off-by Alexander Graf <[email protected]>
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161121/6d7dc799/attachment.sig>
PATCH v2 6/6 Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
In reply to Alexander GrafQuoted 11 lines · Alexander Graf
Most of the time when running the sleep test in Travis for the
integratorcp_cm926ejstarget I get errors like this:E assert 2.999901056289673 >= 3
The deviation is tiny, but fails the overall build result. Since the sleep test is not terribly important as gate keeper for travis tests, let's just exclude it for this board.
Signed-off-by Alexander Graf <[email protected]>Reviewed-by Tom Rini <[email protected]>
Applied to u-boot/master, thanks!
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161127/357984fa/attachment.sig>