On Thu, Oct 17, 2024 at 05:22:52PM -0600, Simon Glass wrote:
Hi Ilias,
On Tue, 15 Oct 2024 at 07:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Tue, 15 Oct 2024 at 16:26, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Mon, 14 Oct 2024 at 22:28, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Sat, 12 Oct 2024 at 00:23, Simon Glass sjg@chromium.org wrote:
U-Boot relocates itself to the top of memory and is supposed to avoid using any memory below that region. This allows the maximum amount of memory to be available for loading images.
The lmb subsystem automatically protects U-Boot's code and data from being overwritten. It relies on this region being a contiguous area of memory. This setup has worked well for at least 15 years and has been documented in the README for as long.
The EFI_LOADER subsystem currently uses memory outside the U-Boot region when starting up.
Some of the downstream problems this causes are:
- It can overwrite images that have been loaded
So can the load command
Can you point to where? If lmb is enabled, it should be using that, so not overwrite anything.
If you load the initrd in memory X and make the kernel ovelap you will overwrite parts of the initrd.
But lmb stops that. It is actually what it is for.
Let's try once again, the ''''problem''' that was discussed in IRC, is that the initramfs overwrites memory that was allocated by the EFI subsystem *because* we haven't merged the LMB followup patches yet.
OK, my problem was booting Ubuntu where the bootflow was unbound by exit-boot-services, resulting in freeing memory (and re-using it) which was still in use. I don't actually remember what was in that memory, though. This was over a year ago, when I sent my first version of the test[1]
This was on x86 as well, yes? I believe that's what you said on the call and part of where people get confused I believe.