[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Alexander Graf]

We have all the building blocks now to run arbitrary efi applications
in travis. The most important one out there is grub2, so let's add
a simple test to verify that grub2 still comes up.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

This patch depends on the previous travis efi_loader enablement

v1 -> v2:

  - Fix syntax errors
  - Make SMBIOS check conditional (missing cmd on armv7 binary)
---
 .travis.yml                      |  8 ++++++
 test/py/tests/test_efi_loader.py | 57 +++++++++++++++++++++++++++++++++-------
 2 files changed, 55 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 1957734..b4ae71a 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -29,6 +29,9 @@ addons:
     - gcc-arm-linux-gnueabihf
     - gcc-aarch64-linux-gnu
     - iasl
+    - grub-efi-ia32-bin
+    - rpm2cpio
+    - wget
 
 install:
  # install latest device tree compiler
@@ -45,6 +48,9 @@ install:
  - virtualenv /tmp/venv
  - . /tmp/venv/bin/activate
  - pip install pytest
+ - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap lsefi lsefisystab efinet tftp minicmd
+ - mkdir ~/grub2-arm
+ - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di )
 
 env:
   global:
@@ -88,6 +94,8 @@ script:
  # "-k something" even when $TEST_PY_TEST_SPEC doesnt need a custom
  # value.
  - export UBOOT_TRAVIS_BUILD_DIR=`cd .. && pwd`/.bm-work/${TEST_PY_BD};
+   cp ~/grub_x86.efi $UBOOT_TRAVIS_BUILD_DIR/;
+   cp ~/grub2-arm/usr/lib/grub2/arm-efi/grub.efi $UBOOT_TRAVIS_BUILD_DIR/grub_arm.efi;
    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}"
diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py
index 7bf0170..5d7f5db 100644
--- a/test/py/tests/test_efi_loader.py
+++ b/test/py/tests/test_efi_loader.py
@@ -104,20 +104,18 @@ def test_efi_setup_static(u_boot_console):
     global net_set_up
     net_set_up = True
 
- at pytest.mark.buildconfigspec('cmd_bootefi_hello_compile')
-def test_efi_helloworld_net(u_boot_console):
-    """Run the helloworld.efi binary via TFTP.
+def fetch_tftp_file(u_boot_console, env_conf):
+    """Grab an env described file via TFTP and return its address
 
-    The helloworld.efi file is downloaded from the TFTP server and gets
-    executed.
+    A file as described by an env config <env_conf> is downloaded from the TFTP
+    server. The address to that file is returned.
     """
-
     if not net_set_up:
         pytest.skip('Network not initialized')
 
-    f = u_boot_console.config.env.get('env__efi_loader_helloworld_file', None)
+    f = u_boot_console.config.env.get(env_conf, None)
     if not f:
-        pytest.skip('No hello world binary specified in environment')
+        pytest.skip('No %s binary specified in environment' % env_conf)
 
     addr = f.get('addr', None)
     if not addr:
@@ -133,14 +131,26 @@ def test_efi_helloworld_net(u_boot_console):
 
     expected_crc = f.get('crc32', None)
     if not expected_crc:
-        return
+        return addr
 
     if u_boot_console.config.buildconfig.get('config_cmd_crc32', 'n') != 'y':
-        return
+        return addr
 
     output = u_boot_console.run_command('crc32 %x $filesize' % addr)
     assert expected_crc in output
 
+    return addr
+
+ at pytest.mark.buildconfigspec('cmd_bootefi_hello_compile')
+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.
+    """
+
+    addr = fetch_tftp_file(u_boot_console, 'env__efi_loader_helloworld_file')
+
     output = u_boot_console.run_command('bootefi %x' % addr)
     expected_text = 'Hello, world'
     assert expected_text in output
@@ -156,3 +166,30 @@ def test_efi_helloworld_builtin(u_boot_console):
     output = u_boot_console.run_command('bootefi hello')
     expected_text = 'Hello, world'
     assert expected_text in output
