* [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with > 2GB of ram @ 2014-10-01 11:02 dinguyen at opensource.altera.com 2014-10-01 13:20 ` Russell King - ARM Linux 0 siblings, 1 reply; 4+ messages in thread From: dinguyen at opensource.altera.com @ 2014-10-01 11:02 UTC (permalink / raw) To: linux-arm-kernel From: Dinh Nguyen <dinguyen@opensource.altera.com> When CPU1 is brought out of reset, it's MMU is not turned yet, so it will only be able to use physical addresses. For systems with 1GB or less, clearing 0x40000000 will work just fine. However for systems with 2GB or more, we need to clear at least 0x80000000. Essentially, the bic instruction is converting the cpu1start_addr from a virtual to a physical address. We should be using bic 0xf0000000 for all systems. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> --- arch/arm/mach-socfpga/headsmp.S | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-socfpga/headsmp.S b/arch/arm/mach-socfpga/headsmp.S index 95c115d..d686f99 100644 --- a/arch/arm/mach-socfpga/headsmp.S +++ b/arch/arm/mach-socfpga/headsmp.S @@ -16,9 +16,8 @@ ENTRY(secondary_trampoline) movw r2, #:lower16:cpu1start_addr movt r2, #:upper16:cpu1start_addr - /* The socfpga VT cannot handle a 0xC0000000 page offset when loading - the cpu1start_addr, we bit clear it. Tested on HW and VT. */ - bic r2, r2, #0x40000000 + /* convert cpu1start_addr to a physical address */ + bic r2, r2, #0xf0000000 ldr r0, [r2] ldr r1, [r0] -- 2.0.3 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with > 2GB of ram 2014-10-01 11:02 [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with > 2GB of ram dinguyen at opensource.altera.com @ 2014-10-01 13:20 ` Russell King - ARM Linux 2014-10-02 22:43 ` Dinh Nguyen 0 siblings, 1 reply; 4+ messages in thread From: Russell King - ARM Linux @ 2014-10-01 13:20 UTC (permalink / raw) To: linux-arm-kernel On Wed, Oct 01, 2014 at 06:02:14AM -0500, dinguyen at opensource.altera.com wrote: > From: Dinh Nguyen <dinguyen@opensource.altera.com> > > When CPU1 is brought out of reset, it's MMU is not turned yet, so it will only > be able to use physical addresses. For systems with 1GB or less, clearing > 0x40000000 will work just fine. However for systems with 2GB or more, we > need to clear at least 0x80000000. > > Essentially, the bic instruction is converting the cpu1start_addr from a > virtual to a physical address. We should be using bic 0xf0000000 for all > systems. Err. Why not do the job properly rather than create this type of hack? This is not a fast path, so it's really not required to code it for an absolute minimum number of cycles. So... adr r0, 1f @ physical address of '1' ldmia r0, {r1, r2} @ load virtual address of '1' and 'cpu1start_addr' sub r0, r0, r1 @ offset between virtual and physical ldr r2, [r2, r0] @ load *cpu1start_addr bx r2 ... .align 1: .long . .long cpu1start_addr will fix it properly. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with > 2GB of ram 2014-10-01 13:20 ` Russell King - ARM Linux @ 2014-10-02 22:43 ` Dinh Nguyen 2014-10-02 23:04 ` Dinh Nguyen 0 siblings, 1 reply; 4+ messages in thread From: Dinh Nguyen @ 2014-10-02 22:43 UTC (permalink / raw) To: linux-arm-kernel On 10/01/2014 08:20 AM, Russell King - ARM Linux wrote: > On Wed, Oct 01, 2014 at 06:02:14AM -0500, dinguyen at opensource.altera.com wrote: >> From: Dinh Nguyen <dinguyen@opensource.altera.com> >> >> When CPU1 is brought out of reset, it's MMU is not turned yet, so it will only >> be able to use physical addresses. For systems with 1GB or less, clearing >> 0x40000000 will work just fine. However for systems with 2GB or more, we >> need to clear at least 0x80000000. >> >> Essentially, the bic instruction is converting the cpu1start_addr from a >> virtual to a physical address. We should be using bic 0xf0000000 for all >> systems. > > Err. Why not do the job properly rather than create this type of hack? > This is not a fast path, so it's really not required to code it for an > absolute minimum number of cycles. So... > > adr r0, 1f @ physical address of '1' > ldmia r0, {r1, r2} @ load virtual address of '1' and 'cpu1start_addr' > sub r0, r0, r1 @ offset between virtual and physical > ldr r2, [r2, r0] @ load *cpu1start_addr > bx r2 > ... > .align > 1: .long . > .long cpu1start_addr > > will fix it properly. > Thanks for the suggestion and the code, but it didn't seem to work for me. But I think I found a way to just load in the value of cpu1start_addr directly with this patch. Please let me know what you think of this solution: diff --git a/arch/arm/mach-socfpga/headsmp.S b/arch/arm/mach-socfpga/headsmp.S index 95c115d..3ca9ed1 100644 --- a/arch/arm/mach-socfpga/headsmp.S +++ b/arch/arm/mach-socfpga/headsmp.S @@ -13,17 +13,14 @@ .arch armv7-a ENTRY(secondary_trampoline) - movw r2, #:lower16:cpu1start_addr - movt r2, #:upper16:cpu1start_addr - - /* The socfpga VT cannot handle a 0xC0000000 page offset when loading - the cpu1start_addr, we bit clear it. Tested on HW and VT. */ - bic r2, r2, #0x40000000 - - ldr r0, [r2] + ldr r0, 1f ldr r1, [r0] bx r1 + .globl cpu1start_addr +cpu1start_addr: +1: .space 4 + ENTRY(secondary_trampoline_end) ENTRY(socfpga_secondary_startup) diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c index adbf383..0fe1883 100644 --- a/arch/arm/mach-socfpga/socfpga.c +++ b/arch/arm/mach-socfpga/socfpga.c @@ -29,7 +29,6 @@ void __iomem *socfpga_scu_base_addr = ((void __iomem *)(SOCFPGA_SCU_VIRT_BASE)); void __iomem *sys_manager_base_addr; void __iomem *rst_manager_base_addr; -unsigned long cpu1start_addr; ^ permalink raw reply related [flat|nested] 4+ messages in thread
* [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with > 2GB of ram 2014-10-02 22:43 ` Dinh Nguyen @ 2014-10-02 23:04 ` Dinh Nguyen 0 siblings, 0 replies; 4+ messages in thread From: Dinh Nguyen @ 2014-10-02 23:04 UTC (permalink / raw) To: linux-arm-kernel On Thu, Oct 2, 2014 at 5:43 PM, Dinh Nguyen <dinguyen@opensource.altera.com> wrote: > On 10/01/2014 08:20 AM, Russell King - ARM Linux wrote: >> On Wed, Oct 01, 2014 at 06:02:14AM -0500, dinguyen at opensource.altera.com wrote: >>> From: Dinh Nguyen <dinguyen@opensource.altera.com> >>> >>> When CPU1 is brought out of reset, it's MMU is not turned yet, so it will only >>> be able to use physical addresses. For systems with 1GB or less, clearing >>> 0x40000000 will work just fine. However for systems with 2GB or more, we >>> need to clear at least 0x80000000. >>> >>> Essentially, the bic instruction is converting the cpu1start_addr from a >>> virtual to a physical address. We should be using bic 0xf0000000 for all >>> systems. >> >> Err. Why not do the job properly rather than create this type of hack? >> This is not a fast path, so it's really not required to code it for an >> absolute minimum number of cycles. So... >> >> adr r0, 1f @ physical address of '1' >> ldmia r0, {r1, r2} @ load virtual address of '1' and 'cpu1start_addr' >> sub r0, r0, r1 @ offset between virtual and physical >> ldr r2, [r2, r0] @ load *cpu1start_addr >> bx r2 >> ... >> .align >> 1: .long . >> .long cpu1start_addr >> >> will fix it properly. >> > > Thanks for the suggestion and the code, but it didn't seem to work for > me. But I think I found a way to just load in the value of > cpu1start_addr directly with this patch. Please let me know what you > think of this solution: > > > diff --git a/arch/arm/mach-socfpga/headsmp.S > b/arch/arm/mach-socfpga/headsmp.S > index 95c115d..3ca9ed1 100644 > --- a/arch/arm/mach-socfpga/headsmp.S > +++ b/arch/arm/mach-socfpga/headsmp.S > @@ -13,17 +13,14 @@ > .arch armv7-a > > ENTRY(secondary_trampoline) > - movw r2, #:lower16:cpu1start_addr > - movt r2, #:upper16:cpu1start_addr > - > - /* The socfpga VT cannot handle a 0xC0000000 page offset when > loading > - the cpu1start_addr, we bit clear it. Tested on HW and VT. */ > - bic r2, r2, #0x40000000 > - > - ldr r0, [r2] > + ldr r0, 1f > ldr r1, [r0] > bx r1 > > + .globl cpu1start_addr > I guess I should also rename cpu1start_addr to socfpga_cpu1start_addr to avoid name collisions? Dinh ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-02 23:04 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-01 11:02 [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with > 2GB of ram dinguyen at opensource.altera.com 2014-10-01 13:20 ` Russell King - ARM Linux 2014-10-02 22:43 ` Dinh Nguyen 2014-10-02 23:04 ` Dinh Nguyen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).