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

[Tom Rini]

On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote:
> 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?

I'm not sure what address you're thinking of modifying but, this isn't
overwriting U-Boot itself so it's a case that needs to work.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240722/32716541/attachment.sig>