| Age | Commit message (Collapse) | Author |
|---|
|
For the purposes of wiring up LUV into an automated test environment,
it's handy to have the machine automatically reboot after a configurable
timeout period.
It's important that we don't synchronously wait for the reboot to occur
and continue to drop the user at a shell on the serial console,
otherwise we'll lose one of the most useful methods of debugging.
Read the timeout period, measured in seconds, from the EFI variable
named LuvTimeout with GUID 3b6bf55d-a6f6-45cf-9f7e-ebf3bdadf74e.
If the variable doesn't exist, use a default timeout value of 5 minutes.
The reboot functionality can be disabled by specifying the
"luv.noreboot" kernel command line parameter.
Acked-by: Ricardo Neri <ricardo.neri@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
When running automated tests it's super handy to be able to power off
the machine once the tests have completed. This signals to any
monitoring processes/machines that results are ready to be inspected.
If you've got a smart PDU you should be able to query it for the
machine's status to know when it's off, but a poor man's solution would
be to ping the machine and wait a couple of seconds extra once it
disappears from the network.
Reviewed-by: Naresh Bhat <naresh.bhat@linaro.org>
Tested-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
In order to enable secure boot without having to use custom certificates,
we use a shim binary signed by Microsoft. Thus, we must obtain the
shim file before builidng the live image.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Upgrade fwts to version 15.03.00. Along with the latest patch
efi_runtime-ensure-we-don-t-allocate-a-zero-byte-buf.patch
This bug is being tracked on bugz
Ubuntu - https://bugs.launchpad.net/ubuntu/+source/fwts/+bug/1429890
Linaro - https://bugs.linaro.org/show_bug.cgi?id=1319
Remove all the other patches which are already upstreamed on FWTS.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Update ACPI enabled leg-kernel commandline arguments.
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Skip some packages for aarch64. The following packages built
only for x86 architecture
- chipsec
- kexec
- vmcore-dmesg
- bits
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
As we move to Yocto Project v1.7, changes in the license require
to update the checksum for it.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
The OVMF binary is used by qemu. We we use qemu from the runqemu
script we use it natively. Thus, we also need to generate a OVMF
binary that is native. This follows the same approach as qemu, which
builds and installs its BIOS binaries as native when built natively.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
As of Yocto Project v1.6, all the recipes that inherit from cmake
utilze separate source and build directories. This is not supported
by efivarfs. Thus, build in-place in the source directory.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
As of Yocto Project 1.6, separe build and source directories are used for
all the recipes that inherit from cmake. Some autotools-based software
pieces fails to build with a separate build directory. This is the case
of FWTS. Thus, inherit from autotools-brokensep.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
As of commit f1cdef5656195566, libjson is known as json-c. Update
the FWTS recipe accordingly.
|
|
Commit 1034518fa73b742e81f ("image.bbclass: default USE_DEVFS to '1'") sets
USE_DEVFS to "1" so that makedevs is not used to populate the /dev directory.
This because it will be populated by the kernel. However, this is only true
for a final rootfs, not for an initramfs. LUV only uses an initramfs but
still needs to have /dev populated. Thus, set USE_DEVFS as "0".
See further info in the kernel's Documentation/early-userspace/README file.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
The UEFI specification does not define the maximum length for the
variable name. Thus, it may happen that some firmware implementations
have variable names longer than 1024 characters. Rather than limiting
the maximum size to 1024 characters, set the initial size to 1024 chars
and enlarge as required.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
We trust the name_size passed by the user_space. Thus, there is not
need to copy from user more bytes than specified.
Furthermore, this behavior could mask potential problems in the
firmware: to start traversing the list of variable names, some firmware
implementations may just blindly check if name[0] is '\0' without
even checking if the size of the buffer passed by the operating system
is at least 2 bytes (UEFI variable names are stored in strings of 2-byte
characters). This behaviour is wrong as the firmware must not access
memory beyond the name buffer. By providing a 1024-bytes buffer of
zeroes we allow the name[0] == '\0' to pass, regardless of the size
of the buffer.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
The memory used to copy the variable name/data from userspace and back is
supplied by the userspace. Thus, we must not write beyond the boundaries
of the supplied memory. Otherwise, problems may arise (e.g., segmentation
faults). However, the UEFI runtime service functions GetNextVariableName/
GetVariable can change the size of the memory if, for instance, the
buffer is too small. The firmware could also be defective.
Hence, only copy to the userspace the variable name/data if the UEFI
functions return successfully. Also, in case there is a defect in the
firmware, only copy to the userspace the variable name/data if the needed
memory is less or equal to what the userspace provide.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
This is a continuation from a work started on commit c2268a9b23a9048bad2040
(fwts: Copied the structure from userland locally in kernel space. )Data structures
used by the FWTS' efi_runtime module are mostly collections of pointers. Such
pointers still point to userspace addresses when used by the driver. Thus, it
is wrong to dereference those pointers by accessing the members of the structures.
Instead, make a deep local copy of the userspace structures and then individually
access the userspace data with the put/get_user copy_to/from_user functions.
Cc: Pradeep Gaddam <pradeep.r.gaddam@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Using a tag causes bitbake to access the remote reposity to find
the corresponding commit ID for the tag. Builds can be made faster
by avoiding that extra step. Thus, this is the usual manner to refer
to SRCREVs in bitbake recipes.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
The CHIPSEC test suite was disabled in the commit #af66ed38bad4
because of hang/freeze issues when running on ASUS P8H67-M LE
hardware as described in issue #7.
Chipsec is know to work well on various platform based on
Broadwell and Haswell. It also ran correctly on HP Elite Book
8470p.
But users are starting to ask for this test suite to be included
in the LUV. There's no sense in disabling it entirely if it hangs
on a specific platform as described in issue #7. So let's enable
CHIPSEC for users test out!
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Modify luv-parser-chipsec to get a timestamp on frontline of each
unittest when chipsec is executed. This provides a better understanding
of how much time each of the unit tests take to run.
Changes meets the schema 1.1 version updated in the luv-test-parser
file by Matt Fleming (commit 3d6102e137422f884327290f81abd1004f61318e)
and now the format looks like this:
"1.1 timestamp chipsec unittest RESULT 1 0 0 0"
Additionally, flush stdout manually from gawk to improve interaction
with the serial output. Further detail can be found in commit
72d7be73daecfbd30050d1d465ab8c0c89d1d262.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
The INFO results currently printed for fwts fail to emit interesting
parts of the log results, due to the following expression in awk,
substring($0, index($0, $8))
I'm not at all sure what the purpose of printing the substring starting
at $8 was, but needless to say that weird things happen if there aren't
8 words on the input line (some of the fwts INF messages are less than 8
words).
With this change, instead of seeing the following in the parsed
directory,
1.1 <timestamp> fwts cpufreq INFO P-State tests.
1.1 <timestamp> fwts cpufreq INFO system, this test steps through
1.1 <timestamp> fwts cpufreq INFO that the BIOS
we now see this instead,
1.1 <timestamp> fwts cpufreq INFO Test 1 of 1: CPU P-State tests.
1.1 <timestamp> fwts cpufreq INFO For each processor in the system, this test steps through
1.1 <timestamp> fwts cpufreq INFO the various frequency states (P-states) that the BIOS
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Modify luv-parser-efivarfs to get a timestamp on
frontline of each unittest when efivarfs executed
Changes will meet the schema 1.1 version updated
in the luv-test-parser file by Matt Fleming and now the
format looks like this
"1.1 timestamp efivarfs unittest RESULT 1 0 0 0"
Patch provides the clear understanding
of how much time did each of the unittests take to run
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Modify luv-parser-fwts to get a timestamp on
frontline of each unittest when fwts executed
Changes will meet the schema 1.1 version updated
in the luv-test-parser file by Matt Fleming and now the
format looks like this
"1.1 timestamp fwts unittest RESULT 1 0 0 0"
Patch provides the clear understanding of how much
time did each of the unittests take to run
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Including a timestamp field in the output of the test results is useful
for gathering performance data, i.e. how long did each unit test take to
run.
Increment the schema version to v1.1 while retaining backwards
compatibility with v1.0. This allows parsers to be upgraded piece-meal
to the new schema.
Upgrading parsers individually is very powerful, since we don't
currently have any way to gather timestamp data from BITS, and can't
update the BITS parser to v1.1 of the schema right now.
Cc: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
If no file system type is specified when creating partitions using
parted (as is currently the case in the luv-live-image recipe) a default
value is used, which happens to be 83 (Linux).
Brian reports that this is causing the luv-results partition to not be
mounted and displayed correctly on his Windows 7 machine, and that some
of the Windows disk management tools are getting kinda confused.
Specify "fat32" when creating partitions, so that the partition label
matches reality.
Reported-by: Brian Richardson <brian.richardson@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Windows will not mount and display more than one partition on a
removable disk.
Make the results partiion the first partition on the image so that users
are able to easily find the test results. Having this one partition
restriction isn't a problem otherwise, since there's little value in
auto-mounting the other partition (the EFI System Partition) anyway.
Of course, we're assuming firmware is smart enough to find the EFI
System Partition based on the partition table.
Fixes issue #23.
Reported-by: William Leara <williamleara@gmail.com>
Debugged-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Tested-by: Gayatri Kammela <gayatri.kammela@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
As more LUV versions are released and the user base grows, it is important to
know which particular version of LUV a given user is running. Knowing the
version makes it easier to provide support and comments regarding bugs and
supported features.
Containing a summary of all the tests, luv.results is a good place to print
the LUV version. The version is pulled from the /etc/issue file, which is
updated with every release.
While here, update also the welcome message in the console to depict the
LUV version.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The internal buffering that gawk does makes the test output pretty
useless, because it's not always possible to tell which test is
currently running. For example, a test may have completed but the output
will not appear on the screen until the output buffer fills and is
subsequently flushed. Effectively all the unit test results from a
single test suite are output as one block.
The wakealarm test from fwts provides a good illustration of the
user-visible problem. This test takes a number of seconds to complete,
but because all the fwts results are output in one go, it's not possible
to attribute delays to any one individual unit test.
Explicitly flush all open file descriptors and pipes anytime that we
print something from gawk.
This gives much better user interaction when looking at the serial
console because it's now possible to figure out which tests have the
longest latencies.
Whenever a unit test begins execution a message will be printed on the
serial console immediately, e.g.
[+] wakealarm...
and when it finishes (in this case after multiple seconds) the result
will be printed too,
[+] wakealarm... passed
Tested-by: Gayatri Kammela <gayatri.kammela@intel.com>
Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
There's some latency somewhere in the test result pipeline, and it's
impossible to trace noticable hangs when writing test results to the
console to the offending unit test.
Just simplify the pipeline, and pipe the result output directly to the
console and results files instead of passing it through another instance
of gawk before it hits the console, since hunting down buffer-related
delays in gawk is extremely tedious.
There's no user-visible change with this patch - it's preparatory work
for a later patch that aggressively flushes the gawk output buffer.
Tested-by: Gayatri Kammela <gayatri.kammela@intel.com>
Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Providing verbose kernel output on the serial console during boot is a
useful way to debug issues. It also provides a much more informative
message of what is currently happening.
Enable both the standard ttyS0 device and ttyPCH0 which is the device
used on the Intel Minnowboard.
Tested-by: Gayatri Kammela <gayatri.kammela@intel.com>
Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
We've no need to turn a data structure on the stack into a pointer and
use get_user() on a kernel address, and in fact, doing so is likely to
return -EFAULT, because the argument isn't a valid user address.
This bug was introduced in commit c2268a9b23a9 ("fwts: Copied the
structure from userland locally in kernel space"), and causes a
uefirttime failure.
Cc: Pradeep Gaddam <pradeep.r.gaddam@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
A recent fix to change a securebootcert failure into an info message was
merged into upstream fwts. We're hitting this false positive on a number
of machines.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This patch was merged in V14.07.00 of fwts but we're currently on
V14.03.01.
We're seeing microcode test failures on a number of Haswell machines,
which shouldn't really be failures. This patch from upstream fixes that.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
LuvOS is intended to be an automated testing tool. Thus, it does really
require much interaction from the user other than inserting the bootable
media, and removing it when tests are complete. Thus, we inform better
to the user what to do when the tests are complete.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Provide a luv splash screen for grub's use, which informs the user that
we're currently running boot tests.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
bits comes with its own version of the grub bootloader, with custom
modules installed as part of the grub image, for example a python module
to interpret the python tests.
We must install this boot loader alongside our default one, along with
the necessary parsers and test runners to extract the results of the
bits tests from userland.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Make sure kernel-efi-warnings is included in the ramfs filesystem.
kerne-efi-warnings is a simple script that analyzes the kernel
messages to search for warnings that the kernel might issue if/when
it finds potential bugs in the UEFI firmware.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Add a recipe to install kernel-efi-warnings. As it inherits from
luv-test, it also takes care of installing the luv-parser.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
In order for the LuvOS test manager to take the rest results of
kernel-efi-warnings, we need a parser that presents the results in
a format that it can understand.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>sdfsdf
|
|
The Linux kernel provides lots of information about its errands
with the UEFI firmware at boot time. However, such information is
buried inside the dmesg buffer. Automated test resources, such as
LuvOS, need automated tools to find, parse and format such
information.
kernel-efi-warnings rely on the dmesg buffer to find specific
expressions. The absence or presence of such expressions are treated
as a test pass/fail.
For now, the scripts only looks for the warnings that the kernel
issues if it detects illegal accesses to the EFI_BOOT_SERVICES_*
memory regions.
The script is intended to grow as mroe kernel tests become available.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
When we have structures that contain pointers, we cannot just do double
dereference on it as in struct->pointer->value. This will end up as a
Page Fault. To fix this problem, I changed efi_runtime kernel module to
first fetch the entire structure into a local copy on stack and use that
to reference the other data members of the struct.
Signed-off-by: Pradeep Gaddam <Pradeep.r.Gaddam@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This SVN revision has a fix for build failures under GCC 4.9 for x86_64
targets. This will ease eventual upstreaming of the OVMF recipe to Yocto
master, which uses GCC 4.9.
The bug is described on the EDK2 mailing list here:
http://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg07451.html
GCC 4.9 changed an alignment from 32 bytes to 64 bytes when building for a 64-
bit target, whereas OVMF was built with the expectation that the alignment
would be 32 bytes. This mismatch caused a build failure that looked like this:
GenFw: ERROR 3000: Invalid
Unsupported section alignment.
SVN revision 15699 of EDK2 includes a fix for this issue by the upstream EDK2
developers. When compiling with GCC 4.9 for a 64-bit target, the build OVMF
build configuration now anticipates a 64-byte alignment.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This fixes an issue where the OVMF recipe always built an x86_64 firmware
regardless of the target architecture or target machine. This issue manifested
itself when qemu-system-i386 was used on an OVMF firmware image-- QEMU would
exit immediately rather than proceeding with the boot process.
The x86_64 firmware was unaffected by this issue.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
While EDK2 has many components that support ARM, OVMF is not one of them. This
should be reflected in the BitBake recipe for OVMF.
This is accomplished by adding a COMPATIBLE_HOST annotation to ovmf_git.bb.
Signed-off-by: Max Eliaser <max.eliaser@intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The build.sh build script in OvmfPkg allows us to optionally specify a
toolchain identifer, which we're currently not doing. By not passing a
toolchain ID directly build.sh invokes the build machine's compiler to
figure it out.
The important point in all of this is that the version identifier is
used in the ovmf build path, which means that if build machine's
compiler is upgraded/downgraded we can end up with multiple ovmf build
directories.
Pass the target's gcc version to build.sh instead.
Reported-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
edk2 does not lend itself to cross-compiling in any form. Instead of
trying to play nice and override ${CC}, etc via the usual methods, just
write our toolchain variables directly in the necessary Makefiles.
The upside is that we get to drop a couple of patches we were carrying.
The downside is that this is a terrible hack and will likely break when
we move forward to newer edk2 versions.
Until such time that BaseTools supports proper configuration of a build
toolchain, this is the best we can do.
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The dmesg buffer can provide valuable information to determine
the causes of a kernel crash. When the systems boots to
runlevel 3, the luv-crash-handler uses vmcore-dmesg to recover
the dmesg buffer from the vmcore dump and saves it to the LuvOS
test results partition.
This information can then be sent to the developers to investigate
further on the causes of the crash.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The waiting is done already by the luv-crash-handler. Thus, there
is not need to repeat the waiting here.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Change
commit 0c91196fcbb953393b3e2f5623b1edc5b40aa445
Author: Andrea Adami <andrea.adami@gmail.com>
Date: Mon Jan 9 23:46:13 2012 +0100
explicitly splits the packages for kexec and kdump. Thus, rather
than generically install kexec-tools. State explicitly which
tools need to be installed.
kexec is needed to reboot a Linux kernel from Linux. vmcore-dmesg
is needed to extract the dmesg buffer from the /proc/vmcore dump
file.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
This reverts commit fcdb6a8c43159704ba16fe1c56a045fa53053180.
The chipsec tests cause one of my test machines to lockup. It's highly
likely that other people will experience similar issues.
The fact that the tests cause lockup isn't the biggest problem, it's
that there's absolutely zero diagnostic information provided to the
user, so they've no data to report other than "my machine freezes".
Disable the tests for now until we can provide useful ways of diagnosing
lockups.
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
Matt Fleming
Ricardo Neri
Naresh Bhat
Gayatri Kammela
Pradeep Gaddam
Max Eliaser