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

[Sughosh Ganu]

On Mon, 8 Jul 2024 at 19:32, Tom Rini <trini at konsulko.com> wrote:
>
> 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 at 1.bootdev.0          extlinux/extlinux.conf
> ** Booting bootflow 'port at 1.bootdev.0' with pxe
> Retrieving file: pxelinux.cfg/default-arm
> am65_cpsw_nuss_port ethernet at 8000000port@1: K3 CPSW: rflow_id_base: 16
> link up on port 1, speed 1000, full duplex
> Using ethernet at 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

So this seems to be failing because the address used to load the pxe
config file seems to be overlapping with an already reserved region of
memory. Can you please check if modifying the address works?

>
> 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.

If this is working fine on the Pi 4, this is mostly to do with needing
to tweak the load address.

-sughosh

>
> --
> Tom