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:
ll_entry_declare(struct driver, fred, driver)
...
void *p = ll_entry_get(struct driver, fred, driver)
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:
.u_boot_list_2_driver_2_testbus_drv
0x0000000000270018 0x80 test/built-in.o
0x0000000000270018 _u_boot_list_2_driver_2_testbus_drv
.u_boot_list_2_driver_2_testfdt1_drv
0x0000000000270098 0x80 test/built-in.o
0x0000000000270098 _u_boot_list_2_driver_2_testfdt1_drv
*fill* 0x0000000000270118 0x8
.u_boot_list_2_driver_2_testfdt_drv
0x0000000000270120 0x80 test/built-in.o
0x0000000000270120 _u_boot_list_2_driver_2_testfdt_drv
.u_boot_list_2_driver_2_testprobe_drv
0x00000000002701a0 0x80 test/built-in.o
0x00000000002701a0 _u_boot_list_2_driver_2_testprobe_drv
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.
Update the ll_entry_start() accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
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>
This doesn't need to be passed the devicetree anymore. Drop it.
Also rename the function to drop the _fdt suffix.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is needed in at least one place. Avoid the conditional code in root.c
by adding this inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is not necessary anymore, since device_bind_ofnode() does
the same thing and works with both flattree and livetree.
Rename it to indicate that it is special.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a handler for SIGILL, SIGBUS, SIGSEGV.
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>
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>
Rename function next_cluster() to fat_next_cluster() and export it.
When creating a new directory entries we should reuse deleted entries.
This requires re-scanning the directory.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
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:
setenv bootargs "console=/dev/ttyS0 rootdev=${uuid}/PARTNROFF=1
kern_guid=${uuid}"
part uuid mmc 2:2 uuid
bootm
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Also add a lot more tests to cover various cases.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to add more processing to this function. Before doing so, rename
it to bootm_process_cmdline_env(), which is more generic.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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.
Signed-off-by: Simon Glass <sjg@chromium.org>
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
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>
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.
Signed-off-by: Michael Walle <michael@walle.cc>
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>
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.
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>
A following patch introduces support for the EFI_TCG2_PROTOCOL
eventlog management.
Introduce the necessary tpm related headers
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>
Address most of the checkpatch issues we found in km_arm and common km
code.
CC: Stefan Roese <sr@denx.de>
CC: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
Signed-off-by: Holger Brunck <holger.brunck@hitachi-powergrids.com>
Reviewed-by: Stefan Roese <sr@denx.de>
There is no reason to define default option for this macro which is
already done in common/cli_hush.c.
87 #ifndef CONFIG_SYS_PROMPT_HUSH_PS2
88 #define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
89 #endif
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Add tests to check for buffer overflow using simple replacement as well
as back references. At present these don't fully pass.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present these values are open-coded in a few places. Add constants so
the meaning is clear.
Also add a comment to cmd_get_data_size()
Signed-off-by: Simon Glass <sjg@chromium.org>
This command currently has no tests. Add some for basic assignment and the
integer operations.
Note that the default size for setexpr is ulong, which varies depending on
the build machine. So for sandbox on a 64-bit host, this means that the
default size is 64 bits.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pack struct efi_mm_communicate_header as done in EDK2 as seen in
release 201808 [1]. If not packed sizeof() for the structure adds
4 additional bytes on 32bit targets which breaks the ABI.
Link: [1] https://github.com/tianocore/edk2/blob/edk2-stable201808/MdePkg/Include/Protocol/MmCommunication.h#L21
Fixes: 23a397d2e2 ("efi_loader: Add headers for EDK2 StandAloneMM communication")
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
For eMMC HS400 mode, the DLL reset is a required step for mmc rescan.
This step has not been documented in reference manual, but the RM will
be fixed sooner or later.
In previous commit to support eMMC HS400,
db8f936 mmc: fsl_esdhc: support eMMC HS400 mode
the steps to configure DLL could be found in commit message,
13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
14. Wait for delay chain to lock.
these would be fixed as,
13. Set DLLCFG0[DLL_ENABLE] and DLLCFG0[DLL_FREQ_SEL].
13.1 Write DLLCFG0[DLL_RESET] to 1 and wait for 1us,
then write DLLCFG0[DLL_RESET]
14. Wait for delay chain to lock.
This patch is to add the step of DLL reset, and make sure delay chain
locked for HS400.
Fixes: db8f93672b ("mmc: fsl_esdhc: support eMMC HS400 mode")
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Handle the register RCC_MP_GCR without SET/CLR registers
but with a direct access to bit BOOT_MCU:
- deassert => set the bit: The MCU will not be in HOLD_BOOT
- assert => clear the bit: The MCU will be set in HOLD_BOOT
With this patch the RCC driver handles the MCU_HOLD_BOOT_R value
added in binding stm32mp1-resets.h
Cc: Fabien DESSENNE <fabien.dessenne@st.com>
Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
