* Re: 2.6.13 ati (ibook) frambuffer problem
From: Benjamin Herrenschmidt @ 2005-10-14 21:58 UTC (permalink / raw)
To: Joerg Dorchain; +Cc: linuxppc-dev
In-Reply-To: <20051014123823.GA9477@Redstar.dorchain.net>
On Fri, 2005-10-14 at 14:38 +0200, Joerg Dorchain wrote:
> 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?
This looks like a bug that was introduced by linus in 2.6.13 and that I
_think_ should be fixed in the stable series, so if you get 2.6.13.x (x
= latest stable release) it should work.
Usually, to debug those crashes, I'm adding a hack to kernel/printk.c to
call btext_drawstring() (with some test to make sure to do that not too
early, typically only after setup_arch has been called).
Ben.
^ 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 21:42 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
In-Reply-To: <20051014151830.GA31442@localhost.localdomain>
On Fri, Oct 14, 2005 at 05:18:30PM +0200, Sven Luther wrote:
> 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 :)
???
I guess what I wrote wasn't clear, since in his most recent patch,
Nicolas added more places like the above where the "{" has been moved
to a line by itself. Just the opposite of what I meant to suggest.
>From Documentation/CodingStyle:
> Chapter 3: Placing Braces
>
>The other issue that always comes up in C styling is the placement of
>braces. Unlike the indent size, there are few technical reasons to
>choose one placement strategy over the other, but the preferred way, as
>shown to us by the prophets Kernighan and Ritchie, is to put the opening
>brace last on the line, and put the closing brace first, thusly:
>
> if (x is true) {
> we do y
> }
>
>However, there is one special case, namely functions: they have the
>opening brace at the beginning of the next line, thus:
>
> int function(int x)
> {
> body of function
> }
-Dale
^ 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 17:45 UTC (permalink / raw)
To: Sven Luther; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <1129311502.28103.0.camel@localhost.localdomain>
Le vendredi 14 octobre 2005 à 19:38 +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 this is ok this time.
The open brackes were not mine ;-P.
Regards
Nicolas DET
^ permalink raw reply
* [PATCH 2.6.14-rc3 1/1] chrp_pegasos_eth: Added Marvell Discovery II SRAM support
From: Nicolas DET @ 2005-10-14 17:38 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: 6312 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-14 19:35:45.339667250 +0200
+++ b/arch/ppc/platforms/chrp_pegasos_eth.c 2005-10-14 19:36:29.682438500 +0200
@@ -17,8 +17,27 @@
#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[] = {
+static struct resource mv643xx_eth_shared_resources[] =
+{
[0] = {
.name = "ethernet shared base",
.start = 0xf1000000 + MV643XX_ETH_SHARED_REGS,
@@ -28,14 +47,16 @@
},
};
-static struct platform_device mv643xx_eth_shared_device = {
+static struct platform_device mv643xx_eth_shared_device =
+{
.name = MV643XX_ETH_SHARED_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mv643xx_eth_shared_resources),
.resource = mv643xx_eth_shared_resources,
};
-static struct resource mv643xx_eth0_resources[] = {
+static struct resource mv643xx_eth0_resources[] =
+{
[0] = {
.name = "eth0 irq",
.start = 9,
@@ -44,9 +65,19 @@
},
};
-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 = {
+static struct platform_device eth0_device =
+{
.name = MV643XX_ETH_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mv643xx_eth0_resources),
@@ -56,7 +87,8 @@
},
};
-static struct resource mv643xx_eth1_resources[] = {
+static struct resource mv643xx_eth1_resources[] =
+{
[0] = {
.name = "eth1 irq",
.start = 9,
@@ -65,9 +97,19 @@
},
};
-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 = {
+static struct platform_device eth1_device =
+{
.name = MV643XX_ETH_NAME,
.id = 1,
.num_resources = ARRAY_SIZE(mv643xx_eth1_resources),
@@ -77,25 +119,120 @@
},
};
-static struct platform_device *mv643xx_eth_pd_devs[] __initdata = {
+static struct platform_device *mv643xx_eth_pd_devs[] __initdata =
+{
&mv643xx_eth_shared_device,
ð0_device,
ð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;
+ 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
* Re: How to porting U-Boot to MPC852T
From: Wolfgang Denk @ 2005-10-14 16:30 UTC (permalink / raw)
To: gokul; +Cc: linuxppc-embedded
In-Reply-To: <02a401c5d0b8$6a6aef40$1600a8c0@Gokul>
In message <02a401c5d0b8$6a6aef40$1600a8c0@Gokul> you wrote:
>
> I have to Port U Boot for MPC852T .Is there u boot code is available ?
Yes.
> Can u send me the link ?
http://source.denx.net/cgi-bin/gitweb.cgi?p=u-boot.git
BTW: your question is off topic here. Please post U-Boot re;lated
questions on the U-Boot mailing list (but note: you are expected to
have read the documentation and the FAQ list *before* posting).
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
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
-- J. Finnegan, USC.
^ permalink raw reply
* Re: open firmware
From: Hollis Blanchard @ 2005-10-14 15:54 UTC (permalink / raw)
To: i2a; +Cc: linuxppc-dev
In-Reply-To: <20051014145644.M46291@gmx.net>
On Oct 14, 2005, at 10:34 AM, i2a wrote:
> On Fri, 14 Oct 2005 15:17:47 +0200, Segher Boessenkool wrote
>>
>> See http://playground.sun.com/1275/
>
> 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=20=
> be a way
> to get the documentation without having to buy =93the book=94.
openbios.org has a better-organized documentation collection.
> 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=20=
> is
> downloadable (it is old, but better then nothing), no idea why there=20=
> are no
> pointers to it..
>
> If someone has any newer documentation pls let me know, the system I=20=
> use is from
> 2004.
The Open Firmware documents have not changed for a long time (which is=20=
probably a bad thing).
-Hollis=
^ 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
* 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: 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: 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: [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: 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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: [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
* 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] 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: [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
* 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
* [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
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