u-boot.git/test/lib, branch v2025.01-rc2 Unnamed repository; edit this file 'description' to name the repository. alist: Add a way to efficiently filter an alist 2024-11-04T03:27:12+00:00 Simon Glass sjg@chromium.org 2024-10-19T15:21:47+00:00 5dfc1c8078572436fc68817d22d9e046eaa01398 Unlike linked lists, it is inefficient to remove items from an alist, particularly if it is large. If most items need to be removed, then the time-complexity approaches O(n2). Provide a way to do this efficiently, by working through the alist once and copying elements down. Signed-off-by: Simon Glass <sjg@chromium.org> 
Unlike linked lists, it is inefficient to remove items from an alist,
particularly if it is large. If most items need to be removed, then the
time-complexity approaches O(n2).

Provide a way to do this efficiently, by working through the alist once
and copying elements down.

Signed-off-by: Simon Glass <sjg@chromium.org>
alist: Add a function to empty the list 2024-11-04T03:27:12+00:00 Simon Glass sjg@chromium.org 2024-10-19T15:21:46+00:00 5bd4ead8bd76c85aa599c44e8bfb12f512d8ed09 Sometimes it is useful to empty the list without de-allocating any of the memory used, e.g. when the list will be re-populated immediately afterwards. Add a new function for this. Signed-off-by: Simon Glass <sjg@chromium.org> 
Sometimes it is useful to empty the list without de-allocating any of
the memory used, e.g. when the list will be re-populated immediately
afterwards.

Add a new function for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
alist: Add for-loop helpers 2024-11-04T03:27:12+00:00 Simon Glass sjg@chromium.org 2024-10-19T15:21:45+00:00 d785a77d18acdf6714f4570c14e622caadf4d5e3 Add some macros which permit easy iteration through an alist, similar to those provided by the 'list' implementation. Signed-off-by: Simon Glass <sjg@chromium.org> 
Add some macros which permit easy iteration through an alist, similar to
those provided by the 'list' implementation.

Signed-off-by: Simon Glass <sjg@chromium.org>
alist: Add a way to get the next element 2024-11-04T03:27:12+00:00 Simon Glass sjg@chromium.org 2024-10-19T15:21:44+00:00 1d49f78c362981435a88d887c777ccc445f5a4e7 Add a new function which returns the next element after the one provided, if it exists in the list. Signed-off-by: Simon Glass <sjg@chromium.org> 
Add a new function which returns the next element after the one
provided, if it exists in the list.

Signed-off-by: Simon Glass <sjg@chromium.org>
lmb: Fix lmb_add_region_flags() return codes and testing 2024-10-29T22:17:47+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2024-10-23T15:22:00+00:00 0f57b009e649e9d140b7f662599a5ace506e2418 The function description says this should return 0 or -1 on failures. When regions coalesce though this returns the number of coalescedregions which is confusing and requires special handling of the return code. On top of that no one is using the number of coalesced regions. So let's just return 0 on success and adjust our selftests accordingly Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> 
The function description says this should return 0 or -1 on failures.
When regions coalesce though this returns the number of coalescedregions
which is confusing and requires special handling of the return code.
On top of that no one is using the number of coalesced regions.

So let's just return 0 on success and adjust our selftests accordingly

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
global: Use CONFIG_XPL_BUILD instead of CONFIG_SPL_BUILD 2024-10-11T17:44:48+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:50+00:00 1d6132e2a2b1217567b88ddd6d11662afd4001df Complete this rename for all directories outside arch/ board/ drivers/ and include/ Use the new symbol to refer to any 'SPL' build, including TPL and VPL Signed-off-by: Simon Glass <sjg@chromium.org> 
Complete this rename for all directories outside arch/ board/ drivers/
and include/

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass <sjg@chromium.org>
test: lib/uuid: add tests for UUID version/variant bits 2024-09-12T15:35:38+00:00 Caleb Connolly caleb.connolly@linaro.org 2024-08-30T12:34:41+00:00 22d3d3cd49339fb0eb70ce22276867993ada090c Add a test to check the version/variant bits of v4 and v5 UUIDs. Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> 
Add a test to check the version/variant bits of v4 and v5 UUIDs.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
test: lib/uuid: add unit tests for dynamic UUIDs 2024-09-12T15:35:38+00:00 Caleb Connolly caleb.connolly@linaro.org 2024-08-30T12:34:40+00:00 26e16a850e644cf9239c426ad19e390d5c6544e5 Add some basic unit tests to validate that the UUID generation behaves as expected. This matches the implementation in efi_loader for sandbox and a Qualcomm board and should catch any regressions. Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> 
Add some basic unit tests to validate that the UUID generation behaves
as expected. This matches the implementation in efi_loader for sandbox
and a Qualcomm board and should catch any regressions.

Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
include: export uuid.h 2024-09-12T15:35:37+00:00 Caleb Connolly caleb.connolly@linaro.org 2024-08-30T12:34:37+00:00 58d825fb18053ec7e432de7bbb70a452b9228076 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> 
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>
Merge patch series "Make LMB memory map global and persistent" 2024-09-03T20:09:30+00:00 Tom Rini trini@konsulko.com 2024-09-03T20:09:30+00:00 360aaddd9cea8c256f50c576794415cadfb61819 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). 
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).