* MPC8560 Gianfar driver hangs after soft reboot
From: Bill Farrow @ 2007-05-25 2:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
The Gianfar driver is hanging during boot-up after a soft reboot. It
works fine when the board is power cycled.
Any hints on where to look further on this issue?
Here are the details (cut and pasted from my colleague's email):
1. Load the kernel from the Flash and the rootfs from a NFS server.
2. Issue the "reboot" command. This runs the Busybox reboot producing
the following output:
The system is going down NOW!
Sending SIGTERM to all processes
Sending SIGKILL to all processes
Requesting system reboot
3. After rebooting, the system starts up Linux and it hangs after:
eth0: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:00
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
When stepped through, the kernel endlessly loops in the function:
gfar_probe(struct platform_device *pdev)
File: gianfar.c
Line 233: while (!(gfar_read(&priv->regs->ievent) & (IEVENT_GRSC |
IEVENT_GTSC)))
cpu_relax();
The soft reset procedure in the MPC8560RM.pdf was followed by separating
out the GTS and GRS completion polling with a delay between these. The
kernel seems to get stuck at waiting for the GTS to complete.
Tried not doing this "Graceful" stop procedure by commenting out the
relevant driver code. In this case the Kernel seems to continue on and
gets stuck at mounting the rootfs from NFS, indicating that the network
cannot be accessed.
Also tried soft rebooting without the network cable and the kernel boots
without hanging, but the network does not work when the re-connected.
The PHY seems to be working because when we plug the cable back in it
detects the link and writes this console message:
[ 1557.465085] PHY: 0:01 - Link is Up - 100/Full
Note that there are two Ethernet controllers on the board (eth0 and
eth1). Only eth1 is connected to the network.
Background info:
Kernel version 2.6.20.4 PPC
Uboot version 1.2.0
Busybox version 1.5.0
ELDK: 4.1
JTAG: BDI-2000
Board : Microsys PM856 - with MPC8560 processor.
Bill
--
Bill Farrow
Phone : +61 3 9538-3386 <http://www.optiscan.com>
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: David Gibson @ 2007-05-25 2:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Alexandre Bounine
In-Reply-To: <1180014348.3360.17.camel@zod.rchland.ibm.com>
On Thu, May 24, 2007 at 08:45:48AM -0500, Josh Boyer wrote:
> On Thu, 2007-05-24 at 14:16 +1000, David Gibson wrote:
> > This patch fixes some problems with the way the Ethernet PHYs are
> > represented in the device tree for the Holly board. This means
> > changes to the dts itself, and to the code with instantiates the
> > tsi108 ethernet platform devices based on the device tree.
> >
> > - First, and most importantly, the PHYs are given with an
> > identical 'reg' property. This reg currently encodes the accessible
> > register used to initiate mdio interaction with the PHYs, rather than
> > a meaningful address on the parent bus (mdio in this case), which is
> > incorrect. Instead we give the address of these registers as 'reg' in
> > the mdio node itself, and encode the ID of each phy in their 'reg'
> > propertys. The PHY's unit name addresses are updated to match.
>
> You'll need to fixup the mpc7448hpc2 board's DTS with the same change
> then, as it shares the same bridge and ethernet code.
Ah, yes. Done.
> > - Second, the PHYs give only "bcm54xx" as a compatible
> > property. This is unfortunate, because there are many bcm54xx PHY
> > models, and they have differences which can matter. We add a more
> > precise compatible string, giving the precise PHY model (bcm5461A in
> > this case).
>
> This part is fine with me.
>
> josh
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Li Yang-r58472 @ 2007-05-25 2:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul
In-Reply-To: <5E953418-3B5B-4051-9ABB-4C3B1CE1567F@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Thursday, May 24, 2007 7:44 PM
> To: Li Yang-r58472
> Cc: Paul; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] qe_lib: export symbols to fix compile error when
QE drivers
> compile as modules
>=20
>=20
> On May 24, 2007, at 4:14 AM, Li Yang wrote:
>=20
> > Export symbols of qe_lib to be used by QE drivers.
> >
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> > arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
> > arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
> > arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
> > 3 files changed, 25 insertions(+), 2 deletions(-)
>=20
> A number of the EXPORT_SYMBOL() are not used by any in kernel drivers
> and thus should not be added. See comments below. Also, should
> these be EXPORT_SYMBOL_GPL().
Some of them are not used by in kernel driver, but they are used by some
off kernel drivers and driver in development. Shouldn't we export them?
I know Linux is again non-GPL modules, but Freescale won't be forcing
customers to use GPL as long as Linux doesn't ban non-GPL module
completely.
> > static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr,
> > u8 * reg_num,
> > u8 * shift)
> > @@ -122,6 +126,7 @@ static void get_cmxucr_reg(int ucc_num,
> > volatile u32 ** p_cmxucr, u8 * reg_num,
> > break;
> > }
> > }
> > +EXPORT_SYMBOL(get_cmxucr_reg);
>=20
> remove, you shouldn't be exporting something marked static.
Good catch.
Thanks,
Leo
^ permalink raw reply
* Re: TSI ethernet PHY question
From: David Gibson @ 2007-05-25 2:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list, Alexandre Bounine
In-Reply-To: <2994f78d2591e45517247003d613bb98@kernel.crashing.org>
On Fri, May 25, 2007 at 01:54:35AM +0200, Segher Boessenkool wrote:
> > For powerpc, I have a solution at hand, it's the device-tree :-)
> >
> > Any struct device in the system can have a device node pointer via the
> > dev_sysdata thingy I added recently. So we can have some code for
> > powerpc that properly hooks up the PHY to an (optional) device-node
> > which can then contains properties describing what kind of workarounds
> > need to be applied.
> >
> > For example, we can have a txc-rxc-delay-disable property on Holly.
>
> This is equivalent to the ethernet driver passing this information
> to phylib via the init arguments.
>
> You still have the same problems as Andy described where the
> necessary workaround is not something local to phylib, but
> needs cooperation of the ethernet code or the soc code or
> some other platform code.
>
> Since the specific bug we're talking about here is not a
> problem with the PHY, but a miswiring on the board, I wouldn't
> put a flag for the workaround in the phy node in the device
> tree. It certainly is an option though.
Uh.. something to bear in mind is that although it is a board
miswiring, it's of a type that it will plausibly occur in other
boards. IIRC, if a LED is attached to this PHY the workaround is
necessary, or something similar. So there is value in having a
particular flag for this rather than just looking at the board model.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Benjamin Herrenschmidt @ 2007-05-25 1:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <adf40b0a9d45728359da78fa45efab8a@kernel.crashing.org>
On Fri, 2007-05-25 at 02:57 +0200, Segher Boessenkool wrote:
>
> However in this case you could put a property in the
> PHY node, similar things have been done before. It's
> ugly and doesn't solve any problem (it is just as much
> work to parse the board model as to find this magic
> property), and you *still* should pass in the flag
> from the platform layer, and not have the phylib try
> to handle it by itself.
I disagree, it's not ugly and nicely solves the problem.
For example, imagine you have 2 PHYs on a board and only one needs the
workaround ? Really, the PHY node is the best place for it.
> The ethernet driver is a powerpc-specific driver, that's
> one thing. Also, the workaround should be initiated by
> the platform code, so has to go through the ethernet driver
> (since it instantiates the phylib driver).
Still... it can be done via generic calls in powerpc ethernet drivers
that set flags in phylib based on things in the device-tree.
> For many similar workarounds, the ethernet driver _does_ have
> to cooperate in the workaround. For some other such workarounds,
> the soc code has to be involved. Etc. etc.
> You can do a quick "fix" now by doing this magic property
> thing, and it sure is a *quick* fix; but later on you'll
> have to do some other workarounds the proper way. And
> you'll be stuck with the property forever. Not such a
> big deal, sure; hey, I already _did_ say I'm okay with it,
> right? It's just the "wrong" thing to do ;-)
I have no bloody idea what you consider "the proper way"
I think it's the right thing to do.
Ben.
^ permalink raw reply
* Re: Xilinx git tree at source.mvista.com
From: David H. Lynch Jr. @ 2007-05-25 1:49 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-dev, Andrei Konovalov, linuxppc-embedded
In-Reply-To: <20070524154211.169C7AE8051@mail10-fra.bigfish.com>
Wolfgang Reissnegger wrote:
> Hi Andrei, David,
>
> It's great to hear that Andrei's git tree is active again.
>
> As you might have heard, Xilinx is in the process of setting up a git
> tree as well. Right now we are waiting for the new hosting machines to
> be installed. We should get those machines up and running shortly
> (within a couple weeks).
>
Absolutely fantastic - however I think kernel.org would be happy to host
your git tree for you
as well as a few other places. Those are locations people would look for
public git trees.
I beleive you can still excecise some control. I beleive they are free -
though I suspect kernel.org would not
mind contributions from xilinx.
>
> Currently the tree is based on mainline and adds support for MicroBlaze.
> I also intent to merge Grant Likely's virtex-dev branch, the framebuffer
> patch and the various other contributions that are out there.
>
You might want to look at the Microbalze-uClinux mailing list as well as
petalogix.
They are not using git yet, but they are puching the microblaze towards
kernel org
inclusion.
> We are also in the process of changing our internal coding guidelines to
> match the common Linux style (e.g. u32, u16 types, 8 char wide (tab)
> indentation, curly brace location etc) to make it easier to integrate
> code into the kernel and push it upstream.
>
For me the most significant issue is the bazillion layers of nested
macro's and includes.
The kernel style guides atleast to me are primarily about the
readability and understandability of the code.
not where the curly brackets are.
> I'll send an update once we have the server up and running.
>
> Thanks,
> Wolfgang
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH 1/13] powerpc: Add Makefile rules to wrap dts file in zImage
From: David Gibson @ 2007-05-25 1:33 UTC (permalink / raw)
To: Mark A. Greer, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070525013242.GC11789@localhost.localdomain>
On Fri, May 25, 2007 at 11:32:42AM +1000, David Gibson wrote:
> On Thu, May 24, 2007 at 02:28:32PM -0700, Mark A. Greer wrote:
> > On Tue, May 22, 2007 at 10:23:49AM +1000, David Gibson wrote:
> > > On Mon, May 21, 2007 at 11:10:43AM -0700, Mark A. Greer wrote:
> > > > On Mon, May 14, 2007 at 10:33:32AM +1000, David Gibson wrote:
> > > > > On Fri, May 11, 2007 at 05:53:36PM -0700, Mark A. Greer wrote:
> > > > > > +$(obj)/zImage.dts: $(addprefix $(obj)/, $(dts-y))
> > > > > > + @rm -f $@; ln $< $@
> > > > > > +$(obj)/zImage.dts_initrd: $(addprefix $(obj)/, $(dts_initrd-y))
> > > > > > + @rm -f $@; ln $< $@
> > > > > > +
> > > > >
> > > > > I thought you said you were going to drop this bit?
> > > >
> > > > Hi David.
> > > >
> > > > Would you elaborate on what your alternative is? A lot of the Makefile
> > > > stuff is still black magic to me.
> > >
> > > Just leave them out. As long as you add the correct specific
> > > zImage.dts.% and zImage.dts_initrd.% targets to image-y and initrd-y,
> > > then a "make zImage" from the top-level Makefile will get them built.
> >
> > That defeats the whole purpose of the patch--to allow the selection of
> > wrapping a dtb or not at build time. Its just like initrd, you choose
> > whether to "do it" at build time.
>
> Ah, right. Remind me why that's useful again?
Sorry, to be more precise, why is that more useful than having "make
zImage" at the top level build both the dts and non-dts versions.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: David Gibson @ 2007-05-25 1:27 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1180030140.3360.24.camel@zod.rchland.ibm.com>
On Thu, May 24, 2007 at 01:09:00PM -0500, Josh Boyer wrote:
> On Thu, 2007-05-24 at 22:02 +0400, Sergei Shtylyov wrote:
> > Dave Jiang wrote:
> >
> > > Has anyone been able to build mpc85xx_* from the latest powerpc.git? I have
> > > tried mpc85xx_cds and mpc8560_ads. I pulled a new git tree and attempted to
> > > build and hit the error message below.
> >
> > > Also, if I comment out the two lines in arch/powerpc/boot/Makefile that was
> > > introduced by the 440 Ebony support patch everything is fine.
> >
> > > $(obj)/44x.o: BOOTCFLAGS += -Wa,-mbooke
> > > $(obj)/ebony.o: BOOTCFLAGS += -Wa,-mbooke
> >
> > > make -f
> > > /home/djiang/community/git-repos/tmp/ppc-master/scripts/Makefile.modpost vmlinux
> > > scripts/mod/modpost -o
> > > /home/djiang/community/git-repos/tmp/ppc-master/Module.symvers
> > > arch/powerpc/kernel/head_fsl_booke.o init/built-in.o usr/built-in.o
> > > arch/powerpc/kernel/built-in.o arch/powerpc/mm/built-in.o
> > > arch/powerpc/lib/built-in.o arch/powerpc/sysdev/built-in.o
> > > arch/powerpc/platforms/built-in.o arch/powerpc/math-emu/built-in.o
> > > kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
> > > security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a
> > > lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o
> > > WARNING: arch/powerpc/mm/built-in.o(.text+0x10bc): Section mismatch: reference
> > > to .init.text:early_get_page (between 'pte_alloc_one_kernel' and 'steal_context')
> > > rm -f .old_version
> > > make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
> > > arch/powerpc/boot/uImage
> > > /opt/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -m32
> > > -Wp,-MD,arch/powerpc/boot/.ebony.o.d -Wall -Wstrict-prototypes -O2
> > > -fomit-frame-pointer -fno-builtin -nostdinc -isystem
> > > /opt/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/include
> > > -fPIC -fno-stack-protector -Iarch/powerpc/boot
> > > -I/home/djiang/community/git-repos/tmp/ppc-master/arch/powerpc/boot -Wa,-mbooke
> > > -c -o arch/powerpc/boot/ebony.o arch/powerpc/boot/ebony.c
> > > /home/djiang/tmp/cc2UVyci.s: Assembler messages:
> > > /home/djiang/tmp/cc2UVyci.s:142: Error: Unrecognized opcode: `isel'
> > > make[1]: *** [arch/powerpc/boot/ebony.o] Error 1
> >
> > I wonder WTF ebony.c gets built for MPC85xx targets? :-O
>
> Because it's part of the bootwrapper and all platform files get built no
> matter what the actual target is at the moment.
>
> We might want to take a look at why we're doing that again.
So that we have a better chance of catching platform specific build
bugs: which we just did.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/13] powerpc: Add Makefile rules to wrap dts file in zImage
From: David Gibson @ 2007-05-25 1:32 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070524212832.GB32012@mag.az.mvista.com>
On Thu, May 24, 2007 at 02:28:32PM -0700, Mark A. Greer wrote:
> On Tue, May 22, 2007 at 10:23:49AM +1000, David Gibson wrote:
> > On Mon, May 21, 2007 at 11:10:43AM -0700, Mark A. Greer wrote:
> > > On Mon, May 14, 2007 at 10:33:32AM +1000, David Gibson wrote:
> > > > On Fri, May 11, 2007 at 05:53:36PM -0700, Mark A. Greer wrote:
> > > > > +$(obj)/zImage.dts: $(addprefix $(obj)/, $(dts-y))
> > > > > + @rm -f $@; ln $< $@
> > > > > +$(obj)/zImage.dts_initrd: $(addprefix $(obj)/, $(dts_initrd-y))
> > > > > + @rm -f $@; ln $< $@
> > > > > +
> > > >
> > > > I thought you said you were going to drop this bit?
> > >
> > > Hi David.
> > >
> > > Would you elaborate on what your alternative is? A lot of the Makefile
> > > stuff is still black magic to me.
> >
> > Just leave them out. As long as you add the correct specific
> > zImage.dts.% and zImage.dts_initrd.% targets to image-y and initrd-y,
> > then a "make zImage" from the top-level Makefile will get them built.
>
> That defeats the whole purpose of the patch--to allow the selection of
> wrapping a dtb or not at build time. Its just like initrd, you choose
> whether to "do it" at build time.
Ah, right. Remind me why that's useful again?
--
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
* initramfs on ppc 405: crc error
From: Shelley, Mike @ 2007-05-25 1:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
I'm having a similar problem to a question posted earlier with
initramfs.
I'm using the 2.6.20 kernel, on a Xilinx Virtex 4, ppc405, no boot
loader. I use a BDI2000 to load the kernel image directly into RAM
(32MB).
When I use a larger (4mb compressed, 13mb uncompressed) cpio archive for
initramfs, I get a crc error when it tries to decompress it. When I use
a small simple archive (30k), it works correctly and does not have the
crc problem. I've tried a cpio.gz archive of about 2mb and still get
the crc error. Are there any size limitations for the kernel and/or for
initramfs? What else could the problem be?
The kernel image is being loaded to an address of 0x800000 instead of
0x400000 since it has problems decompressing the kernel at the lower
address, I'm told due to the size of the kernel image (5mb compressed).
Could this positioning be interfering with the initramfs decompression?
Where is the initramfs decompressed to?
Any help would be appreciated.
Thanks,
Mike
[-- Attachment #2: Type: text/html, Size: 3457 bytes --]
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: David Gibson @ 2007-05-25 1:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <ab81cfaedb70d6911fcbac9c43f5cf69@kernel.crashing.org>
On Fri, May 25, 2007 at 12:02:44AM +0200, Segher Boessenkool wrote:
> >>> Nothing is telling GCC what CPU to compile for, so it
> >>> will just use the compiler's default, which very likely
> >>> is not what you want. For files that will only ever
> >>> be used on 440, the correct flags are -mcpu=440 -Wa,-m440 .
> >>
> >> We could add that to the per-file flags already, right?
> >
> > I think it should really use -mcpu=powerpc on all files.
> > The problem that Dave saw was the result of using a compiler
> > that defaults to -mcpu=8540, which uses instruction that
> > don't work on 440.
>
> No, those options _do_ work on 440, but the -mbooke
> assembler flag disallows isel (since it is an optional
> insn).
But not on 440GP, which is what Ebony is.
> > The common files really need to be built with -mcpu flags that
> > make the code work on any system if you want to be able
> > to use just a single boot wrapper binary for all.
>
> On any system where they can run at all, yes. It should
> be fine to compile a 440-only file with 440-specific flags.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Segher Boessenkool @ 2007-05-25 0:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <1180051272.32247.1087.camel@localhost.localdomain>
>> You still have the same problems as Andy described where the
>> necessary workaround is not something local to phylib, but
>> needs cooperation of the ethernet code or the soc code or
>> some other platform code.
>
> If it's in the PHY device node, the ethernet driver doesn't need to be
> involved more than calling some generic helper that finds the right
> node, parses it and generates known flags.
I am not talking about the workaround for _this_ bug, but
about other PHY workarounds that _do_ need cooperation of
other devices. How should those be described in the
device tree?
>> Since the specific bug we're talking about here is not a
>> problem with the PHY, but a miswiring on the board, I wouldn't
>> put a flag for the workaround in the phy node in the device
>> tree. It certainly is an option though.
>
> Why ? That's the perfect place to put it in !
Only if you think the device tree is a configuration
mechanism for the OS. Your workaround is in the PHY,
sure; but the _bug_ is in the board.
However in this case you could put a property in the
PHY node, similar things have been done before. It's
ugly and doesn't solve any problem (it is just as much
work to parse the board model as to find this magic
property), and you *still* should pass in the flag
from the platform layer, and not have the phylib try
to handle it by itself.
>>> The problem is that of course the PHY driver will need some powerpc
>>> specific code to go fetch that.
>>
>> The ethernet driver can handle it, instead.
>
> I don't understand why you want to involve the ethernet driver in
> something that doesn't have much to do with it.
The ethernet driver is a powerpc-specific driver, that's
one thing. Also, the workaround should be initiated by
the platform code, so has to go through the ethernet driver
(since it instantiates the phylib driver).
> A pin of the PHY is
> miswired causing something to be enabled that shouldn't be. Ok, there
> is
> indeed the fact that the problem is partially related to the TSI
> ethernet not supporting when that PHY feature is "enabled" but still...
> it's a PHY setting, totally specific to a given PHY revision, I'm not
> sure there's much point in having it in the eth driver.
For many similar workarounds, the ethernet driver _does_ have
to cooperate in the workaround. For some other such workarounds,
the soc code has to be involved. Etc. etc.
You can do a quick "fix" now by doing this magic property
thing, and it sure is a *quick* fix; but later on you'll
have to do some other workarounds the proper way. And
you'll be stuck with the property forever. Not such a
big deal, sure; hey, I already _did_ say I'm okay with it,
right? It's just the "wrong" thing to do ;-)
Segher
^ permalink raw reply
* Re: Xilinx git tree at source.mvista.com
From: David H. Lynch Jr. @ 2007-05-25 0:47 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <46558E54.80909@ru.mvista.com>
Andrei Konovalov wrote:
> Hi David,
>
> David H. Lynch Jr. wrote:
>>>
>> I have an almost working FIFO TEMAC driver. It is similarly based.
>> it started out based on the Trek webserver sample
>
> Is this a reference design by Xilinx? Linux based or standalone?
I did a Local Link hard TEMAC driver - that I eventually got
working. However, I could not find anyway to
enable interrupts in the Local Link TEMAC so the driver was strictly
polled and between that and other
issues, perfomances was abysmal almost 50% of all inbound packets
were dropped, we switched to the
PLB FIFO TEMAC I stripped out all the SG and DMA stuff (as it is not
in our hardware) and converted it to
a fairly normal Linux ethernet driver. It sends, it receives, but I
beleive it is not properly confirming to Linux
that packets were successfully sent.
In the interim I have been using the posted driver that uses the EDK.
Until more recently that has lacked features like
autonegotiation.
I beleive its current flaw is primarily massive violations of kernel
code style guidelines.
>
>> I spent probably 3-4 days de-EDKing it into something that fit into a
>> single source and was closer to ko norms.
>> It is based on approximately the EDK 8.1 stuff. You are welcome to it,
>> if it could be helpful in anyway.
>> I am all for getting an acceptable driver into the ko tree.
>
> You could post your driver to the list when you think it is in good
> enough shape.
> If your driver is based on the linux TEMAC driver from EDK, it shouldn't
> be very different from my version (my added value is mostly replacing the
> custom PHY code with the PHY lib stuff). Then we could merge our
> drivers (or
> whatever would make sense).
>
> I would be interested to have a look at your current code just to see
> how much has it cost to "de-EDK" the FIFO part. You could email me
> your (even not quite working) driver privately if you want.
I will email you a copy separately. I do not care what you choose to
do with it.
At the moment I have no time to take it further - something about
asses, alligators
and clearing swamps.
Mostly I would just like to see a Linux friendly driver make its way
into the kernel.
I have almost exactly the same code working as a GHS integrity driver.
In fact I sort of ported a mini shim layer to GHS to implement Linux
SKB's under GHS.
I did trip over something with GHS. If I was able to 64bit align the
data part of the skb
the send/receive code code be vastly simplified.
I have not but I have not done that yet.
>
>
> Thanks,
> Andrei
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Latest GCC/GLIBC working combo for a Linux 2.4.x kernel?
From: Sasvata Chatterjee @ 2007-05-25 0:28 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Hi!
We are using a RHEL/386 machine to cross-compile for Debian/PowerPC (8260)
target, a few year old embedded system that we inherited. The kernel is
2.4.9. Using crosstools, and following Dan Kegel's notes, the combo we have
is gcc-2.95-3/glibc-2.2.5.
Does anybody have any working version using newer versions of the 2.4 kernel
and newer GCC versions for a powerpc-603e target? One motivation is to use
BusyBox-1.5.1, but I am told on that list that GCC 2/x is too old (I tried
before I asked, it doesn't compile).
Any help, pointers, example config files for crosstools, etc. would be
really appreciated!
Thanks in advance,
Shash
[-- Attachment #2: Type: text/html, Size: 699 bytes --]
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Benjamin Herrenschmidt @ 2007-05-25 0:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <2994f78d2591e45517247003d613bb98@kernel.crashing.org>
On Fri, 2007-05-25 at 01:54 +0200, Segher Boessenkool wrote:
> This is equivalent to the ethernet driver passing this information
> to phylib via the init arguments.
>
> You still have the same problems as Andy described where the
> necessary workaround is not something local to phylib, but
> needs cooperation of the ethernet code or the soc code or
> some other platform code.
If it's in the PHY device node, the ethernet driver doesn't need to be
involved more than calling some generic helper that finds the right
node, parses it and generates known flags.
> Since the specific bug we're talking about here is not a
> problem with the PHY, but a miswiring on the board, I wouldn't
> put a flag for the workaround in the phy node in the device
> tree. It certainly is an option though.
Why ? That's the perfect place to put it in !
> > The problem is that of course the PHY driver will need some powerpc
> > specific code to go fetch that.
>
> The ethernet driver can handle it, instead.
I don't understand why you want to involve the ethernet driver in
something that doesn't have much to do with it. A pin of the PHY is
miswired causing something to be enabled that shouldn't be. Ok, there is
indeed the fact that the problem is partially related to the TSI
ethernet not supporting when that PHY feature is "enabled" but still...
it's a PHY setting, totally specific to a given PHY revision, I'm not
sure there's much point in having it in the eth driver.
Ben.
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Segher Boessenkool @ 2007-05-24 23:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <1180047084.32247.1070.camel@localhost.localdomain>
> For powerpc, I have a solution at hand, it's the device-tree :-)
>
> Any struct device in the system can have a device node pointer via the
> dev_sysdata thingy I added recently. So we can have some code for
> powerpc that properly hooks up the PHY to an (optional) device-node
> which can then contains properties describing what kind of workarounds
> need to be applied.
>
> For example, we can have a txc-rxc-delay-disable property on Holly.
This is equivalent to the ethernet driver passing this information
to phylib via the init arguments.
You still have the same problems as Andy described where the
necessary workaround is not something local to phylib, but
needs cooperation of the ethernet code or the soc code or
some other platform code.
Since the specific bug we're talking about here is not a
problem with the PHY, but a miswiring on the board, I wouldn't
put a flag for the workaround in the phy node in the device
tree. It certainly is an option though.
> The problem is that of course the PHY driver will need some powerpc
> specific code to go fetch that.
The ethernet driver can handle it, instead.
> An option would be to instead use flags
> and have a piece of powerpc specific code that translates those
> device-tree properties into flags so that other archs can use the flags
> using their own ways of passing them in.
It really shouldn't ever be needed on any other board, but
sure.
> I'm not too hot with the flag stuff tho since those really need to be
> defined per PHY model/family. But I suppose that's fair enough.
Divide the flags arg into a generic and a chip-specific part?
Segher
^ permalink raw reply
* Re: TSI ethernet PHY question
From: Benjamin Herrenschmidt @ 2007-05-24 22:51 UTC (permalink / raw)
To: Andy Fleming; +Cc: Alexandre Bounine, David Gibson, linuxppc-dev list
In-Reply-To: <396FEEDC-99AB-4E25-9C80-A901923429B0@freescale.com>
> For instance, I think #1 might usually be workable by passing in PHY-
> specific flags, and letting the PHY driver deal with it in
> config_init. This might even be workable for the BCM5461A chip as
> mentioned above. You could define a BCM5461A_TXC_RXC_DELAY_DISABLE
> flag, and have the config_init code check for that flag and perform
> the necessary disable.
For powerpc, I have a solution at hand, it's the device-tree :-)
Any struct device in the system can have a device node pointer via the
dev_sysdata thingy I added recently. So we can have some code for
powerpc that properly hooks up the PHY to an (optional) device-node
which can then contains properties describing what kind of workarounds
need to be applied.
For example, we can have a txc-rxc-delay-disable property on Holly.
The problem is that of course the PHY driver will need some powerpc
specific code to go fetch that. An option would be to instead use flags
and have a piece of powerpc specific code that translates those
device-tree properties into flags so that other archs can use the flags
using their own ways of passing them in.
I'm not too hot with the flag stuff tho since those really need to be
defined per PHY model/family. But I suppose that's fair enough.
Ben.
^ permalink raw reply
* [PATCH] mpc52xx: Correct calculation of FEC RX errors.
From: Grzegorz Bernacki @ 2007-05-24 22:01 UTC (permalink / raw)
To: linuxppc-embedded
'ifconfig eth0' command for mpc5200B-based cards shows error for RX.
However none of RX MIB counters is set to value greater than zero.
Number of errors is equal to number of multicast packet. In linux 2.4
calculation of RX errors is slightly different and takes into account
number of multicast packet. This change is a port of calculation method
of RX errors for FEC controller from linux 2.4 to 2.6.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
---
drivers/net/fec_mpc52xx/fec.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c
index f0ce87e..d2087f6 100644
--- a/drivers/net/fec_mpc52xx/fec.c
+++ b/drivers/net/fec_mpc52xx/fec.c
@@ -395,7 +395,9 @@ static struct net_device_stats *fec_get_stats(struct
net_device *dev)
stats->rx_bytes = in_be32(&fec->rmon_r_octets);
stats->rx_packets = in_be32(&fec->rmon_r_packets);
- stats->rx_errors = stats->rx_packets -
in_be32(&fec->ieee_r_frame_ok);
+ stats->rx_errors = stats->rx_packets - (
+ in_be32(&fec->ieee_r_frame_ok) +
+ in_be32(&fec->rmon_r_mc_pkt));
stats->tx_bytes = in_be32(&fec->rmon_t_octets);
stats->tx_packets = in_be32(&fec->rmon_t_packets);
stats->tx_errors = stats->tx_packets - (
^ permalink raw reply related
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-24 22:09 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <2ded9f19fbaf49a89ed6e32de87f5828@kernel.crashing.org>
> For files that will only ever
> be used on 440, the correct flags are -mcpu=440 -Wa,-m440 .
For the archives: just -mcpu=440 is fine (it implies the
assembler option, via GCC specs).
Segher
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-24 22:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705242316.29713.arnd@arndb.de>
> 1. Pass -Wa,-many to gcc
> This will really allow any possible instruction to be assembled,
> including
> the old POWER architecture, but also includes all the other strange
> stuff like -maltivec, -mspe, -me500, ...
And it doesn't prevent the compiler from compiling insns
that can never work on the platform; for example, the
compiler in the original bug report will happily put isel
insns all over the place.
> 2. protect the use of special instructions with .machine directives.
> You can write all the inline assemblies like
>
> .machine push
> .machine 440
> <440 specific instruction>
> .machine pop
>
> This should work in any reasonably recent version of binutils, meaning
> that we don't need to pass stuff like -Wa,-m440 any more.
[You don't need the assembler flag at all, just the compiler
flag -mcpu=440].
This of course works, but is ultra-silly to do in a file
that will never run on anything other than 440 systems.
Segher
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-24 22:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <1180038295.3360.29.camel@zod.rchland.ibm.com>
> Yeah, it's finding those combinations that work for all the existing
> toolchains out there that's the issue.
No, it was a simple bug -- we shouldn't pass an assembler
flag for 440.o and ebony.o, but a compiler flag.
Segher
^ permalink raw reply
* Re: 440 ebony patch seems to have broken 85xx build on powerpc.git
From: Segher Boessenkool @ 2007-05-24 22:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705242221.17790.arnd@arndb.de>
>>> Nothing is telling GCC what CPU to compile for, so it
>>> will just use the compiler's default, which very likely
>>> is not what you want. =A0For files that will only ever
>>> be used on 440, the correct flags are -mcpu=3D440 -Wa,-m440 .
>>
>> We could add that to the per-file flags already, right?
>
> I think it should really use -mcpu=3Dpowerpc on all files.
> The problem that Dave saw was the result of using a compiler
> that defaults to -mcpu=3D8540, which uses instruction that
> don't work on 440.
No, those options _do_ work on 440, but the -mbooke
assembler flag disallows isel (since it is an optional
insn).
> The common files really need to be built with -mcpu flags that
> make the code work on any system if you want to be able
> to use just a single boot wrapper binary for all.
On any system where they can run at all, yes. It should
be fine to compile a 440-only file with 440-specific flags.
Segher
^ permalink raw reply
* Re: [PATCH 1/13] powerpc: Add Makefile rules to wrap dts file in zImage
From: Mark A. Greer @ 2007-05-24 21:28 UTC (permalink / raw)
To: Mark A. Greer, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070522002349.GA25426@localhost.localdomain>
On Tue, May 22, 2007 at 10:23:49AM +1000, David Gibson wrote:
> On Mon, May 21, 2007 at 11:10:43AM -0700, Mark A. Greer wrote:
> > On Mon, May 14, 2007 at 10:33:32AM +1000, David Gibson wrote:
> > > On Fri, May 11, 2007 at 05:53:36PM -0700, Mark A. Greer wrote:
> > > > +$(obj)/zImage.dts: $(addprefix $(obj)/, $(dts-y))
> > > > + @rm -f $@; ln $< $@
> > > > +$(obj)/zImage.dts_initrd: $(addprefix $(obj)/, $(dts_initrd-y))
> > > > + @rm -f $@; ln $< $@
> > > > +
> > >
> > > I thought you said you were going to drop this bit?
> >
> > Hi David.
> >
> > Would you elaborate on what your alternative is? A lot of the Makefile
> > stuff is still black magic to me.
>
> Just leave them out. As long as you add the correct specific
> zImage.dts.% and zImage.dts_initrd.% targets to image-y and initrd-y,
> then a "make zImage" from the top-level Makefile will get them built.
That defeats the whole purpose of the patch--to allow the selection of
wrapping a dtb or not at build time. Its just like initrd, you choose
whether to "do it" at build time.
Mark
^ permalink raw reply
* Re: [PATCH 2/10] spidernet: beautify error messages
From: Jeff Garzik @ 2007-05-24 21:27 UTC (permalink / raw)
To: Linas Vepstas
Cc: Andrew Morton, netdev, Florin Malita, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20070522231354.GA2147@austin.ibm.com>
Linas Vepstas wrote:
> Make error messages print which interface they apply to.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
>
> ----
> drivers/net/spider_net.c | 10 ++++++----
> drivers/net/spider_net.h | 2 +-
> 2 files changed, 7 insertions(+), 5 deletions(-)
applied 2-10 to #upstream (2.6.23)
^ permalink raw reply
* Re: [PATCH 1/10] spidernet: skb used after netif_receive_skb
From: Jeff Garzik @ 2007-05-24 21:25 UTC (permalink / raw)
To: Linas Vepstas
Cc: Andrew Morton, netdev, Florin Malita, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20070522230942.GT5921@austin.ibm.com>
Linas Vepstas wrote:
> From: Florin Malita <fmalita@gmail.com>
>
> The stats update code in spider_net_pass_skb_up() is touching the skb
> after it's been passed up to the stack. To avoid that, just update the
> stats first.
>
> Signed-off-by: Florin Malita <fmalita@gmail.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> ----
>
> drivers/net/spider_net.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
applied to #upstream-fixes
^ 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