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

+@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to