Hi Tom, On Sun, 16 Feb 2025 at 08:04, Tom Rini <[email protected]> wrote: > > On Sun, Feb 16, 2025 at 07:50:48AM -0700, Simon Glass wrote: > > Hi Sughosh, > > > > On Wed, 27 Nov 2024 at 04:48, Sughosh Ganu <[email protected]> wrote: > > > > > > On Tue, 26 Nov 2024 at 21:09, Simon Glass <[email protected]> wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Thu, 21 Nov 2024 at 00:53, Sughosh Ganu <[email protected]> > > > > wrote: > > > > > > > > > > On Tue, 12 Nov 2024 at 18:48, Simon Glass <[email protected]> wrote: > > > > > > > > > > > > A bisect of Ubuntu 2022.04 boot-failure on qemu-x86_64 resulted in > > > > > > this > > > > > > patch. I am not sure how to investigate it. > > > > > > > > > > > > The boot hangs at some point during booting of the install image, > > > > > > before > > > > > > the Ubuntu logo appears. > > > > > > > > > > > > I will sent a series with a script showing how it is run. > > > > > > > > > > > > This reverts commit a68c9ac5d8afc51c619c5d3e865fcf147bea90cb. > > > > > > > > > > > > Signed-off-by: Simon Glass <[email protected]> > > > > > > --- > > > > > > > > > > I did some digging into this issue, and it turns out that the revert > > > > > is only masking the real issue. What this revert does is mark the > > > > > memory region occupied by U-Boot as EFI_BOOT_SERVICES_CODE. The x86 > > > > > kernel seems to mark memory regions other than > > > > > EFI_{BOOT,RUNTIME}_SERVICES_CODE as not executable -- and this is > > > > > precisely why this crash shows up only on x86. The actual cause of > > > > > this issue is in the efi runtime functionality of U-Boot. The kernel > > > > > is calling the SetVirtualAddressMap() runtime service function, and > > > > > that seems to be calling some of the boot service code of U-Boot, > > > > > which it shouldn't. We do not get the crash after disabling the > > > > > ConvertPointer() and SetVirtualAddressMap() runtime functions. > > > > > > > > OK, so what is the solution here? Did you send a patch? > > > > > > I am trying to check if the installation can be done by disabling the > > > ConvertPointer() and SetVirtualAddressMap() runtime service calls. If > > > so, then I will send a patch which disables them temporarily till the > > > actual issue is triaged and fixed. If the installation does not work > > > without these runtime calls, I would say putting this change in with > > > an explanation of what is happening (similar to the above > > > explanation). Please give me some more days, and I will let you know. > > > Thanks. > > > > I forgot what happened with this. Could you update this thread, please? > > After much further investigation to understand why the revert worked, > the revert was applied with a different commit message.
OK, thanks. I have found another problem in that it breaks sandbox (bootflow_efi test) when it calls exit-boot-services. But you have not applied that series[1] so we can wait to see if you hit that problem in general usage. Hopefully not! Regards, Simon [1] https://patchwork.ozlabs.org/project/uboot/list/?series=439021
