2019-06-04 08:11:33 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2012-10-25 16:41:39 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2003 ARM Limited
|
|
|
|
* Copyright (c) u-boot contributors
|
|
|
|
* Copyright (c) 2012 Pavel Machek <pavel@denx.de>
|
|
|
|
*/
|
|
|
|
#include <linux/linkage.h>
|
|
|
|
#include <linux/init.h>
|
ARM: mm: Make virt_to_pfn() a static inline
Making virt_to_pfn() a static inline taking a strongly typed
(const void *) makes the contract of a passing a pointer of that
type to the function explicit and exposes any misuse of the
macro virt_to_pfn() acting polymorphic and accepting many types
such as (void *), (unitptr_t) or (unsigned long) as arguments
without warnings.
Doing this is a bit intrusive: virt_to_pfn() requires
PHYS_PFN_OFFSET and PAGE_SHIFT to be defined, and this is defined in
<asm/page.h>, so this must be included *before* <asm/memory.h>.
The use of macros were obscuring the unclear inclusion order here,
as the macros would eventually be resolved, but a static inline
like this cannot be compiled with unresolved macros.
The naive solution to include <asm/page.h> at the top of
<asm/memory.h> does not work, because <asm/memory.h> sometimes
includes <asm/page.h> at the end of itself, which would create a
confusing inclusion loop. So instead, take the approach to always
unconditionally include <asm/page.h> at the end of <asm/memory.h>
arch/arm uses <asm/memory.h> explicitly in a lot of places,
however it turns out that if we just unconditionally include
<asm/memory.h> into <asm/page.h> and switch all inclusions of
<asm/memory.h> to <asm/page.h> instead, we enforce the right
order and <asm/memory.h> will always have access to the
definitions.
Put an inclusion guard in place making it impossible to include
<asm/memory.h> explicitly.
Link: https://lore.kernel.org/linux-mm/20220701160004.2ffff4e5ab59a55499f4c736@linux-foundation.org/
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-06-02 08:18:32 +00:00
|
|
|
#include <asm/page.h>
|
2015-03-25 11:27:47 +00:00
|
|
|
#include <asm/assembler.h>
|
2012-10-25 16:41:39 +00:00
|
|
|
|
2012-10-26 23:00:53 +00:00
|
|
|
.arch armv7-a
|
2016-04-20 13:34:31 +00:00
|
|
|
.arm
|
2012-10-25 16:41:39 +00:00
|
|
|
|
|
|
|
ENTRY(secondary_trampoline)
|
arm: socfpga: fix fetching cpu1start_addr for SMP
When CPU1 is brought out of reset, it's MMU is not turned on yet, so it will
only be able to use physical addresses. For systems with that have the
MMU page configured for 0xC0000000, 0x80000000, or 0x40000000
"BIC 0x40000000" will work just fine, as it was just converting the
virtual address of &cpu1start_addr into a physical address, ie. 0xC0000000
became 0x80000000. So for systems where the SDRAM controller was able to do a
wrap-around access, this was working fine, as it was just dropping the MSB,
but for systems where out of bounds memory access is not allowed, this would
not allow CPU1 to correctly fetch &cpu1start_addr.
This patch fixes the secondary_trampoline code to correctly fetch the
physical address of cpu1start_addr directly. The patch will subtract the
correct PAGE_OFFSET from &cpu1start_addr. And since on this platform, the
physical memory will always start at 0x0, subtracting PAGE_OFFSET from
&cpu1start_addr will allow CPU1 to correctly fetch the value of cpu1start_addr.
While at it, change the name of cpu1start_addr to socfpga_cpu1start_addr
to avoid any future naming collisions for multiplatform image.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
v4: Updated commit log to correctly lay out the usage of PAGE_OFFSET and
add comments to the same effect.
v3: Used PAGE_OFFSET to get the physical address
v2: Correctly get the physical address instead of just a BIC hack.
2014-10-01 10:44:48 +00:00
|
|
|
/* CPU1 will always fetch from 0x0 when it is brought out of reset.
|
|
|
|
* Thus, we can just subtract the PAGE_OFFSET to get the physical
|
|
|
|
* address of &cpu1start_addr. This would not work for platforms
|
|
|
|
* where the physical memory does not start at 0x0.
|
2015-03-25 11:27:47 +00:00
|
|
|
*/
|
|
|
|
ARM_BE8(setend be)
|
arm: socfpga: fix fetching cpu1start_addr for SMP
When CPU1 is brought out of reset, it's MMU is not turned on yet, so it will
only be able to use physical addresses. For systems with that have the
MMU page configured for 0xC0000000, 0x80000000, or 0x40000000
"BIC 0x40000000" will work just fine, as it was just converting the
virtual address of &cpu1start_addr into a physical address, ie. 0xC0000000
became 0x80000000. So for systems where the SDRAM controller was able to do a
wrap-around access, this was working fine, as it was just dropping the MSB,
but for systems where out of bounds memory access is not allowed, this would
not allow CPU1 to correctly fetch &cpu1start_addr.
This patch fixes the secondary_trampoline code to correctly fetch the
physical address of cpu1start_addr directly. The patch will subtract the
correct PAGE_OFFSET from &cpu1start_addr. And since on this platform, the
physical memory will always start at 0x0, subtracting PAGE_OFFSET from
&cpu1start_addr will allow CPU1 to correctly fetch the value of cpu1start_addr.
While at it, change the name of cpu1start_addr to socfpga_cpu1start_addr
to avoid any future naming collisions for multiplatform image.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
v4: Updated commit log to correctly lay out the usage of PAGE_OFFSET and
add comments to the same effect.
v3: Used PAGE_OFFSET to get the physical address
v2: Correctly get the physical address instead of just a BIC hack.
2014-10-01 10:44:48 +00:00
|
|
|
adr r0, 1f
|
|
|
|
ldmia r0, {r1, r2}
|
|
|
|
sub r2, r2, #PAGE_OFFSET
|
|
|
|
ldr r3, [r2]
|
|
|
|
ldr r4, [r3]
|
2015-03-25 11:27:47 +00:00
|
|
|
ARM_BE8(rev r4, r4)
|
arm: socfpga: fix fetching cpu1start_addr for SMP
When CPU1 is brought out of reset, it's MMU is not turned on yet, so it will
only be able to use physical addresses. For systems with that have the
MMU page configured for 0xC0000000, 0x80000000, or 0x40000000
"BIC 0x40000000" will work just fine, as it was just converting the
virtual address of &cpu1start_addr into a physical address, ie. 0xC0000000
became 0x80000000. So for systems where the SDRAM controller was able to do a
wrap-around access, this was working fine, as it was just dropping the MSB,
but for systems where out of bounds memory access is not allowed, this would
not allow CPU1 to correctly fetch &cpu1start_addr.
This patch fixes the secondary_trampoline code to correctly fetch the
physical address of cpu1start_addr directly. The patch will subtract the
correct PAGE_OFFSET from &cpu1start_addr. And since on this platform, the
physical memory will always start at 0x0, subtracting PAGE_OFFSET from
&cpu1start_addr will allow CPU1 to correctly fetch the value of cpu1start_addr.
While at it, change the name of cpu1start_addr to socfpga_cpu1start_addr
to avoid any future naming collisions for multiplatform image.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
v4: Updated commit log to correctly lay out the usage of PAGE_OFFSET and
add comments to the same effect.
v3: Used PAGE_OFFSET to get the physical address
v2: Correctly get the physical address instead of just a BIC hack.
2014-10-01 10:44:48 +00:00
|
|
|
bx r4
|
2012-10-25 16:41:39 +00:00
|
|
|
|
arm: socfpga: fix fetching cpu1start_addr for SMP
When CPU1 is brought out of reset, it's MMU is not turned on yet, so it will
only be able to use physical addresses. For systems with that have the
MMU page configured for 0xC0000000, 0x80000000, or 0x40000000
"BIC 0x40000000" will work just fine, as it was just converting the
virtual address of &cpu1start_addr into a physical address, ie. 0xC0000000
became 0x80000000. So for systems where the SDRAM controller was able to do a
wrap-around access, this was working fine, as it was just dropping the MSB,
but for systems where out of bounds memory access is not allowed, this would
not allow CPU1 to correctly fetch &cpu1start_addr.
This patch fixes the secondary_trampoline code to correctly fetch the
physical address of cpu1start_addr directly. The patch will subtract the
correct PAGE_OFFSET from &cpu1start_addr. And since on this platform, the
physical memory will always start at 0x0, subtracting PAGE_OFFSET from
&cpu1start_addr will allow CPU1 to correctly fetch the value of cpu1start_addr.
While at it, change the name of cpu1start_addr to socfpga_cpu1start_addr
to avoid any future naming collisions for multiplatform image.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
v4: Updated commit log to correctly lay out the usage of PAGE_OFFSET and
add comments to the same effect.
v3: Used PAGE_OFFSET to get the physical address
v2: Correctly get the physical address instead of just a BIC hack.
2014-10-01 10:44:48 +00:00
|
|
|
.align
|
|
|
|
1: .long .
|
|
|
|
.long socfpga_cpu1start_addr
|
2012-10-25 16:41:39 +00:00
|
|
|
ENTRY(secondary_trampoline_end)
|