* NPTL support on PPC
From: David Ho @ 2005-10-13 14:20 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
Hi all,
Just out of curiosity, is NPTL support already available on PPC?
I believe there are 2 parts to it. Kernel support which is probably already
there in 2.6. And the other is glibc, is there a generally available
toolchain (i.e. ELDK) that already support NPTL?
Thanks, David
[-- Attachment #2: Type: text/html, Size: 333 bytes --]
^ permalink raw reply
* Re: NPTL support on PPC
From: David Ho @ 2005-10-13 14:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4dd15d180510130720m45089eafk10cd9936457ced8b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
glibc used on ELDK 3.0 is still using linuxthreads.
David
bash-2.05# ./libc.so.6
GNU C Library stable release version 2.3.1, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1).
Compiled on a Linux 2.4.24-pre2 system on 2004-02-17.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
software FPU emulation by Richard Henderson, Jakub Jelinek and others
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
On 10/13/05, David Ho <davidkwho@gmail.com> wrote:
>
> Hi all,
>
> Just out of curiosity, is NPTL support already available on PPC?
>
> I believe there are 2 parts to it. Kernel support which is probably
> already there in 2.6. And the other is glibc, is there a generally
> available toolchain (i.e. ELDK) that already support NPTL?
>
> Thanks, David
>
[-- Attachment #2: Type: text/html, Size: 1971 bytes --]
^ permalink raw reply
* Re: NPTL support on PPC
From: Gerhard Jaeger @ 2005-10-13 14:52 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: David Ho
In-Reply-To: <4dd15d180510130725o3c23326i6f9703015401a381@mail.gmail.com>
On Thursday 13 October 2005 16:25, David Ho wrote:
> glibc used on ELDK 3.0 is still using linuxthreads.
>
> David
>
> bash-2.05# ./libc.so.6
> GNU C Library stable release version 2.3.1, by Roland McGrath et al.
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1).
> Compiled on a Linux 2.4.24-pre2 system on 2004-02-17.
> Available extensions:
> GNU libio by Per Bothner
> crypt add-on version 2.1 by Michael Glad and others
> linuxthreads-0.10 by Xavier Leroy
> BIND-8.2.3-T5B
> libthread_db work sponsored by Alpha Processor Inc
> NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> software FPU emulation by Richard Henderson, Jakub Jelinek and others
> Report bugs using the `glibcbug' script to <bugs@gnu.org>.
>
>
> On 10/13/05, David Ho <davidkwho@gmail.com> wrote:
> >
> > Hi all,
> >
> > Just out of curiosity, is NPTL support already available on PPC?
> >
> > I believe there are 2 parts to it. Kernel support which is probably
> > already there in 2.6. And the other is glibc, is there a generally
> > available toolchain (i.e. ELDK) that already support NPTL?
> >
> > Thanks, David
Yes it's available! you might want to checkout the work done around
the crosstool project (http://www.kegel.com/crosstool) or check my
sig ;)
-/bin/sh-3.00# /lib/tls/libc.so.6
GNU C Library stable release version 2.3.4, by Roland McGrath et al.
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.4.
Compiled on a Linux 2.6.12.6-elinos-214 system on 2005-09-28.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
software FPU emulation by Richard Henderson, Jakub Jelinek and others
Thread-local storage support included.
Ciao,
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* network driver over shared memory
From: gaashpub-lnx @ 2005-10-13 17:09 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: gaashpub-lnx
Experts,
Hope this is not a too dumb question.
I have an embedded system with a few PPCs, one master
and a few slaves. All PPCs are interconnected with
shared memory over PCI.
I would like to create and IP or "Ethernet like"
network between all the PPCs to enable files transfer
over FTP or NFS between the master and the slaves.
Is there a network driver for this in 2.6 kernel. If
not any idea where to look for or with what to begin
with.
PS: Please put my email in the reply as I'm not member
of this list (yet)
Thanks
Gaash
^ permalink raw reply
* Re: MPC7447A based board with MV64462 Marvell Discovery III controller
From: Mark A. Greer @ 2005-10-13 18:26 UTC (permalink / raw)
To: Ashish Bijlani; +Cc: linuxppc-embedded
In-Reply-To: <ec55b17e0510130042m6c6c0c43ndf09f40a03f9cf97@mail.gmail.com>
On Thu, Oct 13, 2005 at 01:12:19PM +0530, Ashish Bijlani wrote:
> Hi,
>
> I'm trying to bring MPC7447A based board with MV64462 Marvell Discovery III
> controller up. Can you guide me to Linux-2.6 sources with support for
> MV64462 Marvell Discovery III controller and MPC7447A PowerPC processor.
> Support for I2c, dual 10/100/1000 ethernet ports, and relevant platform
> should be there. I cannot access the bit keeper repositories so please guide
> me to the linux-2.6 kernel source tree if you can.
Ashish,
Support for both the 7447A and mv64x6x is in the latest 2.6 mainline
kernel source at kernel.org.
If your board is a chrp/openfirmware board, then you probably want to use
the Pegasos code as an example. If your board has U-boot or some other
non-OF firmware, then use the katana or chestnut as an example (katana
is more up-to-date than the chestnut). The ev64360 code may help too.
There are i2c and enet drivers (and mpsc and wdt) in that source as well.
Note that I've never had a 64462 to test with. Since the '2' means it
has less functionality than the '0', you may run into some problems.
If you do, please let me know what they are.
Mark
^ permalink raw reply
* What is OCP_FUNC_OPB ??
From: Roland Dreier @ 2005-10-13 20:05 UTC (permalink / raw)
To: linuxppc-embedded, mporter
While merging Ruslan Sushko's fix for GPIO and IIC addresses into my
440SPe tree, I noticed that ocp_core[] has an entry for a function
OCP_FUNC_OPB. I'd like to get this correct for the 440SPe port, but I
don't see any users in the tree.
Is this field just used to create an entry in sysfs -- if so what does
userspace use it for?? Or is it just completely obsolete? What is
the .paddr member supposed to represent? Is it just the base address
of the whole OPB region?
Is it worth applying the patch below (according to the 440SP manual,
the OPB region starts at 0x1 f000 0000), or should we just get rid of
these entries entirely?
Thanks,
Roland
[PPC32] Correct OPB base address for PowerPC 440SP
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c
index feb17e4..0b7e462 100644
--- a/arch/ppc/platforms/4xx/ibm440sp.c
+++ b/arch/ppc/platforms/4xx/ibm440sp.c
@@ -60,7 +60,7 @@ struct ocp_def core_ocp[] = {
{ .vendor = OCP_VENDOR_IBM,
.function = OCP_FUNC_OPB,
.index = 0,
- .paddr = 0x0000000140000000ULL,
+ .paddr = 0x00000001f0000000ULL,
.irq = OCP_IRQ_NA,
.pm = OCP_CPM_NA,
},
^ permalink raw reply related
* [PATCH 2.6.14-rc3 1/1] chrp_pegasos_eth: Added Marvell Discovery II SRAM support
From: Nicolas DET @ 2005-10-13 20:00 UTC (permalink / raw)
To: Sven Luther, Andrew Morton, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 183 bytes --]
Added proper entry to support the Marvell MV64361 (Marvell Discovery II)
SRAM.
This feature may be used by the mv643xx_eth driver.
Signed-off-by: Nicolas DET <det.nicolas@free.fr)
[-- Attachment #2: chrp_pegasos_eth.2.6.14-rc4.patch --]
[-- Type: text/x-patch, Size: 5110 bytes --]
diff -ur a/arch/ppc/platforms/chrp_pegasos_eth.c b/arch/ppc/platforms/chrp_pegasos_eth.c
--- a/arch/ppc/platforms/chrp_pegasos_eth.c 2005-10-13 21:19:46.590643250 +0200
+++ b/arch/ppc/platforms/chrp_pegasos_eth.c 2005-10-13 21:29:54.976665000 +0200
@@ -17,6 +17,21 @@
#include <linux/mv643xx.h>
#include <linux/pci.h>
+// Pegasos II location and size for the SRAM stuff
+// Only used for the ethernet driver ATM
+#define PEGASOS2_MARVELL_REGBASE (0xf1000000)
+#define PEGASOS2_MARVELL_REGSIZE (0x00004000)
+#define PEGASOS2_SRAM_BASE (0xf2000000)
+#define PEGASOS2_SRAM_SIZE (0x00040000)
+
+#define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE)
+#define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) )
+
+#define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
+#define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
+
+#undef BE_VERBOSE
+
/* Pegasos 2 specific Marvell MV 64361 gigabit ethernet port setup */
static struct resource mv643xx_eth_shared_resources[] = {
[0] = {
@@ -44,7 +59,15 @@
},
};
-static struct mv643xx_eth_platform_data eth0_pd;
+static struct mv643xx_eth_platform_data eth0_pd = {
+ .tx_sram_addr = PEGASOS2_SRAM_BASE_ETH0,
+ .tx_sram_size = PEGASOS2_SRAM_TXRING_SIZE,
+ .tx_queue_size = PEGASOS2_SRAM_TXRING_SIZE/16,
+
+ .rx_sram_addr = PEGASOS2_SRAM_BASE + PEGASOS2_SRAM_TXRING_SIZE,
+ .rx_sram_size = PEGASOS2_SRAM_RXRING_SIZE,
+ .rx_queue_size = PEGASOS2_SRAM_RXRING_SIZE/16,
+};
static struct platform_device eth0_device = {
.name = MV643XX_ETH_NAME,
@@ -65,7 +88,15 @@
},
};
-static struct mv643xx_eth_platform_data eth1_pd;
+static struct mv643xx_eth_platform_data eth1_pd = {
+ .tx_sram_addr = PEGASOS2_SRAM_BASE_ETH1,
+ .tx_sram_size = PEGASOS2_SRAM_TXRING_SIZE,
+ .tx_queue_size = PEGASOS2_SRAM_TXRING_SIZE/16,
+
+ .rx_sram_addr = PEGASOS2_SRAM_BASE_ETH1 + PEGASOS2_SRAM_TXRING_SIZE,
+ .rx_sram_size = PEGASOS2_SRAM_RXRING_SIZE,
+ .rx_queue_size = PEGASOS2_SRAM_RXRING_SIZE/16,
+};
static struct platform_device eth1_device = {
.name = MV643XX_ETH_NAME,
@@ -83,19 +114,111 @@
ð1_device,
};
+/***********/
+/***********/
+#define MV_READ(offset,val) { val = readl(mv643xx_reg_base + offset); }
+#define MV_WRITE(offset,data) writel(data, mv643xx_reg_base + offset)
+
+static void __iomem *mv643xx_reg_base = NULL;
-int
-mv643xx_eth_add_pds(void)
+
+static int Enable_SRAM(void)
+{
+ u32 ALong;
+
+ // Let's io remap the mv register to touch the SRAM config
+ if (mv643xx_reg_base == NULL)
+ mv643xx_reg_base = ioremap(PEGASOS2_MARVELL_REGBASE, PEGASOS2_MARVELL_REGSIZE);
+
+ if (mv643xx_reg_base == NULL)
+ return -ENOMEM;
+
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: register remapped from %p to %p\n", (void *)PEGASOS2_MARVELL_REGBASE, (void *)mv643xx_reg_base);
+#endif
+
+ // First the SRAM config register
+ // We set it to 0 ATM -> No cache coherency, no parity check
+ MV_WRITE(MV64340_SRAM_CONFIG, 0);
+
+ // set the SRAM address on the CPU side
+ MV_WRITE(MV64340_INTEGRATED_SRAM_BASE_ADDR, PEGASOS2_SRAM_BASE >> 16);
+
+ // Now enable it (CPU side)
+ MV_READ(MV64340_BASE_ADDR_ENABLE, ALong);
+ ALong &= ~(1 << 19);
+ MV_WRITE(MV64340_BASE_ADDR_ENABLE, ALong);
+
+ // And now to the GB side on WB 4 (0->3) can be use for DRAM stuff
+ ALong = 0x02; // Integrated SRAM value
+ ALong |= PEGASOS2_SRAM_BASE & 0xffff0000; // Finally set the SRAM adress in the uppter par of the register
+ MV_WRITE(MV643XX_ETH_BAR_4, ALong);
+
+ // and the size ...
+ MV_WRITE(MV643XX_ETH_SIZE_REG_4, PEGASOS2_SRAM_SIZE & 0xffff0000);
+
+ // Finaly enable the window
+ MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+ ALong &= ~(1 << 4);
+ MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: register unmapped\n");
+ printk("Pegasos II/Marvell MV64361: SRAM at %p, size=%x\n", (void*) PEGASOS2_SRAM_BASE, PEGASOS2_SRAM_SIZE);
+#endif
+
+ iounmap(mv643xx_reg_base);
+ mv643xx_reg_base = NULL;
+
+ return 1;
+}
+
+
+/***********/
+/***********/
+int mv643xx_eth_add_pds(void)
{
int ret = 0;
- static struct pci_device_id pci_marvell_mv64360[] = {
+ static struct pci_device_id pci_marvell_mv64360[] =
+ {
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
{ }
};
- if (pci_dev_present(pci_marvell_mv64360)) {
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: init\n");
+#endif
+
+ if (pci_dev_present(pci_marvell_mv64360))
+ {
ret = platform_add_devices(mv643xx_eth_pd_devs, ARRAY_SIZE(mv643xx_eth_pd_devs));
+
+ if ( Enable_SRAM() < 0)
+ {
+ // Humm, disable SRAM stuff
+ eth0_pd.tx_sram_addr = 0;
+ eth0_pd.tx_sram_size = 0;
+ eth0_pd.rx_sram_addr = 0;
+ eth0_pd.rx_sram_size = 0;
+
+ eth1_pd.tx_sram_addr = 0;
+ eth1_pd.tx_sram_size = 0;
+ eth1_pd.rx_sram_addr = 0;
+ eth1_pd.rx_sram_size = 0;
+
+#ifdef BE_VERBOSE
+ printk("Pegasos II/Marvell MV64361: Can't enable the SRAM\n");
+#endif
+ }
}
+
+#ifdef BE_VERBOSE
+
+ printk("Pegasos II/Marvell MV64361: init is over\n");
+#endif
+
return ret;
}
+
device_initcall(mv643xx_eth_add_pds);
+
^ permalink raw reply
* fs_enet driver
From: Rune Torgersen @ 2005-10-13 21:02 UTC (permalink / raw)
To: linuxppc-embedded
Does anybody have a working patchset for fs_enet for 2.6.12?
The patches I've found on this list (and on ozlab's patch list) I cannot
get to compile.
I want to try the fs_enet driver on a 8265 based board to see it it has
better throughput than the standard driver for RTP data.
^ permalink raw reply
* Re: [PATCH] make gcc -O1 in fs/reiserfs optional
From: Andrew Morton @ 2005-10-13 23:27 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, reiserfs-dev, reiser, jeffm
In-Reply-To: <20051011190133.GA31348@suse.de>
Olaf Hering <olh@suse.de> wrote:
>
> On Wed, Apr 27, Hans Reiser wrote:
>
> > Olaf Hering wrote:
> >
> > >Jeff,
> > >
> > >you added this EXTRA_CFLAGS= during 2.4 development, I think the broken
> > >compiler was gcc 3.2 on SLES8. Can we turn this -O1 into a .config
> > >option?
>
> > Sounds reasonable.
>
> only compile with -O1 if the (very old) compiler is broken
> We use reiserfs alot in SLES9 on ppc64, and it was never seen
> with gcc33.
>
I dunno about this.
>
> Index: linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
> ===================================================================
> --- linux-2.6.12-rc3-olh.orig/fs/reiserfs/Makefile
> +++ linux-2.6.12-rc3-olh/fs/reiserfs/Makefile
> @@ -21,13 +21,7 @@ ifeq ($(CONFIG_REISERFS_FS_POSIX_ACL),y)
> reiserfs-objs += xattr_acl.o
> endif
>
> -# gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
> -# functions are used. This causes the compiler to advance the stack
> -# pointer out of the available stack space, corrupting kernel space,
> -# and causing a panic. Since this behavior only affects ppc32, this ifeq
> -# will work around it. If any other architecture displays this behavior,
> -# add it here.
> -ifeq ($(CONFIG_PPC32),y)
> +ifeq ($(CONFIG_REISERFS_CC_REDUCE_OPTIMZE),y)
> EXTRA_CFLAGS := -O1
> endif
>
> Index: linux-2.6.12-rc3-olh/fs/Kconfig
> ===================================================================
> --- linux-2.6.12-rc3-olh.orig/fs/Kconfig
> +++ linux-2.6.12-rc3-olh/fs/Kconfig
> @@ -186,6 +186,18 @@ config REISERFS_FS
> If you like it, you can pay us to add new features to it that you
> need, buy a support contract, or pay us to port it to another OS.
>
> +config REISERFS_CC_REDUCE_OPTIMZE
> + bool "Reduce CC optimization level to workaround compiler bugs"
> + depends on PPC32
> + default n
> + help
> + gcc -O2 (the kernel default) is overaggressive on ppc32 when many inline
> + functions are used. This causes the compiler to advance the stack
> + pointer out of the available stack space, corrupting kernel space,
> + and causing a panic. Since this behavior only affects ppc32, this ifeq
> + will work around it. If any other architecture displays this behavior,
> + add it here.
> +
Are you sure it's due to inline functions? I thought the problem was that
certain versions of gcc did automatic inlining of non-inlined functions and
we get excessive stack windup due to that. And iirc we put in global
compiler options to defeat that behaviour. Andi would recall.
Furthermore, we do have infrastructure for detecting the gcc version at
build time. It would be better to use that for disabling `-O2', rather
than a config option.
^ permalink raw reply
* Re: [PATCH] make gcc -O1 in fs/reiserfs optional
From: Jeff Mahoney @ 2005-10-14 1:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, reiserfs-dev, reiser, Olaf Hering
In-Reply-To: <20051013162734.615bba34.akpm@osdl.org>
Andrew Morton wrote:
> Are you sure it's due to inline functions? I thought the problem was that
> certain versions of gcc did automatic inlining of non-inlined functions and
> we get excessive stack windup due to that. And iirc we put in global
> compiler options to defeat that behaviour. Andi would recall.
>
> Furthermore, we do have infrastructure for detecting the gcc version at
> build time. It would be better to use that for disabling `-O2', rather
> than a config option.
Andrew -
This "fix" has been in the kernel since I developed the endian safe
patches for ReiserFS in the 2.4 days; This patch just makes it optional
rather than required.
You could be correct regarding the behavior. I noticed it was related to
inline functions and stack usage. Since this was quite a few years ago
now, I don't recall the exact details, just that -O1 worked around it. I
was content blaming gcc and moving on with development. I seem to recall
thinking that was overaggressive aliasing avoidance between temporary
variables in static inline functions. The endian safe code frequently
uses static inlines for conversion of disk order bitfields (like key
type and offset). balance_leaf() is a beast of a function at around 1400
lines or so. When compiled with -O2, it wanted to allocate 6k of stack
space. With -O1, it ended up allocating about 230 bytes. It seemed to be
the only function really affected by the bug, but I wanted to be certain.
I do agree that using the kbuild infrastructure to determine the need
for this option would work quite a bit better.
-Jeff
--
Jeff Mahoney
SUSE Labs
^ permalink raw reply
* Re: network driver over shared memory
From: emre kara @ 2005-10-14 6:06 UTC (permalink / raw)
To: gaashpub-lnx, linuxppc-embedded; +Cc: gaashpub-lnx
In-Reply-To: <20051013170932.88571.qmail@web32512.mail.mud.yahoo.com>
There is a dethernet(pci slave)/methernet(pci master)
driver in metrowerks eval8540 bps, this driver
provides ethernet interface that can communicate over
PCI bus. It's specific to 85xx family but may be can
help you.
follow this link:
http://www.metrowerks.com/MW/Develop/Embedded/Linux/DownloadBSP.htm
Emre
--- gaashpub-lnx@yahoo.com wrote:
> Experts,
>
> Hope this is not a too dumb question.
>
> I have an embedded system with a few PPCs, one
> master
> and a few slaves. All PPCs are interconnected with
> shared memory over PCI.
>
> I would like to create and IP or "Ethernet like"
> network between all the PPCs to enable files
> transfer
> over FTP or NFS between the master and the slaves.
>
> Is there a network driver for this in 2.6 kernel. If
> not any idea where to look for or with what to begin
> with.
>
> PS: Please put my email in the reply as I'm not
> member
> of this list (yet)
>
> Thanks
>
> Gaash
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
^ permalink raw reply
* Re: [PATCH 2.6.14-rc3 1/1] chrp_pegasos_eth: Added Marvell Discovery II SRAM support
From: Nicolas DET @ 2005-10-14 6:50 UTC (permalink / raw)
To: Sven Luther; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <1129233624.4161.30.camel@localhost.localdomain>
Le jeudi 13 octobre 2005 à 22:00 +0200, Nicolas DET a écrit :
> Added proper entry to support the Marvell MV64361 (Marvell Discovery II)
> SRAM.
>
> This feature may be used by the mv643xx_eth driver.
>
> Signed-off-by: Nicolas DET <det.nicolas@free.fr)
>
I hope the patch is ok now. I apologized for the text format issue.
By the way, I compiled and booted the 2.6.14-rc4. It feels a bit faster
than rc3 (maybe it's just an impression). I'm also glad the Firewire
supported has been improved since rc3.
Regards
Nicolas DET
^ permalink raw reply
* ramdisk image, unable to mount fs 01:00
From: somshekar chandrashekar kadam @ 2005-10-14 8:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]
Hi ,
i got linux-2.4.25 from denx devel cvs kernel , when i try to mount thr root fs , kernel panics giving the down message ,
i have used tis ramdisk image for 2.4.18 stock kernel ,
cant i use the same ramdisk as i have compiled kernel using the same compiler , ?
if not is that i have to create a new ramdisk image ?
please throw some light on this
Thanks In Advance
Neelu
-------------------------------------------------------
=> bootm 0x500000 0x600000
## Booting image at 00500000 ...
Image Name: Linux-2.4.25
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 473290 Bytes = 462.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 00600000 ...
Image Name: Test Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 939123 Bytes = 917.1 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 03eb8000, end 03f9d473 ... OK
Transferring control to Linux (at address 00000000) ...
Liven 25 (@radop) ver 2.92001 (ree)) Fri 14 1:32 2005 nodtotaes: 4
----------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 4522 bytes --]
^ permalink raw reply
* Re: ramdisk image, unable to mount fs 01:00
From: Wolfgang Denk @ 2005-10-14 8:45 UTC (permalink / raw)
To: somshekar chandrashekar kadam; +Cc: linuxppc-embedded
In-Reply-To: <20051014082220.32133.qmail@webmail10.rediffmail.com>
In message <20051014082220.32133.qmail@webmail10.rediffmail.com> you wrote:
>
> i got linux-2.4.25 from denx devel cvs kernel , when i try
> to mount thr root fs , kernel panics giving the down message ,
There is no "down message" in your mail.
> i have used tis ramdisk image for 2.4.18 stock kernel ,
> cant i use the same ramdisk as i have compiled kernel using the same compiler , ?
You should be able to use the same ramdisk image.
> ## Booting image at 00500000 ...
> Image Name: Linux-2.4.25
> Image Type: PowerPC Linux Kern el Image (gzip compressed)
> Data Size: 473290 Bytes = 462.2 kB
^^^^^^^^^^^^^^^^^^^^^^^
This image is way too small for a working 2.4.25 system. I guess you
seriously misconfigured the Linux kernel. Probably support for some
needed features (like ext2 file system, ramdisk, initial ramdisk
etc.) might be missing.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What's the sound a name makes when it's dropped?
^ permalink raw reply
* Re: What is OCP_FUNC_OPB ??
From: Eugene Surovegin @ 2005-10-14 9:03 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-embedded
In-Reply-To: <5264s12nen.fsf@cisco.com>
On Thu, Oct 13, 2005 at 01:05:20PM -0700, Roland Dreier wrote:
> While merging Ruslan Sushko's fix for GPIO and IIC addresses into my
> 440SPe tree, I noticed that ocp_core[] has an entry for a function
> OCP_FUNC_OPB. I'd like to get this correct for the 440SPe port, but I
> don't see any users in the tree.
>
> Is this field just used to create an entry in sysfs -- if so what does
> userspace use it for?? Or is it just completely obsolete? What is
> the .paddr member supposed to represent? Is it just the base address
> of the whole OPB region?
>
> Is it worth applying the patch below (according to the 440SP manual,
> the OPB region starts at 0x1 f000 0000), or should we just get rid of
> these entries entirely?
>
> Thanks,
> Roland
>
> [PPC32] Correct OPB base address for PowerPC 440SP
>
> Signed-off-by: Roland Dreier <rolandd@cisco.com>
>
> ---
>
> diff --git a/arch/ppc/platforms/4xx/ibm440sp.c b/arch/ppc/platforms/4xx/ibm440sp.c
> index feb17e4..0b7e462 100644
> --- a/arch/ppc/platforms/4xx/ibm440sp.c
> +++ b/arch/ppc/platforms/4xx/ibm440sp.c
> @@ -60,7 +60,7 @@ struct ocp_def core_ocp[] = {
> { .vendor = OCP_VENDOR_IBM,
> .function = OCP_FUNC_OPB,
> .index = 0,
> - .paddr = 0x0000000140000000ULL,
> + .paddr = 0x00000001f0000000ULL,
> .irq = OCP_IRQ_NA,
> .pm = OCP_CPM_NA,
> },
I think this is useless stuff. IIRC Ben added these fields when
converting from Armin's OCP, I have no idea what he had in mind at
the time (probably some "bus" object owning all "peripheral" objects).
I doubt anything in user/kernel-space uses it. IMHO we can safely
remove these entries from all 4xx platform files.
--
Eugene
^ permalink raw reply
* jffs2 robustness against powerfailure
From: David Jander @ 2005-10-14 9:35 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-embedded
Hi,
We have a custom embedded linux board, based on a MPC852T processor, running
2.4.25 kernel from denx. Jffs2 has certain backported patches after cvs from
03/2005.
I wanted to try some stress-testing the flash using jffs2 and the "checkfs"
tool which comes as part of the jffs2 sources. I setup a "power-cycle-box" as
described in the README and started logging everything the system produced.
Since jffs2 claims to be robust against power-failures I set the threshold for
maximum number of corrupt files allowed to 0. The test procedure rewrites all
testfiles using a single write() call for each file, so that should be ok.
After 279 power-cycles, it stopped with a CRC error in "file13". Of course
"file13" was the one being written to when power was cut off the last time.
Question: Is this a known shorcoming of jffs2, or must I assume that my
hardware is broken?
The latter is relatively unlikely, once I try to explain the contents of the
file:
diskles9:/flash # hexdump file13
0000000 0000 0300 0000 036d 0000 0942 0000 20b0
0000010 0000 08dd 0000 0715 0000 1da1 0000 043c
0000020 0000 05c2 0000 228d 0000 10ad 0000 1c35
...
00002e0 0000 14f1 0000 0d94 0000 1911 0000 12dd
00002f0 0000 09e9 0000 0686 0000 2380 0000 2294
0000300 0000 18f1 0000 01be 0000 25bb 0000 1af9
0000310 0000 1b94 0000 02b0 0000 2511 0000 1f79
0000320 0000 1f97 0000 0b53 0000 1eb7 0000 10bb
0000330 0000 2529 0000 2130 0000 0361 0000 0ff8
0000340 0000 1428 0000 10ab 0000 0364 0000 1b89
0000350 b110
As one can easily see, the first int (0x00000300) indicates the file-length,
after which the 16-bit CRC should be placed. At offset 0000300 in the file
there seems to be just more random data (a CRC of 0x0000 is unlikely and
known wrong in this case).
At the end of the file (offset 0x0000350) there is something that looks more
like a checksum.
Apparently the previous file was 0x0352 bytes long and the new file was going
to be 0x0302 bytes long, but was never written completely.
How comes I get a to see a valid file containing a mix of old and new data if
it was written with a single write() call?????
Shouldn't jffs2 throw away the new incomplete node and keep the old version of
the file?
Can anyone explain what happened here??
Greetings,
--
David Jander
^ permalink raw reply
* open firmware
From: i2a @ 2005-10-14 12:04 UTC (permalink / raw)
To: linuxppc-dev
Hi,
The linuxppc kernel uses the open firmware to access the ppc machine infos, I
want to be able to program to the open firmware to. Although there is a lost of
info inside the ppc kernel I still want to know the internals (definitions etc)
of “open firmware”.
Has someone documentation available? On inet I only found the UI description :(
------
Ingmar.
^ permalink raw reply
* How to porting U-Boot to MPC852T
From: gokul @ 2005-10-14 12:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 139 bytes --]
Hi
I have to Port U Boot for MPC852T .Is there u boot code is available ?
Can u send me the link ?
With Regards
Gokul
[-- Attachment #1.2: Type: text/html, Size: 1059 bytes --]
[-- Attachment #2: BitDefender.txt --]
[-- Type: text/plain, Size: 824 bytes --]
--
This message contains information from GDA Technologies LTD and affiliates, and is intended for the sole use of the individual and entity to whom it is addressed. It may contain information, including any attachments, that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this electronic transmission in error, please notify the sender immediately by a "reply to sender only" message and destroy all electronic and hard copies of the communication, including attachments.
This message was scanned for spam and viruses by BitDefender.
^ permalink raw reply
* 2.6.13 ati (ibook) frambuffer problem
From: Joerg Dorchain @ 2005-10-14 12:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hi,
after upgrading to a vanilla 2.6.13 kernel (from 2.6.12) there seems to
be a problem with the framebuffer driver I use for my ibook. The display
statz at the opnpic message, and after a while the machine reboot (looks
like panic().
Can someone confirm? Or better, point me to a patch ;-)?
For given reason, what is the common method to debug crashes before the
display is working?
TIA,
Joerg
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: open firmware
From: Segher Boessenkool @ 2005-10-14 13:17 UTC (permalink / raw)
To: i2a; +Cc: linuxppc-dev
In-Reply-To: <20051014115753.M37114@quicknet.nl>
> The linuxppc kernel uses the open firmware to access the ppc machine=20=
> infos, I
> want to be able to program to the open firmware to. Although there is=20=
> a lost of
> info inside the ppc kernel I still want to know the internals=20
> (definitions etc)
> of =93open firmware=94.
>
> Has someone documentation available? On inet I only found the UI=20
> description :(
See http://playground.sun.com/1275/
Segher
^ permalink raw reply
* Re: [PATCH 2.6.14-rc3 1/1] chrp_pegasos_eth: Added Marvell Discovery II SRAM support
From: Dale Farnsworth @ 2005-10-14 13:56 UTC (permalink / raw)
To: nd, linuxppc-dev
In-Reply-To: <1129233624.4161.30.camel@localhost.localdomain>
In article <1129233624.4161.30.camel@localhost.localdomain> Nicolas DET wrote:
> Added proper entry to support the Marvell MV64361 (Marvell Discovery II)
> SRAM.
Hi Nicolas,
I noticed a couple of style issues.
> +// Pegasos II location and size for the SRAM stuff
C++ style comments are discouraged in the kernel source.
> - static struct pci_device_id pci_marvell_mv64360[] = {
> + static struct pci_device_id pci_marvell_mv64360[] =
> + {
> + if (pci_dev_present(pci_marvell_mv64360))
> + {
Open brace should not be on a line by itself except in function definitions.
-Dale Farnsworth
^ permalink raw reply
* Re: jffs2 robustness against powerfailure
From: Mark Chambers @ 2005-10-14 14:33 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200510141135.47186.david.jander@protonic.nl>
>
> Hi,
>
> We have a custom embedded linux board, based on a MPC852T processor,
running
> 2.4.25 kernel from denx. Jffs2 has certain backported patches after cvs
from
> 03/2005.
> I wanted to try some stress-testing the flash using jffs2 and the
"checkfs"
> tool which comes as part of the jffs2 sources. I setup a "power-cycle-box"
as
> described in the README and started logging everything the system
produced.
> Since jffs2 claims to be robust against power-failures I set the threshold
for
> maximum number of corrupt files allowed to 0. The test procedure rewrites
all
> testfiles using a single write() call for each file, so that should be ok.
> After 279 power-cycles, it stopped with a CRC error in "file13". Of course
> "file13" was the one being written to when power was cut off the last
time.
>
> Question: Is this a known shorcoming of jffs2, or must I assume that my
> hardware is broken?
>
> The latter is relatively unlikely, once I try to explain the contents of
the
> file:
>
> diskles9:/flash # hexdump file13
> 0000000 0000 0300 0000 036d 0000 0942 0000 20b0
> 0000010 0000 08dd 0000 0715 0000 1da1 0000 043c
> 0000020 0000 05c2 0000 228d 0000 10ad 0000 1c35
> ...
> 00002e0 0000 14f1 0000 0d94 0000 1911 0000 12dd
> 00002f0 0000 09e9 0000 0686 0000 2380 0000 2294
> 0000300 0000 18f1 0000 01be 0000 25bb 0000 1af9
> 0000310 0000 1b94 0000 02b0 0000 2511 0000 1f79
> 0000320 0000 1f97 0000 0b53 0000 1eb7 0000 10bb
> 0000330 0000 2529 0000 2130 0000 0361 0000 0ff8
> 0000340 0000 1428 0000 10ab 0000 0364 0000 1b89
> 0000350 b110
>
> As one can easily see, the first int (0x00000300) indicates the
file-length,
> after which the 16-bit CRC should be placed. At offset 0000300 in the file
> there seems to be just more random data (a CRC of 0x0000 is unlikely and
> known wrong in this case).
> At the end of the file (offset 0x0000350) there is something that looks
more
> like a checksum.
> Apparently the previous file was 0x0352 bytes long and the new file was
going
> to be 0x0302 bytes long, but was never written completely.
> How comes I get a to see a valid file containing a mix of old and new data
if
> it was written with a single write() call?????
> Shouldn't jffs2 throw away the new incomplete node and keep the old
version of
> the file?
>
> Can anyone explain what happened here??
>
> Greetings,
>
> --
> David Jander
Well, I can tell you this, from bitter experience: Chips do strange stuff
when power is
coming or going. One thing that can happen is addresses get messed up, so
writes go
to the wrong place. You say your hardware is good, but it may not have been
thoroughly characterized for power-down behavior. Probably the same chip
that
generates a power-up reset generates a reset when power is falling, check if
the trip
voltage is high enough.
You could rule a power problem out by running your tests where you reset the
processor (shorting hreset or poreset somewhere) but not power-cycling the
board, and see if
the failures are the same.
Just my $.02,
Mark Chambers
^ permalink raw reply
* Re: How to porting U-Boot to MPC852T
From: Alex Zeffertt @ 2005-10-14 14:33 UTC (permalink / raw)
To: gokul; +Cc: linuxppc-embedded
In-Reply-To: <02a401c5d0b8$6a6aef40$1600a8c0@Gokul>
On Fri, 14 Oct 2005 17:41:32 +0530
"gokul" <kn.gokul@gdatech.co.in> wrote:
> Hi
>
>
> I have to Port U Boot for MPC852T .Is there u boot code is available
> ?
>
> Can u send me the link ?
>
>
>
> With Regards
> Gokul
>
>
>
First of all: you need to ask on the u-boot-users mailing list, not
here.
Second, u-boot already supports MPC852T. What you really want is for
u-boot to be ported to your board. Ask the u-boot-users list if your
board is supported. If not, maybe you can pay someone to do it for
you.
Alex
^ permalink raw reply
* Re: open firmware
From: i2a @ 2005-10-14 15:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <f308ce32868b18c6be30cf2a28d86ade@kernel.crashing.org>
On Fri, 14 Oct 2005 15:17:47 +0200, Segher Boessenkool wrote
> > The linuxppc kernel uses the open firmware to access the ppc machine
> > infos, I
> > want to be able to program to the open firmware to. Although there is
> > a lost of
> > info inside the ppc kernel I still want to know the internals
> > (definitions etc)
> > of [WINDOWS-1252?]“open [WINDOWS-1252?]firmware”.
> >
> > Has someone documentation available? On inet I only found the UI
> > description :(
>
> See http://playground.sun.com/1275/
>
> Segher
Thanks, initially I had no luck with this site (I had find it),
http://playground.sun.com/1275/home.html#OFDCoreDoc
The two links of the core documentation are dead :(, and there has to be a way
to get the documentation without having to buy “the book”.
But here it is, via this page http://www.firmworks.com/www/ieee.htm
I got to ftp://playground.sun.com/pub/p1275/coredoc/ where the coredoc is
downloadable (it is old, but better then nothing), no idea why there are no
pointers to it..
If someone has any newer documentation pls let me know, the system I use is from
2004.
Grts,
Ingmar
^ permalink raw reply
* Re: [PATCH 2.6.14-rc3 1/1] chrp_pegasos_eth: Added Marvell Discovery II SRAM support
From: Sven Luther @ 2005-10-14 15:18 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, sl
In-Reply-To: <20051014135641.15104.qmail@xyzzy.farnsworth.org>
On Fri, Oct 14, 2005 at 01:56:41PM -0000, Dale Farnsworth wrote:
> > - static struct pci_device_id pci_marvell_mv64360[] = {
> > + static struct pci_device_id pci_marvell_mv64360[] =
> > + {
>
> > + if (pci_dev_present(pci_marvell_mv64360))
> > + {
>
> Open brace should not be on a line by itself except in function definitions.
Oh, neat, i knew i should not use same-line-braces for function but didn't
know i should use them for non-functions :)
Friendly,
Sven Luther
^ 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