| Age | Commit message (Collapse) | Author |
|---|
|
Prepare v2024.10-rc6
|
|
* The function name must be provided in the description.
* The function name must match the name used in the description.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
When dealing with processing of the empty capsule, the capsule gets
applied only when the checks for the empty capsule pass. Print a
message to highlight if empty capsule checks fail, and return an error
value, similar to the normal capsules.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
When in Trial State, the platform keeps a count of the number of times
it has booted in the Trial State. Once the threshold of the maximum
allowed count exceeds, the platform reverts to boot from a different
bank on subsequent boot, thus coming out of the Trial State. It is
expected that all the updated images would be accepted or rejected
while the platform is in Trial State. Put in checks so that it is not
possible to apply an empty capsule once the max Trial Count exceeds.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The FWU code supports both versions of the FWU metadata, i.e. v1 and
v2. A platform can then select one of the two versions through a
config symbol. Put a dependency in the FWU metadata version selection
config symbol to ensure that both versions of the metadata cannot be
enabled.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The platform transitions out of Trial State into the Regular State
only when all the images in the update bank have been accepted. Check
for this condition before transitioning out of Trial State.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Do a sanity check that the version of the FWU metadata that has been
read aligns with the version enabled in the image. This allows to
indicate an early failure as part of the FWU module initialisation.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
In the version 2 of the FWU metadata, the metadata is broken into two
parts, a top-level structure, which provides information on the total
size of the structure among other things. Try reading the primary
partition first, and if that fails, try reading the secondary
partition. This will help in the scenario where the primary metadata
partition has been corrupted, but the secondary partition is intact.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
This was lost in a later commit, so add it back.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
At present EFI output to the console uses fputs() which bypasses the
console-recording feature. This makes it impossible for tests to check
the output of an EFI app.
There doesn't seem to be any need to do this bypass, so adjust it to
simply use the puts() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
|
|
Move this header to include/u-boot/ so that it can be used by external
tools.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Adjust the UUID library code so that it can be compiled as part of a
host tool.
This removes the one redundant log_debug() call, as well as the
incorrectly defined LOG_CATEGORY.
In general this is a fairly trivial change, just adjusting includes and
disabling list_guid.
This will be used by a new genguid tool to generate v5 GUIDs that match
those generated by U-Boot at runtime.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Introduce a new helper efi_capsule_update_info_gen_ids() which populates
the capsule update fw images image_type_id field. This allows for
determinstic UUIDs to be used that can scale to a large number of
different boards and board variants without the need to maintain a big
list.
We call this from efi_fill_image_desc_array() to populate the UUIDs
lazily on-demand.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
Add support for generating version 5 UUIDs, these are determistic and work
by hashing a "namespace" UUID together with some unique data. One intended
usecase is to allow for dynamically generate payload UUIDs for UEFI
capsule updates, so that supported boards can have their own UUIDs
without needing to hardcode them.
In addition, move the common bit twiddling code from gen_ran_uuid into a
separate function and rewrite it not to use clrsetbits (which is not
available when building as part of host tools).
Tests for this are added in an upcoming patch.
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
|
|
The EFI_LOADER and EFI config options are randomly scattered under lib/
making it cumbersome to navigate and enable options, unless you really
know what you are doing. On top of that the existing options are in
random order instead of a logical one.
So let's move things around a bit and move them under boot/. Present a
generic UEFI entry where people can select Capsules, Protocols,
Services, and an option to compile U-Boot as an EFI for X86
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
There's currently a chance for this function to overwrite an error if
one occurred and the subsequent call to
efi_uninstall_multiple_protocol_interfaces() succedded. Although this
is an EFI event and we can't do much let's at least set and return
the correct error
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
We use this event when returning from an EFI HTTP booted image.
The name is a bit confusing since it suggests we always run it,
rename it to make it clearer
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
We use this function to clean up leftover resources when booting an
EFI HTTP boot image, but the name is unnecessary long.
Shorten it to efi_bootmgr_release_uridp()
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Sughosh Ganu <sughosh.ganu@linaro.org> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
|
|
Instead of printing the LMB flags as numerical values, print them as
strings. This makes it easier to understand what flags are associated
with the lmb region. Also make corresponding changes to the bdinfo
command's test code.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The TCG event log buffer is being set at the end of ram memory. This
region of memory is to be reserved as LMB_NOMAP memory in the LMB
memory map. The current location of this buffer overlaps with the
memory region reserved for the U-Boot image, which is at the top of
the usable memory. This worked earlier as the LMB memory map was not
global but caller specific, but fails now because of the overlap.
Move the TCG event log buffer to the start of the ram memory region
instead. Move the location of the early trace buffer and the load
buffer for U-Boot(spl boot) accordingly.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The board_lmb_reserve() function is not being used, and currently
there is only an empty weak function defined. Remove this unused
function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
All of the current definitions of arch_lmb_reserve() are doing the
same thing -- reserve the region of memory occupied by U-Boot,
starting from the current stack address to the ram_top. Introduce a
function lmb_reserve_uboot_region() which does this, and do away with
the arch_lmb_reserve() function.
Instead of using the current value of stack pointer for starting the
reserved region, have a fixed value, considering the stack size config
value.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
All the current function definitions of arch_lmb_reserve() are doing
the same thing -- reserve the U-Boot memory region. The powerpc(ppc)
architecture, in addition, is making some LMB reservations for the
bootm related image loading. Move these ppc specific reservations to
the arch_misc_init() function. This allows to move the U-Boot memory
region reservation to a different function, and remove
arch_lmb_reserve() in a subsequent commit.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
With the move to make the LMB allocations persistent and the common
memory regions being reserved during board init, there is no need for
an explicit reservation of a memory range. Remove the
lmb_init_and_reserve_range() function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
With the changes to make the LMB reservations persistent, the common
memory regions are being added during board init. Remove the
now superfluous lmb_init_and_reserve() function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The LMB module provides API's for allocating and reserving chunks of
memory which is then typically used for things like loading images for
booting. Reserve the portion of memory that is occupied by the U-Boot
image itself, and other parts of memory that might have been marked as
reserved in the board's DTB. When executing in SPL, reserve the
sections that get relocated to the ram memory, the stack and
the global data structure and also the bss.
Mark these regions of memory with the LMB_NOOVERWRITE flag to indicate
that these regions cannot be re-requested or overwritten.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Introduce a function lmb_add_memory() to add available memory to the
LMB memory map. Call this function during board init once the LMB data
structures have been initialised.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
With the introduction of separate config symbols for the SPL phase of
U-Boot, the condition checks need to be tweaked so that platforms that
enable the LMB module in SPL are also able to call the LMB API's. Use
the appropriate condition checks to achieve this.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Add separate config symbols for enabling the LMB module for the SPL
phase. The LMB module implementation now relies on alloced list data
structure which requires heap area to be present. Add specific config
symbol for the SPL phase of U-Boot so that this can be enabled on
platforms which support a heap in SPL.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
The LMB memory maps are now being maintained through a couple of
alloced lists, one for the available(added) memory, and one for the
used memory. These lists are not static arrays but can be extended at
runtime. Remove the config symbols which were being used to define the
size of these lists with the earlier implementation of static arrays.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Allow for resizing of LMB regions if the region attributes match. The
current code returns a failure status on detecting an overlapping
address. This worked up until now since the LMB calls were not
persistent and global -- the LMB memory map was specific and private
to a given caller of the LMB API's.
With the change in the LMB code to make the LMB reservations
persistent, there needs to be a check on whether the memory region can
be resized, and then do it if so. To distinguish between memory that
cannot be resized, add a new flag, LMB_NOOVERWRITE. Reserving a region
of memory with this attribute would indicate that the region cannot be
resized.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
|
|
The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
|
|
The __lmb_alloc_base() function is only called from within the lmb
module. Moreover, the lmb_alloc() and lmb_alloc_base() API's are good
enough for the allocation API calls. Make the __lmb_alloc_base()
function static.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The lmb_is_reserved() API is not used. There is another API,
lmb_is_reserved_flags() which can be used to check if a particular
memory region is reserved. Remove the unused API.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Prepare v2024.10-rc4
|
|
Fix the dependency to avoid a warning if RSA_VERIFY_WITH_PKEY is enabled.
Fixes: b7463f198da6 ("Make ASYMMETRIC_KEY_TYPE depend on FIT_SIGNATURE")
Signed-off-by: Tomas Paukrt <tomaspaukrt@email.cz>
|
|
Use the API function list_count_nodes() to count the number of list
entries.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Shifting this pointer in the loop will be more logical when working
with the code later, because you can see at a glance what exactly
changes at each iteration. Moreover, the code remains equivalent
because this variable is not used after the loop.
Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
If the environment is not enabled we don't need these fields in
global_data. Make them conditional.
Make these fields conditional. Move env_buf up one so it can share
an #ifdef.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
There not only ARM64 boards but also RISC-V boards that require a bounce
buffer to read block devices.
Drop the architecture restriction.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
efi_get_var() allocates memory which must be freed after the variable is
used. Since the device path is duplicated after we deserialize the load
options free the memory used for the variable payload
Fixes: db61e70e0d2a efi_loader: efi_dp_from_lo() should skip VenMedia node
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinric Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Prepare v2024.10-rc3
|
|
Do not load and flush segments whose program header type is not
PT_LOAD to avoid crash happen.
bootelf will load all program headers and then flush cache.
Since PT_GNU_STACK start address is 0x0, crash happens when
it flushes PT_GNU_STACK area for target that memory cannot be
accessed from address 0x0.
crash call stack:
====================================================================
bootelf -p
|-> do_bootelf (cmd/elf.c)
|-> load_elf_image_phdr (lib/elf.c) /* Load each program header */
|-> for (i = 0; i < ehdr->e_phnum; ++i) { /* e_phnum is 2 */
|-> flush_cache(start=0, size=0) (arch/arm/lib/cache.c) （*1）
|-> flush_dcache_range(start=0, 0); (arch/arm/cpu/armv8/cache_v8.c)
|-> __asm_flush_dcache_range(start=0, 0) (arch/arm/cpu/armv8/cache.S)
|-> /* clean & invalidate data or unified cache */
|-> dc civac, x0 <<== crash happen x0:start=0
====================================================================
*1 Here the p_paddr and p_filesz of the GNU_STACK program are 0.
hello_world elf image program headers
====================================================================
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000080ff0000 0x0000000080ff0000
0x0000000000010390 0x0000000000010390 R E 0x10000
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x10
Section to Segment mapping:
Segment Sections...
00 .text .rodata .eh_frame
01
====================================================================
bootelf -p crash error log
====================================================================
bootelf -p 0x80f00000
"Synchronous Abort" handler, esr 0x96000147, far 0x0
elr: 000000008f6035bc lr : 000000008f66ff54 (reloc)
elr: 00000000bd9475bc lr : 00000000bd9b3f54
x0 : 0000000000000000 x1 : 0000000000000000
x2 : 0000000000000040 x3 : 000000000000003f
x4 : 0000000081000390 x5 : 00000000bd12da98
x6 : 0000000000000010 x7 : 0000000000000010
x8 : 000000000000000a x9 : 00000000bd156b30
x10: 00000000bd1526e0 x11: 0000000000000000
x12: 0000000000000004 x13: 00000000bda00000
x14: 00000000ffffffff x15: 00000000bd12dab7
x16: 00000000bd957b14 x17: 0000000000000000
x18: 00000000bd13fd90 x19: 0000000080f000b0
x20: 0000000080f00000 x21: 0000000000000002
x22: 0000000000000000 x23: 0000000000000003
x24: 00000000bd9eacc0 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 00000000bd154c80 x29: 00000000bd12da70
Code: d2800082 9ac32042 d1000443 8a230000 (d50b7e20)
====================================================================
Signed-off-by: Jianfeng Zhu <JianfengA.Zhu@sony.com>
Reviewed-by: Jacky Cao <Jacky.Cao@sony.com>
Reviewed-by: Toyama, Yoshihiro <Yoshihiro.Toyama@sony.com>
|
|
Use the correct function name.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
|
|
Simplify the code by using the list_count_nodes() function.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
|
|
Simon Glass <sjg@chromium.org> says:
Universal Payload (UPL) is an Industry Standard for firmware
components[1]. UPL is designed to improve interoperability within the
firmware industry, allowing mixing and matching of projects with less
friction and fewer project-specific implementations. UPL is
cross-platform, supporting ARM, x86 and RISC-V initially.
This series provides some initial support for this, targeting 0.9.1 and
sandbox only.
Features still to come include:
- Support for architectures
- FIT validation
- Handoff validation
- Interoperability tests
|
|
When the devicetree comes from a bloblist, it is currently overwritten
by the appended one, if present. It should be preserved.
Adjust the logic to support this.
Fixes: 70fe2385943 ("fdt: Allow the devicetree to come from a bloblist")
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Simon Glass <sjg@chromium.org> says:
This data structure provides a list of pointers / array of structures.
I was planning to use it for the lmb restructure, to allow it to
support any number of entries, but then I gave up on it.
There are quite a few places in U-Boot where such a list would be
useful, since it supports growing the array.
[...]
Example:
struct my_struct obj;
struct my_struct *ptr = alist_add(&lst, &obj, struct my_struct);
// now ptr is in the list
[trini: Reword the cover letter slightly, do not merge the RFC portion]
|
|
In various places it is useful to have an array of structures, but allow
it to grow. In some cases we work around it by setting maximum number of
entries, using a Kconfig option. In other places we use a linked list,
which does not provide for random access and can complicate the code.
Introduce a new data structure, which is a variable-sized list of structs
each of the same, pre-set size. It provides O(1) access and is reasonably
efficient at expanding linearly, since it doubles in size when it runs out
of space.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
