| 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>
|
|
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Enabling secure boot requires the following:
1) Replace our bootloader with shim.efi, which is signed by Microsoft
and recognized by production UEFI firmware.
2) Sign and rename our bootloader to grubx64.efi, which is the name
that shim.efi expects. (only x86_64 at the moment).
3) Install MokManager.efi and LUV.cer into the boot partition
4) Sign the BITS bootloader so that our bootloader can chainload to
it using the LoadImage UEFI API.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
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>
|
|
This recipe adds functionality to retrieve and install Matthew
Garret's shim signed by Microsoft. By using this signed binary,
there is not need to add our own signatures to the UEFI firmware.
However, we do need to generate a key and certificate to sign
binaries so that they are recognized by shim.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Yocto Project v1.7 requires to explicitly state the source directory.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
As of Yocto Project 1.7 the autotools recipe supports building in a
directory separate from the source directory. However, not all the
software projects support such separation. Thus, they need to inherit
from autotools-brokensep.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
The x86 architecture builds grub-efi, and hence the bootimg dependency. But
in the case of aarch64 architecture it is required to build the latest grub git repo
Hence update the bootimg dependency.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
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 leg kernel config with official leg-kernel config kernel.config
available at http://snapshots.linaro.org/kernel-hwpack/linux-leg-vexpress64/
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
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>
|
|
Add following changes required to build bootable luv-live-image for aarch64
- Add a condition to install grub2 for aarch64, x86_64.
- Create bits directory and Install bits only for x86_64 architecture.
- Add changes to generate grub.cfg
- Install the Image.
- Remove bits from grub menu for aarch64 architecture.
Signed-off-by: Naresh Bhat <naresh.bhat@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>
|
|
Add leg-kernel recipe to build ACPI enabled
kernel aarch64 targets.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
|
|
Update the recipe to align with Yocto Project v1.7 recipe for a
custom kernel.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
As of commit 40b73e46605a3b49149 ("grub-efi" change to generate EFI
image in target package"), there is not a separate native recipe
for grub efi. Thus, update the dependencies accordingly.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.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>
|
|
We run qemu on the development host, i.e., we run qemu natively. From
this perspective, the OVMF binary should be native as well. Also,
runqemu expect to find the BIOS binary in the native sysroot. Furthermore,
qemu installs its BIOS binarys in the native sysroot.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
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>
|
|
Instead of overriding the function, it suffices to simply define the
variable GRUB_BUILDIN to obtain the same effect.
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
|
|
Also, as per commit 40b73e46605a3b491498 ("grub-efi: change to generate
EFI image in target package"), the native recipe for grub-efi is
deprecated. This requires to rename our append file to reflect that
change.
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>
|
|
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>
|
|
In the dizzy version of the Yocto Project, the build and the source
directory can be different. Regarding BITS, we do not undertake any
build process. Thus, it makes sense to deploy the files from the
source directory.
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>
|
|
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Matt Fleming <matt.fleming@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>
|
|
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.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>
|
Matt Fleming
Ricardo Neri
Naresh Bhat
Gayatri Kammela