+
+ at pytest.mark.buildconfigspec('cmd_bootefi')
+def test_efi_grub_net(u_boot_console):
+    """Run the grub.efi binary via TFTP.
+
+    The grub.efi file is downloaded from the TFTP server and gets
+    executed.
+    """
+
+    addr = fetch_tftp_file(u_boot_console, 'env__efi_loader_grub_file')
+
+    u_boot_console.run_command('bootefi %x' % addr, wait_for_prompt=False)
+
+    # Verify that we have an SMBIOS table
+    check_smbios = u_boot_console.config.env.get('env__efi_loader_check_smbios', False)
+    if check_smbios:
+        u_boot_console.wait_for('grub>')
+        output = u_boot_console.run_command('lsefisystab', wait_for_prompt=False, wait_for_echo=False)
+        u_boot_console.wait_for('SMBIOS')
+
+    # Then exit cleanly
+    u_boot_console.wait_for('grub>')
+    output = u_boot_console.run_command('exit', wait_for_prompt=False, wait_for_echo=False)
+    u_boot_console.wait_for('r = 0')
+
+    # And give us our U-Boot prompt back
+    u_boot_console.run_command('')
-- 
1.8.5.6

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Stephen Warren]

On 11/18/2016 05:18 AM, Alexander Graf wrote:
> We have all the building blocks now to run arbitrary efi applications
> in travis. The most important one out there is grub2, so let's add
> a simple test to verify that grub2 still comes up.

> diff --git a/.travis.yml b/.travis.yml

> @@ -45,6 +48,9 @@ install:
>   - virtualenv /tmp/venv
>   - . /tmp/venv/bin/activate
>   - pip install pytest
> + - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap lsefi lsefisystab efinet tftp minicmd
> + - mkdir ~/grub2-arm
> + - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di )

Do we really want to do this for all the build-only jobs too? I might 
have expected to do this inside the test scripts that actually use those 
binaries.

> diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py

> + at pytest.mark.buildconfigspec('cmd_bootefi')

> +    u_boot_console.run_command('bootefi %x' % addr, wait_for_prompt=False)
> +
> +    # Verify that we have an SMBIOS table
> +    check_smbios = u_boot_console.config.env.get('env__efi_loader_check_smbios', False)
> +    if check_smbios:
> +        u_boot_console.wait_for('grub>')
> +        output = u_boot_console.run_command('lsefisystab', wait_for_prompt=False, wait_for_echo=False)
> +        u_boot_console.wait_for('SMBIOS')
> +
> +    # Then exit cleanly
> +    u_boot_console.wait_for('grub>')
> +    output = u_boot_console.run_command('exit', wait_for_prompt=False, wait_for_echo=False)
> +    u_boot_console.wait_for('r = 0')
> +
> +    # And give us our U-Boot prompt back
> +    u_boot_console.run_command('')

I can't help wondering if adding push_prompt() function (for use in a 
Python "with" statement) to u_boot_console wouldn't be better; that 
would avoid all the wait_for_prompt=False and wait_for(prompt) logic there.

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Tom Rini]

On Mon, Nov 21, 2016 at 03:21:43PM -0700, Stephen Warren wrote:
> On 11/18/2016 05:18 AM, Alexander Graf wrote:
> >We have all the building blocks now to run arbitrary efi applications
> >in travis. The most important one out there is grub2, so let's add
> >a simple test to verify that grub2 still comes up.
> 
> >diff --git a/.travis.yml b/.travis.yml
> 
> >@@ -45,6 +48,9 @@ install:
> >  - virtualenv /tmp/venv
> >  - . /tmp/venv/bin/activate
> >  - pip install pytest
> >+ - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap lsefi lsefisystab efinet tftp minicmd
> >+ - mkdir ~/grub2-arm
> >+ - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di )
> 
> Do we really want to do this for all the build-only jobs too? I
> might have expected to do this inside the test scripts that actually
> use those binaries.

