Patchwork [RFC] sparc32,leon: always include leon code in build

login
register
mail settings
Submitter Sam Ravnborg
Date May 14, 2012, 8:29 p.m.
Message ID <20120514202951.GA4439@merkur.ravnborg.org>
Download mbox | patch
Permalink /patch/159160/
State RFC
Delegated to: David Miller
Headers show

Comments

Sam Ravnborg - May 14, 2012, 8:29 p.m.
From c1caf78ed4ce33bc15ba5e1f186938a1c6668049 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Mon, 14 May 2012 22:22:26 +0200
Subject: [PATCH] sparc32,leon: always include leon code in build

Numerous times I have hit situations where my changes failed
to build on LEON.
Update so we always include leon code in the build.

The resulting kernel will NOT boot on leon, but in this way we
avoid introducing regressions in leon specific parts of the code.

As leon and sun4x uses different values for ASI_M_MMUREGS
I do not expect the same kernel to actually boot both
on leon and sun boxes.
At least I see no way around this right now.

All other differences looks manageable if we can find a way around
the ASI_M_MMUREGS issue.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Konrad Eisele <konrad@gaisler.com>
Cc: Daniel Hellstrom <daniel@gaisler.com>
---
 arch/sparc/include/asm/leon.h      |   19 +------------------
 arch/sparc/include/asm/leon_amba.h |    4 ----
 arch/sparc/include/asm/pgtsrmmu.h  |   16 ----------------
 arch/sparc/kernel/Makefile         |    4 ++--
 arch/sparc/kernel/entry.S          |    3 ---
 arch/sparc/kernel/leon_smp.c       |    4 ----
 arch/sparc/mm/Makefile             |    2 +-
 arch/sparc/mm/leon_mm.c            |    2 +-
 arch/sparc/mm/srmmu.c              |   18 ++++++++++++++++--
 9 files changed, 21 insertions(+), 51 deletions(-)
David Miller - May 14, 2012, 9:56 p.m.
From: Sam Ravnborg <sam@ravnborg.org>
Date: Mon, 14 May 2012 22:29:51 +0200

>>From c1caf78ed4ce33bc15ba5e1f186938a1c6668049 Mon Sep 17 00:00:00 2001
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Mon, 14 May 2012 22:22:26 +0200
> Subject: [PATCH] sparc32,leon: always include leon code in build
> 
> Numerous times I have hit situations where my changes failed
> to build on LEON.
> Update so we always include leon code in the build.
> 
> The resulting kernel will NOT boot on leon, but in this way we
> avoid introducing regressions in leon specific parts of the code.
> 
> As leon and sun4x uses different values for ASI_M_MMUREGS
> I do not expect the same kernel to actually boot both
> on leon and sun boxes.
> At least I see no way around this right now.
> 
> All other differences looks manageable if we can find a way around
> the ASI_M_MMUREGS issue.
> 
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>

Indeed, it's a pain.  My basic build tests involve 4 cases
because of this (iterating on CONFIG_SMP and CONFIG_LEON).

But I think we should resolve the remaining issues that keep LEON
builds from working on other cpus first, because the thing you're
after will fall transparently out of that.

It's beyond embarassing that with how much we parameterize things at
runtime on sparc32, we can't do something so simple as adding LEON to
the mix transparently.

I think we should have been more strict when reviewing the original
LEON patches.

For one thing there is no reason in the world to have a different
value of ASI_M_MMUREGS.

If LEON puts that stuff at a different ASI, well then the code needs
to be different on LEON and either patched at run-time or hooked into
the various OPS method vectors we have.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sam Ravnborg - May 16, 2012, 12:39 p.m.
> > 
> > All other differences looks manageable if we can find a way around
> > the ASI_M_MMUREGS issue.
> > 
> But I think we should resolve the remaining issues that keep LEON
> builds from working on other cpus first, because the thing you're
> after will fall transparently out of that.
> 
> For one thing there is no reason in the world to have a different
> value of ASI_M_MMUREGS.

Konrad / Daniel - any inputs on why LEON uses a different ASI?
As we uses this in head_32.S this is really annoying...

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiri Gaisler - May 16, 2012, 12:55 p.m.
Sam Ravnborg wrote:

> Konrad / Daniel - any inputs on why LEON uses a different ASI?
> As we uses this in head_32.S this is really annoying...

It is not difficult to change the MMU reg ASI from 0x19 to 0x4
(as defined in the SRMMU spec). However, all available LEON2/3/4
chips in production uses 0x19 due to a decision take about 10
years ago. ASI 4 was used for uncached access in the original
MMU-less LEON2, hence the choice to use 0x19. In current LEON3/4
cores, ASI 4 is no longer used, so 0x19 could easily be replaced
with 4. But removing the use of ASI 0x19 in the kernel will make
it incompatible with all present chips. I will change the LEON3/4
IP's to double map the MMU ASI to both 4 and 0x19, but then we have
to wait an other 10 years until the present chips are out of use
before we can remove 0x19 from the kernel ...

