Hi Ilias, On Fri, 27 Sept 2024 at 05:08, Ilias Apalodimas <ilias.apalodi...@linaro.org> wrote: > > Hi Simon, > > On Thu, 19 Sept 2024 at 17:12, Simon Glass <s...@chromium.org> wrote: > > > > Hi, > > > > On Tue, 17 Sept 2024 at 13:55, Sughosh Ganu <sughosh.g...@linaro.org> wrote: > > > > > > On Sat, 14 Sept 2024 at 20:14, Heinrich Schuchardt <xypron.g...@gmx.de> > > > wrote: > > > > > > > > On 9/5/24 10:27, Sughosh Ganu wrote: > > > > > Add a flag LMB_NONOTIFY that can be passed to the LMB API's for > > > > > reserving memory. This will then result in no notification being sent > > > > > from the LMB module for the changes to the LMB's memory map. > > > > > > > > You seem to be using this in patch 3 and 7. > > > > > > > > Please, describe in this patch why you want to be able to suppress > > > > notification. > > > > > > Will add the reasoning behind this flag in the commit message. > > > > > > > > > > > In the EFI context we should use LMB notification to notify the > > > > EFI_EVENT_GROUP_MEMORY_MAP_CHANGE event. > > > > > > > > See chapter 7.1.2 EFI_BOOT_SERVICES.CreateEventEx() in the UEFI > > > > specification. > > > > > > So, do you want me to use the EFI event signaling mechanism for this > > > purpose ? Is my understanding correct ? If so, this will mean that we > > > have an event notification specifically for EFI, and there might be > > > one needed for any other consumers of this event. Currently there > > > aren't any other consumers of the LMB memory map change event other > > > than EFI, but using the U-Boot's event notification mechanism means > > > that the same notification mechanism can be used if there were any > > > additional consumers of this event in the future. In that case, we > > > would have two separate event notifications, one for EFI, and one for > > > non-EFI consumers. > > > > As I have previously said, none of this is necessary. > > > > Essentially all of the EFI setup that is done in U-Boot can be delayed > > until we are actually starting an EFI app. > > Can you explain how you plan to deal with EFI variables, the TPM > eventlog, measuring events when tables are added, capsules updates etc > etc, which expect certain EFI services to be up and running?
Yes, sure. Accessing EFI variables is going to require EFI to be inited, I assume. For capsule updates, I believe that is triggered on boot, so again it would need EFI services. It's fine to use EFI when it is needed. But this memory-map thing has really got out of hand. BTW we need TPM eventlog and measuring for any type of boot so it needs to work without EFI. > > > The current approach of > > keeping parallel EFI tables everywhere is causing much confusion. > > Apart from all of the above the EFI app can return. Which makes all of > the above just a burden It's fine if it returns, isn't it? What is the burden? > > > > > For EFI, it should be enough to read the lmb tables at the end and add > > whatever parallel tables are needed to boot the app. > > Yes apart from the fact that LMB has no idea about memory types or > permissions. Neither should it. It is for laying out images in memory. We need to maintain some separation of concerns here, or we'll end up with a complex mess. Memory types are really an EFI construct which should be easy enough to add statically - e.g. U-Boot code is EFI_BOOT_SERVICES_CODE. Memory permissions are known based on the memory areas, so I don't think lmb needs to know about that. > > > We should not > > need to keep things in sync through the life of U-Boot, since: > > > > 1. EFI pool-allocations should use malloc() until the app starts > > 2. EFI page allocations should not be allowed until the app starts > > > > This whole area needs a healthy dose of 'keep it simple'. Regards, Simon
