[U-Boot] [PATCH] ARM: uniphier: drop UniPhier specific SMP code
The latest Linux can directly handle SMP operations for UniPhier SoCs without any help of U-boot. Drop the relevant code from U-boot.
See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier: rework SMP operations to use trampoline code") in Linux Kernel.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com ---
arch/arm/mach-uniphier/Kconfig | 8 ----- arch/arm/mach-uniphier/lowlevel_init.S | 53 ---------------------------------- 2 files changed, 61 deletions(-)
diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig index 22ab798..9e6ac3a 100644 --- a/arch/arm/mach-uniphier/Kconfig +++ b/arch/arm/mach-uniphier/Kconfig @@ -3,12 +3,8 @@ if ARCH_UNIPHIER config SYS_CONFIG_NAME default "uniphier"
-config UNIPHIER_SMP - bool - config ARCH_UNIPHIER_PH1_SLD3 bool "UniPhier PH1-sLD3 SoC" - select UNIPHIER_SMP help This enables support for UniPhier PH1-sLD3 SoC.
@@ -20,7 +16,6 @@ config ARCH_UNIPHIER_PH1_LD4
config ARCH_UNIPHIER_PH1_PRO4 bool "UniPhier PH1-Pro4 SoC" - select UNIPHIER_SMP depends on !ARCH_UNIPHIER_PH1_SLD3 && \ !ARCH_UNIPHIER_PH1_LD4 && \ !ARCH_UNIPHIER_PH1_SLD8 @@ -35,7 +30,6 @@ config ARCH_UNIPHIER_PH1_SLD8
config ARCH_UNIPHIER_PH1_PRO5 bool "UniPhier PH1-Pro5 SoC" - select UNIPHIER_SMP depends on !ARCH_UNIPHIER_PH1_SLD3 && \ !ARCH_UNIPHIER_PH1_LD4 && \ !ARCH_UNIPHIER_PH1_SLD8 @@ -44,7 +38,6 @@ config ARCH_UNIPHIER_PH1_PRO5
config ARCH_UNIPHIER_PROXSTREAM2 bool "UniPhier ProXstream2 SoC" - select UNIPHIER_SMP depends on !ARCH_UNIPHIER_PH1_SLD3 && \ !ARCH_UNIPHIER_PH1_LD4 && \ !ARCH_UNIPHIER_PH1_SLD8 @@ -53,7 +46,6 @@ config ARCH_UNIPHIER_PROXSTREAM2
config ARCH_UNIPHIER_PH1_LD6B bool "UniPhier PH1-LD6b SoC" - select UNIPHIER_SMP depends on !ARCH_UNIPHIER_PH1_SLD3 && \ !ARCH_UNIPHIER_PH1_LD4 && \ !ARCH_UNIPHIER_PH1_SLD8 diff --git a/arch/arm/mach-uniphier/lowlevel_init.S b/arch/arm/mach-uniphier/lowlevel_init.S index 66cad42..5936045 100644 --- a/arch/arm/mach-uniphier/lowlevel_init.S +++ b/arch/arm/mach-uniphier/lowlevel_init.S @@ -44,59 +44,6 @@ ENTRY(lowlevel_init)
bl enable_mmu
-#ifdef CONFIG_UNIPHIER_SMP -secondary_startup: - /* - * Entry point for secondary CPUs - * - * The Boot ROM has already enabled MMU for the secondary CPUs as well - * as for the primary one. The MMU table embedded in the Boot ROM - * prohibits the DRAM access, so it is impossible to bring the - * secondary CPUs into DRAM directly. They must jump here into SPL, - * which is run on L2 cache. - * - * Boot Sequence - * [primary CPU] [secondary CPUs] - * start from Boot ROM start from Boot ROM - * jump to SPL sleep in Boot ROM - * kick secondaries ---(sev)---> jump to SPL - * jump to U-Boot main sleep in SPL - * jump to Linux - * kick secondaries ---(sev)---> jump to Linux - */ - - /* branch by CPU ID */ - mrc p15, 0, r0, c0, c0, 5 @ MPIDR (Multiprocessor Affinity Register) - and r0, r0, #0x3 - cmp r0, #0x0 - beq primary_cpu - /* only for secondary CPUs */ - ldr r1, =ROM_BOOT_ROMRSV2 @ The last data access to L2 cache - mrc p15, 0, r0, c1, c0, 0 @ SCTLR (System Control Register) - orr r0, r0, #CR_I @ Enable ICache - bic r0, r0, #(CR_C | CR_M) @ MMU and Dcache must be disabled - mcr p15, 0, r0, c1, c0, 0 @ before jumping to Linux - mov r0, #0 - str r0, [r1] - b 1f - /* - * L2 cache is shared among all the CPUs and it might be disabled by - * the primary one. Before that, the following 5 lines must be cached - * on the Icaches of the secondary CPUs. - */ -0: wfe @ kicked by Linux -1: ldr r0, [r1] - cmp r0, #0 - bxne r0 @ r0: Linux entry for secondary CPUs - b 0b -primary_cpu: - ldr r1, =ROM_BOOT_ROMRSV2 - ldr r0, =secondary_startup - str r0, [r1] - ldr r0, [r1] @ make sure str is complete before sev - sev @ kick the secondary CPU -#endif - bl setup_init_ram @ RAM area for temporary stack pointer
mov lr, r8 @ restore link
On Fri, Nov 06, 2015 at 10:16:30PM +0900, Masahiro Yamada wrote:
The latest Linux can directly handle SMP operations for UniPhier SoCs without any help of U-boot. Drop the relevant code from U-boot.
See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier: rework SMP operations to use trampoline code") in Linux Kernel.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com
So my question for you is how much of a concern is running older kernels and newer U-Boots on these platforms? I know that for example we couldn't do something like that in "beagle" land, and for Allwinner platforms we still have ways of making the older but most featureful kernels work.
2015-11-06 22:46 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Nov 06, 2015 at 10:16:30PM +0900, Masahiro Yamada wrote:
The latest Linux can directly handle SMP operations for UniPhier SoCs without any help of U-boot. Drop the relevant code from U-boot.
See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier: rework SMP operations to use trampoline code") in Linux Kernel.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com
So my question for you is how much of a concern is running older kernels and newer U-Boots on these platforms? I know that for example we couldn't do something like that in "beagle" land, and for Allwinner platforms we still have ways of making the older but most featureful kernels work.
Good question.
Socionext (and my former company, Panasonic) tended to modify source code locally (ugly hacks here and there) and never tried to push patches to the upstream.
I started the kernel upstreaming this year, and the company changed the mind and stared to realize its importance, but it is under way.
The mainline kernel requires some more extra patches that have not been upstreamed yet.
So, our customers cannot do anything with the mainline kernel alone. They are supposed to use software stacks released from us.
So, the combination of the older kernels + newer U-boot does not matter. The older kernels were not working in the first place.
On Sat, Nov 07, 2015 at 01:12:14AM +0900, Masahiro Yamada wrote:
2015-11-06 22:46 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Nov 06, 2015 at 10:16:30PM +0900, Masahiro Yamada wrote:
The latest Linux can directly handle SMP operations for UniPhier SoCs without any help of U-boot. Drop the relevant code from U-boot.
See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier: rework SMP operations to use trampoline code") in Linux Kernel.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com
So my question for you is how much of a concern is running older kernels and newer U-Boots on these platforms? I know that for example we couldn't do something like that in "beagle" land, and for Allwinner platforms we still have ways of making the older but most featureful kernels work.
Good question.
Socionext (and my former company, Panasonic) tended to modify source code locally (ugly hacks here and there) and never tried to push patches to the upstream.
I started the kernel upstreaming this year, and the company changed the mind and stared to realize its importance, but it is under way.
The mainline kernel requires some more extra patches that have not been upstreamed yet.
So, our customers cannot do anything with the mainline kernel alone. They are supposed to use software stacks released from us.
So, the combination of the older kernels + newer U-boot does not matter. The older kernels were not working in the first place.
Thanks!
Reviewed-by: Tom Rini trini@konsulko.com
2015-11-08 21:43 GMT+09:00 Tom Rini trini@konsulko.com:
On Sat, Nov 07, 2015 at 01:12:14AM +0900, Masahiro Yamada wrote:
2015-11-06 22:46 GMT+09:00 Tom Rini trini@konsulko.com:
On Fri, Nov 06, 2015 at 10:16:30PM +0900, Masahiro Yamada wrote:
The latest Linux can directly handle SMP operations for UniPhier SoCs without any help of U-boot. Drop the relevant code from U-boot.
See commit b1e4006aeda8c8784029de17d47987c21ea75f6d ("ARM: uniphier: rework SMP operations to use trampoline code") in Linux Kernel.
Signed-off-by: Masahiro Yamada yamada.masahiro@socionext.com
So my question for you is how much of a concern is running older kernels and newer U-Boots on these platforms? I know that for example we couldn't do something like that in "beagle" land, and for Allwinner platforms we still have ways of making the older but most featureful kernels work.
Good question.
Socionext (and my former company, Panasonic) tended to modify source code locally (ugly hacks here and there) and never tried to push patches to the upstream.
I started the kernel upstreaming this year, and the company changed the mind and stared to realize its importance, but it is under way.
The mainline kernel requires some more extra patches that have not been upstreamed yet.
So, our customers cannot do anything with the mainline kernel alone. They are supposed to use software stacks released from us.
So, the combination of the older kernels + newer U-boot does not matter. The older kernels were not working in the first place.
Thanks!
Reviewed-by: Tom Rini trini@konsulko.com
Applied to u-boot-uniphier.
participants (2)
-
Masahiro Yamada -
Tom Rini