On 09.01.26 12:45, Jan Kiszka wrote: > On 09.01.26 12:34, Simon Glass wrote: >> Hi Mark, >> >> On Wed, 7 Jan 2026 at 12:38, Mark Kettenis <[email protected]> wrote: >>> >>>> From: Simon Glass <[email protected]> >>>> Date: Wed, 7 Jan 2026 12:02:27 -0700 >>>> >>>> On Tue, 6 Jan 2026 at 19:42, Peter Robinson <[email protected]> wrote: >>>>> >>>>> On Wed, 7 Jan 2026 at 00:33, Simon Glass <[email protected]> wrote: >>>>>> >>>>>> From: Simon Glass <[email protected]> >>>>>> >>>>>> This work-around dates from 2019 and grub 2.04 which is quite old. New >>>>>> builds of grub don't have the problem and old boards presumably use an >>>>>> older U-Boot, so don't need this. >>>>>> >>>>>> Drop it. >>>>>> >>>>>> Signed-off-by: Simon Glass <[email protected]> >>>>>> Signed-off-by: Simon Glass <[email protected]> >>>>>> --- >>>>>> >>>>>> configs/mt7623n_bpir2_defconfig | 1 - >>>>>> lib/efi_loader/Kconfig | 10 ---------- >>>>>> lib/efi_loader/efi_boottime.c | 26 -------------------------- >>>>>> 3 files changed, 37 deletions(-) >>>>>> >>>>>> diff --git a/configs/mt7623n_bpir2_defconfig >>>>>> b/configs/mt7623n_bpir2_defconfig >>>>>> index 404380558f2..d75168a72ed 100644 >>>>>> --- a/configs/mt7623n_bpir2_defconfig >>>>>> +++ b/configs/mt7623n_bpir2_defconfig >>>>>> @@ -13,7 +13,6 @@ CONFIG_DEFAULT_DEVICE_TREE="mt7623n-bananapi-bpi-r2" >>>>>> CONFIG_TARGET_MT7623=y >>>>>> CONFIG_SYS_BOOTM_LEN=0x4000000 >>>>>> CONFIG_SYS_LOAD_ADDR=0x84000000 >>>>>> -# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set >>>>>> CONFIG_FIT=y >>>>>> CONFIG_FIT_VERBOSE=y >>>>>> CONFIG_DISTRO_DEFAULTS=y >>>>>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >>>>>> index 13e44be1d06..5585c841c27 100644 >>>>>> --- a/lib/efi_loader/Kconfig >>>>>> +++ b/lib/efi_loader/Kconfig >>>>>> @@ -505,16 +505,6 @@ config EFI_LOADER_BOUNCE_BUFFER >>>>>> hardware we can create a bounce buffer so that payloads don't >>>>>> have to >>>>>> worry about platform details. >>>>>> >>>>>> -config EFI_GRUB_ARM32_WORKAROUND >>>>>> - bool "Workaround for GRUB on 32bit ARM" >>>>>> - default n if ARCH_BCM283X || ARCH_SUNXI || ARCH_QEMU >>>>>> - default y >>>>>> - depends on ARM && !ARM64 >>>>>> - help >>>>>> - GRUB prior to version 2.04 requires U-Boot to disable caches. >>>>>> This >>>>>> - workaround currently is also needed on systems with caches that >>>>>> - cannot be managed via CP15. >>>>> >>>>> This also states that it's needed for systems that can't be managed by >>>>> CP15, what systems are they, how are those platforms addressed? >>>> >>>> I'm guessing that some systems have level2 caches with their own >>>> software interface. I certainly have seen this with Tegra2/3, for >>>> example. >>> >>> This is already being discussed in another thread on the mailing list >>> started by Jan Kiszka: >>> >>> https://lists.denx.de/pipermail/u-boot/2026-January/606817.html >>> >>> My suggestion would be to drop this patch from your set and let that >>> thread run its course. >> >> Yes I did see that and I was pleased to see that someone else was >> interested in this topic. >> >> Still, that thread does not actually include a patch. So let's see how >> it pans out. >> > > I'm played with turning off the workaround on a socfpga target, and that > apparently causes troubles: > https://lore.kernel.org/cip-dev/[email protected]/ > > I'm inclined now to keep cache disabling by default, only enable caches > on known-good boards. If someone has a hint how to reliable identify > targets that have architected CR15 cache control, I would use that as > input. Otherwise, we need to maintain a positive list in Kconfig. > > Along that, the control may need renaming because the original reason - > broken bootloaders - is really history. >
* TODO: * According to the UEFI spec caches that can be managed via CP15 * operations should be enabled. Caches requiring platform information * to manage should be disabled. This should not happen in * ExitBootServices() but before invoking any UEFI binary is invoked. So, that last sentence points out another issue for targets with non-architected caches: The current logic seems to disable them too late, right? Should the cache disabling move to do_bootefi_exec? Jan -- Siemens AG, Foundational Technologies Linux Expert Center
