* Re: [patch 12/13] powerpc: fix building without PCI
From: Paul Mackerras @ 2007-06-14 1:44 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <20070612163751.979776796@arndb.de>
arnd@arndb.de writes:
> Some code looks can be configured to be built without
> PCI support, but does not work properly.
I don't think it makes sense to build a chrp kernel without PCI. I
would rather just always select PCI for chrp rather than uglifying the
code with all those ifdefs.
Paul.
^ permalink raw reply
* Re: [patch 00/13] CPU selection Kconfig cleanup, take 3
From: Paul Mackerras @ 2007-06-14 1:46 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <20070612163016.253915076@arndb.de>
Most of this series of patches touch 8xxx or 5xxx stuff in one way or
another, so I'll leave it to Kumar to make the decision about them.
I'll put in 1/13.
Paul.
^ permalink raw reply
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Dave Liu @ 2007-06-14 2:31 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: 'linuxppc-dev Development'
In-Reply-To: <1181744529.30670.298.camel@gentoo-jocke.transmode.se>
On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> a Freescale 832x CPU gives me this:
> ifconfig eth2 up
> ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
> eth2: Cannot configure net device, aborting.
> SIOCSIFFLAGS: Cannot allocate memory
>
> This worked in 2.6.20
Could you print the MURAM memory usage for debug?
eg. start address and size.
-d
^ permalink raw reply
* Re: [patch 05/30] PS3: Use ioremap_flags
From: Takao Shinohara @ 2007-06-14 2:31 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, Masato Noguchi, Paul Mackerras, Arnd Bergmann,
linuxppc-dev
In-Reply-To: <466EE965.404@am.sony.com>
On 2007/06/13, at 3:43, Geoff Levand wrote:
> - spu->problem = ioremap(spu->problem_phys,
> - sizeof(struct spu_problem));
> + spu->problem = (__force void *)ioremap_flags(spu->problem_phys,
> + sizeof(struct spu_problem), _PAGE_NO_CACHE);
> +
> if (!spu->problem) {
> pr_debug("%s:%d: ioremap problem failed\n", __func__, __LINE__);
> goto fail_ioremap;
> }
>
> - spu->priv2 = ioremap(spu_pdata(spu)->priv2_addr,
> - sizeof(struct spu_priv2));
> + spu->priv2 = (__force void
> *)ioremap_flags(spu_pdata(spu)->priv2_addr,
> + sizeof(struct spu_priv2), _PAGE_NO_CACHE);
> +
> if (!spu->priv2) {
> pr_debug("%s:%d: ioremap priv2 failed\n", __func__, __LINE__);
> goto fail_ioremap;
spu->problem and spu->priv2 needs _PAGE_GUARDED, because they are
MMIO register region.
-- Takao Shinohara
^ permalink raw reply
* Re: New to ML-310
From: Grant Likely @ 2007-06-14 2:39 UTC (permalink / raw)
To: biovore; +Cc: linuxppc-dev
In-Reply-To: <200706132031.53942.biovore@biovore.net>
On 6/13/07, biovore <biovore@biovore.net> wrote:
> CC arch/ppc/syslib/xilinx_pic.o
> arch/ppc/syslib/xilinx_pic.c:30:5: warning: "XPAR_XINTC_USE_DCR" is not
> defined
> arch/ppc/syslib/xilinx_pic.c:121:5: warning: "XPAR_XINTC_USE_DCR" is not
> defined
> arch/ppc/syslib/xilinx_pic.c: In function 'ppc4xx_pic_init':
> arch/ppc/syslib/xilinx_pic.c:122: error: 'XPAR_INTC_0_BASEADDR' undeclared
> (first use in this function)
> arch/ppc/syslib/xilinx_pic.c:122: error: (Each undeclared identifier is
> reported only once
> arch/ppc/syslib/xilinx_pic.c:122: error: for each function it appears in.)
> arch/ppc/syslib/xilinx_pic.c:148: error: 'XPAR_INTC_0_KIND_OF_INTR' undeclared
> (first use in this function)
> make[1]: *** [arch/ppc/syslib/xilinx_pic.o] Error 1
> make: *** [arch/ppc/syslib] Error 2
>
> This to me looks like my xparameters.h file is missing something.. Any
> ideas?
Go into software settings, and set a driver for the intc core. (Or
you might be missing an interrupt controller entirely in your design)
BTW, I wouldn't bother with getting EDK to patch your kernel tree.
You're better off to generate the BSP into an empty directory and just
copy in your custom xparams file. The EDK patching is fragile if you
don't use exactly the right kernel version.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Are there any patches of temac driver for kernel 2.6.17 running on ML403?
From: angelalinyao @ 2007-06-14 3:06 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,all
I have run a MontaVista Preview kit which bases on kernel 2.6.17 on ML403 successfully.I compiled the kernel without LSP coverd because of PPC_OCP problem.Now I want to add network function but there is no temac driver in the kernel.I found some patches including temac driver but they all support kernel 2.6.20 or 2.6.21.
So,are there any patches including temac driver supporting kernel 2.6.17?Where can I find one?
Any help from you is appreciated.Thank you!
linyao
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-14 3:14 UTC (permalink / raw)
To: joakim.tjernlund, linuxppc-dev Development
In-Reply-To: <1181744529.30670.298.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Wednesday, June 13, 2007 10:22 PM
> To: 'linuxppc-dev Development'; Li Yang-r58472
> Subject: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> a Freescale 832x CPU gives me this:
> ifconfig eth2 up
> ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
> eth2: Cannot configure net device, aborting.
> SIOCSIFFLAGS: Cannot allocate memory
>=20
> This worked in 2.6.20
Hi Joakim,
Thanks for the bug report. The cause of this problem is that ucc_geth
is set to work in 1000Mbps mode. However, 8323 only supports 100Mbps.
1000Mbps mode consumes much more MURAM for virtual FIFO.
I will investigate this problem further, and see if a patch is needed.
- Leo
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-14 3:37 UTC (permalink / raw)
To: joakim.tjernlund, linuxppc-dev Development
> -----Original Message-----
> From: Li Yang-r58472
> Sent: Thursday, June 14, 2007 11:15 AM
> To: 'joakim.tjernlund@transmode.se'; 'linuxppc-dev Development'
> Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Wednesday, June 13, 2007 10:22 PM
> > To: 'linuxppc-dev Development'; Li Yang-r58472
> > Subject: ucc_geth DPRAM alloc error, 2.6.22-rc3
> >
> > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > a Freescale 832x CPU gives me this:
> > ifconfig eth2 up
> > ucc_geth_startup: Can not allocate DPRAM memory for
p_thread_data_tx.
> > eth2: Cannot configure net device, aborting.
> > SIOCSIFFLAGS: Cannot allocate memory
> >
> > This worked in 2.6.20
> Hi Joakim,
>=20
> Thanks for the bug report. The cause of this problem is that ucc_geth
is set to work in 1000Mbps mode. However, 8323 only supports
> 100Mbps. 1000Mbps mode consumes much more MURAM for virtual FIFO.
You can try adding the following property in your ucc node.
phy-connection-type =3D "mii"
- Leo
^ permalink raw reply
* Re: [PATCH] mpc5200: /dev/watchdog driver for GPT0
From: Kumar Gala @ 2007-06-14 3:57 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <20070612085931.GG23294@moe.telargo.com>
On Jun 12, 2007, at 3:59 AM, Domen Puncer wrote:
> Driver for internal mpc5200 watchdog on general purpose timer 0.
> For IPB clock of 132 MHz the maximum timeout is about 32 seconds.
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Should really be submitted to the watchdog maintainer if you want
this in the kernel
> ---
> Hi!
>
> I also have some generic GPT code that one could extend with
> what he/she needs. Mail me if you'd find it useful.
>
>
> drivers/char/watchdog/Kconfig | 4
> drivers/char/watchdog/Makefile | 1
> drivers/char/watchdog/mpc5200_wdt.c | 257 ++++++++++++++++++++++++
> ++++++++++++
> 3 files changed, 262 insertions(+)
>
> Index: work-powerpc.git/drivers/char/watchdog/Kconfig
> ===================================================================
> --- work-powerpc.git.orig/drivers/char/watchdog/Kconfig
> +++ work-powerpc.git/drivers/char/watchdog/Kconfig
> @@ -521,6 +521,10 @@ config 8xx_WDT
> tristate "MPC8xx Watchdog Timer"
> depends on 8xx
>
> +config MPC5200_WDT
> + tristate "MPC5200 Watchdog Timer"
> + depends on PPC_MPC52xx
> +
> config 83xx_WDT
> tristate "MPC83xx Watchdog Timer"
> depends on PPC_83xx
> Index: work-powerpc.git/drivers/char/watchdog/Makefile
> ===================================================================
> --- work-powerpc.git.orig/drivers/char/watchdog/Makefile
> +++ work-powerpc.git/drivers/char/watchdog/Makefile
> @@ -64,6 +64,7 @@ obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc
>
> # PowerPC Architecture
> obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
> +obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
> obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
> obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
> obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> Index: work-powerpc.git/drivers/char/watchdog/mpc5200_wdt.c
> ===================================================================
> --- /dev/null
> +++ work-powerpc.git/drivers/char/watchdog/mpc5200_wdt.c
> @@ -0,0 +1,257 @@
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/miscdevice.h>
> +#include <linux/watchdog.h>
> +#include <linux/io.h>
> +#include <asm/of_platform.h>
> +#include <asm/uaccess.h>
> +#include <asm/mpc52xx.h>
> +
> +
> +#define GPT_MODE_WDT (1<<15)
> +#define GPT_MODE_CE (1<<12)
> +#define GPT_MODE_MS_TIMER (0x4)
> +
> +
> +struct mpc5200_wdt {
> + unsigned count; /* timer ticks before watchdog kicks in */
> + long ipb_freq;
> + struct miscdevice miscdev;
> + struct resource mem;
> + struct mpc52xx_gpt __iomem *regs;
> + struct mpc52xx_gpt saved_regs;
saved_regs isn't used anywhere
[snip]
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: David Gibson @ 2007-06-14 4:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <791ab8b82c5b5d2b3ae4827a891a43ea@kernel.crashing.org>
On Wed, Jun 13, 2007 at 11:37:42AM +0200, Segher Boessenkool wrote:
> >> How do non-device-tree MTD users handle this?
> >
> > Invidual, board-specific map files with hardcoded partition tables.
>
> That's what I was afraid of. Sigh.
>
> > See drivers/mtd/maps/ebony.c for example.
>
> [/me looks...] Oh horror.
>
> > Hence my view of the device
> > tree as a preferable option.
>
> I think some binary partition table format that can be
> used by _all_ MTD consumers should be defined. How
> that table should be communicated to the kernel in the
> device tree case we can discuss later, then. Maybe
> something as simple as storing it in flash, and have a
> "partition-table-offset" property or something like that.
>
> This is something the MTD people will have to buy into
> of course.
I tought I saw some config option implying that there already existed
an on-device partition table format for flashes. Doesn't help us for
existing boards which don't expect such a setup, of course.
Incidentally, with either the partitions-described-by-properties, or
the revised more-flexible partitions-described-by-subnodes format, I'm
not seeing it as required that the whole of the flash address space be
described. So it would certainly be possible to *only* describe the
sections of the flash used by firmware. But I'm suggesting that we
optionally allow other partitions to be described for boards / systems
which have strong conventions about how the flash is divided and where
we don't have any other way of recording the partition layout short of
hardcoding.
--
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
* silicon motion sm502 or sm501
From: pete c @ 2007-06-14 5:22 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
im looing for a silicon motion sm501 or sm502
pci voyager gx demo board.
I saw a message of yours on a news group,
do you know where i can get one of these,
or do you have one i can buy from you?
thanks Pete.
____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
^ permalink raw reply
* [PATCH] Fix Kexec/Kdump for power6
From: Sachin P. Sant @ 2007-06-14 5:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
Paul, please consider the following patch for next merge.
Thanks
-Sachin
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
[-- Attachment #2: kexec-kdump-on-power6 --]
[-- Type: text/plain, Size: 3123 bytes --]
* On Power machines supporting VRMA, Kexec/Kdump does not work.
* Hypervisor stores VRMA mapping used by the OS, in the hpte hash tables.
* Make sure these hpte entries are left untouched.
*
* This patch also adds plpar_pte_read_raw() on the lines of
* plpar_pte_remove_raw().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
Signed-off-by : Mohan Kumar M <mohan@in.ibm.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
---
diff -Naurp old/arch/powerpc/platforms/pseries/lpar.c new/arch/powerpc/platforms/pseries/lpar.c
--- old/arch/powerpc/platforms/pseries/lpar.c 2007-06-05 06:27:25.000000000 +0530
+++ new/arch/powerpc/platforms/pseries/lpar.c 2007-06-07 15:28:07.000000000 +0530
@@ -373,12 +373,23 @@ static void pSeries_lpar_hptab_clear(voi
{
unsigned long size_bytes = 1UL << ppc64_pft_size;
unsigned long hpte_count = size_bytes >> 4;
- unsigned long dummy1, dummy2;
+ unsigned long dummy1, dummy2, dword0;
+ long lpar_rc;
int i;
/* TODO: Use bulk call */
- for (i = 0; i < hpte_count; i++)
- plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ for (i = 0; i < hpte_count; i++) {
+ /* dont remove HPTEs with VRMA mappings */
+ lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG,
+ &dummy1, &dummy2);
+ if (lpar_rc == H_NOT_FOUND) {
+ lpar_rc = plpar_pte_read_raw(0, i, &dword0, &dummy1);
+ if (!lpar_rc && ((dword0 & HPTE_V_VRMA_MASK)
+ != HPTE_V_VRMA_MASK))
+ /* Can be hpte for 1TB Seg. So remove it */
+ plpar_pte_remove_raw(0, i, 0, &dummy1, &dummy2);
+ }
+ }
}
/*
diff -Naurp old/arch/powerpc/platforms/pseries/plpar_wrappers.h new/arch/powerpc/platforms/pseries/plpar_wrappers.h
--- old/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-06-05 06:27:25.000000000 +0530
+++ new/arch/powerpc/platforms/pseries/plpar_wrappers.h 2007-06-07 15:28:07.000000000 +0530
@@ -108,6 +108,21 @@ static inline long plpar_pte_read(unsign
return rc;
}
+/* plpar_pte_read_raw can be called in real mode. It calls plpar_hcall_raw */
+static inline long plpar_pte_read_raw(unsigned long flags, unsigned long ptex,
+ unsigned long *old_pteh_ret, unsigned long *old_ptel_ret)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall_raw(H_READ, retbuf, flags, ptex);
+
+ *old_pteh_ret = retbuf[0];
+ *old_ptel_ret = retbuf[1];
+
+ return rc;
+}
+
static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex,
unsigned long avpn)
{
diff -Naurp old/include/asm-powerpc/mmu-hash64.h new/include/asm-powerpc/mmu-hash64.h
--- old/include/asm-powerpc/mmu-hash64.h 2007-06-05 06:27:25.000000000 +0530
+++ new/include/asm-powerpc/mmu-hash64.h 2007-06-07 15:28:46.000000000 +0530
@@ -94,6 +94,9 @@ extern char initial_stab[];
#define HPTE_R_C ASM_CONST(0x0000000000000080)
#define HPTE_R_R ASM_CONST(0x0000000000000100)
+#define HPTE_V_1TB_SEG ASM_CONST(0x4000000000000000)
+#define HPTE_V_VRMA_MASK ASM_CONST(0x4001ffffff000000)
+
/* Values for PP (assumes Ks=0, Kp=1) */
/* pp0 will always be 0 for linux */
#define PP_RWXX 0 /* Supervisor read/write, User none */
^ permalink raw reply
* Re: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Kumar Gala @ 2007-06-14 5:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus, linux-kernel, Zhang Wei-r63237
In-Reply-To: <59453d80f2f111b72e8f24e7b489c23e@kernel.crashing.org>
>> Some silicons of Freescale processor are the same RapidIO controller,
>> such as mpc8540/mpc8560 are the same (v0.0), mpc8548/mpc8641 are the
>> same (v1.0). For v1.0 RapidIO controller, should we use mpc8548 or
>> mpc8641? Those will make people confused.
>
> Not at all. On an 8641 it could be
>
> compatible = "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";
>
> which states "this is the 8641 thing and it is compatible
> to the 8548 thing". Perfectly clear.
The concern is this isn't just compatible = "..8641.." "..8548.." but
something like:
"..8641.." "..8641d.." "..8548.." "..8548e.." "..8543.." "..8543e.."
"..8572.." "..8572e.." "..8567.." "..8567e.." "..8568.." "..8568e.."
>> Using IP Block Revision is a
>> clear choice.
>
> I don't think so. For one thing, it describes a version of
> a cell design, not a version of an actual device. For another
> thing, if I hear "8641" I know what you're talking about (sort
> of, anyway), but I draw a blank stare if you say "v1.0". I'm
> sure I'm not the only one. Concrete names are good.
While I agree concrete names are good, we put these 'blocks' in so
many devices that using the device to match on is pointless.
I'm all for making up a name like 'Grande', 'Del', 'Janeiro'. This
is effective what we did with gianfar. The name gets picked up
pretty quickly by people.
- k
^ permalink raw reply
* Re: opb_ethernet driver
From: Grant Likely @ 2007-06-14 6:13 UTC (permalink / raw)
To: xu chen, linuxppc-dev
In-Reply-To: <20070612034522.GA4198@localhost.localdomain>
On 6/11/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Jun 11, 2007 at 10:37:55AM +0800, xu chen wrote:
> > Hello.
> > I'm porting an opb_ethernet driver to my ml403 board now, using the 2.6.17 kernel. I know the ethernet support 3 mode: No DMA, simple DMA, scatter gather DMA, when I use the No DMA mode, we can write the skb into the FIFO, but can't ping other PCs in the network. When I use the simple DMA mode, at the time of ping, in the driver, we should initialize the DMA channel, but when transfering the skb, the DMA returns a "DMA bus time out" signal.
> > Now I'm worry about it. Who had encountered the problem before? I think I need some help.
>
> What's an opb_ethernet?
In this context, it's a Xilinx Ethernet IP core implemented in an FPGA
and connected to the OPB bus.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Joakim Tjernlund @ 2007-06-14 7:03 UTC (permalink / raw)
To: Dave Liu; +Cc: 'linuxppc-dev Development'
In-Reply-To: <1181788277.3658.1.camel@localhost.localdomain>
On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > a Freescale 832x CPU gives me this:
> > ifconfig eth2 up
> > ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
> > eth2: Cannot configure net device, aborting.
> > SIOCSIFFLAGS: Cannot allocate memory
> >
> > This worked in 2.6.20
>
> Could you print the MURAM memory usage for debug?
> eg. start address and size.
>
> -d
Like this?
eth1:
MURAM alloc, start:1400, size:512, align:8
MURAM alloc, start:1608, size:520, align:8
MURAM alloc, start:1880, size:128, align:128
MURAM alloc, start:1a00, size:416, align:256
MURAM alloc, start:1bc0, size:64, align:32
MURAM alloc, start:1d00, size:256, align:256
MURAM alloc, start:1f00, size:160, align:256
MURAM alloc, start:1fc0, size:12, align:64
MURAM alloc, start:2000, size:48, align:8
MURAM alloc, start:2080, size:128, align:128
MURAM alloc, start:2180, size:128, align:128
MURAM alloc, start:2280, size:128, align:128
MURAM alloc, start:2380, size:128, align:128
MURAM alloc, start:2440, size:64, align:64
MURAM alloc, start:24c0, size:64, align:64
MURAM alloc, start:2540, size:64, align:64
MURAM alloc, start:25c0, size:64, align:64
MURAM alloc, start:262c, size:93, align:4
eth0:
MURAM alloc, start:2630, size:512, align:8
MURAM alloc, start:2838, size:520, align:8
MURAM alloc, start:2a80, size:128, align:128
MURAM alloc, start:2c00, size:416, align:256
MURAM alloc, start:2de0, size:64, align:32
MURAM alloc, start:2f00, size:256, align:256
MURAM alloc, start:3100, size:160, align:256
MURAM alloc, start:3200, size:12, align:64
MURAM alloc, start:3228, size:48, align:8
MURAM alloc, start:3280, size:128, align:128
MURAM alloc, start:3380, size:128, align:128
MURAM alloc, start:3480, size:128, align:128
MURAM alloc, start:3580, size:128, align:128
MURAM alloc, start:3680, size:64, align:64
MURAM alloc, start:3700, size:64, align:64
MURAM alloc, start:3780, size:64, align:64
MURAM alloc, start:3800, size:64, align:64
MURAM alloc, start:3858, size:93, align:4
eth2:
MURAM alloc, start:3858, size:512, align:8
MURAM alloc, start:3a60, size:520, align:8
MURAM alloc, start:3c80, size:128, align:128
MURAM alloc, start:fffffff4, size:416, align:256
Jocke
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Joakim Tjernlund @ 2007-06-14 7:04 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development
In-Reply-To: <989B956029373F45A0B8AF0297081890D2AD35@zch01exm26.fsl.freescale.net>
On Thu, 2007-06-14 at 11:37 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Li Yang-r58472
> > Sent: Thursday, June 14, 2007 11:15 AM
> > To: 'joakim.tjernlund@transmode.se'; 'linuxppc-dev Development'
> > Subject: RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
> >
> > > -----Original Message-----
> > > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > > Sent: Wednesday, June 13, 2007 10:22 PM
> > > To: 'linuxppc-dev Development'; Li Yang-r58472
> > > Subject: ucc_geth DPRAM alloc error, 2.6.22-rc3
> > >
> > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > a Freescale 832x CPU gives me this:
> > > ifconfig eth2 up
> > > ucc_geth_startup: Can not allocate DPRAM memory for
> p_thread_data_tx.
> > > eth2: Cannot configure net device, aborting.
> > > SIOCSIFFLAGS: Cannot allocate memory
> > >
> > > This worked in 2.6.20
> > Hi Joakim,
> >
> > Thanks for the bug report. The cause of this problem is that ucc_geth
> is set to work in 1000Mbps mode. However, 8323 only supports
> > 100Mbps. 1000Mbps mode consumes much more MURAM for virtual FIFO.
>
>
> You can try adding the following property in your ucc node.
> phy-connection-type = "mii"
Tried that and it failed too.
Jocke
^ permalink raw reply
* Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Joakim Tjernlund @ 2007-06-14 7:17 UTC (permalink / raw)
To: Dave Liu; +Cc: 'linuxppc-dev Development'
In-Reply-To: <1181804588.30670.344.camel@gentoo-jocke.transmode.se>
On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > a Freescale 832x CPU gives me this:
> > > ifconfig eth2 up
> > > ucc_geth_startup: Can not allocate DPRAM memory for p_thread_data_tx.
> > > eth2: Cannot configure net device, aborting.
> > > SIOCSIFFLAGS: Cannot allocate memory
> > >
> > > This worked in 2.6.20
> >
> > Could you print the MURAM memory usage for debug?
> > eg. start address and size.
> >
> > -d
>
> Like this?
redid with all hex, decimal within()
MURAM alloc, start:1400, size:200(512), align:8(8)
MURAM alloc, start:1608, size:208(520), align:8(8)
MURAM alloc, start:1880, size:80(128), align:80(128)
MURAM alloc, start:1a00, size:1a0(416), align:100(256)
MURAM alloc, start:1bc0, size:40(64), align:20(32)
MURAM alloc, start:1d00, size:100(256), align:100(256)
MURAM alloc, start:1f00, size:a0(160), align:100(256)
MURAM alloc, start:1fc0, size:c(12), align:40(64)
MURAM alloc, start:2000, size:30(48), align:8(8)
MURAM alloc, start:2080, size:80(128), align:80(128)
MURAM alloc, start:2180, size:80(128), align:80(128)
MURAM alloc, start:2280, size:80(128), align:80(128)
MURAM alloc, start:2380, size:80(128), align:80(128)
MURAM alloc, start:2440, size:40(64), align:40(64)
MURAM alloc, start:24c0, size:40(64), align:40(64)
MURAM alloc, start:2540, size:40(64), align:40(64)
MURAM alloc, start:25c0, size:40(64), align:40(64)
MURAM alloc, start:262c, size:5d(93), align:4(4)
MURAM alloc, start:2630, size:200(512), align:8(8)
MURAM alloc, start:2838, size:208(520), align:8(8)
MURAM alloc, start:2a80, size:80(128), align:80(128)
MURAM alloc, start:2c00, size:1a0(416), align:100(256)
MURAM alloc, start:2de0, size:40(64), align:20(32)
MURAM alloc, start:2f00, size:100(256), align:100(256)
MURAM alloc, start:3100, size:a0(160), align:100(256)
MURAM alloc, start:3200, size:c(12), align:40(64)
MURAM alloc, start:3228, size:30(48), align:8(8)
MURAM alloc, start:3280, size:80(128), align:80(128)
MURAM alloc, start:3380, size:80(128), align:80(128)
MURAM alloc, start:3480, size:80(128), align:80(128)
MURAM alloc, start:3580, size:80(128), align:80(128)
MURAM alloc, start:3680, size:40(64), align:40(64)
MURAM alloc, start:3700, size:40(64), align:40(64)
MURAM alloc, start:3780, size:40(64), align:40(64)
MURAM alloc, start:3800, size:40(64), align:40(64)
MURAM alloc, start:3858, size:5d(93), align:4(4)
MURAM alloc, start:3858, size:200(512), align:8(8)
MURAM alloc, start:3a60, size:208(520), align:8(8)
MURAM alloc, start:3c80, size:80(128), align:80(128)
MURAM alloc, start:fffffff4, size:1a0(416), align:100(256)
some comments:
With these aligments, won't you waste alot of MURAM?
Looking at the 2 first allocs:
MURAM alloc, start:1400, size:200(512), align:8(8)
MURAM alloc, start:1608, size:208(520), align:8(8)
shouldn't the second alloc have 0x1600 as start address?
Jocke
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-14 7:26 UTC (permalink / raw)
To: joakim.tjernlund, Liu Dave-r63238; +Cc: linuxppc-dev Development
In-Reply-To: <1181805466.30670.352.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On Behalf
Of
> Joakim Tjernlund
> Sent: Thursday, June 14, 2007 3:18 PM
> To: Liu Dave-r63238
> Cc: 'linuxppc-dev Development'
> Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > a Freescale 832x CPU gives me this:
> > > > ifconfig eth2 up
> > > > ucc_geth_startup: Can not allocate DPRAM memory for
p_thread_data_tx.
> > > > eth2: Cannot configure net device, aborting.
> > > > SIOCSIFFLAGS: Cannot allocate memory
> > > >
> > > > This worked in 2.6.20
> > >
> > > Could you print the MURAM memory usage for debug?
> > > eg. start address and size.
> > >
> > > -d
> >
> > Like this?
>=20
> redid with all hex, decimal within()
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> MURAM alloc, start:1880, size:80(128), align:80(128)
> MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> MURAM alloc, start:1bc0, size:40(64), align:20(32)
> MURAM alloc, start:1d00, size:100(256), align:100(256)
> MURAM alloc, start:1f00, size:a0(160), align:100(256)
> MURAM alloc, start:1fc0, size:c(12), align:40(64)
> MURAM alloc, start:2000, size:30(48), align:8(8)
> MURAM alloc, start:2080, size:80(128), align:80(128)
> MURAM alloc, start:2180, size:80(128), align:80(128)
> MURAM alloc, start:2280, size:80(128), align:80(128)
> MURAM alloc, start:2380, size:80(128), align:80(128)
> MURAM alloc, start:2440, size:40(64), align:40(64)
> MURAM alloc, start:24c0, size:40(64), align:40(64)
> MURAM alloc, start:2540, size:40(64), align:40(64)
> MURAM alloc, start:25c0, size:40(64), align:40(64)
> MURAM alloc, start:262c, size:5d(93), align:4(4)
Looks like you are using virtual FIFO for 100Mbps.
> some comments:
>=20
> With these aligments, won't you waste alot of MURAM?
>=20
> Looking at the 2 first allocs:
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> shouldn't the second alloc have 0x1600 as start address?
This looks like a bug of rheap. The main problem is that at system
startup phase, there is an allocation of size 0x400,align 0x1000.
The rheap starts to allocate next buffer from 0x1400, instead of 0x400.
- Leo
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-14 7:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <1181774801.14818.343.camel@localhost.localdomain>
> No name for the root of the DT.
See my previous mail.
> IMHO, model can be whatever he wants, I would say SonyPS3-XX or
> something like that, whatever, doens't matter, the most precise the
> better.
It should be the model number of the machine.
> Then you want compatible which is the really important one. sony,ps3
> looks good to me for that, though you could have a list if you wanted.
"compatible" is only needed if your "name" is bogus, or your
machine _actually_ is 100% compatible to some other machine.
Segher
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-14 7:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Olaf Hering, paulus
In-Reply-To: <1181774580.14818.337.camel@localhost.localdomain>
>> It should include "sony,", in the "name" property at least.
>>
>> "model" same as "name" cannot make sense either.
>
> Dunno what you are on about the model vs. name but this is the root of
> the DT, it has no name.
Please review the OF spec, sections 3.4 and the "/" entry
of 3.5.
I'f the flat device tree doc and/or code says differently
here, that is a bug.
Segher
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Li Yang-r58472 @ 2007-06-14 7:37 UTC (permalink / raw)
To: joakim.tjernlund, Liu Dave-r63238; +Cc: linuxppc-dev Development
In-Reply-To: <1181805466.30670.352.camel@gentoo-jocke.transmode.se>
Try remove the following lines in rheap.c
/* given alignment larger that default rheap alignment */
if (alignment > info->alignment)
size +=3D alignment - 1;
I don't know if this breaks other things, just have a try.
- Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On Behalf
Of
> Joakim Tjernlund
> Sent: Thursday, June 14, 2007 3:18 PM
> To: Liu Dave-r63238
> Cc: 'linuxppc-dev Development'
> Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
>=20
> On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > a Freescale 832x CPU gives me this:
> > > > ifconfig eth2 up
> > > > ucc_geth_startup: Can not allocate DPRAM memory for
p_thread_data_tx.
> > > > eth2: Cannot configure net device, aborting.
> > > > SIOCSIFFLAGS: Cannot allocate memory
> > > >
> > > > This worked in 2.6.20
> > >
> > > Could you print the MURAM memory usage for debug?
> > > eg. start address and size.
> > >
> > > -d
> >
> > Like this?
>=20
> redid with all hex, decimal within()
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> MURAM alloc, start:1880, size:80(128), align:80(128)
> MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> MURAM alloc, start:1bc0, size:40(64), align:20(32)
> MURAM alloc, start:1d00, size:100(256), align:100(256)
> MURAM alloc, start:1f00, size:a0(160), align:100(256)
> MURAM alloc, start:1fc0, size:c(12), align:40(64)
> MURAM alloc, start:2000, size:30(48), align:8(8)
> MURAM alloc, start:2080, size:80(128), align:80(128)
> MURAM alloc, start:2180, size:80(128), align:80(128)
> MURAM alloc, start:2280, size:80(128), align:80(128)
> MURAM alloc, start:2380, size:80(128), align:80(128)
> MURAM alloc, start:2440, size:40(64), align:40(64)
> MURAM alloc, start:24c0, size:40(64), align:40(64)
> MURAM alloc, start:2540, size:40(64), align:40(64)
> MURAM alloc, start:25c0, size:40(64), align:40(64)
> MURAM alloc, start:262c, size:5d(93), align:4(4)
>=20
> MURAM alloc, start:2630, size:200(512), align:8(8)
> MURAM alloc, start:2838, size:208(520), align:8(8)
> MURAM alloc, start:2a80, size:80(128), align:80(128)
> MURAM alloc, start:2c00, size:1a0(416), align:100(256)
> MURAM alloc, start:2de0, size:40(64), align:20(32)
> MURAM alloc, start:2f00, size:100(256), align:100(256)
> MURAM alloc, start:3100, size:a0(160), align:100(256)
> MURAM alloc, start:3200, size:c(12), align:40(64)
> MURAM alloc, start:3228, size:30(48), align:8(8)
> MURAM alloc, start:3280, size:80(128), align:80(128)
> MURAM alloc, start:3380, size:80(128), align:80(128)
> MURAM alloc, start:3480, size:80(128), align:80(128)
> MURAM alloc, start:3580, size:80(128), align:80(128)
> MURAM alloc, start:3680, size:40(64), align:40(64)
> MURAM alloc, start:3700, size:40(64), align:40(64)
> MURAM alloc, start:3780, size:40(64), align:40(64)
> MURAM alloc, start:3800, size:40(64), align:40(64)
> MURAM alloc, start:3858, size:5d(93), align:4(4)
>=20
> MURAM alloc, start:3858, size:200(512), align:8(8)
> MURAM alloc, start:3a60, size:208(520), align:8(8)
> MURAM alloc, start:3c80, size:80(128), align:80(128)
> MURAM alloc, start:fffffff4, size:1a0(416), align:100(256)
>=20
> some comments:
>=20
> With these aligments, won't you waste alot of MURAM?
>=20
> Looking at the 2 first allocs:
> MURAM alloc, start:1400, size:200(512), align:8(8)
> MURAM alloc, start:1608, size:208(520), align:8(8)
> shouldn't the second alloc have 0x1600 as start address?
>=20
> Jocke
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 29/30] PS3: Device tree source.
From: Segher Boessenkool @ 2007-06-14 7:39 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <46709A84.7030307@am.sony.com>
> I will use model = "SonyPS3";
Okie.
>>> + compatible = "PS3";
>>
>> name = "sony,ps3"
>
>
> As Ben H. said, the top level 'name' cannot be set,
Bug in the flat device tree stuff.
> and
> I found dtc exits with an error if you include one.
>
> The compatible entry is generally used to test for machine
> type, so I think that needs to remain, and I will use
> compatible = "sony,ps3".
"compatible" is a set of alternates for "name", so you can
use it if you have to.
>>> + * Need to keep linux,platform for a while, not used by kernel.
>>> + */
>>
>> Why that?
>
> Newer dtc seems to be OK with this removed, old ones exited with error.
Ok. So you'll remove it?
>>> + CBE,PPE {
>>
>> PowerPC,CBE@0 or cpu@0 -- the important thing is you need
>> the @0 unit address.
>
> OK, I set it up as cpu@0, since the actual type seems to be probed for.
PowerPC CPUs have a defined way of identifying themselves
exactly, and this PVR value is supposed to be in the
device tree too (although Linux probes it directly from
the CPU). You could still put the name in the "compatible"
property, but CPU nodes are a bit special, I don't think
that would gain anything.
>>> + d-cache-size = <8000>;
>>
>> I thought DL1 was 64kB, I might be wrong though?
>
> The BE handbook says 32.
Ok, good.
Segher
^ permalink raw reply
* Re: [PATCH 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
From: Segher Boessenkool @ 2007-06-14 7:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, paulus, linux-kernel, Zhang Wei-r63237
In-Reply-To: <CF39A363-25C6-4780-96EC-6750D77C287F@kernel.crashing.org>
>> Not at all. On an 8641 it could be
>>
>> compatible = "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";
>>
>> which states "this is the 8641 thing and it is compatible
>> to the 8548 thing". Perfectly clear.
>
> The concern is this isn't just compatible = "..8641.." "..8548.." but
> something like:
>
> "..8641.." "..8641d.." "..8548.." "..8548e.." "..8543.." "..8543e.."
> "..8572.." "..8572e.." "..8567.." "..8567e.." "..8568.." "..8568e.."
You don't need to mention _all_ compatible devices in
the "compatible" property, only the few that matter;
typically the oldest one, and sometimes some intermediate
device that has extra features over the original one.
It isn't useful to add "compatible" entries that no OS
probes for.
>> Concrete names are good.
>
> While I agree concrete names are good, we put these 'blocks' in so
> many devices that using the device to match on is pointless.
You *definitely* should put the device name for _this_
device in there, in case it needs some special workaround.
> I'm all for making up a name like 'Grande', 'Del', 'Janeiro'. This is
> effective what we did with gianfar. The name gets picked up pretty
> quickly by people.
That can be used as the "base" name, yes.
Segher
^ permalink raw reply
* RE: ucc_geth DPRAM alloc error, 2.6.22-rc3
From: Joakim Tjernlund @ 2007-06-14 7:54 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev Development, Liu Dave-r63238
In-Reply-To: <989B956029373F45A0B8AF0297081890D2ADB4@zch01exm26.fsl.freescale.net>
On Thu, 2007-06-14 at 15:37 +0800, Li Yang-r58472 wrote:
> Try remove the following lines in rheap.c
>
> /* given alignment larger that default rheap alignment */
> if (alignment > info->alignment)
> size += alignment - 1;
>
> I don't know if this breaks other things, just have a try.
I did and got this alloc:
MURAM alloc, start:400, size:200(512), align:8(8)
MURAM alloc, start:600, size:208(520), align:8(8)
MURAM alloc, start:880, size:80(128), align:80(128)
MURAM alloc, start:900, size:1a0(416), align:100(256)
MURAM alloc, start:a40, size:40(64), align:20(32)
MURAM alloc, start:b00, size:100(256), align:100(256)
MURAM alloc, start:c00, size:a0(160), align:100(256)
MURAM alloc, start:c40, size:c(12), align:40(64)
MURAM alloc, start:c18, size:30(48), align:8(8)
MURAM alloc, start:c80, size:80(128), align:80(128)
MURAM alloc, start:d00, size:80(128), align:80(128)
MURAM alloc, start:d80, size:80(128), align:80(128)
MURAM alloc, start:e00, size:80(128), align:80(128)
MURAM alloc, start:e80, size:40(64), align:40(64)
MURAM alloc, start:ec0, size:40(64), align:40(64)
MURAM alloc, start:f00, size:40(64), align:40(64)
MURAM alloc, start:f40, size:40(64), align:40(64)
MURAM alloc, start:f44, size:5d(93), align:4(4)
MURAM alloc, start:f48, size:200(512), align:8(8)
MURAM alloc, start:1148, size:208(520), align:8(8)
MURAM alloc, start:1380, size:80(128), align:80(128)
MURAM alloc, start:1400, size:1a0(416), align:100(256)
MURAM alloc, start:1580, size:40(64), align:20(32)
MURAM alloc, start:1600, size:100(256), align:100(256)
MURAM alloc, start:1700, size:a0(160), align:100(256)
MURAM alloc, start:1780, size:c(12), align:40(64)
MURAM alloc, start:1758, size:30(48), align:8(8)
MURAM alloc, start:1800, size:80(128), align:80(128)
MURAM alloc, start:1880, size:80(128), align:80(128)
MURAM alloc, start:1900, size:80(128), align:80(128)
MURAM alloc, start:1980, size:80(128), align:80(128)
MURAM alloc, start:19c0, size:40(64), align:40(64)
MURAM alloc, start:1a00, size:40(64), align:40(64)
MURAM alloc, start:1a40, size:40(64), align:40(64)
MURAM alloc, start:1a80, size:40(64), align:40(64)
MURAM alloc, start:1a88, size:5d(93), align:4(4)
MURAM alloc, start:1a88, size:200(512), align:8(8)
MURAM alloc, start:1c88, size:208(520), align:8(8)
MURAM alloc, start:1f00, size:80(128), align:80(128)
MURAM alloc, start:2000, size:1a0(416), align:100(256)
MURAM alloc, start:20c0, size:40(64), align:20(32)
MURAM alloc, start:2100, size:100(256), align:100(256)
MURAM alloc, start:2200, size:a0(160), align:100(256)
MURAM alloc, start:22c0, size:c(12), align:40(64)
MURAM alloc, start:22a0, size:30(48), align:8(8)
MURAM alloc, start:2300, size:80(128), align:80(128)
MURAM alloc, start:2380, size:80(128), align:80(128)
MURAM alloc, start:2400, size:80(128), align:80(128)
MURAM alloc, start:2480, size:80(128), align:80(128)
MURAM alloc, start:2500, size:40(64), align:40(64)
MURAM alloc, start:2540, size:40(64), align:40(64)
MURAM alloc, start:2580, size:40(64), align:40(64)
MURAM alloc, start:25c0, size:40(64), align:40(64)
MURAM alloc, start:25cc, size:5d(93), align:4(4)
But I can't ping anymore
>
> - Leo
>
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf
> Of
> > Joakim Tjernlund
> > Sent: Thursday, June 14, 2007 3:18 PM
> > To: Liu Dave-r63238
> > Cc: 'linuxppc-dev Development'
> > Subject: Re: ucc_geth DPRAM alloc error, 2.6.22-rc3
> >
> > On Thu, 2007-06-14 at 09:03 +0200, Joakim Tjernlund wrote:
> > > On Thu, 2007-06-14 at 10:31 +0800, Dave Liu wrote:
> > > > On Wed, 2007-06-13 at 16:22 +0200, Joakim Tjernlund wrote:
> > > > > Trying to bring up a third ethernet i/f(ifconfig eth2 up) on
> > > > > a Freescale 832x CPU gives me this:
> > > > > ifconfig eth2 up
> > > > > ucc_geth_startup: Can not allocate DPRAM memory for
> p_thread_data_tx.
> > > > > eth2: Cannot configure net device, aborting.
> > > > > SIOCSIFFLAGS: Cannot allocate memory
> > > > >
> > > > > This worked in 2.6.20
> > > >
> > > > Could you print the MURAM memory usage for debug?
> > > > eg. start address and size.
> > > >
> > > > -d
> > >
> > > Like this?
> >
> > redid with all hex, decimal within()
> > MURAM alloc, start:1400, size:200(512), align:8(8)
> > MURAM alloc, start:1608, size:208(520), align:8(8)
> > MURAM alloc, start:1880, size:80(128), align:80(128)
> > MURAM alloc, start:1a00, size:1a0(416), align:100(256)
> > MURAM alloc, start:1bc0, size:40(64), align:20(32)
> > MURAM alloc, start:1d00, size:100(256), align:100(256)
> > MURAM alloc, start:1f00, size:a0(160), align:100(256)
> > MURAM alloc, start:1fc0, size:c(12), align:40(64)
> > MURAM alloc, start:2000, size:30(48), align:8(8)
> > MURAM alloc, start:2080, size:80(128), align:80(128)
> > MURAM alloc, start:2180, size:80(128), align:80(128)
> > MURAM alloc, start:2280, size:80(128), align:80(128)
> > MURAM alloc, start:2380, size:80(128), align:80(128)
> > MURAM alloc, start:2440, size:40(64), align:40(64)
> > MURAM alloc, start:24c0, size:40(64), align:40(64)
> > MURAM alloc, start:2540, size:40(64), align:40(64)
> > MURAM alloc, start:25c0, size:40(64), align:40(64)
> > MURAM alloc, start:262c, size:5d(93), align:4(4)
> >
> > MURAM alloc, start:2630, size:200(512), align:8(8)
> > MURAM alloc, start:2838, size:208(520), align:8(8)
> > MURAM alloc, start:2a80, size:80(128), align:80(128)
> > MURAM alloc, start:2c00, size:1a0(416), align:100(256)
> > MURAM alloc, start:2de0, size:40(64), align:20(32)
> > MURAM alloc, start:2f00, size:100(256), align:100(256)
> > MURAM alloc, start:3100, size:a0(160), align:100(256)
> > MURAM alloc, start:3200, size:c(12), align:40(64)
> > MURAM alloc, start:3228, size:30(48), align:8(8)
> > MURAM alloc, start:3280, size:80(128), align:80(128)
> > MURAM alloc, start:3380, size:80(128), align:80(128)
> > MURAM alloc, start:3480, size:80(128), align:80(128)
> > MURAM alloc, start:3580, size:80(128), align:80(128)
> > MURAM alloc, start:3680, size:40(64), align:40(64)
> > MURAM alloc, start:3700, size:40(64), align:40(64)
> > MURAM alloc, start:3780, size:40(64), align:40(64)
> > MURAM alloc, start:3800, size:40(64), align:40(64)
> > MURAM alloc, start:3858, size:5d(93), align:4(4)
> >
> > MURAM alloc, start:3858, size:200(512), align:8(8)
> > MURAM alloc, start:3a60, size:208(520), align:8(8)
> > MURAM alloc, start:3c80, size:80(128), align:80(128)
> > MURAM alloc, start:fffffff4, size:1a0(416), align:100(256)
> >
> > some comments:
> >
> > With these aligments, won't you waste alot of MURAM?
> >
> > Looking at the 2 first allocs:
> > MURAM alloc, start:1400, size:200(512), align:8(8)
> > MURAM alloc, start:1608, size:208(520), align:8(8)
> > shouldn't the second alloc have 0x1600 as start address?
> >
> > Jocke
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [patch 29/30 v2] PS3: Device tree source.
From: Geert Uytterhoeven @ 2007-06-14 7:55 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <46709A76.4000602@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 963 bytes --]
On Wed, 13 Jun 2007, Geoff Levand wrote:
> Subject: PS3: Device tree source.
>
> The PS3 device tree source.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
>
> ver2: Here's an updated version based on the discussions.
This one doesn't seem to work. The kernel hangs very early in the boot process.
I haven't digged into it yet to find out why.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1930 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 413.825.160 · RPR Brussels
Fortis Bank Londerzeel IBAN BE39 0013 8235 8619 GEBA-BE-BB
^ 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