Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]

On Thu, Jul 04, 2024 at 01:04:56PM +0530, Sughosh Ganu wrote:

> The aim of this patch series is to fix the current state of
> incoherence between modules when it comes to memory usage. The primary
> issue that this series is trying to fix is that the EFI memory module
> which is responsible for allocating and freeing memory, does not have
> any visibility of the memory that is being used by the LMB
> module. This is further complicated by the fact that the LMB
> allocations are caller specific -- the LMB memory map is not global
> nor persistent. This means that the memory "allocated" by the LMB
> module might be relevant only for a given function. Hence one of the
> requirements for making the memory usage visible across modules is to
> make LMB allocations persistent and global, and then have means to
> communicate the use of memory across modules.
> 
> The first set of patches in this series work on making the LMB memory
> map persistent and global. 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.
> 
> A review comment on the earlier version was to do away with the static
> arrays for the LMB lists of free and used memory. This version
> uses the alloced list data structure for the LMB lists.
> 
> The second set of patches are making changes to the EFI memory module
> to make use of the LMB functions to allocate and free memory. A
> *_flags() version of LMB API's has been introduced for the same. The
> earlier version was using notification mechanism from both LMB and EFI
> modules to maintain memory coherence. This version makes use of the
> LMB API functions for the memory allocations. This is based on review
> comments of EFI maintainers.

On am64x_evm_a53, the last test in test/py/tests/test_net_boot.py fails
due to:
...
TFTP from server 192.168.116.10; our IP address is 192.168.116.23
Filename 'pxelinux.cfg/default-arm-k3'.
Load address: 0x80100000
Loading: ##################################################  64 Bytes
         8.8 KiB/s
done
Bytes transferred = 64 (40 hex)
  1  pxe          ready   ethernet     0  port@1.bootdev.0          extlinux/extlinux.conf
** Booting bootflow 'port@1.bootdev.0' with pxe
Retrieving file: pxelinux.cfg/default-arm
am65_cpsw_nuss_port ethernet@8000000port@1: K3 CPSW: rflow_id_base: 16
link up on port 1, speed 1000, full duplex
Using ethernet@8000000port@1 device
TFTP from server 192.168.116.10; our IP address is 192.168.116.23
Filename 'pxelinux.cfg/default-arm'.

TFTP error: trying to overwrite reserved memory...
Couldn't retrieve pxelinux.cfg/default-arm

And note that the pxelinux.cfg files are created as defined by the
example within the test. This test is also still fine on Pi 4.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]