All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH 1/1] efi_loader: QEMU CONFIG_EFI_GRUB_ARM32_WORKAROUND=n
Date: Sat, 19 Sep 2020 14:17:18 +0200	[thread overview]
Message-ID: <e04bc351-41e1-e4ef-3bd5-230066c0ffc7@gmx.de> (raw)
In-Reply-To: <ea27d381d8479754@bloch.sibelius.xs4all.nl>

On 19.09.20 13:42, Mark Kettenis wrote:
>> From: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> Date: Thu, 17 Sep 2020 20:03:24 +0200
>>
>> On 9/17/20 7:47 PM, Tom Rini wrote:
>>> On Thu, Sep 17, 2020 at 07:18:08PM +0200, Heinrich Schuchardt wrote:
>>>
>>>> CONFIG_EFI_GRUB_ARM32 is only needed for architectures with caches that are
>>>> not managed via CP15 (or for some outdated buggy versions of GRUB). It
>>>> makes more sense to disable the setting per architecture than per defconfig.
>>>>
>>>> Move QEMU's CONFIG_EFI_GRUB_ARM32_WORKAROUND=n from defconfig to Kconfig.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> ---
>>>>  configs/qemu_arm_defconfig | 1 -
>>>>  lib/efi_loader/Kconfig     | 1 +
>>>>  2 files changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Why?  Are we about to move this to be a short list of "default y if ..."
>>> instead?  Otherwise no, this is the level of detail that should be in a
>>> defconfig I think and not Kconfig.
>>>
>>
>> Hello Tom,
>>
>> yes, in the long run I want to turn this into "default y if". But I
>> first need to a list of all ARCH_* which have a cache which is not
>> controlled via CP15.
>
> It is fairly standard for SoCs with Cortex-A9 cores.  Maybe some SoCs
> with Cortex-A8 are affected as well.  Probably the list of affected
> SoCs is those that implement v7_outer_cache_enable().
>

git grep -n v7_outer_cache_enable

yields

arch/arm/cpu/armv7/cache_v7.c:210:__weak void v7_outer_cache_enable(void) {}
arch/arm/include/asm/armv7.h:128:void v7_outer_cache_enable(void);
arch/arm/mach-imx/cache.c:83:void v7_outer_cache_enable(void)
arch/arm/mach-mvebu/cpu.c:658:void v7_outer_cache_enable(void)
arch/arm/mach-omap2/omap3/board.c:433:void v7_outer_cache_enable(void)
arch/arm/mach-omap2/omap4/hwinit.c:166:void v7_outer_cache_enable(void)
arch/arm/mach-s5pc1xx/cache.c:27:void v7_outer_cache_enable(void)
arch/arm/mach-socfpga/misc.c:69:void v7_outer_cache_enable(void)
arch/arm/mach-uniphier/arm32/cache-uniphier.c:277:void
v7_outer_cache_enable(void)

arch/arm/mach-kirkwood/cache.c has an architecture specific
implementation of l2_cache_disable().

> However, since other 32-bit ARM UEFI implementation are generally not
> unavailable, I'm not sure disabling this workaround on other SoCs is
> feasable since the code oath for booting OSes without the MMU enabled
> may not be very well tested.
>

According to the UEFI spec we have to fulfill the following requirements
when handing over to the OS on ARM 32bit:

- MMU enabled
- Instruction and data caches enabled
- Access flag disabled
- Translation remap disabled
- Fast Context Switch Extension (FCSE) must be disabled
- caches requiring platform information to manage or invoke
  non-architectural cache/TLB lockdown mechanisms disabled

With the GRUB workaround enabled we call cleanup_before_linux().
According to README.arm_caches this shall disable the MMU.

Mark, I do not understand your concerns regarding a disabled MMU when
*not* calling cleanup_before_linux().

Best regards

Heinrich

      reply	other threads:[~2020-09-19 12:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 17:18 [PATCH 1/1] efi_loader: QEMU CONFIG_EFI_GRUB_ARM32_WORKAROUND=n Heinrich Schuchardt
2020-09-17 17:47 ` Tom Rini
2020-09-17 18:03   ` Heinrich Schuchardt
2020-09-17 18:53     ` Tom Rini
2020-09-18  4:07       ` Heinrich Schuchardt
2020-09-18 11:28         ` Tom Rini
2020-09-18 17:14           ` Heinrich Schuchardt
2020-09-18 17:31             ` Tom Rini
2020-09-19 11:42     ` Mark Kettenis
2020-09-19 12:17       ` Heinrich Schuchardt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e04bc351-41e1-e4ef-3bd5-230066c0ffc7@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.