Hi all,
On Renesas ARM SoCs predating R-Car Gen3, CPU core bringup does not use
a hardware register to program the CPU boot address directly. Instead,
it uses a set of registers (thus not involving the MMU) to remap any CPU
access to the page(s) at physical address zero to the specified address
block containing the CPU core startup code. the MMU. Hence when this
is enabled, any device residing in this low part of physical address
space cannot be accessed. On some boards, a CFI FLASH lives there.
Hence this causes conflicts between CPU onlining and FLASH operation:
- Reading the first page(s) of FLASH returns the CPU startup code
instead of the FLASH contents,
- CFI FLASH probing fails, as it operates on the RAM that contains the
CPU startup code. Moreover, as this probing involves writes, it
corrupts the CPU startup code, causing any subsequent CPU onlining
to fail.
CPU cores can be onlined in 3 places:
A. Secondary core bringup, during early boot (FLASH not yet in use),
B. Enabling secondary CPUs when resuming after s2ram (FLASH not in
use),
C. Manual CPU hotplug (at any time, FLASH may or may not be in use).
Possible solutions:
1. Disable FLASH in SMP initialization:
- Simple to implement,
- Accessing the FLASH from Linux needs a reboot with nosmp.
2. Disable SMP when FLASH@0 is used:
- How to check if @0 is actually used/mapped?
SMP is initialized before FLASH.
3. Map core startup code only when needed:
- Unmap core startup code after secondary core bringup,
- Map/unmap core startup code during s2ram suspend/resume,
- Call cpu_hotplug_disable() from smp_cpus_done(),
- CPU hotplug is broken.
- How to check if @0 is actually used/mapped?
4. As this FLASH is typically used to boot the system, Marek suggested
to fix this in the boot loader (e.g. put a (modified) copy of the
CPU bringup code in FLASH). But I think this is fragile, and cannot
be a generic solution, as there are other ways to boot the system,
and the FLASH may be used for other purposes.
This patch series implements solution 1, by marking the boot area region
reserved during SMP initialization (an alternative method would be to
disable any device node in DT that resides in this area). Subsequent
probing of FLASH will fail with -EBUSY:
physmap-flash 0.flash: can't request region for resource [mem 0x00000000-0x03ffffff]
physmap-flash: probe of 0.flash failed with error -16
When CONFIG_SMP is disabled, or when booted with "nosmp", the FLASH
is available again.
The first patch is a small cleanup in code affected by the third patch.
The other three patches fix the issue on R-Car Gen2 (and RZ/G1), R-Car
H1, and SH-Mobile AG5 SoCs.
Other Renesas SoCs:
- R-Mobile APE6 is also affected, but has no upstream SMP support yet,
- EMMA Mobile EV2 is unaffected, as it uses internal boot ROM code
that watches a special general purpose register in the SMU block,
- RZ/N1 is not affected, as it uses a "cpu-release-addr" property in
DT,
- R-Car Gen3 is not affected, as it extended the R-Car Gen2 RST block
with Cortex-A53/A57 Boot Address Registers for 64-bit mode
(CA5[37]CPUnBAR[HL]), which control the boot address directly,
- R-Car Gen4 is not affected, as it has Reset Vector Base Address
Registers (RVBAR[HL]Cn), which control the boot address directly.
This series has been tested on R-Car V2H (Blanche) and R-Car H1
(Marzen). With this, the CFI FLASHes on Marzen[1] and Blanche (DTS
patch to be posted) work when booted with nosmp.
Thanks for your comments!
[1] "[PATCH/RFC] ARM: dts: marzen: Add FLASH node"
https://lore.kernel.org/r/07cf5e2b466f3ba217403afc66a8246460609e09.1679330105.git.geert+renesas@xxxxxxxxx/
Geert Uytterhoeven (4):
ARM: shmobile: rcar-gen2: Remove unneeded once handling
ARM: shmobile: rcar-gen2: Reserve boot area when SMP is enabled
ARM: shmobile: r8a7779: Reserve boot area when SMP is enabled
ARM: shmobile: sh73a0: Reserve boot area when SMP is enabled
arch/arm/mach-shmobile/pm-rcar-gen2.c | 5 +++--
arch/arm/mach-shmobile/smp-r8a7779.c | 9 ++++++++-
arch/arm/mach-shmobile/smp-sh73a0.c | 10 ++++++++--
3 files changed, 19 insertions(+), 5 deletions(-)
--
2.34.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
