* [PATCH 14/17] Fix powerpc irqflags
From: David Howells @ 2010-09-10 16:25 UTC (permalink / raw)
To: linux-arch; +Cc: torvalds, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20100910162407.20817.34359.stgit@warthog.procyon.org.uk>
This (sub)patch is separated out for reviewing purposes. Once ACK'd it will
need to be rolled into the main patch.
Cc: benh@kernel.crashing.org
Cc: paulus@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/hw_irq.h | 113 ++++++++++++++++++++--------------
arch/powerpc/include/asm/irqflags.h | 2 -
arch/powerpc/kernel/exceptions-64s.S | 4 +
arch/powerpc/kernel/irq.c | 4 +
4 files changed, 70 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index bd100fc..ff08b70 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -16,42 +16,57 @@ extern void timer_interrupt(struct pt_regs *);
#ifdef CONFIG_PPC64
#include <asm/paca.h>
-static inline unsigned long local_get_flags(void)
+static inline unsigned long arch_local_save_flags(void)
{
unsigned long flags;
- __asm__ __volatile__("lbz %0,%1(13)"
- : "=r" (flags)
- : "i" (offsetof(struct paca_struct, soft_enabled)));
+ asm volatile(
+ "lbz %0,%1(13)"
+ : "=r" (flags)
+ : "i" (offsetof(struct paca_struct, soft_enabled)));
return flags;
}
-static inline unsigned long raw_local_irq_disable(void)
+static inline unsigned long arch_local_irq_disable(void)
{
unsigned long flags, zero;
- __asm__ __volatile__("li %1,0; lbz %0,%2(13); stb %1,%2(13)"
- : "=r" (flags), "=&r" (zero)
- : "i" (offsetof(struct paca_struct, soft_enabled))
- : "memory");
+ asm volatile(
+ "li %1,0; lbz %0,%2(13); stb %1,%2(13)"
+ : "=r" (flags), "=&r" (zero)
+ : "i" (offsetof(struct paca_struct, soft_enabled))
+ : "memory");
return flags;
}
-extern void raw_local_irq_restore(unsigned long);
+extern void arch_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define raw_local_irq_enable() raw_local_irq_restore(1)
-#define raw_local_save_flags(flags) ((flags) = local_get_flags())
-#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
+static inline void arch_local_irq_enable(void)
+{
+ arch_local_irq_restore(1);
+}
+
+static inline unsigned long arch_local_irq_save(void)
+{
+ return arch_local_irq_disable();
+}
+
+static inline bool arch_irqs_disabled_flags(unsigned long flags)
+{
+ return flags == 0;
+}
-#define raw_irqs_disabled() (local_get_flags() == 0)
-#define raw_irqs_disabled_flags(flags) ((flags) == 0)
+static inline bool arch_irqs_disabled(void)
+{
+ return arch_irqs_disabled_flags(arch_local_save_flags());
+}
#ifdef CONFIG_PPC_BOOK3E
-#define __hard_irq_enable() __asm__ __volatile__("wrteei 1": : :"memory");
-#define __hard_irq_disable() __asm__ __volatile__("wrteei 0": : :"memory");
+#define __hard_irq_enable() asm volatile("wrteei 1" : : : "memory");
+#define __hard_irq_disable() asm volatile("wrteei 0" : : : "memory");
#else
#define __hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
@@ -64,64 +79,66 @@ extern void iseries_handle_interrupts(void);
get_paca()->hard_enabled = 0; \
} while(0)
-#else
+#else /* CONFIG_PPC64 */
-#if defined(CONFIG_BOOKE)
#define SET_MSR_EE(x) mtmsr(x)
-#define raw_local_irq_restore(flags) __asm__ __volatile__("wrtee %0" : : "r" (flags) : "memory")
+
+static inline unsigned long arch_local_save_flags(void)
+{
+ return mfmsr();
+}
+
+static inline void arch_local_irq_restore(unsigned long flags)
+{
+#if defined(CONFIG_BOOKE)
+ asm volatile("wrtee %0" : : "r" (flags) : "memory");
#else
-#define SET_MSR_EE(x) mtmsr(x)
-#define raw_local_irq_restore(flags) mtmsr(flags)
+ mtmsr(flags);
#endif
+}
-static inline void raw_local_irq_disable(void)
+static inline unsigned long arch_local_irq_save(void)
{
+ unsigned long flags = arch_local_save_flags();
#ifdef CONFIG_BOOKE
- __asm__ __volatile__("wrteei 0": : :"memory");
+ asm volatile("wrteei 0" : : : "memory");
#else
- unsigned long msr;
-
- msr = mfmsr();
- SET_MSR_EE(msr & ~MSR_EE);
+ SET_MSR_EE(flags & ~MSR_EE);
#endif
+ return flags;
}
-static inline void raw_local_irq_enable(void)
+static inline void arch_local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
- __asm__ __volatile__("wrteei 1": : :"memory");
+ asm volatile("wrteei 0" : : : "memory");
#else
- unsigned long msr;
-
- msr = mfmsr();
- SET_MSR_EE(msr | MSR_EE);
+ arch_local_irq_save();
#endif
}
-static inline void raw_local_irq_save_ptr(unsigned long *flags)
+static inline void arch_local_irq_enable(void)
{
- unsigned long msr;
- msr = mfmsr();
- *flags = msr;
#ifdef CONFIG_BOOKE
- __asm__ __volatile__("wrteei 0": : :"memory");
+ asm volatile("wrteei 1" : : : "memory");
#else
- SET_MSR_EE(msr & ~MSR_EE);
+ unsigned long msr = mfmsr();
+ SET_MSR_EE(msr | MSR_EE);
#endif
}
-#define raw_local_save_flags(flags) ((flags) = mfmsr())
-#define raw_local_irq_save(flags) raw_local_irq_save_ptr(&flags)
-#define raw_irqs_disabled() ((mfmsr() & MSR_EE) == 0)
-#define raw_irqs_disabled_flags(flags) (((flags) & MSR_EE) == 0)
-
-#define hard_irq_disable() raw_local_irq_disable()
-
-static inline int irqs_disabled_flags(unsigned long flags)
+static inline bool arch_irqs_disabled_flags(unsigned long flags)
{
return (flags & MSR_EE) == 0;
}
+static inline bool arch_irqs_disabled(void)
+{
+ return arch_irqs_disabled_flags(arch_local_save_flags());
+}
+
+#define hard_irq_disable() arch_local_irq_disable()
+
#endif /* CONFIG_PPC64 */
/*
diff --git a/arch/powerpc/include/asm/irqflags.h b/arch/powerpc/include/asm/irqflags.h
index 5f68ecf..b85d8dd 100644
--- a/arch/powerpc/include/asm/irqflags.h
+++ b/arch/powerpc/include/asm/irqflags.h
@@ -6,7 +6,7 @@
#ifndef __ASSEMBLY__
/*
- * Get definitions for raw_local_save_flags(x), etc.
+ * Get definitions for arch_local_save_flags(x), etc.
*/
#include <asm/hw_irq.h>
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index f53029a..39b0c48 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -818,12 +818,12 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISERIES)
/*
* hash_page couldn't handle it, set soft interrupt enable back
- * to what it was before the trap. Note that .raw_local_irq_restore
+ * to what it was before the trap. Note that .arch_local_irq_restore
* handles any interrupts pending at this point.
*/
ld r3,SOFTE(r1)
TRACE_AND_RESTORE_IRQ_PARTIAL(r3, 11f)
- bl .raw_local_irq_restore
+ bl .arch_local_irq_restore
b 11f
/* We have a data breakpoint exception - handle it */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4a65386..1903290 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -116,7 +116,7 @@ static inline notrace void set_soft_enabled(unsigned long enable)
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-notrace void raw_local_irq_restore(unsigned long en)
+notrace void arch_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
@@ -192,7 +192,7 @@ notrace void raw_local_irq_restore(unsigned long en)
__hard_irq_enable();
}
-EXPORT_SYMBOL(raw_local_irq_restore);
+EXPORT_SYMBOL(arch_local_irq_restore);
#endif /* CONFIG_PPC64 */
static int show_other_interrupts(struct seq_file *p, int prec)
^ permalink raw reply related
* Re: how to understand powerpc's BRx ORx
From: Kumar Gala @ 2010-09-10 13:37 UTC (permalink / raw)
To: hacklu; +Cc: linuxppc-dev
In-Reply-To: <201009101356067140460@gmail.com>
On Sep 10, 2010, at 12:56 AM, hacklu wrote:
> I didn't understand the address mask.
> it's said that: BR[BA] is the base address,the OR[AM] is the address =
mask,
> "Provides masking for corresponding BRx bits. By masking address=20
> bits independently, SDRAM devices of different size address ranges can =
be used. Clearing=20
> bits masks the corresponding address bit. Setting bits causes the =
corresponding address=20
> bit to be compared with the address pins. Address mask bits can be set =
or cleared in any=20
> order, allowing a resource to reside in more than one area of the =
address map. SDAM can=20
> be read or written at any time."
>=20
> how to understand it?
> for instance, if my BR0[BA]=3D0111_0000_0000_0000_0, =
OR0[AM]=3D1111_1111_1111
> if I want to access the 0x70000000 or the 0x71000001.what address =
calculate will be taken?
Can you let us know which chip you are looking at using? There is a bit =
of variation so its useful to know.
- k=
^ permalink raw reply
* CONFIG_KTIME_SCALAR=y
From: Joakim Tjernlund @ 2010-09-10 13:05 UTC (permalink / raw)
To: linuxppc-dev
Noticed that there is a CONFIG_KTIME_SCALAR knob for HIGH_RES on 32 bit
which is off for ppc. I wonder not 64 bit math on 32 bit arch is good
enough on ppc?
Jocke
^ permalink raw reply
* Help configuring CF / IDE on 8315E
From: IMPL Soft3 UK (Implementation Software Design: BELCHAM Rob +44 1562 741515 ext 345) @ 2010-09-10 12:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]
Hi List,
Can anyone point me at any examples or documentation which might help me
configure the IDE/ATA driver for our custom board ?
Our board has an MPC8315E which interfaces to a compact flash card in
true IDE mode via an FPGA on the peripheral bus. The CF registers will
be memory mapped as part of the FPGA address space, but how do I tell
the IDE driver where this is ?
The legacy board, (runs a 2.4 kernel ) which this new board is replacing
had a file in drivers/ide/ which setup these addresses & IRQ with a
couple of functions :-
void nonpci_ide_init_hwif_ports( hw_regs_t *hw, ide_ioreg_t data_port,
ide_ioreg_t ctrl_port, int *irq )
{
int i;
static ide_ioreg_t mapped = 0;
if( data_port == 0 ) {
/* Clear this array if no data_port supplied */
for (i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i )
hw->io_ports[ i ] = data_port;
hw->io_ports[ IDE_CONTROL_OFFSET ] = 0;
}
else {
/* Only configure if base address (data_port) is supplied */
if( mapped == 0 )
mapped = (ide_ioreg_t)( ioremap(data_port, 64) );
for( i = IDE_DATA_OFFSET; i <= IDE_STATUS_OFFSET; ++i )
hw->io_ports[ i ] = mapped + (i*4);
hw->io_ports[ IDE_CONTROL_OFFSET ] = mapped + 0x38;
}
}
int nonpci_ide_default_irq( ide_ioreg_t base ) {
return base == FPGA_IDE ? IDE_IRQ : 0;
}
ide_ioreg_t nonpci_ide_default_io_base( int index ) {
return index == 0 ? FPGA_IDE : 0;
}
But the closest thing to this I can find in the kernel I'm using for the
new board (2.6.29.6) is ide_arm.c (see below), but this appears to be
setting up io ports. Can I just hack a copy of this file & replace the
IO port numbers with the physical FPGA addresses ?
#define IDE_ARM_IO 0x1f0
#define IDE_ARM_IRQ IRQ_HARDDISK
static int __init ide_arm_init(void)
{
unsigned long base = IDE_ARM_IO, ctl = IDE_ARM_IO + 0x206;
hw_regs_t hw, *hws[] = { &hw, NULL, NULL, NULL };
if (!request_region(base, 8, DRV_NAME)) {
printk(KERN_ERR "%s: I/O resource 0x%lX-0x%lX not free.\n",
DRV_NAME, base, base + 7);
return -EBUSY;
}
if (!request_region(ctl, 1, DRV_NAME)) {
printk(KERN_ERR "%s: I/O resource 0x%lX not free.\n",
DRV_NAME, ctl);
release_region(base, 8);
return -EBUSY;
}
memset(&hw, 0, sizeof(hw));
ide_std_init_ports(&hw, base, ctl);
hw.irq = IDE_ARM_IRQ;
hw.chipset = ide_generic;
return ide_host_add(NULL, hws, NULL);
}
Surely I can't be the first person to connect a compact flash to a
powerquicc processor in this way : does a suitable driver exist
somewhere already ?
Kind Regards,
BELCHAM, Rob
Principal Engineer, DSP
MIDAS KLARK TEKNIK LIMITED
Tel: +44 1562 741515 ext 345
Email: IMPLSoft3UK@music-group.com
Web: www.midasconsoles.com | www.klarkteknik.com | www.ktsquareone.com
:-) Build Teamwork :-) Take Ownership :-) Don't Waste Resources
:-) Clean Workplace = Clean Mind :-) Respect Guidelines and Policies
:-) Improve Yourself and Help Others :-) Don't Forget to Smile and Say
Thank You
This email is intended exclusively for the addressee(s) named above and
may contain privileged and confidential information. If you are not
(among) the intended recipient(s), you may not copy, utilize or
distribute any of the information contained herein. If you have received
this email in error, please notify us immediately via return email and
delete the original from your mailbox. Thank you.
[-- Attachment #2: Type: text/html, Size: 19186 bytes --]
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Wolfgang Denk @ 2010-09-10 11:29 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <20100909173735.503c4cc0@schlenkerla.am.freescale.net>
Dear Scott Wood,
In message <20100909173735.503c4cc0@schlenkerla.am.freescale.net> you wrote:
>
> It actually can load an ELF file, but it doesn't currently support
> passing a device tree to it (only argc/argv text arguments, or some
> vxworks stuff).
I see no problems to extend U-Boot such that we support booting Linux
kernel images in form of ELF files. Ideally these should be wrapped
into FIT images to allow for easy combination of kernel and FDT into a
single file (useful for netboot).
> > I've never understood the reasoning for that uImage wrapper
> > thingy. Definitely causes more problems than it solves in my experience.
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
The additional file header serves a number of purposes; even if they
seem of little use to a developer they are really helpful in
production and maintenance/repair.
Assume you were to find out why a system (returned from a customer)
does not boot any more. Being able to identify the kernel image in
flash, with information about version (name string), image build time
and size is really, really helpful then. Of course it's also helpful
to be able to check if the image is OK or for example has been
(partially) overwritten.
The checksum protection is indeed a VERY useful thing.
If we hade similar checksum protection on the device tree we would
have been able to recognize the memory corruption that triggered this
thread MUCH easier.
Acutally this is my biggest critique on the FDT blob: that we cannot
detect corruptions like this.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
^ permalink raw reply
* Re: [PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Anton Vorontsov @ 2010-09-10 9:31 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1FBF4A@zch01exm23.fsl.freescale.net>
On Fri, Sep 10, 2010 at 02:58:15PM +0800, Zang Roy-R61911 wrote:
[...]
> > > +static struct of_platform_driver fsl_lbc_ctrl_driver = {
> >
> > Need linux/of_platform.h for this.
> It has been include by
> fsl_lbc.h->linux/of_platform.h-> linux/platform_device.h
> Before submitting the patch, I have built and tested it.
In Linux we try to include all the headers explicitly (except
for asm/* if the same header name exists in linux/).
That's to avoid problems if for some reason fsl_lbc.h will stop
including of_plaform.h some day.
Oh, and by the way, there is absolutely no reason to add
linux/of_platform.h and interrupts.h into fsl_lbc.h, they're
is simply not needed in fsl_lbc.h.
> Do you think I do not build the tree before I send out the patch?
Nope, that's not what I think. I didn't say that the file
won't build w/o these fixes, but they're still needed.
> > > +
> > > +static struct of_platform_driver fsl_lbc_ctrl_driver = {
> >
> > Need linux/of_platform.h for this.
> >
> > But you actually don't need of_platform_driver, as for the
> > new code you can use platform_driver (and thus
> > linux/platform_device.h).
> I'd prefer using of_platform_driver here for simplified code.
> Any special reason to use platform_device here?
In the new kernels, of_platform_driver is almost a synonym of
platform_driver, and 'of_platform_driver' stuff is soon to be
deleted. You can use platform_driver just like
of_platform_driver nowadays.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCHv4] Xilinx Virtex 4 FX Soft FPU support
From: Sergey Temerkhanov @ 2010-09-10 9:14 UTC (permalink / raw)
To: linuxppc-dev
This patch enables support for Xilinx Virtex 4 FX singe-float FPU.> This patch
enables support for Xilinx Virtex 4 FX singe-float FPU.
Changelog v3-v4
-Added help for CONFIG_XILINX_SOFTFPU option
-Made kernel math emulation dependent on !PPC_FPU.
Changelog v2-v3:
-Fixed whitespaces for SAVE_FPR/REST_FPR.
-Changed description of MSR_AP bit.
-Removed the stub for APU unavailable exception.
Changelog v1->v2:
-Added MSR_AP bit definition
-Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to
'Platform support' and made it Virtex4-FX-only.
-Changed SAVE_FPR/REST_FPR definition style.
Caveats:
- Hard-float binaries which rely on in-kernel math emulation will
give wrong results since they expect 64-bit double-precision instead
of 32-bit single-precision numbers which Xilinx V4-FX Soft FPU produces.
Signed-off-by: Sergey Temerkhanov<temerkhanov@cifronik.ru>
diff -r df25ff2b70a4 arch/powerpc/Kconfig
--- a/arch/powerpc/Kconfig Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/Kconfig Fri Sep 10 13:08:13 2010 +0400
@@ -293,7 +293,7 @@
config MATH_EMULATION
bool "Math emulation"
- depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
+ depends on (4xx || 8xx || E200 || PPC_MPC832x || E500) && !PPC_FPU
---help---
Some PowerPC chips designed for embedded applications do not have
a floating-point unit and therefore do not implement the
diff -r df25ff2b70a4 arch/powerpc/include/asm/ppc_asm.h
--- a/arch/powerpc/include/asm/ppc_asm.h Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/include/asm/ppc_asm.h Fri Sep 10 13:08:13 2010 +0400
@@ -85,13 +85,21 @@
#define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base)
#define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base)
-#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
+#ifdef CONFIG_XILINX_SOFTFPU
+#define SAVE_FPR(n, base) stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#else
+#define SAVE_FPR(n, base) stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+#endif
+
#define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base)
#define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base)
#define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base)
#define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base)
#define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base)
-#define REST_FPR(n, base) lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base)
+
#define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base)
#define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base)
#define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base)
diff -r df25ff2b70a4 arch/powerpc/include/asm/reg.h
--- a/arch/powerpc/include/asm/reg.h Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/include/asm/reg.h Fri Sep 10 13:08:13 2010 +0400
@@ -30,6 +30,7 @@
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
#define MSR_VEC_LG 25 /* Enable AltiVec */
+#define MSR_AP_LG 25 /* Enable APU */
#define MSR_VSX_LG 23 /* Enable VSX */
#define MSR_POW_LG 18 /* Enable Power Management */
#define MSR_WE_LG 18 /* Wait State Enable */
@@ -71,6 +72,7 @@
#define MSR_HV 0
#endif
+#define MSR_AP __MASK(MSR_AP_LG) /* Enable APU */
#define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */
#define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */
#define MSR_POW __MASK(MSR_POW_LG) /* Enable Power Management */
diff -r df25ff2b70a4 arch/powerpc/kernel/fpu.S
--- a/arch/powerpc/kernel/fpu.S Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/kernel/fpu.S Fri Sep 10 13:08:13 2010 +0400
@@ -57,6 +57,9 @@
_GLOBAL(load_up_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -85,6 +88,9 @@
toreal(r5)
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r10,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r10,r10,MSR_AP@h
+#endif
andc r4,r4,r10 /* disable FP for previous task */
PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
@@ -94,6 +100,9 @@
mfspr r5,SPRN_SPRG_THREAD /* current task's THREAD (phys) */
lwz r4,THREAD_FPEXC_MODE(r5)
ori r9,r9,MSR_FP /* enable FP for current */
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r9,r9,MSR_AP@h
+#endif
or r9,r9,r4
#else
ld r4,PACACURRENT(r13)
@@ -124,6 +133,9 @@
_GLOBAL(giveup_fpu)
mfmsr r5
ori r5,r5,MSR_FP
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r5,r5,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r5,r5,MSR_VSX@h
@@ -145,6 +157,9 @@
beq 1f
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
li r3,MSR_FP|MSR_FE0|MSR_FE1
+#ifdef CONFIG_XILINX_SOFTFPU
+ oris r3,r3,MSR_AP@h
+#endif
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
oris r3,r3,MSR_VSX@h
diff -r df25ff2b70a4 arch/powerpc/kernel/head_40x.S
--- a/arch/powerpc/kernel/head_40x.S Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/kernel/head_40x.S Fri Sep 10 13:08:13 2010 +0400
@@ -420,7 +420,19 @@
addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_STD(0x700, program_check_exception)
+/* 0x0800 - FPU unavailable Exception */
+#ifdef CONFIG_PPC_FPU
+ START_EXCEPTION(0x0800, FloatingPointUnavailable)
+ NORMAL_EXCEPTION_PROLOG
+ beq 1f; \
+ bl load_up_fpu; /* if from user, just load it up */ \
+ b fast_exception_return; \
+1: addi r3,r1,STACK_FRAME_OVERHEAD; \
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
+#else
EXCEPTION(0x0800, Trap_08, unknown_exception, EXC_XFER_EE)
+#endif
+
EXCEPTION(0x0900, Trap_09, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0A00, Trap_0A, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0B00, Trap_0B, unknown_exception, EXC_XFER_EE)
@@ -432,7 +444,7 @@
EXCEPTION(0x0D00, Trap_0D, unknown_exception, EXC_XFER_EE)
EXCEPTION(0x0E00, Trap_0E, unknown_exception, EXC_XFER_EE)
- EXCEPTION(0x0F00, Trap_0F, unknown_exception, EXC_XFER_EE)
+ EXCEPTION(0x0F20, Trap_0F, unknown_exception, EXC_XFER_EE)
/* 0x1000 - Programmable Interval Timer (PIT) Exception */
START_EXCEPTION(0x1000, Decrementer)
@@ -821,8 +833,10 @@
* The PowerPC 4xx family of processors do not have an FPU, so this just
* returns.
*/
+#ifndef CONFIG_PPC_FPU
_ENTRY(giveup_fpu)
blr
+#endif
/* This is where the main kernel code starts.
*/
diff -r df25ff2b70a4 arch/powerpc/platforms/Kconfig
--- a/arch/powerpc/platforms/Kconfig Fri Aug 27 21:10:12 2010 +0400
+++ b/arch/powerpc/platforms/Kconfig Fri Sep 10 13:08:13 2010 +0400
@@ -338,4 +338,15 @@
bool "Xilinx PCI host bridge support"
depends on PCI && XILINX_VIRTEX
+config XILINX_SOFTFPU
+ bool "Xilinx Soft FPU support"
+ select PPC_FPU
+ depends on XILINX_VIRTEX_4_FX && !PPC40x_SIMPLE && !405GP && !405GPR
+ help
+ Say Y to enable support for Xilinx Virtex 4 FX singe-float FPU.
+ Caveats:
+ - Hard-float binaries which rely on in-kernel math emulation will give
wrong
+ results since they expect 64-bit double-precision instead of 32-bit
+ single-precision numbers which Virtex-4 soft FPU produces.
+
endmenu
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: André Schwarz @ 2010-09-10 8:11 UTC (permalink / raw)
To: Grant Likely; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <c843f864-2a5a-4146-bd95-13c2fb91f430@email.android.com>
Grant, Anton,
>
> There is no longer any need for separate of and non-of drivers for the same hardware. Any device may have the of_node pointer in struct device set, and drivers can use the pointer as an alternative to platform_data to get information about the hardware configuration.
> Just read the data out of the node in the driver's probe hook.
ok - will do it that way.
>
> For i2c and (soon) spi, the core code will even register child devices for you.
excellent.
Thinking about this device raises even more questions. Since there are
several possible solutions I'd like to hear your opinions :
1.
The SC18IS602 is capable of generating interrupts which is *extremely*
useful triggering on the end of the actual SPI transaction and not the
end of I2C chip access. Since we need an IRQ_ACK over I2C (which takes
loooong with IRQ being still asserted) I'm thinking about using an edge
triggered interrupt.
Since all transactions are in-order there's no risk of missing multiple
edges ... what do you think about this ? Any known issues with edge
triggered IRQs ?
2.
chips select generations is a little tricky.
The device has up to four cs# lines with their assertion being encoded
as subaddr representing a bitfield, i.e. Subaddr 0x01 generates cs0,
0x04 asserts cs3 and 0x07 asserts cs0-2.
At first I thought about registering 4 SPI busses representing the 4 cs#
lines and hide the cs# generation from the user. This would make
multiple cs# assertions for a single write impossible which is a very
useful feature.
Exposing the desired cs# setting for the next transaction via sysfs or
libGPIO requires the user to serialize cs# config and actual SPI
read/write. I also wouldn't know how to properly present the cs# lines
from multiple chips to the user in a clear and unambiguous way.
Any suggestions ?
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
^ permalink raw reply
* RE: [PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-09-10 6:58 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20100909115338.GA12320@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAwOSwgMjAxMCAxOTo1NCBQTQ0KPiBUbzogWmFuZyBSb3ktUjYxOTExDQo+IENjOiBsaW51
eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZzsgZHdtdzJAaW5mcmFkZWFkLm9yZzsgZGVkZWtpbmQx
QGdtYWlsLmNvbTsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgTGFuIENodW5oZS1CMjU4
MDY7IFdvb2QgU2NvdHQtQjA3NDIxOyBHYWxhIEt1bWFyLQ0KPiBCMTE3ODA7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8zIHYyXVtNVERdIFA0MDgwL2VM
QkM6IE1ha2UgRnJlZXNjYWxlIGVsYmMgaW50ZXJydXB0DQo+IGNvbW1vbiB0byBlbGJjIGRldmlj
ZXMNCj4gDQo+IEp1c3QgYSBmZXcgY29zbWV0aWMgbml0cyBmb3IgdGhpcyBwYXRjaC4uLg0KPiAN
Cj4gT24gVGh1LCBTZXAgMDksIDIwMTAgYXQgMDY6MjA6MzBQTSArMDgwMCwgUm95IFphbmcgd3Jv
dGU6DQo+IFsuLi5dDQpbc25pcF0NCj4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9kZXZpY2Vf
aWQgZnNsX2xiY19tYXRjaFtdID0gew0KPiA+ICsJeyAuY29tcGF0aWJsZSA9ICJmc2wsZWxiYyIs
IH0sDQo+ID4gKwl7IC5jb21wYXRpYmxlID0gImZzbCxwcTMtbG9jYWxidXMiLCB9LA0KPiA+ICsJ
eyAuY29tcGF0aWJsZSA9ICJmc2wscHEyLWxvY2FsYnVzIiwgfSwNCj4gPiArCXsgLmNvbXBhdGli
bGUgPSAiZnNsLHBxMnByby1sb2NhbGJ1cyIsIH0sDQo+ID4gKwl7fSwNCj4gPiArfTsNCj4gDQo+
IFlvdSBuZWVkIGxpbnV4L21vZF9kZXZpY2V0YWJsZS5oIGZvciB0aGlzLg0KSXQgaGFzIGJlZW4g
aW5jbHVkZSBpbiBsaW51eC9vZi5oLg0KDQo+IA0KPiA+ICsNCj4gPiArc3RhdGljIHN0cnVjdCBv
Zl9wbGF0Zm9ybV9kcml2ZXIgZnNsX2xiY19jdHJsX2RyaXZlciA9IHsNCj4gDQo+IE5lZWQgbGlu
dXgvb2ZfcGxhdGZvcm0uaCBmb3IgdGhpcy4NCkl0IGhhcyBiZWVuIGluY2x1ZGUgYnkNCmZzbF9s
YmMuaC0+bGludXgvb2ZfcGxhdGZvcm0uaC0+IGxpbnV4L3BsYXRmb3JtX2RldmljZS5oDQpCZWZv
cmUgc3VibWl0dGluZyB0aGUgcGF0Y2gsIEkgaGF2ZSBidWlsdCBhbmQgdGVzdGVkIGl0Lg0KDQpE
byB5b3UgdGhpbmsgSSBkbyBub3QgYnVpbGQgdGhlIHRyZWUgYmVmb3JlIEkgc2VuZCBvdXQgdGhl
IHBhdGNoPw0KPiANCj4gPiArDQo+ID4gK3N0YXRpYyBzdHJ1Y3Qgb2ZfcGxhdGZvcm1fZHJpdmVy
IGZzbF9sYmNfY3RybF9kcml2ZXIgPSB7DQo+IA0KPiBOZWVkIGxpbnV4L29mX3BsYXRmb3JtLmgg
Zm9yIHRoaXMuDQo+IA0KPiBCdXQgeW91IGFjdHVhbGx5IGRvbid0IG5lZWQgb2ZfcGxhdGZvcm1f
ZHJpdmVyLCBhcyBmb3IgdGhlDQo+IG5ldyBjb2RlIHlvdSBjYW4gdXNlIHBsYXRmb3JtX2RyaXZl
ciAoYW5kIHRodXMNCj4gbGludXgvcGxhdGZvcm1fZGV2aWNlLmgpLg0KSSdkIHByZWZlciB1c2lu
ZyBvZl9wbGF0Zm9ybV9kcml2ZXIgaGVyZSBmb3Igc2ltcGxpZmllZCBjb2RlLg0KQW55IHNwZWNp
YWwgcmVhc29uIHRvIHVzZSBwbGF0Zm9ybV9kZXZpY2UgaGVyZT8NClRoYW5rcy4NClJveQ0K
^ permalink raw reply
* how to understand powerpc's BRx ORx
From: hacklu @ 2010-09-10 5:56 UTC (permalink / raw)
To: linuxppc-dev
I didn't understand the address mask.
it's said that: BR[BA] is the base address,the OR[AM] is the address mask,
"Provides masking for corresponding BRx bits. By masking address
bits independently, SDRAM devices of different size address ranges can be used. Clearing
bits masks the corresponding address bit. Setting bits causes the corresponding address
bit to be compared with the address pins. Address mask bits can be set or cleared in any
order, allowing a resource to reside in more than one area of the address map. SDAM can
be read or written at any time."
how to understand it?
for instance, if my BR0[BA]=0111_0000_0000_0000_0, OR0[AM]=1111_1111_1111
if I want to access the 0x70000000 or the 0x71000001.what address calculate will be taken?
thanks all
--------------
hacklu
2010-09-10
^ permalink raw reply
* Re: pci_request_regions() failure
From: tiejun.chen @ 2010-09-10 5:23 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev
In-Reply-To: <AANLkTik1gWKO6vif+HgtM-j_5EUMJGwKRf+saRgK4TZg@mail.gmail.com>
Ravi Gupta wrote:
> Hi Tiejun,
>
> Thanks for the reply.
>
> Omm.
>> Often we always disable this pref windows so please disable this window.
>> Try use
>> the following ways to clear PCI_PREF_MEMORY_BASE and PCI_PREF_MEMORY_LIMIT.
>> ------
>> pci_write_config_word(dev, PCI_PREF_MEMORY_BASE, 0);
>> pci_write_config_word(dev, PCI_PREF_MEMORY_LIMIT, 0);
>>
>>
> I have a little confusion about what you said. You said I should disable
> prefetched window corresponds to PCI Bridge to [bus 02-ff], the dmesgs shows
> that it is already disabled.
>
> pci 0001:01:00.0: PCI bridge to [bus 02-ff]
> pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
> pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
> *pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref]
> (disabled)*
Sorry I miss this line.
>
> Is it something that I am not getting right or you have miss read something?
> If it is problem with me, then what should be the O/P in case when I disable
> the prefetch window (by issuing pci_write_config_word(dev,
> PCI_PREF_MEMORY_BASE, 0); and pci_write_config_word(dev,
> PCI_PREF_MEMORY_LIMIT, 0); function calls)? And also, I will be really
> thankful to you if you also tell me the function in which I should place
> there function calls as I am new to linux device driver programming.
Firstly I think we'd better print the BAR0 and BAR1 on the probe function of
your device driver because you have to make sure if a8000000-a803ffff is
assigned to BAR0 and 0xa8040000-0xa807ffff for BAR1 as we expect.
u32 value;
pci_read_config_word(pdev, PCI_BASE_ADDRESS_0, &value); printk...
pci_read_config_word(pdev, PCI_BASE_ADDRESS_1, &value); printk....
And you can print this pci_resource_start(pdev, bar), pci_resource_len(pdev,
bar) from the function, __pci_request_region, on the file drivers/pci/pci.c.
Please check this as well.
And currently we have to debug this so on the function, __pci_assign_resource,
from the file drivers/pci/setup-res.c, we can force skipping temporarily
pci_bus_alloc_resource for bus 0001:01 since that will call pci_update_resource
for bus 0001:01.
static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
int resno)
{
struct resource *res = dev->resource + resno;
resource_size_t size, min, align;
int ret;
size = resource_size(res);
min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
align = pci_resource_alignment(dev, res);
-------
if (bus->number == 0x01) {
ret = -ENOMEM
return ret;
}
-------
I means we don't want to assign resource as the below line on the log.
------
pci 0001:01:00.0: BAR 8: assigned [mem 0xa8000000-0xa80fffff]
I expect the following output:
------
pci 0001:01:00.0: BAR 8: can't assign mem pref (size 0x100000)
Best Regards
Tiejun
>
> Regards,
> Ravi
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc, perf: Fix sampling enable for PPC970
From: Paul Mackerras @ 2010-09-10 5:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Binderman
The logic to distinguish marked instruction events from ordinary events
on PPC970 and derivatives was flawed. The result is that instruction
sampling didn't get enabled in the PMU for some marked instruction
events, so they would never trigger. This fixes it by adding the
appropriate break statements in the switch statement.
Reported-by: David Binderman <dcb314@hotmail.com>
Cc: stable@kernel.org
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/kernel/ppc970-pmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/ppc970-pmu.c b/arch/powerpc/kernel/ppc970-pmu.c
index 8eff48e..3fee685 100644
--- a/arch/powerpc/kernel/ppc970-pmu.c
+++ b/arch/powerpc/kernel/ppc970-pmu.c
@@ -169,9 +169,11 @@ static int p970_marked_instr_event(u64 event)
switch (unit) {
case PM_VPU:
mask = 0x4c; /* byte 0 bits 2,3,6 */
+ break;
case PM_LSU0:
/* byte 2 bits 0,2,3,4,6; all of byte 1 */
mask = 0x085dff00;
+ break;
case PM_LSU1L:
mask = 0x50 << 24; /* byte 3 bits 4,6 */
break;
^ permalink raw reply related
* Re: [PATCH] ppc64: increase TREEWORDS value in ppc64
From: Simon Horman @ 2010-09-10 1:43 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, kexec, vgoyal
In-Reply-To: <20100909202711.GA22581@hmsreliant.think-freely.org>
[ Repost with correct kexec ML address ]
[ CCed linuxppc-dev ]
On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
> hey-
> Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
> Tracked it back to running over the end of the device tree buffer that we have
> allocated. I can't find any docs on how big the device tree can legally be, so
> for now I figure just upping its size is sufficient. Confirmed that this fixed
> the segfault.
Thanks Neil, though it would be nice to know what the limit actually is.
I'll hold off on applying this for a few days to see of the PPC people
have any comments on that.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> fs2dt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c
> index 238a3f2..2f0f937 100644
> --- a/kexec/arch/ppc/fs2dt.c
> +++ b/kexec/arch/ppc/fs2dt.c
> @@ -33,7 +33,7 @@
>
> #define MAXPATH 1024 /* max path name length */
> #define NAMESPACE 16384 /* max bytes for property names */
> -#define TREEWORDS 65536 /* max 32 bit words for properties */
> +#define TREEWORDS 131070 /* max 32 bit words for properties */
> #define MEMRESERVE 256 /* max number of reserved memory blks */
> #define MAX_MEMORY_RANGES 1024
> #define COMMAND_LINE_SIZE 512 /* from kernel */
^ permalink raw reply
* Re: [PATCH] ppc64: increase TREEWORDS value in ppc64
From: Simon Horman @ 2010-09-10 1:41 UTC (permalink / raw)
To: Neil Horman; +Cc: linuxppc-dev, vgoyal, kexec
In-Reply-To: <20100909202711.GA22581@hmsreliant.think-freely.org>
[ CCed linuxppc-dev ]
On Thu, Sep 09, 2010 at 04:27:11PM -0400, Neil Horman wrote:
> hey-
> Got a segfault recently on ppc64 kexec with a system with 256Gb of ram.
> Tracked it back to running over the end of the device tree buffer that we have
> allocated. I can't find any docs on how big the device tree can legally be, so
> for now I figure just upping its size is sufficient. Confirmed that this fixed
> the segfault.
Thanks Neil, though it would be nice to know what the limit actually is.
I'll hold off on applying this for a few days to see of the ppc people
have any comments on that.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
>
> fs2dt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> diff --git a/kexec/arch/ppc/fs2dt.c b/kexec/arch/ppc/fs2dt.c
> index 238a3f2..2f0f937 100644
> --- a/kexec/arch/ppc/fs2dt.c
> +++ b/kexec/arch/ppc/fs2dt.c
> @@ -33,7 +33,7 @@
>
> #define MAXPATH 1024 /* max path name length */
> #define NAMESPACE 16384 /* max bytes for property names */
> -#define TREEWORDS 65536 /* max 32 bit words for properties */
> +#define TREEWORDS 131070 /* max 32 bit words for properties */
> #define MEMRESERVE 256 /* max number of reserved memory blks */
> #define MAX_MEMORY_RANGES 1024
> #define COMMAND_LINE_SIZE 512 /* from kernel */
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:49 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <20100909173735.503c4cc0@schlenkerla.am.freescale.net>
On Thu, 2010-09-09 at 17:37 -0500, Scott Wood wrote:
>
> Wolfgang was just defending it on the U-Boot list the past couple
> days... seems like the main thing in its favor is the CRC, especially
> as a final check before reflashing an image.
Right, then fwd my 2 cents:
Makes sense to have a wrapper like that for flashing, but
- It could/should contain an ELF
- u-boot should be capable to just load/boot the ELF, not everybody
uses flashable images (netboot anyone ? espectially when debugging) and
it's really a burden to do the wrapping all the time. In addition, we
just see how it can actually hurt due to losing information such as the
BSS size.
Cheers,
Ben.
^ permalink raw reply
* Re: Combining defconfigs for 44x based boards
From: Stephen Rothwell @ 2010-09-09 22:42 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev, Wolfgang Denk, Sean MacLennan
In-Reply-To: <69da3260c595cc3870a9ff1eee9a7898@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hi,
On Thu, 9 Sep 2010 15:17:10 -0700 Tirumala Marri <tmarri@apm.com> wrote:
>
> [Marri]That is kind of true. Can we create new defconfigs then ?
> I am trying to check-in new defconfig.
Just make sure that it is minimal by using "make savedefconfig". This
will create a file "defconfig" in the current directory which should have
the minimal amount of stuff in it to reproduce the current .config.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Scott Wood @ 2010-09-09 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <1284070433.6515.39.camel@pasglop>
On Fri, 10 Sep 2010 08:13:53 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is. uImage is just a wrapper around a flat binary.
>
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage...
It actually can load an ELF file, but it doesn't currently support
passing a device tree to it (only argc/argv text arguments, or some
vxworks stuff).
> I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.
Wolfgang was just defending it on the U-Boot list the past couple
days... seems like the main thing in its favor is the CRC, especially
as a final check before reflashing an image.
-Scott
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Scott Wood @ 2010-09-09 22:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <1284069534.6515.36.camel@pasglop>
On Fri, 10 Sep 2010 07:58:54 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I would have expected uboot to warn (the kernel ELF header contains the
> BSS size) but apparently that isn't the case.
U-Boot doesn't use ELF files with Linux, so it has no idea where the
BSS is. uImage is just a wrapper around a flat binary.
-Scott
^ permalink raw reply
* RE: Combining defconfigs for 44x based boards
From: Tirumala Marri @ 2010-09-09 22:17 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Wolfgang Denk
In-Reply-To: <20100909130954.265adb37@lappy.seanm.ca>
> On Thu, 9 Sep 2010 09:49:14 -0700
> Tirumala Marri <tmarri@apm.com> wrote:
>
> > [Marri] Great we already have it. We should remove the defconfigs
> > under 44x then ?
>
> I'd rather we didn't. I thought Linus' beef was over the churn in the
> defconfigs, not the fact that they exist. The 44x defconfigs change
> very rarely.
[Marri]That is kind of true. Can we create new defconfigs then ?
I am trying to check-in new defconfig.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:16 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <1284070433.6515.39.camel@pasglop>
On Fri, 2010-09-10 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > > I would have expected uboot to warn (the kernel ELF header contains
> > the
> > > BSS size) but apparently that isn't the case.
> >
> > U-Boot doesn't use ELF files with Linux, so it has no idea where the
> > BSS is. uImage is just a wrapper around a flat binary.
>
> Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
> time it grows the ability to load ELF or to at least stick an ELF in a
> uImage... I've never understood the reasoning for that uImage wrapper
> thingy. Definitely causes more problems than it solves in my experience.
Note that with ePAPR we know the top of mapped memory on entry, so
in theory, if the bootloader is fully ePAPR compliant we -could- detect
that case and move the FDT up to after the .dts before we clear the
bss... do we care enough tho ?
Even if we aren't totally ePAPR compliant, we could still try to move
it, if we hit the end of memory well... we won't do more damage than we
already did by by overwriting the dts in the first place.
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:13 UTC (permalink / raw)
To: Scott Wood; +Cc: peterz, mingo, linuxppc-dev, Ira W. Snyder
In-Reply-To: <20100909171116.1b9b6e44@schlenkerla.am.freescale.net>
On Thu, 2010-09-09 at 17:11 -0500, Scott Wood wrote:
> > I would have expected uboot to warn (the kernel ELF header contains
> the
> > BSS size) but apparently that isn't the case.
>
> U-Boot doesn't use ELF files with Linux, so it has no idea where the
> BSS is. uImage is just a wrapper around a flat binary.
Oh, right, I forgot about that... -1 for uboot there. Seriously, it's
time it grows the ability to load ELF or to at least stick an ELF in a
uImage... I've never understood the reasoning for that uImage wrapper
thingy. Definitely causes more problems than it solves in my experience.
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 22:01 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev, Timur Tabi
In-Reply-To: <20100909193642.GD3496@ovro.caltech.edu>
On Thu, 2010-09-09 at 12:36 -0700, Ira W. Snyder wrote:
> On Thu, Sep 09, 2010 at 02:10:59PM -0500, Timur Tabi wrote:
> > On Thu, Sep 9, 2010 at 1:44 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> >
> > > Single stepping through the initial assembly portion of kernel startup
> > > shows that the FDT gets clobbered during the function early_init(). This
> > > trace is reproduced below.
> >
> > Have you tried also enabling CONFIG_DEBUG_LOCK_ALLOC? These two
> > config options are related.
> >
>
> Yes, I have had it enabled the whole time.
>
> As noted in another email, it appears that U-Boot puts the FDT in such a
> place that Linux overwrites it with the BSS. The CONFIG_PROVE_LOCKING=y
> option expands the BSS by a large amount, which causes the error. It
> isn't directly lockdep related.
>
> I don't know if this is a U-Boot problem or a Linux problem. I have no
> idea how to fix the bug.
Definitely a u-boot problem. There must be a way to set where the fdt
goes somewhere.
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Benjamin Herrenschmidt @ 2010-09-09 21:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: peterz, mingo, linuxppc-dev
In-Reply-To: <20100909162306.GA3496@ovro.caltech.edu>
> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
>
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
>
> Booting using the fdt blob at 0x2269f1c
> Uncompressing Kernel Image ... OK
> Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
> Loading Device Tree to 007f8000, end 007ff78f ... OK
>
> As soon an the debugger hit the start_here breakpoint, I ran the
> following command. It should dump out the flat device tree to a file,
> which I can then analyze:
>
> (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
>
> On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
> in fdt.bin. I see the stuff I would expect.
>
> On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
> So clearly something is overwriting the fdt.
>
> However, note that this happens *before* lockdep_init() runs. Grepping
> for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
> I'm not sure exactly how this is related to lockdep.
>
> Some more suggestions for things to try would be great. For now, I'm
> going to try getting the debugger to break near the end of U-Boot, to
> see if the memory is overwritten there, and not in Linux.
I suspect your uboot setup. The one thing lockdep does is massively
increase the amount of kernel bss. I suspect you are just overlapping DT
and bss and hence wiping out the DT when clearing the bss.
I would have expected uboot to warn (the kernel ELF header contains the
BSS size) but apparently that isn't the case.
Cheers,
Ben.
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Timur Tabi @ 2010-09-09 21:19 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Kumar Gala, linuxppc-dev
In-Reply-To: <20100909205507.GG3496@ovro.caltech.edu>
Ira W. Snyder wrote:
> I have no idea how to determine this.
>
> The code that caused the problem runs so early in boot that the MMU is
> not running yet. Looking through the tiny bit of code, it appears that
> it just uses whatever the bootloader set up for it. It hasn't gotten to
> the initial_bats function yet.
I just spoke to Kumar, and he said that the 8MB is just historical. We ran
into the same exact problem that you ran into, except it was with a normal
kernel, so we changed 8MB to 16MB on our 85xx boards, but we never went back
and made the same change to 83xx boards.
So it should be safe to change CONFIG_SYS_BOOTMAPSZ from 8MB to 16MB on all
83xx systems. However, U-Boot does not verify that CONFIG_SYS_BOOTMAPSZ <=
the actual amount of RAM in the system, so we need to make sure that
CONFIG_SYS_BOOTMAPSZ isn't increased on any board that actually did ship
with only 8MB of RAM. My guess is that no such board exists, but I will get
confirmation.
However, this comment for CONFIG_SYS_BOOTMAPSZ still bothers me:
/*
* For booting Linux, the board info and command line data
* have to be in the first 8 MB of memory, since this is
* the maximum mapped by the Linux kernel during initialization.
*/
This same comment says 16MB on 85xx systems, so I don't think the statement
about "maximum mapped by the Linux kernel" is really true. Maybe someone
else can shed some light on this.
> I think the MPC8349EA would be a 603 CPU, meaning that we could increase
> CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).
Except that I'm still not sure what CONFIG_SYS_BOOTMAPSZ really means. I
was under the impression that CONFIG_MAX_MEM_MAPPED is the actual value of
the size of the mapping that U-Boot creates for the kernel. When the kernel
initializes the MMU for its own purposes, does it limit anything to 16MB? I
seriously doubt it.
> You'll see that your patch now relocated the FDT. It didn't cause any
> problems. I'll post to the thread on the U-Boot ML.
Yes, please. I need someone to confirm that he tested my patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
From: Ira W. Snyder @ 2010-09-09 20:55 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4C89454F.8070701@freescale.com>
On Thu, Sep 09, 2010 at 03:36:31PM -0500, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > That did it!
>
> Yea!
>
> > I'm using include/configs/MPC8349EMDS.h. On that board,
> > CONFIG_SYS_BOOTMAPSZ is 8MB. Boosting it to 16MB fixed the problem and
> > the kernel now boots.
>
> Ah, yes. I believe the reason that is the case is because some of those
> boards were shipped with only 8MB of RAM.
>
> > I'll make a post to the U-Boot list asking if this should be boosted for
> > MPC8349EMDS (and others?). It is easy to build a kernel that overruns
> > this limit. Other than debugging options, my kernel is fairly minimal,
> > only a few drivers are built in.
>
> I think we should first determine if the kernel boot map limit really is
> 16MB. If it's more than that, then we should consider making it match.
> Assuming, of course, that the U-Boot code can handle a situation where
> CONFIG_SYS_BOOTMAPSZ is larger than the actual amount of RAM.
>
I have no idea how to determine this.
The code that caused the problem runs so early in boot that the MMU is
not running yet. Looking through the tiny bit of code, it appears that
it just uses whatever the bootloader set up for it. It hasn't gotten to
the initial_bats function yet.
The comment in initial_bats (arch/powerpc/kernel/head_32.S) says:
/*
* On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
* (we keep one for debugging) and on others, we use one 256M BAT.
*/
I think the MPC8349EA would be a 603 CPU, meaning that we could increase
CONFIG_SYS_BOOTMAPSZ up to 256MB (if the board had that much RAM).
> > I'm using your always-relocate-fdt patch. Your patch made no difference
> > to the FDT location. U-Boot with and without your patch bo
>
> My patch only does something if the FDT is already located inside the boot
> map. Since you were expanding the size of the boot map, there's a chance
> that the FDT was located between 8MB and 16MB, and if so, my patch would
> have made a difference.
>
Yep, you're exactly correct. I tried loading my FIT image to a lower
address (0xa00000 == 10MB), both with and without your patch:
Without your patch (vanilla U-Boot):
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0xc6a278
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
With your patch:
Verifying Hash Integrity ... crc32+ OK
Booting using the fdt blob at 0xc42d6c
Uncompressing Kernel Image ... OK
Loading Ramdisk to 0fe9f000, end 0ff75699 ... OK
Loading Device Tree to 00ff8000, end 00fff84f ... OK
You'll see that your patch now relocated the FDT. It didn't cause any
problems. I'll post to the thread on the U-Boot ML.
[ dropped mingo and peterz from the CC list, they're not powerpc people ]
Thanks,
Ira
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox