Hi Ilias, On Thu, 3 Apr 2025 at 08:27, Ilias Apalodimas <[email protected]> wrote: > > On Wed, 2 Apr 2025 at 22:19, Simon Glass <[email protected]> wrote: > > > > Hi, > > > > On Thu, 3 Apr 2025 at 03:36, Ilias Apalodimas > > <[email protected]> wrote: > > > > > > On Wed, 2 Apr 2025 at 17:26, Ilias Apalodimas > > > <[email protected]> wrote: > > > > > > > > Hey Bjorn > > > > > > > > Long time, hope all is well! > > > > > > > > On Wed, 2 Apr 2025 at 16:22, Björn Töpel <[email protected]> wrote: > > > > > > > > > > Hi, > > > > > > > > > > I think I got a regression from commit 53d5a221632e ("emulation: Use > > > > > bloblist to hold tables"), and v2024.10 for > > > > > qemu-riscv64_smode_defconfig + acpi.config booting Linux with UEFI. > > > > > > > > > > TL;DR: It seems like the RSDP is placed in the wrong EFI memory map > > > > > type (it should be "ACPI Reclaim"). > > > > > > > > > > I might also be misunderstanding what config fragments should be > > > > > used -- I'm out in the weeds here! ;-) > > > > > > > > > > When I was using v2024.10, ACPI RSDP was in ACPI Reclaim memory. All > > > > > good, and e.g. a kexec would properly work. However, when using u-boot > > > > > with commit 53d5a221632e ("emulation: Use bloblist to hold tables") I > > > > > get the following when booting, and then kexec: > > > > > > > > > > First kernel: > > > > > [ 0.000000] ACPI: Early table checksum verification disabled > > > > > [ 0.000000] ACPI: > > > > > RSDP 0x000000047EED3000 000024 (v02 BOCHS ) > > > > > Kexec kernel: > > > > > [ 0.000000] ACPI: Early table checksum verification disabled > > > > > [ 0.000000] ACPI: 0x000000047EED3000 000000 (v00 > > > > > 00000000 00000000) > > > > > [ 0.000000] Oops - load access fault [#1] > > > > > > > > > > RSDP reside in: > > > > > [ 0.000000] efi: 0x00047ded1000-0x00047eee3fff [Boot Code | | > > > > > | | | | | | | | | |WB| | | ] > > > > > > > > > > (Boot Code vs ACPI Reclaimed) > > > > > > > > > > Now to get qemu-riscv64_smode_defconfig + acpi.config to build > > > > > post-2024.10, I needed to add the following fragments: > > > > > > > > > > CONFIG_BLOBLIST=y > > > > > CONFIG_BLOBLIST_ALLOC=y > > > > > CONFIG_BLOBLIST_SIZE_RELOC=0x20000 > > > > > > > > > > which is really just a "make the build not complain", guessing game > > > > > from my side. > > > > > > > > > > My guess would be that it's related to the change in > > > > > evt_write_acpi_tables(), where: > > > > > > > > > > - ptr = memalign(SZ_4K, SZ_64K); > > > > > + ptr = bloblist_add(BLOBLISTT_ACPI_TABLES, SZ_64K, 12); > > > > > > > > > > is done. > > > > > > > > > > Is my config fragment broken, or is this a proper regression? > > > > > > > > I think it's a regression and I think what breaks it is commit > > > > cfb4aa2a754ed1 > > > > Yes, that's right. It was reported by Patrick Rudolph in mid-Feb and I > > sent a patch about a month ago [1] > > > > It seems to be in Heinrich's queue in patchwork. > > > > > > > > > > Can you apply the diff below and see if it fixes it for you? > > > > > > > > diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c > > > > index 4422b31ac6a7..afa5eee85484 100644 > > > > --- a/lib/efi_loader/efi_acpi.c > > > > +++ b/lib/efi_loader/efi_acpi.c > > > > @@ -34,8 +34,8 @@ efi_status_t efi_acpi_register(void) > > > > * add_u_boot_and_runtime(). At some point that function could > > > > create a > > > > * more detailed map. > > > > */ > > > > - if (IS_ENABLED(CONFIG_BLOBLIST_TABLES)) > > > > - return EFI_SUCCESS; > > > > + //if (IS_ENABLED(CONFIG_BLOBLIST_TABLES)) > > > > + ////return EFI_SUCCESS; > > > > > > > > /* Mark space used for tables */ > > > > start = ALIGN_DOWN(gd->arch.table_start, EFI_PAGE_MASK); > > > > > > > > Simon, why that PR got sent with no ACKs from any of the EFI > > > > maintainers? > > > > I didn't send a PR, but it's not clear that anyone would have spotted > > this bug as it is pretty subtle. It would be good to have testing for > > this case. We can actually do that by expanding the bootflow_efi() > > test. > > > > > > > > And please fix whatever tooling you use to CC the proper maintainers > > > next time [0] as I don't see my name in the CC list > > > > You had asked not to be cc'd on my patches anymore, > > Are you sure? > > > so I just cc > > Heinrich now, unless I manually override it. > > I asked not to be cc'ed on patches that don't apply to -master or > -next and are for your tree. I obviously want to be CC'ed for anything > related to subsystems I help maintain. > > Thanks > /Ilias > > > Let me know what you'd > > like me to do.
OK, well unfortunately for now all of my patches are based on my tree. I would love that to change, but so far it has been my only option for landing things, like bootstd migrations, EFI-app improvements, PXE improvements and so on. I can manually override this for individual patches (as I did with the TPM patch). I also make sure to put an 'efi_loader' tag on each patch related to that area, as you requested. > > > > Regards, > > Simon > > > > > > > > [0] > > > https://lore.kernel.org/u-boot/[email protected]/ > > [1] > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ Regards, Simon