Jiri.


> 
> 	Sam
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sam Ravnborg - May 16, 2012, 2:58 p.m.
Hi Jiri.

> 
> > Konrad / Daniel - any inputs on why LEON uses a different ASI?
> > As we uses this in head_32.S this is really annoying...
> 
> It is not difficult to change the MMU reg ASI from 0x19 to 0x4
> (as defined in the SRMMU spec). However, all available LEON2/3/4
> chips in production uses 0x19 due to a decision take about 10
> years ago.
Then I consider that cast in stone :-(
We have leon boards out that uses ASI == 0x19.

What we really need is an implementation of head_32.S that transparently
handle the existing sun4m + sun4d boxes + the leon based boards.

If there is a way we reliably early on can decide if we run
one of the leon chips then we can always use a separate track in
head_32.S for the leon stuff.

Not that I like to do so - but this is better than the current
situation where we magically redefine ASI and thus are not
compatible with all paltforms in the same code.

I am having something in mind where we from head_32.S call

    void sparc32_start_kernel(int cpu_model)

Then we can do the final preparations here before we call
start_kernel().

Today we transfer the cpu_model in the global variable
cputypval - and we may continue to do so too.

The point is that we should try to come up with
a head_32.S that handle but leon and non-leon
cpu's in the same file.
Then we can always handle the remaining issues using
instruction patching or ops structures etc.

If someone a Gaisler can look into head_32.S then
I would be happy to help with the rest.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sam Ravnborg - May 16, 2012, 5:20 p.m.
On Wed, May 16, 2012 at 04:58:26PM +0200, Sam Ravnborg wrote:
> Hi Jiri.
> 
> > 
> > > Konrad / Daniel - any inputs on why LEON uses a different ASI?
> > > As we uses this in head_32.S this is really annoying...
> > 
> > It is not difficult to change the MMU reg ASI from 0x19 to 0x4
> > (as defined in the SRMMU spec). However, all available LEON2/3/4
> > chips in production uses 0x19 due to a decision take about 10
> > years ago.
> Then I consider that cast in stone :-(
> We have leon boards out that uses ASI == 0x19.
> 
> What we really need is an implementation of head_32.S that transparently
> handle the existing sun4m + sun4d boxes + the leon based boards.
> 
> If there is a way we reliably early on can decide if we run
> one of the leon chips then we can always use a separate track in
> head_32.S for the leon stuff.

I have looked at what they do in BSD - and if I combinethat
with what we have in Linux I think I can come up with something.
It requre that we read PSR early to determine the CPU type,
but we already read PSR so this should not be an issue.

Let me try to cook up something.
It will take some days - so do not hold your breath...

	Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - May 16, 2012, 7:09 p.m.
From: Jiri Gaisler <jiri@gaisler.se>
Date: Wed, 16 May 2012 14:55:48 +0200

> 
> 
> Sam Ravnborg wrote:
> 
>> Konrad / Daniel - any inputs on why LEON uses a different ASI?
>> As we uses this in head_32.S this is really annoying...
> 
> It is not difficult to change the MMU reg ASI from 0x19 to 0x4
> (as defined in the SRMMU spec). However, all available LEON2/3/4
> chips in production uses 0x19 due to a decision take about 10
> years ago. ASI 4 was used for uncached access in the original
> MMU-less LEON2, hence the choice to use 0x19. In current LEON3/4
> cores, ASI 4 is no longer used, so 0x19 could easily be replaced
> with 4. But removing the use of ASI 0x19 in the kernel will make
> it incompatible with all present chips. I will change the LEON3/4
> IP's to double map the MMU ASI to both 4 and 0x19, but then we have
> to wait an other 10 years until the present chips are out of use
> before we can remove 0x19 from the kernel ...

This is not what we're asking you to do.

We're asking you to rearrange the code so that we can set
ASI_M_MMUREGS to it's proper SRMMU value, and then you change all the
LEON code to take different paths and use Leon specific code to
program the MMU.

In that way we can have one kernel image that boots properly
on all cpu types, rather than the current broken situation where
a Leon enabled build makes the kernel unbootable on real SRMMU
chips.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/sparc/include/asm/leon.h b/arch/sparc/include/asm/leon.h
index 8095be2..7a5c396 100644
--- a/arch/sparc/include/asm/leon.h
+++ b/arch/sparc/include/asm/leon.h
@@ -8,8 +8,6 @@ 
 #ifndef LEON_H_INCLUDE
 #define LEON_H_INCLUDE
 
-#ifdef CONFIG_SPARC_LEON
-
 #define ASI_LEON_NOCACHE	0x01
 
 #define ASI_LEON_DCACHE_MISS	0x1
@@ -278,7 +276,7 @@  static inline int sparc_leon3_cpuid(void)
 #define LEON2_CFG_SSIZE_MASK 0x00007000UL
 
 #ifndef __ASSEMBLY__
-extern unsigned long srmmu_swprobe(unsigned long vaddr, unsigned long *paddr);
+extern unsigned long leon_srmmu_swprobe(unsigned long vaddr, unsigned long *paddr);
 extern void leon_flush_icache_all(void);
 extern void leon_flush_dcache_all(void);
 extern void leon_flush_cache_all(void);
@@ -326,7 +324,6 @@  extern void leon_trans_init(struct device_node *dp);
 extern void leon_node_init(struct device_node *dp, struct device_node ***nextp);
 extern void leon_init_IRQ(void);
 extern void leon_init(void);
-extern unsigned long srmmu_swprobe(unsigned long vaddr, unsigned long *paddr);
 extern void init_leon(void);
 extern void poke_leonsparc(void);
 extern void leon3_getCacheRegs(struct leon3_cacheregs *regs);
@@ -367,18 +364,4 @@  extern int leon_ipi_irq;
 #define _pfn_valid(pfn)	 ((pfn < last_valid_pfn) && (pfn >= PFN(phys_base)))
 #define _SRMMU_PTE_PMASK_LEON 0xffffffff
 
-#else /* defined(CONFIG_SPARC_LEON) */
-
-/* nop definitions for !LEON case */
-#define leon_init() do {} while (0)
-#define leon_switch_mm() do {} while (0)
-#define leon_init_IRQ() do {} while (0)
-#define init_leon() do {} while (0)
-#define leon_smp_done() do {} while (0)
-#define leon_boot_cpus() do {} while (0)
-#define leon_boot_one_cpu(i) 1
-#define leon_init_smp() do {} while (0)
-
-#endif /* !defined(CONFIG_SPARC_LEON) */
-
 #endif
diff --git a/arch/sparc/include/asm/leon_amba.h b/arch/sparc/include/asm/leon_amba.h
index e50f326..f3034ed 100644
--- a/arch/sparc/include/asm/leon_amba.h
+++ b/arch/sparc/include/asm/leon_amba.h
@@ -87,8 +87,6 @@  struct amba_prom_registers {
 #define LEON3_GPTIMER_CONFIG_NRTIMERS(c) ((c)->config & 0x7)
 #define LEON3_GPTIMER_CTRL_ISPENDING(r)  (((r)&LEON3_GPTIMER_CTRL_PENDING) ? 1 : 0)
 
-#ifdef CONFIG_SPARC_LEON
-
 #ifndef __ASSEMBLY__
 
 struct leon3_irqctrl_regs_map {
@@ -264,6 +262,4 @@  extern unsigned int sparc_leon_eirq;
 
 #define amba_device(x) (((x) >> 12) & 0xfff)
 
-#endif /* !defined(CONFIG_SPARC_LEON) */
-
 #endif
diff --git a/arch/sparc/include/asm/pgtsrmmu.h b/arch/sparc/include/asm/pgtsrmmu.h
index f6ae2b2..065e036 100644
--- a/arch/sparc/include/asm/pgtsrmmu.h
+++ b/arch/sparc/include/asm/pgtsrmmu.h
@@ -267,22 +267,6 @@  static inline void srmmu_flush_tlb_page(unsigned long page)
 
 }
 
-#ifndef CONFIG_SPARC_LEON
-static inline unsigned long srmmu_hwprobe(unsigned long vaddr)
-{
-	unsigned long retval;
-
-	vaddr &= PAGE_MASK;
-	__asm__ __volatile__("lda [%1] %2, %0\n\t" :
-			     "=r" (retval) :
-			     "r" (vaddr | 0x400), "i" (ASI_M_FLUSH_PROBE));
-
-	return retval;
-}
-#else
-#define srmmu_hwprobe(addr) srmmu_swprobe(addr, 0)
-#endif
-
 static inline int
 srmmu_get_pte (unsigned long addr)
 {
diff --git a/arch/sparc/kernel/Makefile b/arch/sparc/kernel/Makefile
index bfb93c3..aca3044 100644
--- a/arch/sparc/kernel/Makefile
+++ b/arch/sparc/kernel/Makefile
@@ -53,8 +53,8 @@  obj-y                   += of_device_common.o
 obj-y                   += of_device_$(BITS).o
 obj-$(CONFIG_SPARC64)   += prom_irqtrans.o
 
-obj-$(CONFIG_SPARC_LEON)+= leon_kernel.o
-obj-$(CONFIG_SPARC_LEON)+= leon_pmc.o
+obj-$(CONFIG_SPARC32)   += leon_kernel.o
+obj-$(CONFIG_SPARC32)   += leon_pmc.o
 
 obj-$(CONFIG_SPARC64)   += reboot.o
 obj-$(CONFIG_SPARC64)   += sysfs.o
diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S
index 3215b6d..8ea040c 100644
--- a/arch/sparc/kernel/entry.S
+++ b/arch/sparc/kernel/entry.S
@@ -388,7 +388,6 @@  linux_trap_ipi15_sun4d:
 	/* FIXME */
 1:	b,a	1b
 
-#ifdef CONFIG_SPARC_LEON
 	.globl	smpleon_ipi
 	.extern leon_ipi_interrupt
 	/* SMP per-cpu IPI interrupts are handled specially. */
@@ -419,8 +418,6 @@  linux_trap_ipi15_leon:
 	b	ret_trap_lockless_ipi
 	 clr	%l6
 
-#endif /* CONFIG_SPARC_LEON */
-
 #endif /* CONFIG_SMP */
 
 	/* This routine handles illegal instructions and privileged
diff --git a/arch/sparc/kernel/leon_smp.c b/arch/sparc/kernel/leon_smp.c
index 29325ba..0c1b358 100644
--- a/arch/sparc/kernel/leon_smp.c
+++ b/arch/sparc/kernel/leon_smp.c
@@ -48,8 +48,6 @@ 
 
 #include "kernel.h"
 
-#ifdef CONFIG_SPARC_LEON
-
 #include "irq.h"
 
 extern ctxd_t *srmmu_ctx_table_phys;
@@ -512,5 +510,3 @@  void __init leon_init_smp(void)
 
 	sparc32_ipi_ops = &leon_ipi_ops;
 }
-
-#endif /* CONFIG_SPARC_LEON */
diff --git a/arch/sparc/mm/Makefile b/arch/sparc/mm/Makefile
index 69ffd31..389aebd 100644
--- a/arch/sparc/mm/Makefile
+++ b/arch/sparc/mm/Makefile
@@ -9,7 +9,7 @@  obj-y                   += fault_$(BITS).o
 obj-y                   += init_$(BITS).o
 obj-$(CONFIG_SPARC32)   += extable.o srmmu.o iommu.o io-unit.o
 obj-$(CONFIG_SPARC32)   += hypersparc.o viking.o tsunami.o swift.o
-obj-$(CONFIG_SPARC_LEON)+= leon_mm.o
+obj-$(CONFIG_SPARC32)   += leon_mm.o
 
 # Only used by sparc64
 obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
diff --git a/arch/sparc/mm/leon_mm.c b/arch/sparc/mm/leon_mm.c
index 13c2169..ec866eb 100644
--- a/arch/sparc/mm/leon_mm.c
+++ b/arch/sparc/mm/leon_mm.c
@@ -18,7 +18,7 @@ 
 int leon_flush_during_switch = 1;
 int srmmu_swprobe_trace;
 
-unsigned long srmmu_swprobe(unsigned long vaddr, unsigned long *paddr)
+unsigned long leon_srmmu_swprobe(unsigned long vaddr, unsigned long *paddr)
 {
 
 	unsigned int ctxtbl;
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 765b1a5..b569ecf 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -928,6 +928,22 @@  static void __init srmmu_allocate_ptable_skeleton(unsigned long start,
 	}
 }
 
+static unsigned long srmmu_hwprobe(unsigned long vaddr)
+{
+	if (sparc_cpu_model != sparc_leon) {
+		unsigned long retval;
+
+		vaddr &= PAGE_MASK;
+		__asm__ __volatile__("lda [%1] %2, %0\n\t" :
+				     "=r" (retval) :
+				     "r" (vaddr | 0x400), "i" (ASI_M_FLUSH_PROBE));
+
+		return retval;
+	} else {
+		return leon_srmmu_swprobe(vaddr, 0);
+	}
+}
+
 /*
  * This is much cleaner than poking around physical address space
  * looking at the prom's page table directly which is what most
@@ -1801,7 +1817,6 @@  static void __init init_viking(void)
 	poke_srmmu = poke_viking;
 }
 
-#ifdef CONFIG_SPARC_LEON
 static void leon_flush_cache_mm(struct mm_struct *mm)
 {
 	leon_flush_cache_all();
@@ -1880,7 +1895,6 @@  void __init init_leon(void)
 
 	leon_flush_during_switch = leon_flush_needed();
 }
-#endif
 
 /* Probe for the srmmu chip version. */
 static void __init get_srmmu_type(void)