On Tue, Jul 23, 2024 at 08:21:11PM +0530, Sughosh Ganu wrote: > On Tue, 23 Jul 2024 at 20:18, Tom Rini <tr...@konsulko.com> wrote: > > > > On Mon, Jul 22, 2024 at 11:07:45PM +0530, Sughosh Ganu wrote: > > > On Mon, 22 Jul 2024 at 23:03, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > > > > > On Mon, 8 Jul 2024 at 19:32, Tom Rini <tr...@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@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 > > > > > > > > > > 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. > > > > > > Can you please print the lmb memory map through bdinfo and share it > > > with me. That will give some info on what is causing the issue. Thing > > > is, with this patchset, if there is another reservation with a > > > different flag(like LMB_NOMAP, LMB_NOOVERWRITE), this would cause the > > > load to fail. > > > > Well hunh. I thought I had reproduced the issue before posting, but I > > just pushed the same tree (I'm fairly certain) over to my lab and the > > tests are passing now. So, lets just see what happens with the next > > iteration of the series, sorry for the noise. > > Okay, I will put out the LMB only, non-rfc series once the CI has gone > through fine. Btw, I hope you have seen my comment on irc about having > the SPL_LMB config symbol as a bool, instead of def_bool y. Thanks.
I'll investigate that further once I can poke at the code, thanks. -- Tom
signature.asc
Description: PGP signature
