All of lore.kernel.org
 help / color / mirror / Atom feed
From: dinguyen@opensource.altera.com (Dinh Nguyen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: socfpga: fix fetching cpu1start_addr for system with  > 2GB of ram
Date: Thu, 2 Oct 2014 17:43:01 -0500	[thread overview]
Message-ID: <542DD4F5.1050602@opensource.altera.com> (raw)
In-Reply-To: <20141001132057.GO5182@n2100.arm.linux.org.uk>

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;

  reply	other threads:[~2014-10-02 22:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2014-10-02 23:04     ` Dinh Nguyen

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=542DD4F5.1050602@opensource.altera.com \
    --to=dinguyen@opensource.altera.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.