So, it's the difference between making various jobs / stanzas more
correct vs taking more time to do stuff.  Unless this starts to push the
"catch-all" arm job over the time limit, I don't think it's a big deal
either way.  And since travis-ci will tell us how long a given stanza
takes we'll have a good idea pretty quick on if that's starting to take
too long.  That said, I don't have a strong opinion here and it wouldn't
be too hard to move all of this into being under the TEST_PY_BD check
and since we aren't relying on apt, it's not going to be time-in-apt
factor.

-- 
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/ac79e439/attachment.sig>

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Alexander Graf]

On 21/11/2016 23:31, Tom Rini wrote:
> On Mon, Nov 21, 2016 at 03:21:43PM -0700, Stephen Warren wrote:
>> On 11/18/2016 05:18 AM, Alexander Graf wrote:
>>> We have all the building blocks now to run arbitrary efi applications
>>> in travis. The most important one out there is grub2, so let's add
>>> a simple test to verify that grub2 still comes up.
>>
>>> diff --git a/.travis.yml b/.travis.yml
>>
>>> @@ -45,6 +48,9 @@ install:
>>>  - virtualenv /tmp/venv
>>>  - . /tmp/venv/bin/activate
>>>  - pip install pytest
>>> + - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap lsefi lsefisystab efinet tftp minicmd
>>> + - mkdir ~/grub2-arm
>>> + - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di )
>>
>> Do we really want to do this for all the build-only jobs too? I
>> might have expected to do this inside the test scripts that actually
>> use those binaries.
>
> So, it's the difference between making various jobs / stanzas more
> correct vs taking more time to do stuff.  Unless this starts to push the
> "catch-all" arm job over the time limit, I don't think it's a big deal
> either way.  And since travis-ci will tell us how long a given stanza
> takes we'll have a good idea pretty quick on if that's starting to take
> too long.  That said, I don't have a strong opinion here and it wouldn't
> be too hard to move all of this into being under the TEST_PY_BD check
> and since we aren't relying on apt, it's not going to be time-in-apt
> factor.

If we move it into TEST_PY_BD, we would either run the same sequence 
over and over again for individual tests or check if the file exists 
inside the generation path. Either way, it will get less readable :).

Overall, we're talking of 1s of build time for this:

   https://travis-ci.org/agraf/u-boot/jobs/177000864

so I'd definitely prefer to keep it simple rather than optimized.


Alex

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Alexander Graf]

On 21/11/2016 23:21, Stephen Warren wrote:
> On 11/18/2016 05:18 AM, Alexander Graf wrote:
>> We have all the building blocks now to run arbitrary efi applications
>> in travis. The most important one out there is grub2, so let's add
>> a simple test to verify that grub2 still comes up.
>
>> diff --git a/.travis.yml b/.travis.yml
>
>> @@ -45,6 +48,9 @@ install:
>>   - virtualenv /tmp/venv
>>   - . /tmp/venv/bin/activate
>>   - pip install pytest
>> + - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap
>> lsefi lsefisystab efinet tftp minicmd
>> + - mkdir ~/grub2-arm
>> + - ( cd ~/grub2-arm; wget -O -
>> http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm
>> | rpm2cpio | cpio -di )
>
> Do we really want to do this for all the build-only jobs too? I might
> have expected to do this inside the test scripts that actually use those
> binaries.
>
>> diff --git a/test/py/tests/test_efi_loader.py
>> b/test/py/tests/test_efi_loader.py
>
>> + at pytest.mark.buildconfigspec('cmd_bootefi')
>
>> +    u_boot_console.run_command('bootefi %x' % addr,
>> wait_for_prompt=False)
>> +
>> +    # Verify that we have an SMBIOS table
>> +    check_smbios =
>> u_boot_console.config.env.get('env__efi_loader_check_smbios', False)
>> +    if check_smbios:
>> +        u_boot_console.wait_for('grub>')
>> +        output = u_boot_console.run_command('lsefisystab',
>> wait_for_prompt=False, wait_for_echo=False)
>> +        u_boot_console.wait_for('SMBIOS')
>> +
>> +    # Then exit cleanly
>> +    u_boot_console.wait_for('grub>')
>> +    output = u_boot_console.run_command('exit',
>> wait_for_prompt=False, wait_for_echo=False)
>> +    u_boot_console.wait_for('r = 0')
>> +
>> +    # And give us our U-Boot prompt back
>> +    u_boot_console.run_command('')
>
> I can't help wondering if adding push_prompt() function (for use in a
> Python "with" statement) to u_boot_console wouldn't be better; that
> would avoid all the wait_for_prompt=False and wait_for(prompt) logic there.

