* [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage
@ 2016-11-17 17:31 Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
` (5 more replies)
0 siblings, 6 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
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
--
1.8.5.6
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
@ 2016-11-17 17:31 ` Alexander Graf
2016-11-19 13:48 ` Simon Glass
` (2 more replies)
2016-11-17 17:31 ` [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable Alexander Graf
` (4 subsequent siblings)
5 siblings, 3 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
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 <agraf@suse.de>
---
test/py/tests/test_net.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index 0884051..293b73a 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -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))
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
@ 2016-11-17 17:31 ` Alexander Graf
2016-11-21 13:56 ` Tom Rini
2016-11-27 14:54 ` [U-Boot] [U-Boot,v2,2/6] " Tom Rini
2016-11-17 17:31 ` [U-Boot] [PATCH v2 3/6] travis: Add python path for environments Alexander Graf
` (3 subsequent siblings)
5 siblings, 2 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
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 <agraf@suse.de>
---
.travis.yml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index 3d7fffe..acb41ea 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -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:
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 3/6] travis: Add python path for environments
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable Alexander Graf
@ 2016-11-17 17:31 ` Alexander Graf
2016-11-21 13:56 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
2016-11-17 17:31 ` [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test Alexander Graf
` (2 subsequent siblings)
5 siblings, 2 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
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 <agraf@suse.de>
---
.travis.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/.travis.yml b/.travis.yml
index acb41ea..89f78d3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -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++"
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
` (2 preceding siblings ...)
2016-11-17 17:31 ` [U-Boot] [PATCH v2 3/6] travis: Add python path for environments Alexander Graf
@ 2016-11-17 17:31 ` Alexander Graf
2016-11-19 13:48 ` Simon Glass
` (2 more replies)
2016-11-17 17:31 ` [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test Alexander Graf
5 siblings, 3 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
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 <agraf@suse.de>
---
test/py/tests/test_efi_loader.py | 158 +++++++++++++++++++++++++++++++++++++++
1 file changed, 158 insertions(+)
create mode 100644 test/py/tests/test_efi_loader.py
diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py
new file mode 100644
index 0000000..1c42653
--- /dev/null
+++ b/test/py/tests/test_efi_loader.py
@@ -0,0 +1,158 @@
+# Copyright (c) 2016, NVIDIA CORPORATION. All rights reserved.
+# Copyright (c) 2016, Alexander Graf <agraf@suse.de>
+#
+# 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
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
` (3 preceding siblings ...)
2016-11-17 17:31 ` [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test Alexander Graf
@ 2016-11-17 17:31 ` Alexander Graf
2016-11-17 21:40 ` [U-Boot] [PATCH v3 " Alexander Graf
2016-11-19 13:48 ` [U-Boot] [PATCH v2 " Simon Glass
2016-11-17 17:31 ` [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test Alexander Graf
5 siblings, 2 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
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.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
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(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index a812306..0051f76 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -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)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 03c71f7..1697dca 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -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
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index ff402dc..723288f 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -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
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2a2f23e..b16c603 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -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
diff --git a/configs/qemu-x86_efi_payload64_defconfig b/configs/qemu-x86_efi_payload64_defconfig
index c081ead..eaf0e32 100644
--- a/configs/qemu-x86_efi_payload64_defconfig
+++ b/configs/qemu-x86_efi_payload64_defconfig
@@ -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
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index f466408..fa8b91a 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -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
diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py
index 1c42653..7bf0170 100644
--- a/test/py/tests/test_efi_loader.py
+++ b/test/py/tests/test_efi_loader.py
@@ -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.
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
` (4 preceding siblings ...)
2016-11-17 17:31 ` [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it Alexander Graf
@ 2016-11-17 17:31 ` Alexander Graf
2016-11-21 14:00 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
5 siblings, 2 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 17:31 UTC (permalink / raw)
To: u-boot
Most 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.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
.travis.yml | 1 +
1 file changed, 1 insertion(+)
diff --git a/.travis.yml b/.travis.yml
index 89f78d3..1957734 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -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:
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-17 17:31 ` [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it Alexander Graf
@ 2016-11-17 21:40 ` Alexander Graf
2016-11-21 13:58 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-11-19 13:48 ` [U-Boot] [PATCH v2 " Simon Glass
1 sibling, 2 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-17 21:40 UTC (permalink / raw)
To: u-boot
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.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
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(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index a812306..0051f76 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -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)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 03c71f7..1697dca 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -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
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index ff402dc..723288f 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -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
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2a2f23e..b16c603 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -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
diff --git a/configs/qemu-x86_efi_payload64_defconfig b/configs/qemu-x86_efi_payload64_defconfig
index c081ead..eaf0e32 100644
--- a/configs/qemu-x86_efi_payload64_defconfig
+++ b/configs/qemu-x86_efi_payload64_defconfig
@@ -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
diff --git a/configs/stm32f429-discovery_defconfig b/configs/stm32f429-discovery_defconfig
index 24e2221..bb161d4 100644
--- a/configs/stm32f429-discovery_defconfig
+++ b/configs/stm32f429-discovery_defconfig
@@ -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
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index f466408..fa8b91a 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -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
diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py
index 1c42653..7bf0170 100644
--- a/test/py/tests/test_efi_loader.py
+++ b/test/py/tests/test_efi_loader.py
@@ -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.
--
1.8.5.6
^ permalink raw reply related [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
@ 2016-11-19 13:48 ` Simon Glass
2016-11-21 13:54 ` Tom Rini
2016-11-27 14:54 ` [U-Boot] [U-Boot,v2,1/6] " Tom Rini
2 siblings, 0 replies; 32+ messages in thread
From: Simon Glass @ 2016-11-19 13:48 UTC (permalink / raw)
To: u-boot
On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
> 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 <agraf@suse.de>
> ---
> test/py/tests/test_net.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test
2016-11-17 17:31 ` [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test Alexander Graf
@ 2016-11-19 13:48 ` Simon Glass
2016-11-21 13:57 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
2 siblings, 0 replies; 32+ messages in thread
From: Simon Glass @ 2016-11-19 13:48 UTC (permalink / raw)
To: u-boot
Hi Alex,
On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
> 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 <agraf@suse.de>
> ---
> 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():
Reviewed-by: Simon Glass <sjg@chromium.org>
I wonder if you should separate these two tests into different patches?
Regards,
Simon
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-17 17:31 ` [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it Alexander Graf
2016-11-17 21:40 ` [U-Boot] [PATCH v3 " Alexander Graf
@ 2016-11-19 13:48 ` Simon Glass
2016-11-19 14:13 ` Alexander Graf
1 sibling, 1 reply; 32+ messages in thread
From: Simon Glass @ 2016-11-19 13:48 UTC (permalink / raw)
To: u-boot
Hi Alex,
On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
> 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.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
> 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-19 13:48 ` [U-Boot] [PATCH v2 " Simon Glass
@ 2016-11-19 14:13 ` Alexander Graf
2016-11-19 20:02 ` Simon Glass
0 siblings, 1 reply; 32+ messages in thread
From: Alexander Graf @ 2016-11-19 14:13 UTC (permalink / raw)
To: u-boot
On 19/11/2016 14:48, Simon Glass wrote:
> Hi Alex,
>
> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>> 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.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>> 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?
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-19 14:13 ` Alexander Graf
@ 2016-11-19 20:02 ` Simon Glass
2016-11-19 21:47 ` Alexander Graf
0 siblings, 1 reply; 32+ messages in thread
From: Simon Glass @ 2016-11-19 20:02 UTC (permalink / raw)
To: u-boot
Hi Alex,
On 19 November 2016 at 07:13, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 19/11/2016 14:48, Simon Glass wrote:
>>
>> Hi Alex,
>>
>> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>>>
>>> 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.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>> ---
>>> 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?
>
>
> 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-19 20:02 ` Simon Glass
@ 2016-11-19 21:47 ` Alexander Graf
2016-11-19 23:56 ` Simon Glass
0 siblings, 1 reply; 32+ messages in thread
From: Alexander Graf @ 2016-11-19 21:47 UTC (permalink / raw)
To: u-boot
> Am 19.11.2016 um 21:02 schrieb Simon Glass <sjg@chromium.org>:
>
> Hi Alex,
>
>> On 19 November 2016 at 07:13, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>>> On 19/11/2016 14:48, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>>> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>> 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.
>>>>
>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>> ---
>>>> 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?
>>
>>
>> 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.
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-19 21:47 ` Alexander Graf
@ 2016-11-19 23:56 ` Simon Glass
2016-11-20 0:13 ` Alexander Graf
0 siblings, 1 reply; 32+ messages in thread
From: Simon Glass @ 2016-11-19 23:56 UTC (permalink / raw)
To: u-boot
Hi Alex,
On 19 November 2016 at 14:47, Alexander Graf <agraf@suse.de> wrote:
>
>
>> Am 19.11.2016 um 21:02 schrieb Simon Glass <sjg@chromium.org>:
>>
>> Hi Alex,
>>
>>> On 19 November 2016 at 07:13, Alexander Graf <agraf@suse.de> wrote:
>>>
>>>
>>>> On 19/11/2016 14:48, Simon Glass wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>>> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>> ---
>>>>> 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?
>>>
>>>
>>> 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.
>
> 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-19 23:56 ` Simon Glass
@ 2016-11-20 0:13 ` Alexander Graf
2016-11-22 17:50 ` Simon Glass
0 siblings, 1 reply; 32+ messages in thread
From: Alexander Graf @ 2016-11-20 0:13 UTC (permalink / raw)
To: u-boot
> Am 20.11.2016 um 00:56 schrieb Simon Glass <sjg@chromium.org>:
>
> Hi Alex,
>
>> On 19 November 2016 at 14:47, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>>> Am 19.11.2016 um 21:02 schrieb Simon Glass <sjg@chromium.org>:
>>>
>>> Hi Alex,
>>>
>>>> On 19 November 2016 at 07:13, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>
>>>>> On 19/11/2016 14:48, Simon Glass wrote:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>>> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>> ---
>>>>>> 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?
>>>>
>>>>
>>>> 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.
>>
>> 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.
>
> 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.
> the second with the
> existing option for the 'bootefi hello' command.
Yes, that too is what the patch does :).
Alex
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
2016-11-19 13:48 ` Simon Glass
@ 2016-11-21 13:54 ` Tom Rini
2016-11-27 14:54 ` [U-Boot] [U-Boot,v2,1/6] " Tom Rini
2 siblings, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-21 13:54 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:02PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
I've been fixing this locally by setting an address as needed in board
files. But this is probably still a good idea, so:
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable
2016-11-17 17:31 ` [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable Alexander Graf
@ 2016-11-21 13:56 ` Tom Rini
2016-11-27 14:54 ` [U-Boot] [U-Boot,v2,2/6] " Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-21 13:56 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:03PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 3/6] travis: Add python path for environments
2016-11-17 17:31 ` [U-Boot] [PATCH v2 3/6] travis: Add python path for environments Alexander Graf
@ 2016-11-21 13:56 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-21 13:56 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:04PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test
2016-11-17 17:31 ` [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test Alexander Graf
2016-11-19 13:48 ` Simon Glass
@ 2016-11-21 13:57 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
2 siblings, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-21 13:57 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:05PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v3 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-17 21:40 ` [U-Boot] [PATCH v3 " Alexander Graf
@ 2016-11-21 13:58 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v3, " Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-21 13:58 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 10:40:10PM +0100, Alexander Graf wrote:
> 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.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
2016-11-17 17:31 ` [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test Alexander Graf
@ 2016-11-21 14:00 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-21 14:00 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:07PM +0100, Alexander Graf wrote:
> Most 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.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-20 0:13 ` Alexander Graf
@ 2016-11-22 17:50 ` Simon Glass
2016-11-22 18:27 ` Tom Rini
2016-11-22 20:49 ` Alexander Graf
0 siblings, 2 replies; 32+ messages in thread
From: Simon Glass @ 2016-11-22 17:50 UTC (permalink / raw)
To: u-boot
Hi Alex,
On 19 November 2016 at 17:13, Alexander Graf <agraf@suse.de> wrote:
>
>
>> Am 20.11.2016 um 00:56 schrieb Simon Glass <sjg@chromium.org>:
>>
>> Hi Alex,
>>
>>> On 19 November 2016 at 14:47, Alexander Graf <agraf@suse.de> wrote:
>>>
>>>
>>>> Am 19.11.2016 um 21:02 schrieb Simon Glass <sjg@chromium.org>:
>>>>
>>>> Hi Alex,
>>>>
>>>>> On 19 November 2016 at 07:13, Alexander Graf <agraf@suse.de> wrote:
>>>>>
>>>>>
>>>>>> On 19/11/2016 14:48, Simon Glass wrote:
>>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>>> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>> ---
>>>>>>> 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?
>>>>>
>>>>>
>>>>> 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.
>>>
>>> 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.
Except that I don't think we need the extra CONFIG.
>
>>
>> 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.
Well if no one can compile for stm32 then it is unlikely to work
anyway. Does anyone actually use Thumb 1 with EFI?
>
> 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.
>
>> 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-22 17:50 ` Simon Glass
@ 2016-11-22 18:27 ` Tom Rini
2016-11-22 18:48 ` Alexander Graf
2016-11-22 20:49 ` Alexander Graf
1 sibling, 1 reply; 32+ messages in thread
From: Tom Rini @ 2016-11-22 18:27 UTC (permalink / raw)
To: u-boot
On Tue, Nov 22, 2016 at 10:50:50AM -0700, Simon Glass wrote:
> Hi Alex,
>
> On 19 November 2016 at 17:13, Alexander Graf <agraf@suse.de> wrote:
[snip]
> > 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.
>
> 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.
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-22 18:27 ` Tom Rini
@ 2016-11-22 18:48 ` Alexander Graf
0 siblings, 0 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-22 18:48 UTC (permalink / raw)
To: u-boot
> Am 22.11.2016 um 19:27 schrieb Tom Rini <trini@konsulko.com>:
>
>> On Tue, Nov 22, 2016 at 10:50:50AM -0700, Simon Glass wrote:
>> Hi Alex,
>>
>> On 19 November 2016 at 17:13, Alexander Graf <agraf@suse.de> wrote:
> [snip]
>>> 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.
>>
>> 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
>
> --
> Tom
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-22 17:50 ` Simon Glass
2016-11-22 18:27 ` Tom Rini
@ 2016-11-22 20:49 ` Alexander Graf
1 sibling, 0 replies; 32+ messages in thread
From: Alexander Graf @ 2016-11-22 20:49 UTC (permalink / raw)
To: u-boot
On 22/11/2016 18:50, Simon Glass wrote:
> Hi Alex,
>
> On 19 November 2016 at 17:13, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>>> Am 20.11.2016 um 00:56 schrieb Simon Glass <sjg@chromium.org>:
>>>
>>> Hi Alex,
>>>
>>>> On 19 November 2016 at 14:47, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>
>>>>> Am 19.11.2016 um 21:02 schrieb Simon Glass <sjg@chromium.org>:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>>> On 19 November 2016 at 07:13, Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>>
>>>>>>> On 19/11/2016 14:48, Simon Glass wrote:
>>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>>> On 17 November 2016 at 10:31, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>>>> ---
>>>>>>>> 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?
>>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>
> 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.
>>> 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.
>
> 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.
>> 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.
>
>>
>>> 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [U-Boot,v2,1/6] tests: net: Offset downloads to 4MB
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
2016-11-19 13:48 ` Simon Glass
2016-11-21 13:54 ` Tom Rini
@ 2016-11-27 14:54 ` Tom Rini
2 siblings, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-27 14:54 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:02PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [U-Boot,v2,2/6] Travis: Expose build dir as variable
2016-11-17 17:31 ` [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable Alexander Graf
2016-11-21 13:56 ` Tom Rini
@ 2016-11-27 14:54 ` Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-27 14:54 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:03PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [U-Boot, v2, 3/6] travis: Add python path for environments
2016-11-17 17:31 ` [U-Boot] [PATCH v2 3/6] travis: Add python path for environments Alexander Graf
2016-11-21 13:56 ` Tom Rini
@ 2016-11-27 14:55 ` Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-27 14:55 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:04PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [U-Boot, v2, 4/6] tests: Add efi_loader hello world test
2016-11-17 17:31 ` [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test Alexander Graf
2016-11-19 13:48 ` Simon Glass
2016-11-21 13:57 ` Tom Rini
@ 2016-11-27 14:55 ` Tom Rini
2 siblings, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-27 14:55 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:05PM +0100, Alexander Graf wrote:
> 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 <agraf@suse.de>
> Reviewed-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [U-Boot, v2, 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test
2016-11-17 17:31 ` [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test Alexander Graf
2016-11-21 14:00 ` Tom Rini
@ 2016-11-27 14:55 ` Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-27 14:55 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 06:31:07PM +0100, Alexander Graf wrote:
> Most 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.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
* [U-Boot] [U-Boot, v3, 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it
2016-11-17 21:40 ` [U-Boot] [PATCH v3 " Alexander Graf
2016-11-21 13:58 ` Tom Rini
@ 2016-11-27 14:55 ` Tom Rini
1 sibling, 0 replies; 32+ messages in thread
From: Tom Rini @ 2016-11-27 14:55 UTC (permalink / raw)
To: u-boot
On Thu, Nov 17, 2016 at 10:40:10PM +0100, Alexander Graf wrote:
> 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.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> Reviewed-by: Tom Rini <trini@konsulko.com>
Applied to u-boot/master, thanks!
--
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>
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2016-11-27 14:55 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-17 17:31 [U-Boot] [PATCH v2 0/6] efi_laoder: Add travis test coverage Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 1/6] tests: net: Offset downloads to 4MB Alexander Graf
2016-11-19 13:48 ` Simon Glass
2016-11-21 13:54 ` Tom Rini
2016-11-27 14:54 ` [U-Boot] [U-Boot,v2,1/6] " Tom Rini
2016-11-17 17:31 ` [U-Boot] [PATCH v2 2/6] Travis: Expose build dir as variable Alexander Graf
2016-11-21 13:56 ` Tom Rini
2016-11-27 14:54 ` [U-Boot] [U-Boot,v2,2/6] " Tom Rini
2016-11-17 17:31 ` [U-Boot] [PATCH v2 3/6] travis: Add python path for environments Alexander Graf
2016-11-21 13:56 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
2016-11-17 17:31 ` [U-Boot] [PATCH v2 4/6] tests: Add efi_loader hello world test Alexander Graf
2016-11-19 13:48 ` Simon Glass
2016-11-21 13:57 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
2016-11-17 17:31 ` [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it Alexander Graf
2016-11-17 21:40 ` [U-Boot] [PATCH v3 " Alexander Graf
2016-11-21 13:58 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v3, " Tom Rini
2016-11-19 13:48 ` [U-Boot] [PATCH v2 " Simon Glass
2016-11-19 14:13 ` Alexander Graf
2016-11-19 20:02 ` Simon Glass
2016-11-19 21:47 ` Alexander Graf
2016-11-19 23:56 ` Simon Glass
2016-11-20 0:13 ` Alexander Graf
2016-11-22 17:50 ` Simon Glass
2016-11-22 18:27 ` Tom Rini
2016-11-22 18:48 ` Alexander Graf
2016-11-22 20:49 ` Alexander Graf
2016-11-17 17:31 ` [U-Boot] [PATCH v2 6/6] Travis: Remove sleep test from integratorcp_cm926ejs-qemu test Alexander Graf
2016-11-21 14:00 ` Tom Rini
2016-11-27 14:55 ` [U-Boot] [U-Boot, v2, " Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.