There is no-longer any need to check if sequence numbers are valid, since
this is ensured by driver model. Drop the unwanted logic.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.
The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a unit test that causes an illegal instruction to occur.
The test can be run with the following commands:
=> setenv efi_selftest exception
=> bootefi selftest
This might be the output:
Executing 'exception'
EFI application triggers exception.
Illegal instruction
pc = 0x1444d016, pc_reloc = 0xffffaa078e8dd016
UEFI image [0x0000000000000000:0xffffffffffffffff] '/\selftest'
UEFI image [0x000000001444b000:0x0000000014451fff] pc=0x2016 '/bug.efi'
Resetting ...
It would tell us that the exception was triggered by an instruction
0x2016 bytes after the load address of the binary with filename /bug.efi.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
We provide a UEFI driver for block devices. When ConnectController() is
called for a handle with the EFI_BLOCK_IO_PROTOCOL this driver creates the
partitions. When DisconnectController() is called the handles for the
partitions have to be deleted. This requires that the child controllers
(partitions) open the EFI_BLOCK_IO_PROTOCOL of the controller (block IO
device) with attribute EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
A unit test is supplied to test the support for the EFI_LOAD_FILE_PROTOCOL
and the EFI_LOAD_FILE2_PROTOCOL by the LoadImage() boot service.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_load_image_from_file() should read via either of:
* EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
* EFI_LOAD_FILE_PROTOCOL
* EFI_LOAD_FILE2_PROTOCOL
To make the code readable carve out a function to load the image via the
file system protocol.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Implementing support for loading images via the EFI_LOAD_FILE_PROTOCOL
requires the boot policy as input for efi_load_image_from_path().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The EFI_LOAD_FILE_PROTOCOL_GUID and EFI_LOAD_FILE2_PROTOCOL_GUID are needed
to complement the implementation of the LoadFile() boot service.
Remove a duplicate declaration of a variable for the
EFI_LOAD_FILE2_PROTOCOL_GUID.
Move the remaining declaration to efi_boottime.c.
Add a variable for the EFI_LOAD_FILE_PROTOCOL_GUID.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For implementing support for the EFI_LOAD_FILE_PROTOCOL in the LoadImage()
service we will have to call the LocateDevicePath() service. To avoid a
forward declaration resequence the functions.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Our implementation of the EFI_HII_CONFIG_ROUTING_PROTOCOL is a mere stub,
where all services return an error code. The protocol is neither needed for
the EFI shell nor for the UEFI SCT. To reduce the code size remove it from
the U-Boot binary.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The EFI_RT_PROPERTIES_TABLE configuration table indicates which runtime
services are available at runtime.
Even if CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y, we neither support
UpdateCapsule() nor QueryCapsuleCapabilities() at runtime. Thus we should
not set the corresponding flags EFI_RT_SUPPORTED_UPDATE_CAPSULE and
EFI_RT_SUPPORTED_QUERY_CAPSULE_CAPABILITIES in RuntimeServicesSupported.
Fixes: 2bc27ca8a0 ("efi_loader: define UpdateCapsule api")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The current function set_name() used to create short names has the
following deficiencies resolved by this patch:
* Long names (e.g. FOO.TXT) are stored even if a short name is enough.
* Short names with spaces are created, e.g. "A ~1.TXT".
* Short names with illegal characters are created, e.g. "FOO++BAR".
* Debug output does not not consider that the short file name has no
concluding '\0'.
The solution for the following bug is split of into a separate patch:
* Short file names must be unique.
This patch only provides the loop over possible short file names.
Fixes: c30a15e590 ("FAT: Add FAT write feature")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
At present this function returns 1 on success and 0 on failure. But in
the latter case it provides no indication of what went wrong.
If an attempt is made to delete a non-existent variable, the caller may
want to ignore this error. This happens when setting a non-existent
variable to "", for example.
Update the function to return 0 on success and a useful error code on
failure. Add a function comment too.
Make sure that env_set() does not return an error if it is deleting a
variable that doesn't exist. We could update env_set() to return useful
error numbers also, but that is beyond the scope of this change.
Signed-off-by: Simon Glass <sjg@chromium.org>
wip
In this commit, a very simple firmware management protocol driver
is implemented. It will take a binary image in a capsule file and
apply the data using dfu backend storage drivers via dfu_write_by_alt()
interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In this commit, a very simple firmware management protocol driver
is implemented. It will take a common FIT image firmware in a capsule
file and apply the data using dfu backend storage drivers via
update_fit() interface.
So "dfu_alt_info" variable should be properly set to specify a device
and location to be updated. Please read README.dfu.
Fit image is a common file format for firmware update on U-Boot, and
this protocol works neatly just as a wrapper for one.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
A capsule tagged with the guid, EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID,
is handled as a firmware update object.
What efi_update_capsule() basically does is to load any firmware management
protocol (or fmp) drivers contained in a capsule, find out an appropriate
fmp driver and then invoke its set_image() interface against each binary
in a capsule.
In this commit, however, loading drivers is not supported.
The result of applying a capsule is set to be stored in "CapsuleXXXX"
variable, but its implementation is deferred to a fmp driver.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Capsule data can be loaded into the system either via UpdateCapsule
runtime service or files on a file system (of boot device).
The latter case is called "capsules on disk", and actual updates will
take place at the next boot time.
In this commit, we will support capsule on disk mechanism.
Please note that U-Boot itself has no notion of "boot device" and
all the capsule files to be executed will be detected only if they
are located in a specific directory, \EFI\UpdateCapsule, on a device
that is identified as a boot device by "BootXXXX" variables.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In this commit, skeleton functions for capsule-related API's are
added under CONFIG_EFI_UPDATE_CAPSULE configuration.
Detailed implementation for a specific capsule type will be added
in the succeeding patches.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In the previous patches we only introduced a minimal subset of the
EFI_TCG2_PROTOCOL protocol implementing GetCapability().
So let's continue adding features to it, introducing the
GetEventLog() and HashLogExtendEvent() functions.
In order to do that we first need to construct the eventlog in memory,
specifically in EFI_BOOT_SERVICES_DATA memory and a configuration table
from EFI_ACPI_MEMORY_NVS.
U-Boot won't currently add any events to the log or measure any
components, but will expose the necessary EFI APIs for applications
to do so.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The current tpm2_pcr_extend is hardcoded using SHA256.
Let's make the actual command to the TPM2 configurable so we can support
a wider range of algorithms and keep the current command line as-is i.e
limited to SHA256 only
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use logging functions instead of printf() and debug().
Change logging messages for uclass creation and destruction to log_debug().
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
commit 1fabfeef506c ("efi_loader: parameter check in GetNextVariableName()")
introduces a check using u16_strnlen(). This code is used on EFI
runtime variables as well, so unless we mark it as runtime, the kernel
will crash trying to access it.
Fixes: 1fabfeef506c ("efi_loader: parameter check in GetNextVariableName()")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Enable EFI_SET_TIME on the sandbox and QEMU ARM to ensure that we compile
and test the relevant code.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
If GetNextVariableName() is called with a non-existing combination of
VariableName and VendorGuid, return EFI_INVALID_PARAMETER.
If GetNextVariableName() is called with a string that is not zero
terminated, return EFI_INVALID_PARAMETER.
Reformat a line over 80 characters.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Since U-boot EFI implementation is getting richer it makes sense to
add support for EFI_TCG2_PROTOCOL taking advantage of any hardware TPM
available on the device.
This is the initial implementation of the protocol which only adds
support for GetCapability(). It's limited in the newer and safer
TPMv2 devices.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When copying a string with must allocate a byte for the terminating '\0' in
the target buffer.
Fixes: fbe4c7df00 ("efi_loader: enable file SetInfo()")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add missing newline to log messages in efi_rng_register() otherwise
something like below would be shown
Scanning disk virtio-blk#31...
Found 2 disks
Missing RNG device for EFI_RNG_PROTOCOLNo EFI system partition
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When calling ExitBootServices during out unit tests we should not detach
devices as we need console output for runtime tests.
Fixes: 529441ca89 ("efi_loader: Disable devices before handing over control")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For implementing the EFI_TCG2_PROTOCOL we need the count field returned by
the TPM when reading capabilities via tpm2_get_capability().
Adjust the implementation of the 'tpm2 get_capability' command accordingly.
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For validating the fixed up device tree we need a tool to need to save it
to a file.
dtbdump.efi copies the configuration table with the device tree to a file
on the same partition from which dtbdump.efi was invoked. The file name can
be entered on the console.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When deleting a non-volatile variable it was deleted from memory but the
deletion was not persisted to the file system.
SetVariable() may be called with attributes == 0 to delete a variable. To
determine if the deletion shall be persisted we have to consider the
non-volatile flag in the attributes of the deleted variable and not the
value passed in the call parameter.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
patman showing email replies from Patchwork
sandbox poweroff command
minor fixes in binman, tests
-----BEGIN PGP SIGNATURE-----
iQFFBAABCgAvFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl+kJL8RHHNqZ0BjaHJv
bWl1bS5vcmcACgkQfxc6PpAIreaDpAf+MajyuxlmGmFTjpyiB026aWiYE4rAn4AE
bXEDxHpOTIH4hDX7kYVWPmuKivHJo2hF0WUpIFBEAgtc2dOfjOP+mrDjBzG1Pikl
z5yuilG7eHwC1kTIkPv/tPHwDWRBI5VNwTYq0VTtffMKr8LCBo96wEYEbeYK0xdQ
kpNa9d4G+tpx20BCRgPLeOMk2pg5SVszkCCkmmPd12rO2zJ9+wWa8fwA759E93Rw
RshoRCtLNo2nEA3uJVG2aN9n3eAdM/iupDVdBLg50SFKabUxt7OcvGOC8NzGdAmT
9UbB8scvQJyI/kylGT+ghH3o2RqQGvuIRXmDyETckdkpiqK0SQvysg==
=eOGz
-----END PGP SIGNATURE-----
Merge tag 'dm-pull5nov20' of git://git.denx.de/u-boot-dm
patman status subcommand to collect tags from Patchwork
patman showing email replies from Patchwork
sandbox poweroff command
minor fixes in binman, tests
Now that we can use devicetree to specify this information, drop the old
CONFIG options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some boards want to specify the manufacturer or product name but do not
need to have their own sysinfo driver.
Add a default driver which provides a way to specify this SMBIOS
information in the devicetree, without needing any board-specific
functionality.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The current tables only support a subset of the available fields defined
by the SMBIOS spec. Add a few more.
We could use CONFIG_SYS_CPU or CONFIG_SYS_SOC as a default for family, but
the meaning of that value relates more to the whole system rather than
just the SoC.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Support a way to put SMBIOS properties in the device tree. These can be
placed in a 'board' device in an 'smbios' subnode.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
As a first step to obtaining SMBIOS information from the devicetree, add
an ofnode parameter to the writing functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
If there is no reset line, this still emits ACPI code for the reset GPIO.
Fix it by updating the check.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present all tables are placed starting at address f0000 in memory, and
can be up to 64KB in size. If the tables are very large, this may not
provide enough space.
Also if the tables point to other tables (such as console log or a ramoops
area) then we must allocate other memory anyway.
The bloblist is a nice place to put these tables since it is contiguous,
which makes it easy to reserve this memory for linux using the 820 tables.
Add an option to put some of the tables in the bloblist. For SMBIOS and
ACPI, create suitable pointers from the f0000 region to the new location
of the tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
[bmeng: squashed in http://patchwork.ozlabs.org/project/uboot/patch/
20201105062407.1.I8091ad931cbbb5e3b6f6ababdf3f8d5db0d17bb9@changeid/]
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
There is prepared function for filing rom_offset. That's why use it instead
of copying content of it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a very simple API to be able to access SMBIOS strings
like vendor, model and bios version.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
