Hi Heinrich, On Wed, 15 Nov 2023 at 19:18, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > On 11/16/23 02:35, Simon Glass wrote: > > EFI applications can be very large and thus used to cause boot failures > > when malloc() space was exhausted. > > > > A recent changed fixed this by using the kernel_addr_r environment var > > as the address of the buffer. However, it still frees the buffer when > > the bootflow is discarded. > > > > Fix this by introducing a flag to indicate whether the buffer was > > allocated, or not. > > > > Note that kernel_addr_r is not the last word here. It might be better > > to use lmb to place images. But there is a lot of refactoring to do > > We need a discussion about memory management. We currently have: > > * malloc > * EFI - AllocatePages(), AllocatePool() > * lmb > * preassigned addresses like $kernel_addr_r, $fdt_addr_r
Yes indeed. There have been discussions already, but we need to do this on the ML. > > EFI manages memory on page level. It needs to provide a complete memory > map to the OS with flags for different types of memory. Currently it is > not aware of where files are loaded and might allocate those regions for > its own usage. > > lmb does not track any allocations but tries to recreate a memory map on > the fly whenever a file is loaded. > > It would be preferable to allocate memory for files and require to > explicitly unload a file before reusing the same memory area. > > We should start a separate thread on this topic. Indeed. If you start it, I will reply with some thoughts. The nice thing is that with bootstd we can start to tidy all this up and make sure it has tests. > > > before we can remove the environment variables. The distro scripts rely > > on them so it is safe for bootstd to do so too. > > > > Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > Reported by: Simon Glass <s...@chromium.org> > > Reported by: Shantur Rathore <i...@shantur.com> > > Reviewed-by: Heinrich Schuchardt <xypron.g...@gmx.de> > [..] Regards, Simon
