Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
On Tue, Jul 23, 2024 at 08:21:11PM +0530, Sughosh Ganu wrote: > On Tue, 23 Jul 2024 at 20:18, Tom Rini wrote: > > > > On Mon, Jul 22, 2024 at 11:07:45PM +0530, Sughosh Ganu wrote: > > > On Mon, 22 Jul 2024 at 23:03, Tom Rini wrote: > > > > > > > > On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > > > > > On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > > > > > > 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@800port@1: K3 CPSW: rflow_id_base: > > > > > > 16 > > > > > > link up on port 1, speed 1000, full duplex > > > > > > Using ethernet@800port@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.
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
On Tue, 23 Jul 2024 at 20:18, Tom Rini wrote: > > On Mon, Jul 22, 2024 at 11:07:45PM +0530, Sughosh Ganu wrote: > > On Mon, 22 Jul 2024 at 23:03, Tom Rini wrote: > > > > > > On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > > > > On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > > > > > 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@800port@1: K3 CPSW: rflow_id_base: 16 > > > > > link up on port 1, speed 1000, full duplex > > > > > Using ethernet@800port@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
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
On Mon, Jul 22, 2024 at 11:07:45PM +0530, Sughosh Ganu wrote: > On Mon, 22 Jul 2024 at 23:03, Tom Rini wrote: > > > > On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > > > On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > > > > 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@800port@1: K3 CPSW: rflow_id_base: 16 > > > > link up on port 1, speed 1000, full duplex > > > > Using ethernet@800port@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. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
Hi Sughosh, On Mon, 22 Jul 2024 at 18:37, Sughosh Ganu wrote: > > On Mon, 22 Jul 2024 at 23:03, Tom Rini wrote: > > > > On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > > > On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > > > > 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@800port@1: K3 CPSW: rflow_id_base: 16 > > > > link up on port 1, speed 1000, full duplex > > > > Using ethernet@800port@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. I too am interested in what it might be. Scripts in general can load things where they want, so we need to be careful. Also, as mentioned I would really like to clean up the 'EFI' 'allocations' so that they only happen when booting an EFI payload. I am not too sure what the current state is, but I will see if I can take a look. Regards, SImon
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
On Mon, 22 Jul 2024 at 23:03, Tom Rini wrote: > > On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > > On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > > > 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@800port@1: K3 CPSW: rflow_id_base: 16 > > > link up on port 1, speed 1000, full duplex > > > Using ethernet@800port@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. -sughosh > > -- > Tom
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
On Mon, Jul 22, 2024 at 11:58:18AM +0530, Sughosh Ganu wrote: > On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > > 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@800port@1: K3 CPSW: rflow_id_base: 16 > > link up on port 1, speed 1000, full duplex > > Using ethernet@800port@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 signature.asc Description: PGP signature
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
On Mon, 8 Jul 2024 at 19:32, Tom Rini 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: 0x8010 > 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@800port@1: K3 CPSW: rflow_id_base: 16 > link up on port 1, speed 1000, full duplex > Using ethernet@800port@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
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
Hi Sugosh, On Mon, 8 Jul 2024 at 15:35, Tom Rini wrote: > > On Thu, Jul 04, 2024 at 01:04:56PM +0530, Sughosh Ganu wrote: I don't believe coherent is the right word here. Perhaps 'more persistent' is better? > > > 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. > > Please re-work so that the series is bisectable. For example > xilinx_zynqmp_r5 fails that check currently. And I found that looking in > to why it grows by ~1500 bytes overall. This likely is due to > CONFIG_EFI_LOADER=n and so while the case where EFI_LOADER is enabled > tends to be a size win (reduction) or wash we need to look at the > CONFIG_EFI_LOADER=n case more. The alist code will be a little growth > and that's fine enough. But realloc and do_bdinfo are the two big > growths at the top, in this case. > > -- > Tom Regards, Simon
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
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. Please re-work so that the series is bisectable. For example xilinx_zynqmp_r5 fails that check currently. And I found that looking in to why it grows by ~1500 bytes overall. This likely is due to CONFIG_EFI_LOADER=n and so while the case where EFI_LOADER is enabled tends to be a size win (reduction) or wash we need to look at the CONFIG_EFI_LOADER=n case more. The alist code will be a little growth and that's fine enough. But realloc and do_bdinfo are the two big growths at the top, in this case. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
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: 0x8010 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@800port@1: K3 CPSW: rflow_id_base: 16 link up on port 1, speed 1000, full duplex Using ethernet@800port@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 signature.asc Description: PGP signature
[RFC PATCH v2 00/48] Make U-Boot memory reservations coherent
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. Patches 1 - 4 are from Simon Glass and are adding support for the alloced list data structure. Patches 5 - 33 are for making the LMB memory map persistent and global. Patches 34 - 48 are for making EFI memory allocations work with LMB API's. Note: * Once the general direction of these patches has been agreed upon, I plan to split these patches into two series, with the above split. * I am running the CI over a patch from Rasmus Villemoes - RFC-test-cyclic-try-to-avoid-spurious-test-failures-due-to-cyclic-callbacks.patch I get spurious watchdog timeout errors without this patch. * Because this is common code, and I was not able to disable LMB config(some code under boot/ fails to build), all of the patches need to be applied together when testing. Todo's -- There needs to be a test written for testing the various scenarios of memory being allocated and freed by different modules, namely LMB and EFI. I have written a couple of commands for testing the changes that I have made. I will be working on this once there is agreement on the patches. Secondly, there were comments on the earlier series about things like code size impact etc, but I have not looked at those right now. I will look at these aspects in the following version. Simon Glass (4): malloc: Support testing with realloc() lib: Handle a special case with str_to_list() alist: Add support for an allocated pointer list lib: Convert str_to_list() to use alist Sughosh Ganu (44): alist: add a couple of helper functions alist: add a function declaration for alist_expand_by() lmb: remove the unused lmb_is_reserved() function lmb: staticize __lmb_alloc_base() lmb: remove call to lmb_init() lmb: remove local instances of the lmb structure variable lmb: pass a flag to image_setup_libfdt() for lmb reservations lmb: allow for resizing lmb regions lmb: make LMB memory map persistent and global lmb: remove config symbols used for lmb region count test: lmb: remove the test for max regions lmb: config: add lmb config symbols for SPL lmb: allow lmb module to be used in SPL lmb: introduce a function to add memory to the lmb memory map lmb: remove the lmb_init_and_reserve() function lmb: reserve common areas during board init lmb: remove lmb_init_and_reserve_range() function lmb: init: initialise the lmb data structures during board init lmb: use the BIT macro for lmb flags lmb: add a common implementation of arch_lmb_reserve() sandbox: spl: enable lmb in SPL sandbox: iommu: remove lmb allocation in the driver zynq: lmb: do not add to lmb map before relocation test: cedit: use allocated address for reading file test: lmb: tweak the tests for the persistent lmb memory map test: lmb: run lmb tests only manually test: lmb: add a separate class of unit tests for lmb test: lmb: invoke the LMB unit tests from a separate script test: bdinfo: dump the global LMB memory map lmb: add versions of the lmb API with flags lmb: add a flag to allow suppressing memory map change notification efi: memory: u