Simon Glass [Thu, 17 Dec 2020 04:20:07 +0000 (21:20 -0700)]
dm: Avoid accessing seq directly
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.
Simon Glass [Thu, 17 Dec 2020 04:20:06 +0000 (21:20 -0700)]
linker_lists: Fix alignment issue
The linker script uses alphabetic sorting to group the different linker
lists together. Each group has its own struct and potentially its own
alignment. But when the linker packs the structs together it cannot ensure
that a linker list starts on the expected alignment boundary.
For example, if the first list has a struct size of 8 and we place 3 of
them in the image, that means that the next struct will start at offset
0x18 from the start of the linker_list section. If the next struct has
a size of 16 then it will start at an 8-byte aligned offset, but not a
16-byte aligned offset.
With sandbox on x86_64, a reference to a linker list item using
ll_entry_get() can force alignment of that particular linker_list item,
if it is in the same file as the linker_list item is declared.
Consider this example, where struct driver is 0x80 bytes:
If these two lines of code are in the same file, then the entry is forced
to be aligned at the 'struct driver' alignment, which is 16 bytes. If the
second line of code is in a different file, then no action is taken, since
the compiler cannot update the alignment of the linker_list item.
In the first case, an 8-byte 'fill' region is added:
With this, the linker_list no-longer works since items after testfdt1_drv
are not at the expected address.
Ideally we would have a way to tell gcc not to align structs in this way.
It is not clear how we could do this, and in any case it would require us
to adjust every struct used by the linker_list feature.
One possible fix is to force each separate linker_list to start on the
largest possible boundary that can be required by the compiler. However
that does not seem to work on x86_64, which uses 16-byte alignment in this
case but needs 32-byte alignment.
So add a Kconfig option to handle this. Set the default value to 4 so
as to avoid changing platforms that don't need it.
Simon Glass [Thu, 3 Dec 2020 23:55:18 +0000 (16:55 -0700)]
dm: treewide: Rename 'platdata' variables to just 'plat'
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.
Simon Glass [Thu, 3 Dec 2020 23:55:17 +0000 (16:55 -0700)]
dm: treewide: Rename auto_alloc_size members to be shorter
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.
Simon Glass [Sun, 29 Nov 2020 00:50:08 +0000 (17:50 -0700)]
dm: core: Combine the flattree and livetree binding code
At present there are two copies of this code. With ofnode we can combine
them to reduce duplication. Update the dm_scan_fdt_node() function and
adjust its callers.
When an exception occurs print the program counter and the loaded
UEFI binaries and reset the system if CONFIG_SANDBOX_CRASH_RESET=y
or exit to the OS otherwise.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
Tom Rini [Thu, 10 Dec 2020 18:54:33 +0000 (13:54 -0500)]
Merge tag 'efi-next' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi into next
Pull request for UEFI sub-system for next
Bug fixes
* avoid corruption of FAT file system when using long names
* correct values for RuntimeServicesSupport concerning UEFI capsule update
* link partition to block device via EFI_OPEN_PROTOCOL_BY_CHILD_CONTROLLER
New feature
* support EFI_LOAD_FILE_PROTOCOL in LoadImage() boot service
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>
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>
efi_loader: resequence functions in efi_boottime.c
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>
efi_loader: don't set EFI_RT_SUPPORTED_UPDATE_CAPSULE
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: 2bc27ca8a04a ("efi_loader: define UpdateCapsule api") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
fs: fat: first dentry of long name in FAT iterator
A long name is split over multiple directory entries. When deleting a file
with a long name we need the first directory entry to be able to delete the
whole chain.
Add the necessary fields to the FAT iterator:
* cluster of first directory entry
* address of first directory entry
* remaining entries in cluster
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
When iterating over a child directory we set itr->start_clust.
Do the same when over the root directory.
When looking for deleted directory entries or existing short names we will
have to iterate over directories a second and third time. With this patch
we do not need any special logic for the root directory.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
For reusing deleted directory entries we have to adjust the function called
to step to the next directory entry.
This patch alone is not enough to actually reuse deleted directory entries
as the fill_dir_slot() is still called with first never used directory
entry.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
In set_name() we select the short name. Once this is correctly implemented
this will be a performance intensive operation because we need to check
that the name does not exist yet. So set_name should only be called once.
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.
The FAT specification [1] requires that for a '..' directory entry pointing
to the root directory the fields DIR_FstClusHi and DIR_FstClusLo are 0.
[1] Microsoft FAT Specification, Microsoft Corporation, August 30 2005
Fixes: 31a18d570d96 ("fs: fat: support mkdir") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
spl: fit: Prefer a malloc()'d buffer for loading images
Fit images were loaded to a buffer provided by spl_get_load_buffer().
This may work when the FIT image is small and fits between the start
of DRAM and SYS_TEXT_BASE.
One problem with this approach is that the location of the buffer may
be manipulated by changing the 'size' field of the FIT. A maliciously
crafted FIT image could place the buffer over executable code and be
able to take control of SPL. This is unacceptable for secure boot of
signed FIT images.
Another problem is with larger FIT images, usually containing one or
more linux kernels. In such cases the buffer be be large enough so as
to start before DRAM (Figure I). Trying to load an image in this case
has undefined behavior.
For example, on stm32mp1, the MMC controller hits a RX overrun error,
and aborts loading.
_________________
| FIT Image |
| |
/===================\ /=====================\
|| DRAM || | DRAM |
|| || | |
||_________________|| SYS_TEXT_BASE | ___________________ |
| | || FIT Image ||
| | || ||
| _________________ | SYS_SPL_MALLOC_START || _________________ ||
|| malloc() data || ||| malloc() data |||
||_________________|| |||_________________|||
| | ||___________________||
| | | |
Figure I Figure II
One possibility that was analyzed was to remove the negative offset,
such that the buffer starts at SYS_TEXT_BASE. This is not a proper
solution because on a number of platforms, the malloc buffer() is
placed at a fixed address, usually after SYS_TEXT_BASE. A large
enough FIT image could cause the malloc()'d data to be overwritten
(Figure II) when loading.
The solution proposed here is to replace the ad-hoc heuristics of
spl_get_load_buffer() with malloc(). This provides two advantages:
* Bounds checking of the buffer region
* Guarantees the buffer does not conflict with other memory
The first problem is solved by constraining the buffer such that it
will not overlap currently executing code. This eliminates the chance
of a malicious FIT being able to replace the executing SPL code prior
to signature checking.
The second problem is solved in conjunction with increasing
CONFIG_SYS_SPL_MALLOC_SIZE. Since the SPL malloc() region is
carefully crafted on a per-platform basis, the chances of memory
conflicts are virtually eliminated.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tom Rini [Mon, 7 Dec 2020 22:16:23 +0000 (17:16 -0500)]
Merge branch '2020-12-07-bootm-and-spl-atf-improvements' into next
- Series to improve "bootm" by allowing variable evaluation within the
cmdline we would be passing. This will help with Chrome OS but can be
useful elsewhere.
- Improve ATF (TF-A) support within SPL.
Simon Glass [Thu, 5 Nov 2020 17:33:48 +0000 (10:33 -0700)]
bootm: Support string substitution in bootargs
In some cases it is necessary to pass parameters to Linux so that it will
boot correctly. For example, the rootdev parameter is often used to
specify the root device. However the root device may change depending on
whence U-Boot loads the kernel. At present it is necessary to build up
the command line by adding device strings to it one by one.
It is often more convenient to provide a template for bootargs, with
U-Boot doing the substitution from other environment variables.
Add a way to substitute strings in the bootargs variable. This allows
things like "rootdev=${rootdev}" to be used in bootargs, with the
${rootdev} substitution providing the UUID of the root device.
For example, to substitute the GUID of the kernel partition:
This is particularly useful when the command line from another place. For
example, Chrome OS stores the command line next to the kernel itself. It
depends on the kernel version being used as well as the hardware features,
so it is extremely difficult to devise a U-Boot script that works on all
boards and kernel versions. With this feature, the command line can be
read from disk and used directly, with a few substitutions set up.
Simon Glass [Thu, 5 Nov 2020 17:33:47 +0000 (10:33 -0700)]
cli: Support macro processing with a fixed-size buffer
At present cli_simple_process_macros() requires that the caller provide
an output buffer that is exactly CONFIG_SYS_CBSIZE bytes in length. This
makes sense since it is designed to be used from the command line. But we
also want to use it for bootargs substitution.
Update the function to allow the caller to specify the buffer size. Also
return an error if the buffer is exhausted. The caller can ignore that if
preferred.
Simon Glass [Thu, 5 Nov 2020 17:33:46 +0000 (10:33 -0700)]
x86: zimage: Add silent-console processing
At present zimage does its own command-line processing and does not
support the 'silent console' feature. There doesn't seem to be any good
reason for this.
Simon Glass [Thu, 5 Nov 2020 17:33:45 +0000 (10:33 -0700)]
bootm: Allow updating the bootargs in a buffer
At present we only support updating the 'bootargs' environment
variable. Add another function to update a buffer instead. This will
allow zimage to use this feature.
Simon Glass [Thu, 5 Nov 2020 17:33:44 +0000 (10:33 -0700)]
bootm: Update bootm_process_cmdline_env() to use flags
At present only one transformation is supported: making the Linux console
silent. To prepare for adding more, convert the boolean parameter into a
flag value.
Simon Glass [Thu, 5 Nov 2020 17:33:43 +0000 (10:33 -0700)]
bootm: Split out bootargs environment reading / writing
At present bootm_process_cmdline_env() reads the 'bootargs' variable and
then writes it back afterwards. This is painful for tests, which would
rather use a simple buffer.
It is also useful for zimage to use a buffer, since it does not actually
put the Linux command line in the bootargs variable.
Refactor the existing code into two pieces. One handles reading and
writing the environment variable, as well as allocating a buffer for use
by the rest of the code, which now operates on a buffer.
Simon Glass [Thu, 5 Nov 2020 17:33:41 +0000 (10:33 -0700)]
bootm: Add a bool parameter to bootm_process_cmdline_env()
This function will soon do more than just handle the 'silent linux'
feature. As a first step, update it to take a boolean parameter,
indicating whether or not the processing is required.
Simon Glass [Thu, 5 Nov 2020 17:33:39 +0000 (10:33 -0700)]
bootm: Update fixup_silent_linux() to return an error
At present this function fails silently on error. Update it to produce
an error code. Report this error to the user and abort the boot, since it
likely will prevent a successful start.
No tests are added at this stage, since additional refactoring is taking
place in subsequent patches.
Simon Glass [Thu, 5 Nov 2020 17:33:38 +0000 (10:33 -0700)]
bootm: Add tests for fixup_silent_linux()
This function currently has no tests. Export it so that we can implement
a simple test on sandbox. Use IS_ENABLED() to remove the unused code,
instead #ifdef.
Simon Glass [Thu, 5 Nov 2020 17:33:37 +0000 (10:33 -0700)]
env: Allow returning errors from hdelete_r()
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.
Michael Walle [Wed, 18 Nov 2020 16:45:59 +0000 (17:45 +0100)]
armv8: layerscape: don't initialize GIC in SPL
The BL31 expects the GIC to be uninitialized. Thus, if we are loading
the BL31 by the SPL we must not initialize it. If u-boot is loaded by
the SPL directly, it will initialize the GIC again (in the same
lowlevel_init()).
This was tested on a custom board with SPL loading the BL31 and jumping
to u-boot as BL33 as well as loading u-boot directly by the SPL. In case
the ATF BL1/BL2 is used, this patch won't change anything, because no
SPL is used at all.
Michael Walle [Wed, 18 Nov 2020 16:45:57 +0000 (17:45 +0100)]
spl: atf: remove helper structure from common header
bl2_to_bl31_params_mem is just an implementation detail of the SPL ATF
support and is not needed anywhere else. Move it from the header to the
actual module.
Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Michal Simek <michal.simek@xilinx.com>
Michael Walle [Wed, 18 Nov 2020 16:45:56 +0000 (17:45 +0100)]
spl: atf: provide a bl2_plat_get_bl31_params_default()
Move the actual implementation of the bl2_plat_get_bl31_params() to its
own function. The weak function will just call the default
implementation. This has the advantage that board code can still call
the original implementation if it just want to modify minor things.
Michael Walle [Wed, 18 Nov 2020 16:45:55 +0000 (17:45 +0100)]
spl: atf: move storage for bl31_params into function
There is no need to have the storage available globally. This is also a
preparation for LOAD_IMAGE_V2 support. That will introduce a similar
generator function which also has its own storage.
Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Michal Simek <michal.simek@xilinx.com>
AKASHI Takahiro [Mon, 30 Nov 2020 09:12:17 +0000 (18:12 +0900)]
test/py: efi_capsule: test for raw image capsule
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a raw image capsule,
CONFIG_EFI_CAPSULE_RAW.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on Travis CI, at least, for now.
AKASHI Takahiro [Mon, 30 Nov 2020 09:12:16 +0000 (18:12 +0900)]
test/py: efi_capsule: test for FIT image capsule
The test can run on sandbox build and it attempts to execute a firmware
update via a capsule-on-disk, using a FIT image capsule,
CONFIG_EFI_CAPSULE_FIT.
To run this test successfully, you need configure U-Boot specifically;
See test_capsule_firmware.py for requirements, and hence it won't run
on Travis CI, at least, for now.
AKASHI Takahiro [Tue, 17 Nov 2020 00:28:01 +0000 (09:28 +0900)]
cmd: add "efidebug capsule" command
"efidebug capsule" is more or less a debugging utility.
efidebug capsule update: invoke UpdateCapsule against data on memory
efidebug capsule show: show a capsule header
efidebug capsule result: dump a capsule result variable
AKASHI Takahiro [Tue, 17 Nov 2020 00:28:00 +0000 (09:28 +0900)]
efi_loader: add firmware management protocol for raw image
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.
AKASHI Takahiro [Mon, 30 Nov 2020 09:12:12 +0000 (18:12 +0900)]
efi_loader: add firmware management protocol for FIT image
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.
AKASHI Takahiro [Mon, 30 Nov 2020 09:12:11 +0000 (18:12 +0900)]
efi_loader: capsule: support firmware update
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.
AKASHI Takahiro [Tue, 17 Nov 2020 00:27:57 +0000 (09:27 +0900)]
efi_loader: capsule: add memory range capsule definitions
Memory range capsule gives us a way to notify that some memory regions
should be left untouched across the next reset.
See UEFI specification, section 8.5.3.
Since how we should handle this kind of capsule is totally up to
the system, no implementation will be added in this commit.
AKASHI Takahiro [Tue, 17 Nov 2020 00:27:56 +0000 (09:27 +0900)]
efi_loader: capsule: add capsule_on_disk support
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.
AKASHI Takahiro [Tue, 17 Nov 2020 00:27:55 +0000 (09:27 +0900)]
efi_loader: define UpdateCapsule api
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.
AKASHI Takahiro [Thu, 19 Nov 2020 00:37:19 +0000 (09:37 +0900)]
common: update: fix an "unused" warning against update_flash()
Since update_flash() is used only in update_tftp(), it should be
guarded with appropriate config options.
After the commit 3149e524fc1e, common/update.c will be built under
either CONFIG_UDATE_TFTP, CONFIG_DFU_TFTP or CONFIG_UPDATE_FIT.
Since CONFIG_UPDATE_FIT, hence fit_update(), doesn't rely on
update_flash(), the compiler may cause an "unused" warning if
CONFIG_UPDATE_FIT=y and CONFIG_UPDATE_TFTP=n and CONFIG_DFU_TFTP=n.
This is, for example, the case for sandbox defconfig where
EFI_CAPSULE_FIRMWARE_FIT is enabled for test purpose.
Fixes: 3149e524fc1e ("common: update: add a generic interface for FIT
image") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Ilias Apalodimas [Mon, 30 Nov 2020 09:47:41 +0000 (11:47 +0200)]
cmd: efidebug: Add support for TCG2 final events table
A previous commit is adding EFI_TCG2_PROTOCOL, which in it's eventlog
support registers an EFI configuration table.
Let's add the necessary GUID so 'efidebug table' command can display
table names properly.
Ilias Apalodimas [Mon, 30 Nov 2020 09:47:40 +0000 (11:47 +0200)]
efi_loader: Introduce eventlog support for TCG2_PROTOCOL
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.
projects / u-boot.git / log