What would that function do? The same?

JFYI, I've added the html log output for the sequence above at the end 
of the email.


Alex


tftpboot 80400000 grub_arm.efi
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
Using smc911x-0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'grub_arm.efi'.
Load address: 0x80400000
Loading: 
*%08#################################################################
          #################################################################
          ##############
          14.3 MiB/s
done
Bytes transferred = 732672 (b2e00 hex)
smc911x: MAC 52:54:00:12:34:56
=> crc32 80400000 $filesize
CRC32 for 80400000 ... 804b2dff ==> 4afa7ec6
=> bootefi 80400000
## Starting EFI application at 80400000 ...
WARNING: Invalid device tree, expect boot to fail
Scanning disks on mmc...
Card did not respond to voltage select!
MMC Device 1 not found
MMC Device 2 not found
MMC Device 3 not found
Found 0 disks
%1b[?25hWelcome to GRUB!

smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
smc911x: detected LAN9118 controller
smc911x: phy initialized
smc911x: MAC 52:54:00:12:34:56
%1b[2J%1b[18t%1b[1;26fGNU GRUB  version 2.02~beta2

%1b[?25h Minimal BASH-like line editing is supported. For the first 
word, TAB
    lists possible command completions. Anywhere else TAB lists possible
    device or file completions.



grub> 
%1b[9;6fe%1b[9;7f%1b[9;7fx%1b[9;8f%1b[9;8fi%1b[9;9f%1b[9;9ft%1b[9;10f
## Application terminated, r = 0

[U-Boot] [U-Boot,v2] travis: Add efi_loader grub2 test

[Tom Rini]

On Fri, Nov 18, 2016 at 01:18:00PM +0100, Alexander Graf wrote:

> We have all the building blocks now to run arbitrary efi applications
> in travis. The most important one out there is grub2, so let's add
> a simple test to verify that grub2 still comes up.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>

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/f865d8eb/attachment.sig>

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Stephen Warren]

On 11/21/2016 04:15 PM, Alexander Graf wrote:
>
>
> On 21/11/2016 23:31, Tom Rini wrote:
>> On Mon, Nov 21, 2016 at 03:21:43PM -0700, Stephen Warren wrote:
>>> On 11/18/2016 05:18 AM, Alexander Graf wrote:
>>>> We have all the building blocks now to run arbitrary efi applications
>>>> in travis. The most important one out there is grub2, so let's add
>>>> a simple test to verify that grub2 still comes up.
>>>
>>>> diff --git a/.travis.yml b/.travis.yml
>>>
>>>> @@ -45,6 +48,9 @@ install:
>>>>  - virtualenv /tmp/venv
>>>>  - . /tmp/venv/bin/activate
>>>>  - pip install pytest
>>>> + - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo
>>>> lsefimmap lsefi lsefisystab efinet tftp minicmd
>>>> + - mkdir ~/grub2-arm
>>>> + - ( cd ~/grub2-arm; wget -O -
>>>> http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm
>>>> | rpm2cpio | cpio -di )
>>>
>>> Do we really want to do this for all the build-only jobs too? I
>>> might have expected to do this inside the test scripts that actually
>>> use those binaries.
>>
>> So, it's the difference between making various jobs / stanzas more
>> correct vs taking more time to do stuff.  Unless this starts to push the
>> "catch-all" arm job over the time limit, I don't think it's a big deal
>> either way.  And since travis-ci will tell us how long a given stanza
>> takes we'll have a good idea pretty quick on if that's starting to take
>> too long.  That said, I don't have a strong opinion here and it wouldn't
>> be too hard to move all of this into being under the TEST_PY_BD check
>> and since we aren't relying on apt, it's not going to be time-in-apt
>> factor.
>
> If we move it into TEST_PY_BD, we would either run the same sequence
> over and over again for individual tests or check if the file exists
> inside the generation path. Either way, it will get less readable :).

I believe each test job configures a new container, so no, the change I 
suggested would mean a given job would either:

a) Run a build without downloading the test EFI RPM.

b) Run a test and download the EFI RPM once.

It seems trivial to just put this in the right place, although 
admittedly if it's quick it's not going to save much, except that it 
will make all the compile-only tests not depend on so many 
potentially-intermittent network accesses.

> Overall, we're talking of 1s of build time for this:
>
>   https://travis-ci.org/agraf/u-boot/jobs/177000864
>
> so I'd definitely prefer to keep it simple rather than optimized.

[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Stephen Warren]

On 11/21/2016 04:21 PM, Alexander Graf wrote:
>
>
> On 21/11/2016 23:21, Stephen Warren wrote:
>> On 11/18/2016 05:18 AM, Alexander Graf wrote:
>>> We have all the building blocks now to run arbitrary efi applications
>>> in travis. The most important one out there is grub2, so let's add
>>> a simple test to verify that grub2 still comes up.
>>
>>> diff --git a/.travis.yml b/.travis.yml
>>
>>> @@ -45,6 +48,9 @@ install:
>>>   - virtualenv /tmp/venv
>>>   - . /tmp/venv/bin/activate
>>>   - pip install pytest
>>> + - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap
>>> lsefi lsefisystab efinet tftp minicmd
>>> + - mkdir ~/grub2-arm
>>> + - ( cd ~/grub2-arm; wget -O -
>>> http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm
>>>
>>> | rpm2cpio | cpio -di )
>>
>> Do we really want to do this for all the build-only jobs too? I might
>> have expected to do this inside the test scripts that actually use those
>> binaries.
>>
>>> diff --git a/test/py/tests/test_efi_loader.py
>>> b/test/py/tests/test_efi_loader.py
>>
>>> + at pytest.mark.buildconfigspec('cmd_bootefi')
>>
>>> +    u_boot_console.run_command('bootefi %x' % addr,
>>> wait_for_prompt=False)
>>> +
>>> +    # Verify that we have an SMBIOS table
>>> +    check_smbios =
>>> u_boot_console.config.env.get('env__efi_loader_check_smbios', False)
>>> +    if check_smbios:
>>> +        u_boot_console.wait_for('grub>')
>>> +        output = u_boot_console.run_command('lsefisystab',
>>> wait_for_prompt=False, wait_for_echo=False)
>>> +        u_boot_console.wait_for('SMBIOS')
>>> +
>>> +    # Then exit cleanly
>>> +    u_boot_console.wait_for('grub>')
>>> +    output = u_boot_console.run_command('exit',
>>> wait_for_prompt=False, wait_for_echo=False)
>>> +    u_boot_console.wait_for('r = 0')
>>> +
>>> +    # And give us our U-Boot prompt back
>>> +    u_boot_console.run_command('')
>>
>> I can't help wondering if adding push_prompt() function (for use in a
>> Python "with" statement) to u_boot_console wouldn't be better; that
>> would avoid all the wait_for_prompt=False and wait_for(prompt) logic
>> there.
>
> What would that function do? The same?

The internal implementation would likely look the same, but it would 
avoid needing to implement/replicate such low-level prompt-parsing 
details in each test that invokes "sub-commands" with different prompts.