* [PATCH 6/82] remove linux/version.h include from arch/ppc
From: Olaf Hering @ 2005-07-10 19:35 UTC (permalink / raw)
To: Andrew Morton, linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <20050710193508.0.PmFpst2252.2247.olh@nectarine.suse.de>
changing CONFIG_LOCALVERSION rebuilds too much, for no appearent reason.
use system_utsname for CONFIG_BOOTX_TEXT welcome message
Signed-off-by: Olaf Hering <olh@suse.de>
arch/ppc/syslib/btext.c | 6 ++++--
arch/ppc/syslib/prom.c | 1 -
arch/ppc/syslib/prom_init.c | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.13-rc2-mm1/arch/ppc/syslib/btext.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/ppc/syslib/btext.c
+++ linux-2.6.13-rc2-mm1/arch/ppc/syslib/btext.c
@@ -7,7 +7,7 @@
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/version.h>
+#include <linux/utsname.h>
#include <asm/sections.h>
#include <asm/bootx.h>
@@ -81,7 +81,9 @@ btext_welcome(void)
unsigned long pvr;
boot_infos_t* bi = &disp_bi;
- btext_drawstring("Welcome to Linux, kernel " UTS_RELEASE "n");
+ btext_drawstring("Welcome to Linux, kernel ");
+ btext_drawstring(system_utsname.version);
+ btext_drawstring("n");
btext_drawstring("nlinked at : 0x");
btext_drawhex(KERNELBASE);
btext_drawstring("nframe buffer at : 0x");
Index: linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/ppc/syslib/prom.c
+++ linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom.c
@@ -13,7 +13,6 @@
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/version.h>
#include <linux/threads.h>
#include <linux/spinlock.h>
#include <linux/ioport.h>
Index: linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom_init.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/ppc/syslib/prom_init.c
+++ linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom_init.c
@@ -9,7 +9,6 @@
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/version.h>
#include <linux/threads.h>
#include <linux/spinlock.h>
#include <linux/ioport.h>
^ permalink raw reply
* [2.6 patch] arch/ppc/kernel/ppc_ksyms.c: remove unused #define EXPORT_SYMTAB_STROPS
From: Adrian Bunk @ 2005-07-10 15:37 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
This #define is only used on sparc.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc2-mm1-full/arch/ppc/kernel/ppc_ksyms.c.old 2005-07-10 17:35:05.000000000 +0200
+++ linux-2.6.13-rc2-mm1-full/arch/ppc/kernel/ppc_ksyms.c 2005-07-10 17:35:12.000000000 +0200
@@ -51,9 +51,6 @@
#include <asm/commproc.h>
#endif
-/* Tell string.h we don't want memcpy etc. as cpp defines */
-#define EXPORT_SYMTAB_STROPS
-
extern void transfer_to_handler(void);
extern void do_IRQ(struct pt_regs *regs);
extern void MachineCheckException(struct pt_regs *regs);
^ permalink raw reply
* [PATCH] PPC: [PATCH resend] C99 initializers for hw_interrupt_type structures
From: tglx @ 2005-07-10 21:47 UTC (permalink / raw)
To: trini; +Cc: akpm, linux-kernel, linuxppc-embedded
In-Reply-To: <1121031634.26713.243.camel@tglx.tec.linutronix.de>
Convert the initializers of hw_interrupt_type structures to C99 initializers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
platforms/adir_pic.c | 12 ++++--------
syslib/cpc700_pic.c | 12 ++++--------
syslib/i8259.c | 13 +++++--------
syslib/open_pic2.c | 12 +++++-------
syslib/ppc403_pic.c | 11 ++++-------
syslib/xilinx_pic.c | 13 +++++--------
6 files changed, 27 insertions(+), 46 deletions(-)
---
diff -urN --exclude='*~' linux-2.6.13-rc2/arch/ppc/platforms/adir_pic.c linux-2.6.13-rc2-armirq/arch/ppc/platforms/adir_pic.c
--- linux-2.6.13-rc2/arch/ppc/platforms/adir_pic.c 2005-07-09 13:04:31.000000000 +0200
+++ linux-2.6.13-rc2-armirq/arch/ppc/platforms/adir_pic.c 2005-07-09 13:10:41.000000000 +0200
@@ -73,14 +73,10 @@
}
static struct hw_interrupt_type adir_onboard_pic = {
- " ADIR PIC ",
- NULL,
- NULL,
- adir_onboard_pic_enable, /* unmask */
- adir_onboard_pic_disable, /* mask */
- adir_onboard_pic_disable, /* mask and ack */
- NULL,
- NULL
+ .typename = " ADIR PIC ",
+ .enable = adir_onboard_pic_enable, /* unmask */
+ .disable = adir_onboard_pic_disable, /* mask */
+ .ack = adir_onboard_pic_disable, /* mask and ack */
};
static struct irqaction noop_action = {
diff -urN --exclude='*~' linux-2.6.13-rc2/arch/ppc/syslib/cpc700_pic.c linux-2.6.13-rc2-armirq/arch/ppc/syslib/cpc700_pic.c
--- linux-2.6.13-rc2/arch/ppc/syslib/cpc700_pic.c 2005-07-09 13:04:31.000000000 +0200
+++ linux-2.6.13-rc2-armirq/arch/ppc/syslib/cpc700_pic.c 2005-07-09 13:10:41.000000000 +0200
@@ -90,14 +90,10 @@
}
static struct hw_interrupt_type cpc700_pic = {
- "CPC700 PIC",
- NULL,
- NULL,
- cpc700_unmask_irq,
- cpc700_mask_irq,
- cpc700_mask_and_ack_irq,
- NULL,
- NULL
+ .typename = "CPC700 PIC",
+ .enable = cpc700_unmask_irq,
+ .disable = cpc700_mask_irq,
+ .ack = cpc700_mask_and_ack_irq,
};
__init static void
diff -urN --exclude='*~' linux-2.6.13-rc2/arch/ppc/syslib/i8259.c linux-2.6.13-rc2-armirq/arch/ppc/syslib/i8259.c
--- linux-2.6.13-rc2/arch/ppc/syslib/i8259.c 2005-07-09 13:04:31.000000000 +0200
+++ linux-2.6.13-rc2-armirq/arch/ppc/syslib/i8259.c 2005-07-09 13:10:41.000000000 +0200
@@ -129,14 +129,11 @@
}
struct hw_interrupt_type i8259_pic = {
- " i8259 ",
- NULL,
- NULL,
- i8259_unmask_irq,
- i8259_mask_irq,
- i8259_mask_and_ack_irq,
- i8259_end_irq,
- NULL
+ .typename = " i8259 ",
+ .enable = i8259_unmask_irq,
+ .disable = i8259_mask_irq,
+ .ack = i8259_mask_and_ack_irq,
+ .end = i8259_end_irq,
};
static struct resource pic1_iores = {
diff -urN --exclude='*~' linux-2.6.13-rc2/arch/ppc/syslib/open_pic2.c linux-2.6.13-rc2-armirq/arch/ppc/syslib/open_pic2.c
--- linux-2.6.13-rc2/arch/ppc/syslib/open_pic2.c 2005-07-09 13:08:08.000000000 +0200
+++ linux-2.6.13-rc2-armirq/arch/ppc/syslib/open_pic2.c 2005-07-09 13:10:41.000000000 +0200
@@ -82,13 +82,11 @@
static void openpic2_ack_irq(unsigned int irq_nr);
struct hw_interrupt_type open_pic2 = {
- " OpenPIC2 ",
- NULL,
- NULL,
- openpic2_enable_irq,
- openpic2_disable_irq,
- openpic2_ack_irq,
- openpic2_end_irq,
+ .typename = " OpenPIC2 ",
+ .enable = openpic2_enable_irq,
+ .disable = openpic2_disable_irq,
+ .ack = openpic2_ack_irq,
+ .end = openpic2_end_irq,
};
/*
diff -urN --exclude='*~' linux-2.6.13-rc2/arch/ppc/syslib/ppc403_pic.c linux-2.6.13-rc2-armirq/arch/ppc/syslib/ppc403_pic.c
--- linux-2.6.13-rc2/arch/ppc/syslib/ppc403_pic.c 2005-07-09 13:04:31.000000000 +0200
+++ linux-2.6.13-rc2-armirq/arch/ppc/syslib/ppc403_pic.c 2005-07-09 13:10:41.000000000 +0200
@@ -34,13 +34,10 @@
static void ppc403_aic_disable_and_ack(unsigned int irq);
static struct hw_interrupt_type ppc403_aic = {
- "403GC AIC",
- NULL,
- NULL,
- ppc403_aic_enable,
- ppc403_aic_disable,
- ppc403_aic_disable_and_ack,
- 0
+ .typename = "403GC AIC",
+ .enable = ppc403_aic_enable,
+ .disable = ppc403_aic_disable,
+ .ack = ppc403_aic_disable_and_ack,
};
int
diff -urN --exclude='*~' linux-2.6.13-rc2/arch/ppc/syslib/xilinx_pic.c linux-2.6.13-rc2-armirq/arch/ppc/syslib/xilinx_pic.c
--- linux-2.6.13-rc2/arch/ppc/syslib/xilinx_pic.c 2005-07-09 13:04:31.000000000 +0200
+++ linux-2.6.13-rc2-armirq/arch/ppc/syslib/xilinx_pic.c 2005-07-09 13:10:41.000000000 +0200
@@ -79,14 +79,11 @@
}
static struct hw_interrupt_type xilinx_intc = {
- "Xilinx Interrupt Controller",
- NULL,
- NULL,
- xilinx_intc_enable,
- xilinx_intc_disable,
- xilinx_intc_disable_and_ack,
- xilinx_intc_end,
- 0
+ .typename = "Xilinx Interrupt Controller",
+ .enable = xilinx_intc_enable,
+ .disable = xilinx_intc_disable,
+ .ack = xilinx_intc_disable_and_ack,
+ .end = xilinx_intc_end,
};
int
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: David Gibson @ 2005-07-11 4:55 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1120859097.8609.15.camel@cashmere.sps.mot.com>
On Fri, Jul 08, 2005 at 04:44:58PM -0500, Jon Loeliger wrote:
> David and Ben,
>
> This patch adds support for memreserve to the DTC's notion
> of the "source file". That is, you can now say this:
>
>
> memreserve = <
> 0000 0001 0000 0002
> 0000 0003 0000 0004
> >
>
> / {
> model = "MPC8555CDS";
> compatible = "MPC85xxCDS";
> #address-cells = <2>;
> #size-cells = <2>;
> linux,phandle = <100>;
Hrm.. nice idea, but I don't really like the syntax. It looks like a
property definition, which it's really not, and forcing the user to
split up these 64-bit quantities into cells is kind of silly. Plus
the fact that "memreserve" is lexed as a reserved word means it can't
be used as a property name. And it really ought to have a ';' at the
end, for consistency.
Hrm... wonder how to do this, without making the lex and yacc stuff
too unspeakable.
Maybe
/memreserve/ = { 00000001-00000002;
00000003-00000004;
};
I'm not that fond of the /.../ form, although the '/' is the best way
I can think of to ensure it can't be confused with a property or node
name. We'lll also need some sort of lexing magic so that it actually
recognizes the things within as numbers, not property names, too.
Hrm... will need to think about that.
> There is minor fiddling with the -R flag that needs to be
> resolved at this point.
I think -R should add the given number of extra empty entries, on top
of the ones given in the source.
> I've included read and writing for the source and blob formats,
> but don't have a clue what to do with the /proc/devices format.
Just ignore it, I think. If you need memreserves with fs input, you
can just use -R and patch them in later.
> I've also tinkered the Makefile to do automatic dependency
> file generation and inclusion. Yep, I got bit by out of
> date dependencies during my development here. :-)
Hrm.. seems kinda overkill for a project this small, but ok. Although
it would be nice to have this as a separate patch.
> Please feel free to adjust my coding approach or argument
> passing or whatever as needed. Hope this helps!
Yeah, there are some things I'd like to change (in addition to the
input syntax itself), but I'm thinking about just applying it and
fixing up afterwards.
Biggest thing is that rather than passing the tree itself and the
memreserve info about as two parameters all over the place, I'd rather
create a new structure which has both (and later can have anything
else that might be needed).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: David Gibson @ 2005-07-11 6:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1120859097.8609.15.camel@cashmere.sps.mot.com>
On Fri, Jul 08, 2005 at 04:44:58PM -0500, Jon Loeliger wrote:
> David and Ben,
>
> This patch adds support for memreserve to the DTC's notion
> of the "source file". That is, you can now say this:
>
>
> memreserve = <
> 0000 0001 0000 0002
> 0000 0003 0000 0004
> >
>
> / {
> model = "MPC8555CDS";
> compatible = "MPC85xxCDS";
> #address-cells = <2>;
> #size-cells = <2>;
> linux,phandle = <100>;
>
> There is minor fiddling with the -R flag that needs to be
> resolved at this point.
>
> I've included read and writing for the source and blob formats,
> but don't have a clue what to do with the /proc/devices format.
>
> I've also tinkered the Makefile to do automatic dependency
> file generation and inclusion. Yep, I got bit by out of
> date dependencies during my development here. :-)
I applied the dependency portions of the patch to the git tree, with
some tweaks to fix some corner cases.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Update Your Account Records
From: PayPal @ 2005-07-11 4:30 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 3644 bytes --]
^ permalink raw reply
* crosstool-0.37
From: David Ho @ 2005-07-11 12:45 UTC (permalink / raw)
To: linuxppc-embedded
Hi, Thanks to Tim Hayman (my boss =), Crosstool-0.37 can now build a
cross-compiling GCJ using GCC 4.0.x source and an older GCC core (the GCC
core is used to build glibc which is required for the actual GCC build when
you select more complex features such as C++ and Java). This is of course
tested on MPC8xx our favourite platform at Nanometrics.
David
^ permalink raw reply
* This email confirms that you sent $67.00 USD to north_pools@yahoo.com
From: PayPal @ 2005-07-11 13:01 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1937 bytes --]
^ permalink raw reply
* This email confirms that you sent $67.00 USD to north_pools@yahoo.com
From: PayPal @ 2005-07-11 13:42 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1937 bytes --]
^ permalink raw reply
* Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Absolut Hunter @ 2005-07-11 13:38 UTC (permalink / raw)
To: linuxppc-embedded
Anybody,
I ran into a peculiar issue, though it could be user error.
I am using U-boot to configure up the SDRAM and SRAM in our system before we
launch Linux. We have 32 Mb of SDRAM and 2 MB of SRAM in the system.
If I leave the SRAM mapped at higher addresses 0x10000000 and SDRAM at
0x00000000, like U-boot defaults to Linux works great. However, my goal is
to map SRAM <8ns speeds> down to the address 0x00000000, to map the vector
table, so I can achieve a very fast interrupt response time.
I hacked U-boot a little bit to remap these addresses, after all the init
code was finished. U-boot relocates itself to higher memory, i.e. the last
2MB's of SDRAM and all is well within U-boot. I ran a 14 hour test on the
memory area to proof it. Now we have 0x02200000 <34M> memory size being
reported to Linux, in the bd->memsize. However, now Linux crashes randomly
all over the place, mostly sig11's task: swapper. I know this is not an
issue with SDRAM stability, and I can't imagine SRAM having problems seeing
as its 8ns capable and we're running at 15ns at the moment (66mhz).
Linux reports BAT mappings as BAT2=32Mb, BAT3=2MB when all 34 Megs are
presented via U-boot.
Does anyone have any idea what would cause this instability? Physically all
memory seems to be great if used by itself. I know very little about how
Linux manages its pages, BATS, TBLs, etc... Are the limits on odd memory
sizes? Or certain configurations that it expects to see?
Thanks in advance.
-Russell McGuire
^ permalink raw reply
* RE: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Steven Blakeslee @ 2005-07-11 13:59 UTC (permalink / raw)
To: Absolut Hunter, linuxppc-embedded
> I am using U-boot to configure up the SDRAM and SRAM in our=20
> system before we launch Linux. We have 32 Mb of SDRAM and 2=20
> MB of SRAM in the system.=20
>=20
When I was working on an 8260 a while back I had to map PSDRAM at
address 0x00000000 and LSDRAM starting at the PSDRAM's end. I found
that when I made the PSDRAM smaller than the LSDRAM then the LSDRAM was
not mapped properly. This was due to the fact that the start address
for the memory bank needed to be a multiple of the bank size. If the
LSDRAM was 32Meg then the start address of the bank needed to be on a
32Meg boundary.
I am not sure but if you are mapping a 2Meg SRAM at 0x00000000 followed
by a 32Meg SDRAM then the SDRAM is not on a 32Meg boundary. This may
not be your issue but it may be worth looking in to.
^ permalink raw reply
* Re: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Mark Chambers @ 2005-07-11 14:03 UTC (permalink / raw)
To: Absolut Hunter, linuxppc-embedded
In-Reply-To: <20050711134713.D767067C13@ozlabs.org>
> I am using U-boot to configure up the SDRAM and SRAM in our system before
we
> launch Linux. We have 32 Mb of SDRAM and 2 MB of SRAM in the system.
>
> If I leave the SRAM mapped at higher addresses 0x10000000 and SDRAM at
> 0x00000000, like U-boot defaults to Linux works great. However, my goal is
> to map SRAM <8ns speeds> down to the address 0x00000000, to map the vector
> table, so I can achieve a very fast interrupt response time.
>
Your core is probably running at about 400MHz, so 66MHz SRAM is still slow.
This is what cache is for. Maybe you should look into locking interrupt
code in
cache. Probably, however, you will find that messing with the overall
optimizations
of the kernel will be a net slowdown.
Mark Chambers
^ permalink raw reply
* Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Absolut Hunter @ 2005-07-11 14:02 UTC (permalink / raw)
To: linuxppc-embedded
A useful piece to this might be that I am attempting to map these two memory
regions contiguously, so that Linux doesn't see any memory holes.
0-2MB SRAM
2MB-34MB SDRAM
I would be open to any other ways that SRAM / SDRAM might be mapped to work,
and still provide a performance increase for the kernel.
-Russell
-----Original Message-----
From: Absolut Hunter [mailto:absoluthunter@comcast.net]
Sent: Monday, July 11, 2005 6:38 AM
To: 'linuxppc-embedded@ozlabs.org'
Subject: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
Anybody,
I ran into a peculiar issue, though it could be user error.
I am using U-boot to configure up the SDRAM and SRAM in our system before we
launch Linux. We have 32 Mb of SDRAM and 2 MB of SRAM in the system.
If I leave the SRAM mapped at higher addresses 0x10000000 and SDRAM at
0x00000000, like U-boot defaults to Linux works great. However, my goal is
to map SRAM <8ns speeds> down to the address 0x00000000, to map the vector
table, so I can achieve a very fast interrupt response time.
I hacked U-boot a little bit to remap these addresses, after all the init
code was finished. U-boot relocates itself to higher memory, i.e. the last
2MB's of SDRAM and all is well within U-boot. I ran a 14 hour test on the
memory area to proof it. Now we have 0x02200000 <34M> memory size being
reported to Linux, in the bd->memsize. However, now Linux crashes randomly
all over the place, mostly sig11's task: swapper. I know this is not an
issue with SDRAM stability, and I can't imagine SRAM having problems seeing
as its 8ns capable and we're running at 15ns at the moment (66mhz).
Linux reports BAT mappings as BAT2=32Mb, BAT3=2MB when all 34 Megs are
presented via U-boot.
Does anyone have any idea what would cause this instability? Physically all
memory seems to be great if used by itself. I know very little about how
Linux manages its pages, BATS, TBLs, etc... Are the limits on odd memory
sizes? Or certain configurations that it expects to see?
Thanks in advance.
-Russell McGuire
^ permalink raw reply
* Re: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Wolfgang Denk @ 2005-07-11 14:22 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <20050711134713.D767067C13@ozlabs.org>
In message <20050711134713.D767067C13@ozlabs.org> you wrote:
>
> If I leave the SRAM mapped at higher addresses 0x10000000 and SDRAM at
> 0x00000000, like U-boot defaults to Linux works great. However, my goal is
> to map SRAM <8ns speeds> down to the address 0x00000000, to map the vector
> table, so I can achieve a very fast interrupt response time.
How fast is your bus? 8 ns is not exactly very fast.
> I hacked U-boot a little bit to remap these addresses, after all the init
Hacked? No hack at all should have been necessary. This is standard
configuration stuff.
> reported to Linux, in the bd->memsize. However, now Linux crashes randomly
> all over the place, mostly sig11's task: swapper. I know this is not an
SO one or your memory banks does not work reliably.
> issue with SDRAM stability, and I can't imagine SRAM having problems seeing
> as its 8ns capable and we're running at 15ns at the moment (66mhz).
And what about the state of your hardware? Did you check the signals,
especially when the CPU is stressing the bus in burst mode?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Let the programmers be many and the managers few -- then all will be
productive. -- Geoffrey James, "The Tao of Programming"
^ permalink raw reply
* Re: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Michael Richardson @ 2005-07-11 14:01 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <20050711134713.D767067C13@ozlabs.org>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Absolut" == Absolut Hunter <absoluthunter@comcast.net> writes:
Absolut> If I leave the SRAM mapped at higher addresses 0x10000000
Absolut> and SDRAM at 0x00000000, like U-boot defaults to Linux
Absolut> works great. However, my goal is to map SRAM <8ns speeds>
Absolut> down to the address 0x00000000, to map the vector table, so
Absolut> I can achieve a very fast interrupt response time.
Are you mapping the SRAM *OVER* the lower 2MB of address space?
If so, then you won't have 34Mb of ram, you'll have 32Mb, and Linux
may well be running off the end under stress.
My memory is that you can move the vector table to another address.
Wouldn't that be easier?
- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQtJ7yoqHRg3pndX9AQF+eQQA0QBhaZAjq3vDQm8glqV0j+jmzO9+7U0m
aZvOt5FsXu2mv3lS/2FySIQf3UuRcl0lIR5zaNfyn+I11K0YlfZvXgY97U2TMcmu
1K5sod0j3DpaIrK/a+VyWa+tQFe9zoPktazinVoQm4+geNRlTZf9P5XyYwXE7knn
+TOTFRzLq7c=
=iPOS
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Michael Richardson @ 2005-07-11 14:39 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <20050711140714.C743F67C23@ozlabs.org>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Absolut" == Absolut Hunter <absoluthunter@comcast.net> writes:
Absolut> A useful piece to this might be that I am attempting to map
Absolut> these two memory regions contiguously, so that Linux
Absolut> doesn't see any memory holes.
Absolut> 0-2MB SRAM 2MB-34MB SDRAM
Likely you can't do that, because you must map the blocks at a
multiple of their address. (I'm not an expert at PPC mappings, but this
is typically the case)
So you can do:
0x000000000 SRAM (has a hole from 2MB->32Mb)
0x002000000 SDRAM
or:
0x000000000 SDRAM
0x002000000 SRAM
Absolut> I would be open to any other ways that SRAM / SDRAM might
Absolut> be mapped to work, and still provide a performance increase
Absolut> for the kernel.
I think that you would be better to lock the relevant interrupt code
into the cache, if that is possible.
- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQtKEkYqHRg3pndX9AQFm6wP8C6xu9Wwbbv/eCr3UaZDcn4mEx35F28s1
eAdYxTqKREhewSJZH1QGn2QGBXxHKMlnBWttgmSYb814aXDeEzEKm3pLg45cB9nj
kU49kcDuyJ8Ug62/dFg9iZn4udfuJJHeaDNGITEwj2ov0RCENdJLsnCO33tZOjEs
Mz9qUutzG4g=
=DGvh
-----END PGP SIGNATURE-----
^ permalink raw reply
* MPC5200 Rev. B
From: mgberry @ 2005-07-11 15:39 UTC (permalink / raw)
To: linuxppc-embedded
Has anyone experienced any issues with the Rev. B silicon for the MPC5200. We
are seeing Linux hanging and are suspecting the SDRAM errata for Rev. B. If we
disable the cache this seems to improve but will still crash over time in heavy
loads. We have not seen any of these type issues with the original rev.
Matt
^ permalink raw reply
* Re: MPC5200 Rev. B
From: Eric N. Johnson (ACD) @ 2005-07-11 16:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050711113948.vznzvgxu15nkkwcg@webmail.ellipticity.com>
mgberry@ellipticity.com wrote:
>Has anyone experienced any issues with the Rev. B silicon for the
>MPC5200. We are seeing Linux hanging and are suspecting the SDRAM
>errata for Rev. B. If we disable the cache this seems to improve
>but will still crash over time in heavy loads. We have not seen any
>of these type issues with the original rev.
Are you sure you have revision B of the MPC5200? Freescale has
announced a "B" version, but I don't believe that any of them have
hit the public yet. There may be some engineering grade samples out
there. (Let me know if you really do have "B" parts. Freescale has
been telling me "real soon now" since last year)
More likely you're seeing the "B" in the part number, as in
MPC5200CBV400. The chip revision is the "mask set" on the next line
of printing. The latest public version I know of is L25R.
The L25R version has a major bug that you basically can't use two CS
pins for SDRAM, and the DDR implimentation is borderline at best.
Exactly what problems are seeing? What hardware platform do you run
on? We're using an MPC5200 with SDR-SDRAM running at 132MHz (two 16
bit SDRAM devices), and haven't seen any issues.
I don't know what bootloader you're using, but I believe uboot has
basic memory testing built in. This would allow you to isolate
memory issues from software issues.
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* Re: MPC5200 Rev. B
From: Nick Barendt @ 2005-07-11 17:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <6.2.3.4.1.20050711112652.02b82cc8@mail.int.acdstar.com>
Eric N. Johnson (ACD) wrote:
> mgberry@ellipticity.com wrote:
>
>> Has anyone experienced any issues with the Rev. B silicon for the
>> MPC5200. We are seeing Linux hanging and are suspecting the SDRAM
>> errata for Rev. B. If we disable the cache this seems to improve but
>> will still crash over time in heavy loads. We have not seen any of
>> these type issues with the original rev.
>
>
> Are you sure you have revision B of the MPC5200? Freescale has
> announced a "B" version, but I don't believe that any of them have hit
> the public yet. There may be some engineering grade samples out
> there. (Let me know if you really do have "B" parts. Freescale has
> been telling me "real soon now" since last year)
I can confirm that there are engineering samples of at least the first
mask set of the Rev. B part floating around. A friend sent me one:
PPC5200CVR400 mask set M08A.
Our local rep has hemming and hawing, too, which is getting very
frustrating, knowing that other developers have had silicon in there
hands for some time, and that several of the errata on the L25R mask set
(PCI DMA arbitration, among them) have been causing us some serious
headaches.
We have had very limited success with the Rev B engineering part,
populated on a custom board. Basically locking up at boot time when the
DDR is enabled. We're trying to isolate the problem to a hardware
(board/part damaged) or software (are there changes to the memory
controller configuration required for the Rev. B?).
We do know that there are still errata on the first mask rev and that a
second mask rev is in process.
Anyone else have anything to report?
-Nick
^ permalink raw reply
* MPC5200 Rev. B
From: mgberry @ 2005-07-11 18:13 UTC (permalink / raw)
To: linuxppc-embedded
>Are you sure you have revision B of the MPC5200? Freescale has
>announced a "B" version, but I don't believe that any of them have
>hit the public yet. There may be some engineering grade samples out
>there. (Let me know if you really do have "B" parts. Freescale has
>been telling me "real soon now" since last year)
We have receieved 10 samples of Rev. B last week. Part # PPC5200CBV400B
Sounds like others may be having similiar problems, glad to know Im not the only
frustrated one here. The schedule freescale provided showed a production
release in July that would resolve these issues. The reason we went to the
Rev. B was because the PCI Bridge PLX6152 would not respond due to PCI timing
errata in the 5200. The suggested workaround seemed unfeaseable due to the
local bus being shared. Any input?
Matt Berry
Austin, TX
^ permalink raw reply
* Re: Linux 2.4.25 / MPC8280 / ram config vs Linux instability?
From: Dan Malek @ 2005-07-11 18:39 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <20050711134713.D767067C13@ozlabs.org>
On Jul 11, 2005, at 6:38 AM, Absolut Hunter wrote:
> ..... However, my goal is
> to map SRAM <8ns speeds> down to the address 0x00000000, to map the
> vector
> table, so I can achieve a very fast interrupt response time.
The things Linux does to cause interrupt latencies are going to ensure
you aren't going to see any differences to the "interrupt response
time." :-)
From a system perspective, you are going to be much better off using
your SRAM for CPM data buffering than for any general software use.
> Does anyone have any idea what would cause this instability?
Yeah, I can't find a way to actually map the memory as you have
described. You actually have the SRAM and SDRAM multiply mapped
on top of one another, and depending upon which chip selects
are used and the values in their registers, you are selecting between
the two memories. Several cases exist. You are either mapping the
SRAM on top of the SDRAM, or vice versa. You really have only 32M
of memory available, so any access to the "upper" 2M is wrapping
around to the lower memory. Basically, you have a big mess ;-)
You need to map these memories to modulo their size, so to put
the 2M at low memory, you are going to have a hole up to a 32M
boundary before you can map the SDRAM. It's possible to do
this, but not without some custom Linux modifications.
Thanks.
-- Dan
^ permalink raw reply
* Re: MPC5200 Rev. B
From: Wolfgang Denk @ 2005-07-11 19:46 UTC (permalink / raw)
To: Nick Barendt; +Cc: linuxppc-embedded
In-Reply-To: <42D2AF46.9000200@vxitech.com>
In message <42D2AF46.9000200@vxitech.com> you wrote:
>
> I can confirm that there are engineering samples of at least the first
> mask set of the Rev. B part floating around. A friend sent me one:
...
> We have had very limited success with the Rev B engineering part,
We, too, have some problems with hardware which uses the currently
available negineering samples. It's not completely clear if these are
board or processor or software issues yet.
> We do know that there are still errata on the first mask rev and that a
> second mask rev is in process.
>
> Anyone else have anything to report?
If you got samples, you should also have access to the updated errata
sheet (MPC5200B_Customer_Info_addendum_errata). Read it. Also note
that you have to use BAPI v2.2 with Rev. B processors.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every program has at least one bug and can be shortened by at least
one instruction -- from which, by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: Jon Loeliger @ 2005-07-11 21:22 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20050711045532.GC32545@localhost.localdomain>
On Sun, 2005-07-10 at 23:55, David Gibson wrote:
> On Fri, Jul 08, 2005 at 04:44:58PM -0500, Jon Loeliger wrote:
> > David and Ben,
> >
> > This patch adds support for memreserve to the DTC's notion
> > of the "source file". That is, you can now say this:
> >
> >
> > memreserve = <
> > 0000 0001 0000 0002
> > 0000 0003 0000 0004
> > >
>
> Hrm.. nice idea, but I don't really like the syntax. It looks like a
> property definition, which it's really not,
Well, syntax is relatively easy to change. I picked one
that was already present in the grammar and lex code.
I wanted to use something more braces oriented, but it
got gross looking once I decided to use the "struct data"
parts for the cell_t values.
> and forcing the user to
> split up these 64-bit quantities into cells is kind of silly.
Hey, I didn't set that up! :-) There wasn't an existing
clean way to state 64 bit values, and an arbitrary list of
them. So I uh, leveraged the existing cell_t support!
> Plus
> the fact that "memreserve" is lexed as a reserved word means it can't
> be used as a property name.
Yeah, I wasn't happy about that either. Wasn't sure
what you wanted to do to "fix" that. Thought it better
to get the code into your hands than try to discuss the
issues via mail.
> And it really ought to have a ';' at the
> end, for consistency.
Sure. Easy.
And, I actually anticipated making the "header" parts
of the grammar be more general, of which then the memory
reserve area would be just one part. For example, suppose
you wanted to specify the "version" too:
/header/ = {
version = 10;
memreserve = < .... .... .... .... >;
};
Or so.
> Hrm... wonder how to do this, without making the lex and yacc stuff
> too unspeakable.
>
> Maybe
>
> /memreserve/ = { 00000001-00000002;
> 00000003-00000004;
> };
>
> I'm not that fond of the /.../ form, although the '/' is the best way
> I can think of to ensure it can't be confused with a property or node
> name. We'lll also need some sort of lexing magic so that it actually
> recognizes the things within as numbers, not property names, too.
> Hrm... will need to think about that.
Which was sort of the problem I faced... :-)
> > There is minor fiddling with the -R flag that needs to be
> > resolved at this point.
>
> I think -R should add the given number of extra empty entries, on top
> of the ones given in the source.
Except now you have to carry the count along in the header.
How else do you know if the _first_ or _last_ 0-size value
really ends the list? Well, you could maybe assume ordered
parts an subtract the base offset of the memreserve section
from the following section to get its total size. Gross, though.
> > Please feel free to adjust my coding approach or argument
> > passing or whatever as needed. Hope this helps!
>
> Yeah, there are some things I'd like to change (in addition to the
> input syntax itself), but I'm thinking about just applying it and
> fixing up afterwards.
That sounds good.
> Biggest thing is that rather than passing the tree itself and the
> memreserve info about as two parameters all over the place, I'd rather
> create a new structure which has both (and later can have anything
> else that might be needed).
If you'd like, I'll do this work.
jdl
^ permalink raw reply
* Re: PATCH: Add memreserve to DTC
From: David Gibson @ 2005-07-12 2:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1121116950.15394.14.camel@cashmere.sps.mot.com>
On Mon, Jul 11, 2005 at 04:22:30PM -0500, Jon Loeliger wrote:
> On Sun, 2005-07-10 at 23:55, David Gibson wrote:
> > On Fri, Jul 08, 2005 at 04:44:58PM -0500, Jon Loeliger wrote:
> > > David and Ben,
> > >
> > > This patch adds support for memreserve to the DTC's notion
> > > of the "source file". That is, you can now say this:
> > >
> > >
> > > memreserve = <
> > > 0000 0001 0000 0002
> > > 0000 0003 0000 0004
> > > >
>
> >
> > Hrm.. nice idea, but I don't really like the syntax. It looks like a
> > property definition, which it's really not,
>
> Well, syntax is relatively easy to change. I picked one
> that was already present in the grammar and lex code.
> I wanted to use something more braces oriented, but it
> got gross looking once I decided to use the "struct data"
> parts for the cell_t values.
>
> > and forcing the user to
> > split up these 64-bit quantities into cells is kind of silly.
>
> Hey, I didn't set that up! :-) There wasn't an existing
> clean way to state 64 bit values, and an arbitrary list of
> them. So I uh, leveraged the existing cell_t support!
Cells make sense for the actual OF-like data, becayse they're an OF
concept. For memreserve, which is purely Linux specific, they don't/
> > Plus
> > the fact that "memreserve" is lexed as a reserved word means it can't
> > be used as a property name.
>
> Yeah, I wasn't happy about that either. Wasn't sure
> what you wanted to do to "fix" that. Thought it better
> to get the code into your hands than try to discuss the
> issues via mail.
Yeah... I have some ideas, maybe replacing some of the start
conditions with a lexical tie-in from the parser level. I'll see what
I can come up with.
> > And it really ought to have a ';' at the
> > end, for consistency.
>
> Sure. Easy.
>
> And, I actually anticipated making the "header" parts
> of the grammar be more general, of which then the memory
> reserve area would be just one part. For example, suppose
> you wanted to specify the "version" too:
>
> /header/ = {
> version = 10;
> memreserve = < .... .... .... .... >;
> };
Perhaps, I don't think there's anything else that we really want to
set for now. I don't think version should be set in the source file.
> Or so.
Actually, I'm having second thoughts on the form I suggested before.
I'm now leaning towards:
/memreserve/ 00000001-00000002;
/memreserve/ 00000003-00000004;
/ {
...
};
> > Hrm... wonder how to do this, without making the lex and yacc stuff
> > too unspeakable.
> >
> > Maybe
> >
> > /memreserve/ = { 00000001-00000002;
> > 00000003-00000004;
> > };
> >
> > I'm not that fond of the /.../ form, although the '/' is the best way
> > I can think of to ensure it can't be confused with a property or node
> > name. We'lll also need some sort of lexing magic so that it actually
> > recognizes the things within as numbers, not property names, too.
> > Hrm... will need to think about that.
>
> Which was sort of the problem I faced... :-)
>
> > > There is minor fiddling with the -R flag that needs to be
> > > resolved at this point.
> >
> > I think -R should add the given number of extra empty entries, on top
> > of the ones given in the source.
>
> Except now you have to carry the count along in the header.
> How else do you know if the _first_ or _last_ 0-size value
> really ends the list? Well, you could maybe assume ordered
> parts an subtract the base offset of the memreserve section
> from the following section to get its total size. Gross, though.
>
>
> > > Please feel free to adjust my coding approach or argument
> > > passing or whatever as needed. Hope this helps!
> >
> > Yeah, there are some things I'd like to change (in addition to the
> > input syntax itself), but I'm thinking about just applying it and
> > fixing up afterwards.
>
> That sounds good.
>
> > Biggest thing is that rather than passing the tree itself and the
> > memreserve info about as two parameters all over the place, I'd rather
> > create a new structure which has both (and later can have anything
> > else that might be needed).
>
> If you'd like, I'll do this work.
>
> jdl
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: OLS 2005
From: Grant Likely @ 2005-07-12 4:04 UTC (permalink / raw)
To: Kumar Gala, greg; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <18C1CAA6-F980-4F8C-8FDD-E5D676D084ED@freescale.com>
On 7/6/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> > On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> >
> >> I wondering if we can get a PPC BoF together, ...
The schedule is now posted on the OLS website. Thursday and Friday
evenings are set for scheduled BOFs. Why don't we tentatively plan an
unoffical PPCembedded BOF Thursday evening?
We should try to meet each other during the day Wednesday and choose a
good time.
> > I'd like to discuss the platform bus a bit. As was discussed a month
> > or so ago, there is no clean way of matching multiple device drivers
> > to a single device type, like with PSCs on the MPC5200.
> >
> We should try to see if we can find GregKH to discuss what changes
> would need to be made to the driver core to allow this.
>=20
How 'bout it Greg? Can we get some of your time?
Cheers,
g.
^ 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