u-boot.git/common/spl/spl.c, branch v2025.01 Unnamed repository; edit this file 'description' to name the repository. common: Tidy up how malloc() is inited 2024-10-25T20:22:24+00:00 Simon Glass sjg@chromium.org 2024-10-21T08:19:26+00:00 41fecdc94e3b3714f33a28c139f61cfa48bf16f9 The call to malloc() is a bit strange. The naming of the arguments suggests that an address is passed, but in fact it is a pointer, at least in the board_init_r() function and SPL equivalent. Update it to work as described. Add a function comment as well. Note that this does adjustment does not extend into the malloc() implementation itself, apart from changing mem_malloc_init(), since there are lots of casts and pointers and integers are used interchangeably. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> 
The call to malloc() is a bit strange. The naming of the arguments
suggests that an address is passed, but in fact it is a pointer, at
least in the board_init_r() function and SPL equivalent.

Update it to work as described. Add a function comment as well.

Note that this does adjustment does not extend into the malloc()
implementation itself, apart from changing mem_malloc_init(), since
there are lots of casts and pointers and integers are used
interchangeably.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
spl: Rename SPL_TPL_NAME and SPL_TPL_PROMPT 2024-10-11T17:44:48+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:55+00:00 96ed5b0e3e3376851c4cbb4e6750c11e5f02ba5b Rename these to use the word PHASE instead. Signed-off-by: Simon Glass <sjg@chromium.org> 
Rename these to use the word PHASE instead.

Signed-off-by: Simon Glass <sjg@chromium.org>
xpl: Rename spl_phase_prefix() and spl_phase_name() 2024-10-11T17:44:47+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:40+00:00 80580cd98167771a0aae4a6c4c7ffe6d7e70a155 Use simpler names for these functions. Signed-off-by: Simon Glass <sjg@chromium.org> 
Use simpler names for these functions.

Signed-off-by: Simon Glass <sjg@chromium.org>
xpl: Rename spl_next_phase() and spl_prev_phase() 2024-10-11T17:44:47+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:39+00:00 6c49fc5882baa2c496b03f8260a5b21ef48ed9c5 Rename this to use the xpl prefix. Signed-off-by: Simon Glass <sjg@chromium.org> 
Rename this to use the xpl prefix.

Signed-off-by: Simon Glass <sjg@chromium.org>
xpl: Rename spl_phase() to xpl_phase() 2024-10-11T17:44:47+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:36+00:00 456bdb70def1fe371f964e82158a53f6baf1d3a4 Rename this function to indicate that it refers to any xPL phase. Signed-off-by: Simon Glass <sjg@chromium.org> 
Rename this function to indicate that it refers to any xPL phase.

Signed-off-by: Simon Glass <sjg@chromium.org>
xpl: Rename spl_phase to xpl_phase_t 2024-10-11T17:44:47+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:35+00:00 41ea75aa00079ff8368fca53267671cee6289415 This name fits better with the new naming scheme, so update it. Signed-off-by: Simon Glass <sjg@chromium.org> 
This name fits better with the new naming scheme, so update it.

Signed-off-by: Simon Glass <sjg@chromium.org>
xpl: Rename u_boot_first_phase to xpl_is_first_phase() 2024-10-11T17:44:47+00:00 Simon Glass sjg@chromium.org 2024-09-30T01:49:34+00:00 713bfc58f948e46e0e01ff8b50ef9f30f6f8317c This is a better name for this function, so update it. Tidy up the function comment to mention VPL. Signed-off-by: Simon Glass <sjg@chromium.org> 
This is a better name for this function, so update it.

Tidy up the function comment to mention VPL.

Signed-off-by: Simon Glass <sjg@chromium.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).
spl: call spl_board_init() at the end of the spl init sequence 2024-09-03T20:08:50+00:00 Sughosh Ganu sughosh.ganu@linaro.org 2024-08-26T11:59:33+00:00 fa6333afdf3191a09a7c1174c55faa3b111daa6e The spl_board_init() function on sandbox invokes the unit tests. Invoking the tests should be done once the rest of the system has been initialised. Call the spl_board_init() function at the very end, once the rest of the initilisation functions have been called, including the setting up of the LMB memory map. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
The spl_board_init() function on sandbox invokes the unit
tests. Invoking the tests should be done once the rest of the system
has been initialised. Call the spl_board_init() function at the very
end, once the rest of the initilisation functions have been called,
including the setting up of the LMB memory map.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
lmb: init: initialise the lmb data structures during board init 2024-09-03T20:08:50+00:00 Sughosh Ganu sughosh.ganu@linaro.org 2024-08-26T11:59:28+00:00 b6400de7e03cdd5e93195bf260dc7ab9f68aea8f The memory map maintained by the LMB module is now persistent and global. This memory map is being maintained through the alloced list structure which can be extended at runtime -- there is one list for the available memory, and one for the used memory. Allocate and initialise these lists during the board init. 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 memory map maintained by the LMB module is now persistent and
global. This memory map is being maintained through the alloced list
structure which can be extended at runtime -- there is one list for
the available memory, and one for the used memory. Allocate and
initialise these lists during the board init.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>