* ppc405ep and Ready enable in EBC0_BnAP register
From: ravi.rao @ 2008-04-02 18:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
Hi All,
Our target is based on PPC405EP and we are using a TDMoIP chip on the
peripheral bus with chipselect 2. Since the access time to the chip is not
deterministic we are planning to use the Ready enable. By probing into
Chipselect and ready enable bits it looks like the chip select gets
extended untill the ready enable becomes 1 but the access crashes with a
Bus error.
But If I just set the twt to a very high value say 20 with ready enable
set to 0 then it works. Any pointers to understand what is happening
will be of great help.
####################### Screen Dump #################################
Data machine check in kernel mode.
PLB0: BEAR= 0xf8000000 ACR= 0x00000000 BESR= 0x00000000
PLB0 to OPB: BEAR= 0x01000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#5]
NIP: C90C69BC LR: C90C6AA4 CTR: 000003E0
REGS: c023ef50 TRAP: 0202 Not tainted (2.6.21)
MSR: 00029030 <EE,ME,IR,DR> CR: 84044408 XER: 00000007
TASK = c3fab050[666] 'cat' THREAD: c2710000
GPR00: 00000000 C2711650 C3FAB050 C2729000 C2711EAC 00000000 00000C00
C2711EA8
GPR08: 00000000 00000040 FFFFFFFF C9400000 44044408 100A54C0 03FF9C00
00000001
GPR16: 0000005E C01DA824 C02E7F78 C01E0C50 C2711EA8 C01E0C20 C2711EAC
C25DC320
GPR24: C2729000 00000000 C2711F20 C90C7FF4 C2729000 C2711EA8 C2711658
C2729000
Call Trace:
[C2711E80] [C90C6AA4]
[C2711EA0] [C009BA60]
[C2711EF0] [C0063E6C]
[C2711F10] [C00642C8]
[C2711F40] [C0002CB4]
Instruction dump:
bf210814 3b697ff4 90010834 817b006c 7c7f1b78 a00b0000 39200002 b0010008
380003ff 7c0903a6 3bc10008 7c0b4a2e <7c09f32e> 39290002 4200fff4 3c80c90c
Bus error
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
[-- Attachment #2: Type: text/html, Size: 4149 bytes --]
^ permalink raw reply
* [PATCH] E500 Make steal_context SMP-safe.
From: Randy Vinson @ 2008-04-02 17:55 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
>From c4923d80bbd40f91c7b402db37fabb4995632b7e Mon Sep 17 00:00:00 2001
From: Randy Vinson <rvinson@mvista.com>
Date: Tue, 1 Apr 2008 17:19:06 -0700
Subject: [PATCH] E500 Make steal_context SMP-safe.
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking to
prevent this as suggested by BenH.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
Note: This is a proof-of-concept patch. This isn't my area of expertise,
so I'd greatly appreciate any guidance I can get. I'm considering the
use of for_each_online_cpu() instead of for_each_possible_cpu() and
possibly putting the changes under a CONFIG_SMP switch to prevent unnecessary
overhead in the non-SMP case.
Thx,
Randy Vinson
arch/powerpc/mm/mmu_context_32.c | 27 +++++++++++++++++++++++++++
include/asm-powerpc/mmu_context.h | 5 +++++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_32.c b/arch/powerpc/mm/mmu_context_32.c
index cc32ba4..cf04aa8 100644
--- a/arch/powerpc/mm/mmu_context_32.c
+++ b/arch/powerpc/mm/mmu_context_32.c
@@ -34,6 +34,8 @@ unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
atomic_t nr_free_contexts;
struct mm_struct *context_mm[LAST_CONTEXT+1];
void steal_context(void);
+DEFINE_SPINLOCK(mm_lock);
+DEFINE_PER_CPU(struct mm_struct *, curr_mm);
#endif /* FEW_CONTEXTS */
/*
@@ -42,6 +44,9 @@ void steal_context(void);
void __init
mmu_context_init(void)
{
+#ifdef FEW_CONTEXTS
+ int cpu;
+#endif
/*
* Some processors have too few contexts to reserve one for
* init_mm, and require using context 0 for a normal task.
@@ -52,6 +57,8 @@ mmu_context_init(void)
next_mmu_context = FIRST_CONTEXT;
#ifdef FEW_CONTEXTS
atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+ for_each_possible_cpu(cpu)
+ per_cpu(curr_mm, cpu) = NULL;
#endif /* FEW_CONTEXTS */
}
@@ -72,6 +79,24 @@ void
steal_context(void)
{
struct mm_struct *mm;
+ int cpu;
+ cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
+
+ do {
+ /* free up context `next_mmu_context' */
+ /* if we shouldn't free context 0, don't... */
+ if (next_mmu_context < FIRST_CONTEXT)
+ next_mmu_context = FIRST_CONTEXT;
+ mm = context_mm[next_mmu_context];
+ for_each_possible_cpu(cpu) {
+ if ((cpu != smp_processor_id()) &&
+ per_cpu(curr_mm, cpu) == mm) {
+ mm = NULL;
+ next_mmu_context = (next_mmu_context + 1) &
+ LAST_CONTEXT;
+ }
+ }
+ } while(!mm);
/* free up context `next_mmu_context' */
/* if we shouldn't free context 0, don't... */
@@ -80,5 +105,7 @@ steal_context(void)
mm = context_mm[next_mmu_context];
flush_tlb_mm(mm);
destroy_context(mm);
+ if (!cpus_equal(mm->cpu_vm_mask, local_cpumask))
+ flush_tlb_mm(mm);
}
#endif /* FEW_CONTEXTS */
diff --git a/include/asm-powerpc/mmu_context.h b/include/asm-powerpc/mmu_context.h
index 9102b8b..e083b25 100644
--- a/include/asm-powerpc/mmu_context.h
+++ b/include/asm-powerpc/mmu_context.h
@@ -113,6 +113,8 @@ extern unsigned long next_mmu_context;
extern atomic_t nr_free_contexts;
extern struct mm_struct *context_mm[LAST_CONTEXT+1];
extern void steal_context(void);
+extern spinlock_t mm_lock;
+DECLARE_PER_CPU(struct mm_struct *, curr_mm);
#endif
/*
@@ -125,6 +127,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
if (mm->context.id != NO_CONTEXT)
return;
#ifdef FEW_CONTEXTS
+ spin_lock(&mm_lock);
while (atomic_dec_if_positive(&nr_free_contexts) < 0)
steal_context();
#endif
@@ -138,6 +141,8 @@ static inline void get_mmu_context(struct mm_struct *mm)
mm->context.id = ctx;
#ifdef FEW_CONTEXTS
context_mm[ctx] = mm;
+ per_cpu(curr_mm, smp_processor_id()) = mm;
+ spin_unlock(&mm_lock);
#endif
}
--
1.5.4.4.551.g1658c
^ permalink raw reply related
* Re: [PATCH] RTAS - adapt procfs interface
From: Nathan Lynch @ 2008-04-02 18:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: maxim, cbe-oss-dev, linuxppc-dev
In-Reply-To: <18419.29333.344126.231799@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Nathan Lynch writes:
>
> > I think this is better... the way these files are used is lame, but
> > this should preserve the existing behavior. I haven't yet tested
> > this, can you?
>
> Looks OK -- can I have a proper patch description and a signed-off-by
> line for this please?
Actually, my patch has the potentially undesirable consequence of
allowing only one of the three flash-related proc files to be open at
any time, whereas the previous behavior enforced exclusive open on a
per-file basis.
If you want something for 2.6.25, I think the patch Jens posted is
of lower risk.
^ permalink raw reply
* Re: u-boot ppc440epx bootstrap configuration without eval board
From: Stefan Roese @ 2008-04-02 19:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000901c894eb$e0707170$2001a8c0@DCOGLEYNEW>
On Wednesday 02 April 2008, Dave Cogley wrote:
> Disregard the boot strapping problem. It appears we are hardwired strapped
> to use option "C" however my CPU is not being recognized as a 667MHz.
> Which option should I be using for the 667MHz processor?
First, this is the wrong mailing list for this discussion. Please post to the
U-Boot list instead.
But here some general comments:
The bootstrap controller has multiple configuration options. Some of them
result in hardwired frequencies (CPU, PLB, OPB...), and some of them load the
PLL setup from an I2C EEPROM. Using this bootstrap EEPROM is the most
flexible solution. If you have only option "C", then you hardwired to 533MHz.
There is no way to "detect" which frequency this CPU is labeled.
But it *is* possible to reconfigure the PLL from within U-Boot an reset the
PPC to run with this different PLL setup. I just recently added some code the
u-boot-ppc4xx custodian repository.
Let's continue this thread on the U-Boot list.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-04-02 19:19 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165222.2468414080A9@mail104-dub.bigfish.com>
Hello.
John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
> Signed-off-by: John Linn <john.linn@xilinx.com>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such that they
> + use the ns16550 binding with properties to specify register spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
I'm proposing you to use the already existing "big-endian" property ISO
"reg-offset" (used in the nodes describing OpenPIC, for example).
WBR, Sergei
^ permalink raw reply
* Two MPC8641D's on a single JTAG chain with BDI2000/3000. Anyone got it to work?
From: Phil Terry @ 2008-04-02 19:14 UTC (permalink / raw)
To: linuxppc-dev
Hi Guys'n'Gals,
We have a board with two Freescale MPC8641D chips (ie four cores, two in
each chip) on a single jtag chain, nothing else on the chain. We are
unable to get BDI and WindRiver jtag debuggers to work with both chips,
only the second (last) chip works. With the BDI we can configure to work
with both cores in the second chip, with windriver only one core in
second chip configuration works.
If we split the jtag chain in the lab we can work with each processor
independently with no problems. We want both to work however.
On the BDI if we configure predecessor 1,8, successor 0,0 we can talk to
the second chip as expected, but if we try predecessor 0,0 successor 1,8
to talk to the first chip we get nothing.
Is there something else we need to configure in either the BDM or the
Freescale chip to get this to work?
Any suggestions or pointers to helpful resources welcome, either
privately or to the list if this isn't too far off topic.
Cheers
Phil
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-02 19:27 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402182023.8FA7318B808D@mail52-dub.bigfish.com>
On Wed, Apr 2, 2008 at 12:20 PM, John Linn <John.Linn@xilinx.com> wrote:
> Sounds good, those are easy changes and make sense.
>
> Since I'm a newbie, I don't know any better sometimes when I copy other
> code that may not be as safe.
>
> The same thing, of_get_property(np, "current-speed", NULL);, is done
> right above my code I added.
>
> Should the other code in the driver using the same method be fixed, or
> just my patch?
It would be good to fix the other code, but not in this patch. Write
another patch to fix that.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: Ethernet Jumbo Frames
From: Rick Moleres @ 2008-04-02 21:15 UTC (permalink / raw)
To: Darcy Watkins, LinuxPPC-Embedded
In-Reply-To: <D61182AC8012EA4EBC531B3AF23BE109582F00@tranzeo-mail2.12stewart.tranzeo.com>
Sure, it can be done. The Xilinx 10/100 Ethernet drivers have jumbo
frame support in MontaVista/WindRiver Linux. As long as both ends are
talking jumbo frames, works just fine.
-Rick
-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of Darcy Watkins
Sent: Monday, March 31, 2008 2:48 PM
To: LinuxPPC-Embedded
Subject: Ethernet Jumbo Frames
Has anyone on this list ever been given a requirement to implement
support for ethernet frames larger than the standard MTU of 1500? ...
... for normal 10/100 Ethernet? ... not gigabit.
The application is to support certain encapsulation protocols without
imposing smaller than 1500 byte MTU restrictions on the innermost
protocol.
I have been tasked to investigate this for a system based on PPC405EP.
Can it be done using the IBM EMAC, Linux drivers, etc?
Regards,
Darcy
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: u-boot ppc440epx bootstrap configuration without eval board
From: Wolfgang Denk @ 2008-04-02 21:16 UTC (permalink / raw)
To: Dave Cogley; +Cc: linuxppc-embedded
In-Reply-To: <000901c894eb$e0707170$2001a8c0@DCOGLEYNEW>
In message <000901c894eb$e0707170$2001a8c0@DCOGLEYNEW> you wrote:
>
> Disregard the boot strapping problem. It appears we are hardwired strapped
> to use option "C" however my CPU is not being recognized as a 667MHz. Which
> option should I be using for the 667MHz processor?
U-Boot related questions are off topic here. You should try the
u-boot-users mailing list instead...
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
When the ax entered the forest, the trees said, "The handle is one of
us!" -- Turkish proverb
^ permalink raw reply
* RE: Ethernet Jumbo Frames
From: Darcy Watkins @ 2008-04-02 21:32 UTC (permalink / raw)
To: LinuxPPC-Embedded
In-Reply-To: <20080402211552.729E82B007F@mail93-dub.bigfish.com>
Thanks for the comments...
I have hacked the IBM EMAC driver (Xenomai-2.3.0 Real Time Linux
2.6.19.2) and got jumbo frames to pass back and forth between two such
embedded boards. Checked it using ping, iperf and httpd / wget file
transfer with md5sum check.
Still have to clean things up a bit and do some more tests before I can
share it as a patch.
Regards,
Darcy
-----Original Message-----
Sure, it can be done. The Xilinx 10/100 Ethernet drivers have jumbo
frame support in MontaVista/WindRiver Linux. As long as both ends are
talking jumbo frames, works just fine.
-Rick
-----Original Message-----
We've done it for our 2.4 based kernel that runs on a Freescale MPC8270.
10/100/1000 doesn't really make any difference. For us the trick was to
support receving jumbo frames in multiple RX BufDescriptors (because our
MPC8270 FCC eth driver pre-allocates 2k buffers per RX BD).
For transmitting hardly any changes were necessary.
From linux (driver) standpoint there should be no problems,
the question is whether your ethernet MAC (IBM EMAC) properly supports
it.
hth,
N. van Bolhuis.
^ permalink raw reply
* RE: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Stephen Neuendorffer @ 2008-04-02 21:39 UTC (permalink / raw)
To: John Linn, Grant Likely, sshtylyov; +Cc: linuxppc-dev
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C05FC4762@XCO-EXCHVS1.xlnx.xilinx.com>
I don't think big-endian has the same context as reg-shift/reg-offset.
The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If
we were talking about a 32 bit device, then I'd probably agree with you,
but in this case, the reg-shift (and to some extent) reg-offset have
been used before and probably make more sense, I think.
Steve
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]
> Sent: Wednesday, April 02, 2008 1:20 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca
> Subject: Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for
Xilinx uart 16550.
>=20
> Hello.
>=20
> John Linn wrote:
>=20
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based addressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
>=20
> > This code updates the of_serial driver to handle the reg-offset
> > and reg-shift properties to enable this core to be used.
>=20
> > Signed-off-by: John Linn <john.linn@xilinx.com>
>=20
> > diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-
> of.txt
> > index 87f4d84..af112d9 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -2539,6 +2539,17 @@ platforms are moved over to use the
flattened-device-tree model.
> > differ between different families. May be
> > 'virtex2p', 'virtex4', or 'virtex5'.
> >
> > + iv) Xilinx Uart 16550
> > +
> > + Xilinx UART 16550 devices are very similar to the NS16550
such that they
> > + use the ns16550 binding with properties to specify register
spacing and
> > + an offset from the base address.
> > +
> > + Requred properties:
> > + - clock-frequency : Frequency of the clock input
> > + - reg-offset : A value of 3 is required
>=20
> I'm proposing you to use the already existing "big-endian"
property ISO
> "reg-offset" (used in the nodes describing OpenPIC, for example).
>=20
> WBR, Sergei
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Yinghai Lu @ 2008-04-02 21:57 UTC (permalink / raw)
To: Badari Pulavarty
Cc: lkml, Kamalesh Babulal, linuxppc-dev, Andrew Morton, Balbir Singh
In-Reply-To: <1207164127.30407.36.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > >>
> > > >> [ 0.000000] ------------[ cut here ]------------
> > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [ 0.000000] Modules linked in:
> > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [ 0.000000] Call Trace:
> > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > >> [ 0.000000] Instruction dump:
> > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > > >>
> > > >
> > > > int __meminit vmemmap_populate(struct page *start_page,
> > > > unsigned long nr_pages, int node)
> > > > {
> > > > unsigned long mode_rw;
> > > > unsigned long start = (unsigned long)start_page;
> > > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > > >
> > > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > > >
> > > > /* Align to the page size of the linear mapping. */
> > > > start = _ALIGN_DOWN(start, page_size);
> > > >
> > > > for (; start < end; start += page_size) {
> > > > int mapped;
> > > > void *p;
> > > >
> > > > if (vmemmap_populated(start, page_size))
> > > > continue;
> > > >
> > > > p = vmemmap_alloc_block(page_size, node);
> > > > if (!p)
> > > > return -ENOMEM;
> > > >
> > > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > > start, p, __pa(p));
> > > >
> > > > mapped = htab_bolt_mapping(start, start + page_size,
> > > > __pa(p), mode_rw, mmu_linear_psize,
> > > > mmu_kernel_ssize);
> > > > =====> BUG_ON(mapped < 0);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > > in git-powerpc...
> > >
> > > One of the machines is the Power5 and another is PowerMac G5, on which the
> > > same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
>
> Okay. Found it.
>
> Root cause is:
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
>
will send you patch workaround it...
YH
^ permalink raw reply
* [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-02 22:25 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Badari Pulavarty,
Balbir Singh
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
on powerpc,
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > >>
> > > >> [ 0.000000] ------------[ cut here ]------------
> > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [ 0.000000] Modules linked in:
> > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [ 0.000000] Call Trace:
> > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > >> [ 0.000000] Instruction dump:
> > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
so try to allocate usemap at first altogether.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
diff --git a/mm/sparse.c b/mm/sparse.c
index d3cb085..782ebe5 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -294,7 +294,7 @@ void __init sparse_init(void)
unsigned long pnum;
struct page *map;
unsigned long *usemap;
- struct page **section_map;
+ unsigned long **usemap_map;
int size;
int node;
@@ -305,27 +305,31 @@ void __init sparse_init(void)
* make next 2M slip to one more 2M later.
* then in big system, the memmory will have a lot hole...
* here try to allocate 2M pages continously.
+ *
+ * powerpc hope to sparse_init_one_section right after each
+ * sparse_early_mem_map_alloc, so allocate usemap_map
+ * at first.
*/
- size = sizeof(struct page *) * NR_MEM_SECTIONS;
- section_map = alloc_bootmem(size);
- if (!section_map)
- panic("can not allocate section_map\n");
+ size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
+ usemap_map = alloc_bootmem(size);
+ if (!usemap_map)
+ panic("can not allocate usemap_map\n");
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
- section_map[pnum] = sparse_early_mem_map_alloc(pnum);
+ usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
}
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
- map = section_map[pnum];
+ map = sparse_early_mem_map_alloc(pnum);
if (!map)
continue;
- usemap = sparse_early_usemap_alloc(pnum);
+ usemap = usemap_map[pnum];
if (!usemap)
continue;
@@ -333,7 +337,7 @@ void __init sparse_init(void)
usemap);
}
- free_bootmem(__pa(section_map), size);
+ free_bootmem(__pa(usemap_map), size);
}
#ifdef CONFIG_MEMORY_HOTPLUG
^ permalink raw reply related
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Yinghai Lu @ 2008-04-02 22:24 UTC (permalink / raw)
To: Badari Pulavarty
Cc: lkml, Kamalesh Babulal, linuxppc-dev, Andrew Morton, Balbir Singh
In-Reply-To: <1207164127.30407.36.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > >>
> > > >> [ 0.000000] ------------[ cut here ]------------
> > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [ 0.000000] Modules linked in:
> > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [ 0.000000] Call Trace:
> > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > >> [ 0.000000] Instruction dump:
> > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > > >>
> > > >
> > > > int __meminit vmemmap_populate(struct page *start_page,
> > > > unsigned long nr_pages, int node)
> > > > {
> > > > unsigned long mode_rw;
> > > > unsigned long start = (unsigned long)start_page;
> > > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > > >
> > > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > > >
> > > > /* Align to the page size of the linear mapping. */
> > > > start = _ALIGN_DOWN(start, page_size);
> > > >
> > > > for (; start < end; start += page_size) {
> > > > int mapped;
> > > > void *p;
> > > >
> > > > if (vmemmap_populated(start, page_size))
> > > > continue;
> > > >
> > > > p = vmemmap_alloc_block(page_size, node);
> > > > if (!p)
> > > > return -ENOMEM;
> > > >
> > > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > > start, p, __pa(p));
> > > >
> > > > mapped = htab_bolt_mapping(start, start + page_size,
> > > > __pa(p), mode_rw, mmu_linear_psize,
> > > > mmu_kernel_ssize);
> > > > =====> BUG_ON(mapped < 0);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > > in git-powerpc...
> > >
> > > One of the machines is the Power5 and another is PowerMac G5, on which the
> > > same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
>
> Okay. Found it.
>
> Root cause is:
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
>
http://lkml.org/lkml/2008/4/2/592
Thanks
YH
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Badari Pulavarty @ 2008-04-02 23:51 UTC (permalink / raw)
To: yhlu.kernel
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
Ingo Molnar, Balbir Singh
In-Reply-To: <200804021525.48799.yhlu.kernel@gmail.com>
On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> so try to allocate usemap at first altogether.
>
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -294,7 +294,7 @@ void __init sparse_init(void)
> unsigned long pnum;
> struct page *map;
> unsigned long *usemap;
> - struct page **section_map;
> + unsigned long **usemap_map;
> int size;
> int node;
>
> @@ -305,27 +305,31 @@ void __init sparse_init(void)
> * make next 2M slip to one more 2M later.
> * then in big system, the memmory will have a lot hole...
> * here try to allocate 2M pages continously.
Comments are x86-64 specific. On ppc its 16MB chunks :(
> + *
> + * powerpc hope to sparse_init_one_section right after each
> + * sparse_early_mem_map_alloc, so allocate usemap_map
> + * at first.
> */
> - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> - section_map = alloc_bootmem(size);
> - if (!section_map)
> - panic("can not allocate section_map\n");
> + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> + usemap_map = alloc_bootmem(size);
> + if (!usemap_map)
> + panic("can not allocate usemap_map\n");
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
> - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> }
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
>
> - map = section_map[pnum];
> + map = sparse_early_mem_map_alloc(pnum);
> if (!map)
> continue;
>
> - usemap = sparse_early_usemap_alloc(pnum);
> + usemap = usemap_map[pnum];
> if (!usemap)
> continue;
You may want to move this check before doing sparse_early_mem_map_alloc
(). We are also not handling errors properly (freeing up the unused
map or usemap) if we "continue". I know the original code is this way,
but you touched it last :)
>
> @@ -333,7 +337,7 @@ void __init sparse_init(void)
> usemap);
> }
>
> - free_bootmem(__pa(section_map), size);
> + free_bootmem(__pa(usemap_map), size);
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
Tested and boots my machine fine.
Acked-by: Badari Pulavarty <pbadari@us.ibm.com>
Thanks,
Badari
^ permalink raw reply
* RE: Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-02 22:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C025292E2@ehost011-3.exch011.intermedia.net>
Hi, Josh:
I have resolved my kernel driver problem, it was my own bug, didn't have
anything to do with memory remapping itself. Your suggestion to move to
ioremap64() did resolve problem completely.
I still need investigate mmap() crash. Apparently switch to mmap64()
didn't help, but it could be some another bug, I'll double check.
Thanks,
Leonid.=20
-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Leonid
Sent: Tuesday, April 01, 2008 9:30 PM
To: Josh Boyer
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: Access physical memory via mmap() on ppc440epx.
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).=20
What can it be?
Thanks,
Leonid.=20
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>=20
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>=20
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Andrew Morton @ 2008-04-02 22:52 UTC (permalink / raw)
To: yhlu.kernel
Cc: Balbir, Kamalesh, kernel list, Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Singh
In-Reply-To: <200804021525.48799.yhlu.kernel@gmail.com>
On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> on powerpc,
>
> On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > > Andrew Morton wrote:
> > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > > >
> > > > >> Hi Andrew,
> > > > >>
> > > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > > >>
> > > > >> [ 0.000000] ------------[ cut here ]------------
> > > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > > >> [ 0.000000] Modules linked in:
> > > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > > >> [ 0.000000] Call Trace:
> > > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > > >> [ 0.000000] Instruction dump:
> > > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >
> > mm-make-mem_map-allocation-continuous.patch
> > and its friends in -mm.
> >
> > You have to call sparse_init_one_section() on each pmap and usemap
> > as we allocate - since valid_section() depends on it (which is needed
> > by vmemmap_populate() to check if the section is populated or not).
> > On ppc, we need to call htab_bolted_mapping() on each section and
> > we need to skip existing sections.
> >
> > These patches tried to group all allocations together and then later
> > calls sparse_init_one_section() - which is not good :(
>
> so try to allocate usemap at first altogether.
I have to turn all the above crud into a proper changelog. I'd prefer that
you do it.
Unless this patch should be folded into another one, in which case it
doesn't matter.
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
We shouldn't merge this patch on its own because then that will leave a
non-bisectable region in the powerpc history.
So which patch is this patch fixing? Lexically it applies to
mm-allocate-section_map-for-sparse_init.patch (and its updates). But is
that where it logically lies?
^ permalink raw reply
* [PATCH] [POWERPC] Fix a mm compile error
From: Emil Medve @ 2008-04-02 23:05 UTC (permalink / raw)
To: paulus, linuxppc-dev, linuxppc-embedded; +Cc: Emil Medve
arch/powerpc/mm/init_32.c:102: error: conflicting types for '__initial_memory_limit_addr'
arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of '__initial_memory_limit_addr' was here
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
arch/powerpc/mm/init_32.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 555bb7e..63c5e3d 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM;
* address of the limit of what is accessible with initial MMU setup -
* 256MB usually, but only 16MB on 601.
*/
-unsigned long __initial_memory_limit_addr = 0x10000000;
+phys_addr_t __initial_memory_limit_addr = 0x10000000;
/*
* Check for command-line options that affect what MMU_init will do.
--
1.5.4.GIT
^ permalink raw reply related
* [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 23:22 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift properties to enable this core to be used.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
V3 has fixes suggested by Grant. They were incorporated and tested.
Documentation/powerpc/booting-without-of.txt | 10 ++++++++++
drivers/serial/of_serial.c | 14 +++++++++++++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 87f4d84..4066ec8 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
+ iv) Xilinx Uart 16550
+
+ Xilinx UART 16550 devices are very similar to the NS16550 but with
+ different register spacing and an offset from the base address.
+
+ Requred properties:
+ - clock-frequency : Frequency of the clock input
+ - reg-offset : A value of 3 is required
+ - reg-shift : A value of 2 is required
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..73c47a5 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -31,7 +31,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
struct resource resource;
struct device_node *np = ofdev->node;
const unsigned int *clk, *spd;
- int ret;
+ const u32 *prop;
+ int ret, prop_size;
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
@@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
spin_lock_init(&port->lock);
port->mapbase = resource.start;
+
+ /* Check for shifted address mapping */
+ prop = of_get_property(np, "reg-offset", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ port->mapbase += *prop;
+
+ /* Check for registers offset within the devices address range */
+ prop = of_get_property(np, "reg-shift", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ port->regshift = *prop;
+
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
port->type = type;
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Arnd Bergmann @ 2008-04-02 23:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, John Linn
In-Reply-To: <fa686aa40804021046n1bc0626ay6a3f9f2a251331ef@mail.gmail.com>
On Wednesday 02 April 2008, Grant Likely wrote:
> On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> > From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> >
> > =A0The of_serial driver queries the current-speed property and attempts
> > =A0to use it to register the custom_divisor property of the uart_port.
> > =A0However, if current-speed is not set, then this code will dereference
> > =A0a bad pointer. =A0The fix is to only set custom_divisor when a
> > =A0current-speed property appears in the device tree.
> >
> > =A0Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > =A0Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Arnd Bergmann @ 2008-04-02 23:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
In-Reply-To: <20080402232213.5D87515B8067@mail37-sin.bigfish.com>
On Thursday 03 April 2008, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
I may not be the best driver maintainer, but please keep the illusion
alive for me and Cc me on patches to drivers I wrote ;-)
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..4066ec8 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 but with
> + different register spacing and an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
Since it is not really compatible with ns16550, shouldn't you at least specify
a different "compatible" property? That way, the driver won't do incorrect
accesses when you try to use an old driver with a device tree that specifies
one of these.
> @@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
>
> spin_lock_init(&port->lock);
> port->mapbase = resource.start;
> +
> + /* Check for shifted address mapping */
> + prop = of_get_property(np, "reg-offset", &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + port->mapbase += *prop;
> +
> + /* Check for registers offset within the devices address range */
> + prop = of_get_property(np, "reg-shift", &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + port->regshift = *prop;
> +
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
This part looks good to me.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: David Gibson @ 2008-04-03 0:02 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.C835D1CF8088@mail12-sin.bigfish.com>
On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> arch/powerpc/boot/ns16550.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
Uh... how does the behaviour of reg-offset differ from just bumping
the address in "reg"?
--
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/~dgibson
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: John Bonesio @ 2008-04-03 0:31 UTC (permalink / raw)
To: Johann Baudy; +Cc: linuxppc-embedded, John Linn, git
In-Reply-To: <7e0dd21a0804020020s66a091ferfbbf4142adcd84ae@mail.gmail.com>
The change with the extra parenthesis (in the patch starting with line 133)=
seems unecessary. I looked at the XLlDma_mBdWrite macro and it appeared to=
have the correct use of parethesis in the implementation.
So, assuming there's nothing subtle that I missed, it's not needed. However=
, it does no harm either.
The rest of the patch seems fine.
=2D John
On Wednesday 02 April 2008 00:20, Johann Baudy wrote:
> I've solved this checksum offloading issue with this below patch.
> It may help, if you need performance. It certainly needs review but it wo=
rks
> on my side.
>=20
> --- xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c.orig 2008-03-=
21
> 09:11:43.000000000 +0100
> +++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c 2008-03-21
> 09:24:23.000000000 +0100
> @@ -133,7 +133,7 @@
> (XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
> 0xFFFFFFFE )
>=20
> #define BdCsumSetup(BdPtr, Start, Insert) \
> - XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
> (Insert))
> + XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
> (Insert))
>=20
> /* Used for debugging */
> #define BdCsumInsert(BdPtr) \
> @@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
> /*
> * if tx checksum offloading is enabled, when the ethernet stack
> * wants us to perform the checksum in hardware,
> - * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
> + * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
> * CHECKSUM_NONE, meaning the checksum is already done, or
> * CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
> * loopback interface)
> @@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
> * skb_transport_header(skb) points to the beginning of the ip header
> *
> */
> - if (skb->ip_summed =3D=3D CHECKSUM_COMPLETE) {
> + if (skb->ip_summed =3D=3D CHECKSUM_PARTIAL) {
> +
> + unsigned int csum_start_off =3D skb_transport_offset(skb);
> + unsigned int csum_index_off =3D csum_start_off + skb->csum_offse=
t;
>=20
> - unsigned char *raw =3D skb_transport_header(skb);
> #if 0
> {
> unsigned int csum =3D _xenet_tx_csum(skb);
> @@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
> }
> #else
> BdCsumEnable(bd_ptr);
> - BdCsumSetup(bd_ptr, raw - skb->data,
> - (raw - skb->data) + skb->csum);
> -
> + BdCsumSetup(bd_ptr, csum_start_off,
> + csum_index_off);
> #endif
> lp->tx_hw_csums++;
> }
> @@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
> struct resource *r_irq =3D &r_irq_struct; /* Interrupt resources =
*/
> struct resource *r_mem =3D &r_mem_struct; /* IO mem resources */
> struct xlltemac_platform_data *pdata =3D &pdata_struct;
> - void *mac_address;
> + const void *mac_address;
> int rc =3D 0;
> const phandle *llink_connected_handle;
> struct device_node *llink_connected_node;
>=20
>=20
> On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <mh@omnisys.se> wrote:
>=20
> > Deactivating checksum offloading helped a lot! I still have some packet
> > loss and not the best performance (TFTP transfer about 100 kbyte/s) but=
at
> > least it works.
> >
> > Thanks!
> >
> > //Magnus
> >
> > > -----Original Message-----
> > > From: rza1 [mailto:rza1@so-logic.net]
> > > Sent: den 31 mars 2008 11:14
> > > To: Magnus Hjorth
> > > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
> > > Subject: Re: Xilinx LLTEMAC driver issues
> > >
> > > Hi Magnus,
> > >
> > > 1.
> > > I am using nearly the same versions then you and got the same problems
> > > too ;-).
> > > I think there are some problems with the checksum offloading.
> > > Try to sniff the some packages (e.g. wireshark)...
> > > For me ICMP (ping) worked but udp and tcp not (because off a wrong
> > > checksum in the transport layer).
> > > A quick solution is to just deactivate checksum offloading.
> > >
> > > 2.
> > > I remember some problems with Virtex-4 presamples too.
> > > There where problems with the hard-temac wrapper. You had to use 1.00=
=2Ea
> > > and not b version.
> > > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
> > >
> > > all the best,
> > > Robert
> > >
> > > Magnus Hjorth wrote:
> > > > Hi John,
> > > >
> > > > Thanks for the very fast reply! Right now I'm not at work so I don't
> > > > have the board or EDK here to test anything.
> > > >
> > > > I'm using checksum offload, but I don't know if DRE is enabled or n=
ot.
> > I
> > > > can't recall seeing any setting to enable/disable DRE..
> > > >
> > > > A few things that crossed my mind:
> > > >
> > > > Last year I did a design with EDK 8.2, back then there was an issue
> > with
> > > > the ML403 boards having an old revision of the FPGA which wasn't
> > > > compatible with some versions of the IP core. There are no such
> > version
> > > > issues with the xps_ll_temac?
> > > >
> > > > I don't think that I had phy-addr set in the DTS file. Will test th=
at
> > on
> > > > Monday.
> > > >
> > > > Best regards,
> > > > Magnus
> > > >
> > > >
> > > > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
> > > >
> > > >> Hi Magnus,
> > > >>
> > > >> Sorry to hear you're having problems with it.
> > > >>
> > > >> I am doing testing on an ML405 which is the same board but with a
> > bigger
> > > FPGA, but with ppc arch and I don't see this issue. I have done limit=
ed
> > testing
> > > with powerpc arch and the LL TEMAC, but I didn't see this issue there
> > either.
> > > Powerpc arch is definitely less mature in my experience than the ppc
> > arch. I'll
> > > do a quick test with my powerpc arch and make sure again I'm not seei=
ng
> > it.
> > > >>
> > > >> My kernel is from the Xilinx Git tree, but there have been a number
> > of
> > > changes we have pushed out so I don't know how long ago you pulled fr=
om
> > the Git
> > > tree.
> > > >>
> > > >> My EDK project is 10.1 so it's a little newer. I am using LL TEMAC
> > 1.01a so
> > > it's a little newer. I reviewed the change log for the LL TEMAC and
> > don't see
> > > any big problems that were fixed in the newer versions, more new
> > features. I'll
> > > check with some others here to see if I missed something there.
> > > >>
> > > >> I am using DMA also, but no DRE or checksum offload. You didn't s=
ay
> > anything
> > > about those. I'm going to insert my mhs file that describes my system=
to
> > let you
> > > compare your system configuration. It's not clear to me yet if you ha=
ve
> > a h/w or
> > > s/w problem.
> > > >>
> > > >> I'll also insert some of my device tree with the LL TEMAC so you c=
an
> > compare
> > > (ignore 16550 stuff as we are still working on that).
> > > >>
> > > >> Since you can't ping reliably I would probably focus on that since
> > it's
> > > simpler than the other issues you're seeing.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >>
> > > >>
> > > >> #
> > >
> > #######################################################################=
#######
> > > >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1 Build
> > > EDK_K_SP1.1
> > > >> # Thu Feb 14 14:11:12 2008
> > > >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
> > > >> # Family: virtex4
> > > >> # Device: xc4vfx20
> > > >> # Package: ff672
> > > >> # Speed Grade: -10
> > > >> # Processor: ppc405_0
> > > >> # Processor clock frequency: 300.00 MHz
> > > >> # Bus clock frequency: 100.00 MHz
> > > >> # On Chip Memory : 8 KB
> > > >> # Total Off Chip Memory : 128 MB
> > > >> # - DDR_SDRAM =3D 128 MB
> > > >> #
> > >
> > #######################################################################=
#######
> > > >> PARAMETER VERSION =3D 2.1.0
> > > >>
> > > >>
> > > >> PORT fpga_0_RS232_Uart_sin_pin =3D fpga_0_RS232_Uart_sin, DIR =3D=
I
> > > >> PORT fpga_0_RS232_Uart_sout_pin =3D fpga_0_RS232_Uart_sout, DIR =
=3D O
> > > >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin =3D fpga_0_LEDs_4Bit_GPIO_IO, D=
IR =3D
> > IO, VEC
> > > =3D [0:3]
> > > >> PORT fpga_0_IIC_EEPROM_Scl_pin =3D fpga_0_IIC_EEPROM_Scl, DIR =3D=
IO
> > > >> PORT fpga_0_IIC_EEPROM_Sda_pin =3D fpga_0_IIC_EEPROM_Sda, DIR =3D=
IO
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR =3D I
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR =3D O, VEC =3D [6:1]
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR =3D IO, VEC =3D [15:0]
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR =3D O
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR =3D O
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR =3D O
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR =3D I
> > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin =3D fpga_0_DDR_SDRAM_DDR_Clk, D=
IR =3D
> > O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin =3D fpga_0_DDR_SDRAM_DDR_Clk_=
n,
> > DIR =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin =3D fpga_0_DDR_SDRAM_DDR_Addr,=
DIR
> > =3D O, VEC
> > > =3D [12:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =3D
> > fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
> > > =3D O, VEC =3D [1:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin =3D fpga_0_DDR_SDRAM_DDR_CAS_=
n,
> > DIR =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin =3D fpga_0_DDR_SDRAM_DDR_CE, DIR=
=3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin =3D fpga_0_DDR_SDRAM_DDR_CS_n,=
DIR
> > =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin =3D fpga_0_DDR_SDRAM_DDR_RAS_=
n,
> > DIR =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin =3D fpga_0_DDR_SDRAM_DDR_WE_n,=
DIR
> > =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin =3D fpga_0_DDR_SDRAM_DDR_DM, DIR=
=3D O,
> > VEC =3D
> > > [3:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_DQS =3D fpga_0_DDR_SDRAM_DDR_DQS, DIR =
=3D IO,
> > VEC =3D
> > > [3:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_DQ =3D fpga_0_DDR_SDRAM_DDR_DQ, DIR =3D=
IO,
> > VEC =3D
> > > [31:0]
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR =3D O, VEC =3D [7:0]
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR =3D I, VEC =3D [7:0]
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =3D
> > fpga_0_TriMode_MAC_GMII_MDIO_0,
> > > DIR =3D IO
> > > >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =3D
> > fpga_0_TriMode_MAC_GMII_MDC_0, DIR
> > > =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =3D
> > > fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR =3D O
> > > >> PORT sys_clk_pin =3D dcm_clk_s, DIR =3D I, SIGIS =3D CLK, CLK_FRE=
Q =3D
> > 100000000
> > > >> PORT sys_rst_pin =3D sys_rst_s, DIR =3D I, RST_POLARITY =3D 0, SI=
GIS =3D RST
> > > >>
> > > >>
> > > >> BEGIN ppc405_virtex4
> > > >> PARAMETER INSTANCE =3D ppc405_0
> > > >> PARAMETER HW_VER =3D 2.01.a
> > > >> PARAMETER C_FASTEST_PLB_CLOCK =3D DPLB1
> > > >> PARAMETER C_IDCR_BASEADDR =3D 0b0100000000
> > > >> PARAMETER C_IDCR_HIGHADDR =3D 0b0111111111
> > > >> BUS_INTERFACE JTAGPPC =3D jtagppc_0_0
> > > >> BUS_INTERFACE IPLB0 =3D plb
> > > >> BUS_INTERFACE DPLB0 =3D plb
> > > >> BUS_INTERFACE IPLB1 =3D ppc405_0_iplb1
> > > >> BUS_INTERFACE DPLB1 =3D ppc405_0_dplb1
> > > >> BUS_INTERFACE RESETPPC =3D ppc_reset_bus
> > > >> PORT CPMC405CLOCK =3D proc_clk_s
> > > >> PORT EICC405EXTINPUTIRQ =3D EICC405EXTINPUTIRQ
> > > >> END
> > > >>
> > > >> BEGIN jtagppc_cntlr
> > > >> PARAMETER INSTANCE =3D jtagppc_0
> > > >> PARAMETER HW_VER =3D 2.01.a
> > > >> BUS_INTERFACE JTAGPPC0 =3D jtagppc_0_0
> > > >> END
> > > >>
> > > >> BEGIN plb_v46
> > > >> PARAMETER INSTANCE =3D plb
> > > >> PARAMETER C_DCR_INTFCE =3D 0
> > > >> PARAMETER C_NUM_CLK_PLB2OPB_REARB =3D 100
> > > >> PARAMETER HW_VER =3D 1.02.a
> > > >> PORT PLB_Clk =3D sys_clk_s
> > > >> PORT SYS_Rst =3D sys_bus_reset
> > > >> END
> > > >>
> > > >> BEGIN xps_bram_if_cntlr
> > > >> PARAMETER INSTANCE =3D xps_bram_if_cntlr_1
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_SPLB_NATIVE_DWIDTH =3D 64
> > > >> PARAMETER C_BASEADDR =3D 0xffffe000
> > > >> PARAMETER C_HIGHADDR =3D 0xffffffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> BUS_INTERFACE PORTA =3D xps_bram_if_cntlr_1_port
> > > >> END
> > > >>
> > > >> BEGIN bram_block
> > > >> PARAMETER INSTANCE =3D plb_bram_if_cntlr_1_bram
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> BUS_INTERFACE PORTA =3D xps_bram_if_cntlr_1_port
> > > >> END
> > > >>
> > > >> BEGIN xps_uart16550
> > > >> PARAMETER INSTANCE =3D RS232_Uart
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_IS_A_16550 =3D 1
> > > >> PARAMETER C_BASEADDR =3D 0x83e00000
> > > >> PARAMETER C_HIGHADDR =3D 0x83e0ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT sin =3D fpga_0_RS232_Uart_sin
> > > >> PORT sout =3D fpga_0_RS232_Uart_sout
> > > >> PORT IP2INTC_Irpt =3D RS232_Uart_IP2INTC_Irpt
> > > >> END
> > > >>
> > > >> BEGIN xps_gpio
> > > >> PARAMETER INSTANCE =3D LEDs_4Bit
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_INTERRUPT_PRESENT =3D 1
> > > >> PARAMETER C_GPIO_WIDTH =3D 4
> > > >> PARAMETER C_IS_DUAL =3D 0
> > > >> PARAMETER C_IS_BIDIR =3D 1
> > > >> PARAMETER C_ALL_INPUTS =3D 0
> > > >> PARAMETER C_BASEADDR =3D 0x81400000
> > > >> PARAMETER C_HIGHADDR =3D 0x8140ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT GPIO_IO =3D fpga_0_LEDs_4Bit_GPIO_IO
> > > >> PORT IP2INTC_Irpt =3D LEDs_4Bit_IP2INTC_Irpt
> > > >> END
> > > >>
> > > >> BEGIN xps_iic
> > > >> PARAMETER INSTANCE =3D IIC_EEPROM
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_CLK_FREQ =3D 100000000
> > > >> PARAMETER C_IIC_FREQ =3D 100000
> > > >> PARAMETER C_TEN_BIT_ADR =3D 0
> > > >> PARAMETER C_BASEADDR =3D 0x81600000
> > > >> PARAMETER C_HIGHADDR =3D 0x8160ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT Scl =3D fpga_0_IIC_EEPROM_Scl
> > > >> PORT Sda =3D fpga_0_IIC_EEPROM_Sda
> > > >> PORT IIC2INTC_Irpt =3D IIC_EEPROM_IIC2INTC_Irpt
> > > >> END
> > > >>
> > > >> BEGIN xps_sysace
> > > >> PARAMETER INSTANCE =3D SysACE_CompactFlash
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_MEM_WIDTH =3D 16
> > > >> PARAMETER C_BASEADDR =3D 0x83600000
> > > >> PARAMETER C_HIGHADDR =3D 0x8360ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT SysACE_CLK =3D fpga_0_SysACE_CompactFlash_SysACE_CLK
> > > >> PORT SysACE_MPA =3D fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > > >> PORT SysACE_MPD =3D fpga_0_SysACE_CompactFlash_SysACE_MPD
> > > >> PORT SysACE_CEN =3D fpga_0_SysACE_CompactFlash_SysACE_CEN
> > > >> PORT SysACE_OEN =3D fpga_0_SysACE_CompactFlash_SysACE_OEN
> > > >> PORT SysACE_WEN =3D fpga_0_SysACE_CompactFlash_SysACE_WEN
> > > >> PORT SysACE_MPIRQ =3D fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
> > > >> PORT SysACE_IRQ =3D SysACE_CompactFlash_SysACE_IRQ
> > > >> END
> > > >>
> > > >> BEGIN mpmc
> > > >> PARAMETER INSTANCE =3D DDR_SDRAM
> > > >> PARAMETER HW_VER =3D 4.00.a
> > > >> PARAMETER C_NUM_PORTS =3D 3
> > > >> PARAMETER C_MEM_PARTNO =3D HYB25D512160BE-5
> > > >> PARAMETER C_MEM_DATA_WIDTH =3D 32
> > > >> PARAMETER C_MEM_DQS_WIDTH =3D 4
> > > >> PARAMETER C_MEM_DM_WIDTH =3D 4
> > > >> PARAMETER C_MEM_TYPE =3D DDR
> > > >> PARAMETER C_NUM_IDELAYCTRL =3D 2
> > > >> PARAMETER C_IDELAYCTRL_LOC =3D IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
> > > >> PARAMETER C_PIM0_BASETYPE =3D 2
> > > >> PARAMETER C_PIM1_BASETYPE =3D 2
> > > >> PARAMETER C_PIM2_BASETYPE =3D 3
> > > >> PARAMETER C_MPMC_CLK0_PERIOD_PS =3D 10000
> > > >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO =3D 1
> > > >> PARAMETER C_MPMC_BASEADDR =3D 0x00000000
> > > >> PARAMETER C_MPMC_HIGHADDR =3D 0x07ffffff
> > > >> PARAMETER C_SDMA_CTRL_BASEADDR =3D 0x84600000
> > > >> PARAMETER C_SDMA_CTRL_HIGHADDR =3D 0x8460ffff
> > > >> BUS_INTERFACE SPLB0 =3D ppc405_0_iplb1
> > > >> BUS_INTERFACE SPLB1 =3D ppc405_0_dplb1
> > > >> BUS_INTERFACE SDMA_LL2 =3D TriMode_MAC_GMII_LLINK0
> > > >> BUS_INTERFACE SDMA_CTRL2 =3D plb
> > > >> PORT DDR_Addr =3D fpga_0_DDR_SDRAM_DDR_Addr
> > > >> PORT DDR_BankAddr =3D fpga_0_DDR_SDRAM_DDR_BankAddr
> > > >> PORT DDR_CAS_n =3D fpga_0_DDR_SDRAM_DDR_CAS_n
> > > >> PORT DDR_CE =3D fpga_0_DDR_SDRAM_DDR_CE
> > > >> PORT DDR_CS_n =3D fpga_0_DDR_SDRAM_DDR_CS_n
> > > >> PORT DDR_RAS_n =3D fpga_0_DDR_SDRAM_DDR_RAS_n
> > > >> PORT DDR_WE_n =3D fpga_0_DDR_SDRAM_DDR_WE_n
> > > >> PORT DDR_DM =3D fpga_0_DDR_SDRAM_DDR_DM
> > > >> PORT DDR_DQS =3D fpga_0_DDR_SDRAM_DDR_DQS
> > > >> PORT DDR_DQ =3D fpga_0_DDR_SDRAM_DDR_DQ
> > > >> PORT DDR_Clk =3D fpga_0_DDR_SDRAM_DDR_Clk
> > > >> PORT DDR_Clk_n =3D fpga_0_DDR_SDRAM_DDR_Clk_n
> > > >> PORT MPMC_Clk0 =3D sys_clk_s
> > > >> PORT MPMC_Clk90 =3D DDR_SDRAM_mpmc_clk_90_s
> > > >> PORT SDMA2_Clk =3D sys_clk_s
> > > >> PORT MPMC_Clk_200MHz =3D clk_200mhz_s
> > > >> PORT MPMC_Rst =3D sys_periph_reset
> > > >> PORT SDMA2_Rx_IntOut =3D DDR_SDRAM_SDMA2_Rx_IntOut
> > > >> PORT SDMA2_Tx_IntOut =3D DDR_SDRAM_SDMA2_Tx_IntOut
> > > >> END
> > > >>
> > > >> BEGIN xps_ll_temac
> > > >> PARAMETER INSTANCE =3D TriMode_MAC_GMII
> > > >> PARAMETER HW_VER =3D 1.01.a
> > > >> PARAMETER C_SPLB_CLK_PERIOD_PS =3D 10000
> > > >> PARAMETER C_PHY_TYPE =3D 1
> > > >> PARAMETER C_NUM_IDELAYCTRL =3D 4
> > > >> PARAMETER C_IDELAYCTRL_LOC =3D IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
> > > IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
> > > >> PARAMETER C_TEMAC_TYPE =3D 1
> > > >> PARAMETER C_BUS2CORE_CLK_RATIO =3D 1
> > > >> PARAMETER C_BASEADDR =3D 0x81c00000
> > > >> PARAMETER C_HIGHADDR =3D 0x81c0ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> BUS_INTERFACE LLINK0 =3D TriMode_MAC_GMII_LLINK0
> > > >> PORT GMII_TXD_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TXD_0
> > > >> PORT GMII_TX_EN_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
> > > >> PORT GMII_TX_ER_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
> > > >> PORT GMII_TX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
> > > >> PORT GMII_RXD_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RXD_0
> > > >> PORT GMII_RX_DV_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
> > > >> PORT GMII_RX_ER_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
> > > >> PORT GMII_RX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
> > > >> PORT MII_TX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
> > > >> PORT MDIO_0 =3D fpga_0_TriMode_MAC_GMII_MDIO_0
> > > >> PORT MDC_0 =3D fpga_0_TriMode_MAC_GMII_MDC_0
> > > >> PORT TemacPhy_RST_n =3D fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
> > > >> PORT GTX_CLK_0 =3D temac_clk_s
> > > >> PORT REFCLK =3D clk_200mhz_s
> > > >> PORT LlinkTemac0_CLK =3D sys_clk_s
> > > >> PORT TemacIntc0_Irpt =3D TriMode_MAC_GMII_TemacIntc0_Irpt
> > > >> END
> > > >>
> > > >> BEGIN util_bus_split
> > > >> PARAMETER INSTANCE =3D SysACE_CompactFlash_util_bus_split_0
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_SIZE_IN =3D 7
> > > >> PARAMETER C_LEFT_POS =3D 0
> > > >> PARAMETER C_SPLIT =3D 6
> > > >> PORT Sig =3D fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > > >> PORT Out1 =3D fpga_0_SysACE_CompactFlash_SysACE_MPA
> > > >> END
> > > >>
> > > >> BEGIN plb_v46
> > > >> PARAMETER INSTANCE =3D ppc405_0_iplb1
> > > >> PARAMETER HW_VER =3D 1.02.a
> > > >> PORT PLB_Clk =3D sys_clk_s
> > > >> PORT SYS_Rst =3D sys_bus_reset
> > > >> END
> > > >>
> > > >> BEGIN plb_v46
> > > >> PARAMETER INSTANCE =3D ppc405_0_dplb1
> > > >> PARAMETER HW_VER =3D 1.02.a
> > > >> PORT PLB_Clk =3D sys_clk_s
> > > >> PORT SYS_Rst =3D sys_bus_reset
> > > >> END
> > > >>
> > > >> BEGIN clock_generator
> > > >> PARAMETER INSTANCE =3D clock_generator_0
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_EXT_RESET_HIGH =3D 1
> > > >> PARAMETER C_CLKIN_FREQ =3D 100000000
> > > >> PARAMETER C_CLKOUT0_FREQ =3D 100000000
> > > >> PARAMETER C_CLKOUT0_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT0_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT0_GROUP =3D DCM0
> > > >> PARAMETER C_CLKOUT1_FREQ =3D 100000000
> > > >> PARAMETER C_CLKOUT1_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT1_PHASE =3D 90
> > > >> PARAMETER C_CLKOUT1_GROUP =3D DCM0
> > > >> PARAMETER C_CLKOUT2_FREQ =3D 300000000
> > > >> PARAMETER C_CLKOUT2_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT2_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT2_GROUP =3D DCM0
> > > >> PARAMETER C_CLKOUT3_FREQ =3D 200000000
> > > >> PARAMETER C_CLKOUT3_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT3_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT3_GROUP =3D NONE
> > > >> PARAMETER C_CLKOUT4_FREQ =3D 125000000
> > > >> PARAMETER C_CLKOUT4_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT4_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT4_GROUP =3D NONE
> > > >> PORT CLKOUT0 =3D sys_clk_s
> > > >> PORT CLKOUT1 =3D DDR_SDRAM_mpmc_clk_90_s
> > > >> PORT CLKOUT2 =3D proc_clk_s
> > > >> PORT CLKOUT3 =3D clk_200mhz_s
> > > >> PORT CLKOUT4 =3D temac_clk_s
> > > >> PORT CLKIN =3D dcm_clk_s
> > > >> PORT LOCKED =3D Dcm_all_locked
> > > >> PORT RST =3D net_gnd
> > > >> END
> > > >>
> > > >> BEGIN proc_sys_reset
> > > >> PARAMETER INSTANCE =3D proc_sys_reset_0
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_EXT_RESET_HIGH =3D 0
> > > >> BUS_INTERFACE RESETPPC0 =3D ppc_reset_bus
> > > >> PORT Slowest_sync_clk =3D sys_clk_s
> > > >> PORT Dcm_locked =3D Dcm_all_locked
> > > >> PORT Ext_Reset_In =3D sys_rst_s
> > > >> PORT Bus_Struct_Reset =3D sys_bus_reset
> > > >> PORT Peripheral_Reset =3D sys_periph_reset
> > > >> END
> > > >>
> > > >> BEGIN xps_intc
> > > >> PARAMETER INSTANCE =3D xps_intc_0
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_BASEADDR =3D 0x81800000
> > > >> PARAMETER C_HIGHADDR =3D 0x8180ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT Irq =3D EICC405EXTINPUTIRQ
> > > >> PORT Intr =3D RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
> > > IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
> > > TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
> > > DDR_SDRAM_SDMA2_Tx_IntOut
> > > >> END
> > > >>
> > > >>
> > > >>
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,virtex";
> > > >> model =3D "testing";
> > > >> DDR_SDRAM: memory@0 {
> > > >> device_type =3D "memory";
> > > >> reg =3D < 0 8000000 >;
> > > >> } ;
> > > >> chosen {
> > > >> bootargs =3D "console=3DttyS0,9600 ip=3Don
> > > nfsroot=3D172.16.40.76:/v2pclients/jhl26,tcp";
> > > >> linux,stdout-path =3D "/plb@0/serial@83e00000";
> > > >> } ;
> > > >> cpus {
> > > >> #address-cells =3D <1>;
> > > >> #cpus =3D <1>;
> > > >> #size-cells =3D <0>;
> > > >> ppc405_0: cpu@0 {
> > > >> clock-frequency =3D <11e1a300>;
> > > >> compatible =3D "PowerPC,405", "ibm,ppc405";
> > > >> d-cache-line-size =3D <20>;
> > > >> d-cache-size =3D <4000>;
> > > >> device_type =3D "cpu";
> > > >> i-cache-line-size =3D <20>;
> > > >> i-cache-size =3D <4000>;
> > > >> model =3D "PowerPC,405";
> > > >> reg =3D <0>;
> > > >> timebase-frequency =3D <11e1a300>;
> > > >> xlnx,apu-control =3D <de00>;
> > > >> xlnx,apu-udi-1 =3D <a18983>;
> > > >> xlnx,apu-udi-2 =3D <a38983>;
> > > >> xlnx,apu-udi-3 =3D <a589c3>;
> > > >> xlnx,apu-udi-4 =3D <a789c3>;
> > > >> xlnx,apu-udi-5 =3D <a98c03>;
> > > >> xlnx,apu-udi-6 =3D <ab8c03>;
> > > >> xlnx,apu-udi-7 =3D <ad8c43>;
> > > >> xlnx,apu-udi-8 =3D <af8c43>;
> > > >> xlnx,deterministic-mult =3D <0>;
> > > >> xlnx,disable-operand-forwarding =3D <1>;
> > > >> xlnx,fastest-plb-clock =3D "DPLB0";
> > > >> xlnx,generate-plb-timespecs =3D <1>;
> > > >> xlnx,mmu-enable =3D <1>;
> > > >> xlnx,pvr-high =3D <0>;
> > > >> xlnx,pvr-low =3D <0>;
> > > >> } ;
> > > >> } ;
> > > >> plb: plb@0 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,plb-v46-1.02.a";
> > > >> ranges ;
> > > >> IIC_EEPROM: i2c@81600000 {
> > > >> compatible =3D "xlnx,xps-iic-2.00.a";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 4 2 >;
> > > >> reg =3D < 81600000 10000 >;
> > > >> xlnx,clk-freq =3D <5f5e100>;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,gpo-width =3D <1>;
> > > >> xlnx,iic-freq =3D <186a0>;
> > > >> xlnx,scl-inertial-delay =3D <0>;
> > > >> xlnx,sda-inertial-delay =3D <0>;
> > > >> xlnx,ten-bit-adr =3D <0>;
> > > >> } ;
> > > >> LEDs_4Bit: gpio@81400000 {
> > > >> compatible =3D "xlnx,xps-gpio-1.00.a";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 5 2 >;
> > > >> reg =3D < 81400000 10000 >;
> > > >> xlnx,all-inputs =3D <0>;
> > > >> xlnx,all-inputs-2 =3D <0>;
> > > >> xlnx,dout-default =3D <0>;
> > > >> xlnx,dout-default-2 =3D <0>;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,gpio-width =3D <4>;
> > > >> xlnx,interrupt-present =3D <1>;
> > > >> xlnx,is-bidir =3D <1>;
> > > >> xlnx,is-bidir-2 =3D <1>;
> > > >> xlnx,is-dual =3D <0>;
> > > >> xlnx,tri-default =3D <ffffffff>;
> > > >> xlnx,tri-default-2 =3D <ffffffff>;
> > > >> } ;
> > > >> RS232_Uart: serial@83e00000 {
> > > >> compatible =3D "xlnx,xps-uart16550-2.00.a";
> > > >> // compatible =3D "ns16550";
> > > >> device_type =3D "serial";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 6 2 >;
> > > >> reg =3D < 83e00000 10000 >;
> > > >> current-speed =3D <d#9600>;
> > > >> clock-frequency =3D <d#100000000>; /* added
> > > by jhl */
> > > >> reg-shift =3D <2>;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,has-external-rclk =3D <0>;
> > > >> xlnx,has-external-xin =3D <0>;
> > > >> xlnx,is-a-16550 =3D <1>;
> > > >> } ;
> > > >> SysACE_CompactFlash: sysace@83600000 {
> > > >> compatible =3D "xlnx,xps-sysace-1.00.a";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 3 2 >;
> > > >> reg =3D < 83600000 10000 >;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,mem-width =3D <10>;
> > > >> } ;
> > > >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,compound";
> > > >> ethernet@81c00000 {
> > > >> compatible =3D "xlnx,xps-ll-temac-
> > > 1.01.a";
> > > >> device_type =3D "network";
> > > >> interrupt-parent =3D
> > > <&xps_intc_0>;
> > > >> interrupts =3D < 2 2 >;
> > > >> llink-connected =3D <&PIM2>;
> > > >> local-mac-address =3D [ 02 00 00
> > > 00 00 01 ];
> > > >> reg =3D < 81c00000 40 >;
> > > >> xlnx,bus2core-clk-ratio =3D <1>;
> > > >> xlnx,phy-type =3D <1>;
> > > >> xlnx,phyaddr =3D <1>;
> > > >> xlnx,rxcsum =3D <0>;
> > > >> xlnx,rxfifo =3D <1000>;
> > > >> xlnx,temac-type =3D <1>;
> > > >> xlnx,txcsum =3D <0>;
> > > >> xlnx,txfifo =3D <1000>;
> > > >> } ;
> > > >> } ;
> > > >> mpmc@0 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,mpmc-4.00.a";
> > > >> PIM2: sdma@84600100 {
> > > >> compatible =3D "xlnx,ll-dma-
> > > 1.00.a";
> > > >> interrupt-parent =3D
> > > <&xps_intc_0>;
> > > >> interrupts =3D < 1 2 0 2 >;
> > > >> reg =3D < 84600100 80 >;
> > > >> } ;
> > > >> } ;
> > > >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
> > > >> compatible =3D "xlnx,xps-bram-if-cntlr-
> > > 1.00.a";
> > > >> reg =3D < ffffe000 2000 >;
> > > >> xlnx,family =3D "virtex4";
> > > >> } ;
> > > >> xps_intc_0: interrupt-controller@81800000 {
> > > >> #interrupt-cells =3D <2>;
> > > >> compatible =3D "xlnx,xps-intc-1.00.a";
> > > >> interrupt-controller ;
> > > >> reg =3D < 81800000 10000 >;
> > > >> xlnx,num-intr-inputs =3D <7>;
> > > >> } ;
> > > >> } ;
> > > >> ppc405_0_dplb1: plb@1 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,plb-v46-1.02.a";
> > > >> ranges ;
> > > >> } ;
> > > >> } ;
> > > >>
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: Magnus Hjorth [mailto:mh@omnisys.se]
> > > >> Sent: Saturday, March 29, 2008 6:54 AM
> > > >> To: git
> > > >> Cc: linuxppc-embedded@ozlabs.org
> > > >> Subject: Xilinx LLTEMAC driver issues
> > > >>
> > > >> Hi,
> > > >>
> > > >> I'm having some networking troubles with the Xilinx LLTEMAC driver
> > from the
> > > >> Xilinx Linux git tree (powerpc arch) on an ML403 board. EDK9.2SP2,
> > > >> xps_ll_temac v1.00.b
> > > >>
> > > >> The weird thing is, that it sort of half works. It successfully ma=
kes
> > a DHCP
> > > >> request and gets its IP address. I tried setting up a tftpd server,
> > and I can
> > > >> see UDP requests coming in but the response doesn't seem to come o=
ut.
> > I also
> > > >> tried running a TCP server on the board, and it can see and accept
> > incoming
> > > >> connections but after that no data seems to get through. I can ping
> > out and
> > > >> get around 40% packet loss.
> > > >>
> > > >> Looking at /proc/interrupts, I can see both TxDma interrupts and
> > RxDma
> > > >> interrupts. No eth0 interrupts but that seems to be OK judging by =
the
> > driver
> > > >> source comments. Ifconfig shows no collistions, no dropped packets,
> > no
> > > errors,
> > > >> so the system seems to think that everything is OK.
> > > >>
> > > >> Clues anyone? I'm starting to run out of ideas...
> > > >>
> > > >> Best regards,
> > > >> Magnus
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Magnus Hjorth, M.Sc.
> > > >> Omnisys Instruments AB
> > > >> Gruvgatan 8
> > > >> SE-421 30 V=C3=A4stra Fr=C3=B6lunda, SWEDEN
> > > >> Phone: +46 31 734 34 09
> > > >> Fax: +46 31 734 34 29
> > > >> http://www.omnisys.se
> > > >>
> > > >
> > > > _______________________________________________
> > > > Linuxppc-embedded mailing list
> > > > Linuxppc-embedded@ozlabs.org
> > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>=20
>=20
>=20
> --=20
> Johann Baudy
> johaahn@gmail.com
>=20
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 0:44 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel list, Kamalesh Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Balbir Singh
In-Reply-To: <20080402155247.5e746be7.akpm@linux-foundation.org>
On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
>
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> >
> > on powerpc,
> >
> > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > > > Andrew Morton wrote:
> > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > > > >
> > > > > >> Hi Andrew,
> > > > > >>
> > > > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > > > >>
> > > > > >> [ 0.000000] ------------[ cut here ]------------
> > > > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > > > >> [ 0.000000] Modules linked in:
> > > > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > > > >> [ 0.000000] Call Trace:
> > > > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > > > >> [ 0.000000] Instruction dump:
> > > > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > >
> > > mm-make-mem_map-allocation-continuous.patch
> > > and its friends in -mm.
> > >
> > > You have to call sparse_init_one_section() on each pmap and usemap
> > > as we allocate - since valid_section() depends on it (which is needed
> > > by vmemmap_populate() to check if the section is populated or not).
> > > On ppc, we need to call htab_bolted_mapping() on each section and
> > > we need to skip existing sections.
> > >
> > > These patches tried to group all allocations together and then later
> > > calls sparse_init_one_section() - which is not good :(
> >
> > so try to allocate usemap at first altogether.
>
> I have to turn all the above crud into a proper changelog. I'd prefer that
> you do it.
>
> Unless this patch should be folded into another one, in which case it
> doesn't matter.
>
>
> > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index d3cb085..782ebe5 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
>
> We shouldn't merge this patch on its own because then that will leave a
> non-bisectable region in the powerpc history.
>
> So which patch is this patch fixing? Lexically it applies to
> mm-allocate-section_map-for-sparse_init.patch (and its updates). But is
> that where it logically lies?
yes. we should fold
mm-make-mem_map-allocation-continuous.patch
mm-allocate-section_map-for-sparse_init.patch
and this one
to big one (not big really).
YH
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 0:47 UTC (permalink / raw)
To: Badari Pulavarty
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
Ingo Molnar, Balbir Singh
In-Reply-To: <1207180285.30407.45.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 4:51 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> > so try to allocate usemap at first altogether.
> >
> > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index d3cb085..782ebe5 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -294,7 +294,7 @@ void __init sparse_init(void)
> > unsigned long pnum;
> > struct page *map;
> > unsigned long *usemap;
> > - struct page **section_map;
> > + unsigned long **usemap_map;
> > int size;
> > int node;
> >
> > @@ -305,27 +305,31 @@ void __init sparse_init(void)
> > * make next 2M slip to one more 2M later.
> > * then in big system, the memmory will have a lot hole...
> > * here try to allocate 2M pages continously.
>
> Comments are x86-64 specific. On ppc its 16MB chunks :(
>
>
>
> > + *
> > + * powerpc hope to sparse_init_one_section right after each
> > + * sparse_early_mem_map_alloc, so allocate usemap_map
> > + * at first.
> > */
> > - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> > - section_map = alloc_bootmem(size);
> > - if (!section_map)
> > - panic("can not allocate section_map\n");
> > + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> > + usemap_map = alloc_bootmem(size);
> > + if (!usemap_map)
> > + panic("can not allocate usemap_map\n");
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> > - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> > + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> > }
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> >
> > - map = section_map[pnum];
> > + map = sparse_early_mem_map_alloc(pnum);
> > if (!map)
> > continue;
> >
> > - usemap = sparse_early_usemap_alloc(pnum);
> > + usemap = usemap_map[pnum];
> > if (!usemap)
> > continue;
>
> You may want to move this check before doing sparse_early_mem_map_alloc
> (). We are also not handling errors properly (freeing up the unused
> map or usemap) if we "continue". I know the original code is this way,
> but you touched it last :)
Yes. could avoid some leak...
YH
^ 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