* Re: porting pci driverfrom arch=ppc on kernel 2.6.16 to arch=powerpc on 2.6.24...
From: Scott Wood @ 2008-05-06 19:41 UTC (permalink / raw)
To: Mike Timmons; +Cc: Mark Gibson, linuxppc-embedded
In-Reply-To: <161B3BAD77161449A144FF054231C3D6020D6B08@uss-am-xch-01.am.trimblecorp.net>
Mike Timmons wrote:
> If I'm not supposed to read the interrupt using config_read, should I
> also not be writing to the host register on the coral P to clear the
> interrupt?
>
> Should I instead be using some PCI helper functions?
No, clearing interrupts is device-specific.
Have you verified that the device does not think it's generating an
interrupt during the interrupt storm? Do other PCI cards work?
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 core
From: Josh Boyer @ 2008-05-06 19:41 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200805061841.44277.sr@denx.de>
On Tue, 6 May 2008 18:41:44 +0200
Stefan Roese <sr@denx.de> wrote:
> On Tuesday 06 May 2008, Josh Boyer wrote:
> > > The new 440x6 core used on AMCC 460EX/GT introduces new storage attibure
> > > fields to the TLB2 word. Those are:
> > >
> > > Bit 11 12 13 14 15
> > > WL1 IL1I IL1D IL2I IL2D
> > >
> > > With these bits the cache (L1 and L2) can be configured in a more
> > > flexible way, instruction- and data-cache independently now. The "old" I
> > > and W bits are still available and setting these old bits will
> > > automically set these new bits too (for backward compatibilty).
> > >
> > > The current code does not clear these fields resulting in disabling the
> > > cache by chance. This patch now makes sure that these new bits are
> > > cleared when the TLB2 word is written.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > Finally catching back up with email. This looks like .26 material,
> > correct?
>
> Definitely, yes.
Figured. I have it queued up.
josh
^ permalink raw reply
* Please pull 'for-2.6.26' branch of 4xx tree
From: Josh Boyer @ 2008-05-06 19:57 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26
to pick up a small number of fixes for 4xx. One corrects the PCI
addresses for Sequoia boards, another fixes TLB issues with newer 440x6
cores. Stefan's pci-e endpoint driver is also included here as it is
a fairly contained change with Ben's Ack. It should have been included
in my last pull request, but I missed it and have been out.
thx,
josh
Christian Ehrhardt (1):
[POWERPC] 4xx: Fix PCI mem in sequoia DTS
Stefan Roese (2):
[POWERPC] 4xx: Fix problem with new TLB storage attibute fields on 440x6 c
[POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
arch/powerpc/boot/dts/sequoia.dts | 9 ++-
arch/powerpc/kernel/head_44x.S | 9 ++-
arch/powerpc/sysdev/ppc4xx_pci.c | 180 +++++++++++++++++++++++++----------
include/asm-powerpc/pgtable-ppc32.h | 7 ++
4 files changed, 153 insertions(+), 52 deletions(-)
^ permalink raw reply
* arch/ppc is broken
From: Josh Boyer @ 2008-05-06 20:09 UTC (permalink / raw)
To: linuxppc-dev
Every arch/ppc defconfig I built today failed. Someone broke it.
Those interested in fixing it might want to see why. I suspect the
ppc/powerpc: use kbuild.h instead of defining macros in asm-offsets.c
is responsible, but I have no evidence of that.
josh
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:152: error: '__flush_icache_range' undeclared here (not in a function)
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:152: warning: type defaults to 'int' in declaration of '__flush_icache_range'
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:153: error: 'flush_dcache_range' undeclared here (not in a function)
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:153: warning: type defaults to 'int' in declaration of 'flush_dcache_range'
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:154: error: 'flush_icache_user_range' undeclared here (not in a function)
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:154: warning: type defaults to 'int' in declaration of 'flush_icache_user_range'
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:155: error: 'flush_dcache_page' undeclared here (not in a function)
/home/jwboyer/src/linux-2.6/arch/ppc/kernel/ppc_ksyms.c:155: warning: type defaults to 'int' in declaration of 'flush_dcache_page'
make[2]: *** [arch/ppc/kernel/ppc_ksyms.o] Error 1
/home/jwboyer/src/linux-2.6/arch/powerpc/kernel/prom_init.c:130: error: expected specifier-qualifier-list before 'ihandle'
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: Rick Jones @ 2008-05-06 20:07 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linuxppc-dev
In-Reply-To: <20080506192008.GA30148@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> Hi all,
>
> Down here few question regarding networking throughput, I would
> appreciate any thoughts or ideas.
>
> On the MPC8315E-RDB board (CPU at 400MHz, CSB at 133 MHz) I'm observing
> relatively low TCP throughput using gianfar driver...
What is the "target" of the test - is it another of those boards, or
something else?
>
> The maximum value I've seen with the current kernels is 142 Mb/s of TCP
> and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled):
>
> root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
> TCP STREAM TEST to 10.0.1.1
> #Cpu utilization 0.10
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 206848 212992 32768 10.00 142.40
>
> root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344
> UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
> #Cpu utilization 100.00
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 212992 32768 10.00 13539 0 354.84
> 206848 10.00 13539 354.84
>
I have _got_ to make CPU utilization enabled by default one of these
days :) At least for mechanisms which don't require calibration.
> Is this normal?
Does gianfar do TSO? If not, what happens when you tell UDP_STREAM to
send 1472 byte messages to bypass IP fragmentation?
While stock netperf won't report what the socket buffer size becomes
when you allow autotuning to rear its head, you can take the top of
trunk and enable the "omni" tests (./configure --enable-omni) and those
versions of *_STREAM etc can report what the socket buffer size was at
the beginning and at the end of the test. You can let the stack autotune
and see if anything changes there. You can do the same with stock
netperf, just it will only report the initial socket buffer sizes...
> netperf running in loopback gives me 329 Mb/s of TCP throughput:
>
> root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
> TCP STREAM TEST to 127.0.0.1
> #Cpu utilization 100.00
> #Cpu utilization 100.00
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 212992 212992 32768 10.00 329.60
>
>
> May I consider this as a something that is close to the Linux'
> theoretical maximum for this setup? Or this isn't reliable test?
I'm always leery of using a loopback number. It excercises both send
and receive at the same time, but without the driver. Also, lo tends to
have a much larger MTU than a "standard" NIC and if that NIC doesn't to
TSO and LRO that can be a big difference in the number of times up and
down the stack per KB transferred.
> I can compare with teh MPC8377E-RDB (very similar board - exactly the same
> ethernet phy, the same drivers are used, i.e. everything is the same from
> the ethernet stand point), but running at 666 MHz, CSB at 333MHz:
>
> |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s|
> ------------------------------------------
> MPC8377| 666| 333| 646| 264|
> MPC8315| 400| 133| 354| 142|
> ------------------------------------------
> RATIO | 1.6| 2.5| 1.8| 1.8|
>
> It seems that things are really dependant on the CPU/CSB speed.
What is the nature of the DMA stream between the two tests? I find it
interesting that the TCP Mb/s went up by more than the CPU MHz and
wonder how much the Bus MHz came into play there - perhaps there were
more DMA's to setup or across a broader memory footprint for TCP than
for UDP.
>
> I've tried to tune gianfar driver in various ways... and it gave
> some positive results with this patch:
>
> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
> index fd487be..b5943f9 100644
> --- a/drivers/net/gianfar.h
> +++ b/drivers/net/gianfar.h
> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
> #define GFAR_10_TIME 25600
>
> #define DEFAULT_TX_COALESCE 1
> -#define DEFAULT_TXCOUNT 16
> -#define DEFAULT_TXTIME 21
> +#define DEFAULT_TXCOUNT 80
> +#define DEFAULT_TXTIME 105
>
> #define DEFAULT_RXTIME 21
No ethtool coalescing tuning support for gianfar?-)
> Basically this raises the tx interrupts coalescing threshold (raising
> it more didn't help, as well as didn't help raising rx thresholds).
> Now:
>
> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
> TCP STREAM TEST to 10.0.1.1
> #Cpu utilization 100.00
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 206848 212992 32768 3.00 163.04
>
>
> That is +21 Mb/s (14% up). Not fantastic, but good anyway.
>
> As expected, the latency increased too:
>
> Before the patch:
>
> --- 10.0.1.1 ping statistics ---
> 20 packets transmitted, 20 received, 0% packet loss, time 18997ms
> rtt min/avg/max/mdev = 0.108/0.124/0.173/0.022 ms
>
> After:
>
> --- 10.0.1.1 ping statistics ---
> 22 packets transmitted, 22 received, 0% packet loss, time 20997ms
> rtt min/avg/max/mdev = 0.158/0.167/0.182/0.004 ms
>
>
> 34% up... heh. Should we sacrifice the latency in favour of throughput?
> Is 34% latency growth bad thing? What is worse, lose 21 Mb/s or 34% of
> latency? ;-)
Well, I'm not always fond of that sort of trade-off:
ftp://ftp.cup.hp.com/dist/networking/briefs/
there should be a nic latency vs tput writeup there.
>
>
> Thanks in advance,
>
> p.s. Btw, the patch above helps even better on the on the -rt kernels,
> since on the -rt kernels the throughput is near 100 Mb/s, with the
> patch the throughput is close to 140 Mb/s.
>
^ permalink raw reply
* Re: [RFC] gianfar: low gigabit throughput
From: Andy Fleming @ 2008-05-06 20:29 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, linuxppc-dev
In-Reply-To: <4820BA72.3090903@hp.com>
>>
>> I've tried to tune gianfar driver in various ways... and it gave
>> some positive results with this patch:
>> diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
>> index fd487be..b5943f9 100644
>> --- a/drivers/net/gianfar.h
>> +++ b/drivers/net/gianfar.h
>> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
>> #define GFAR_10_TIME 25600
>> #define DEFAULT_TX_COALESCE 1
>> -#define DEFAULT_TXCOUNT 16
>> -#define DEFAULT_TXTIME 21
>> +#define DEFAULT_TXCOUNT 80
>> +#define DEFAULT_TXTIME 105
>> #define DEFAULT_RXTIME 21
>
> No ethtool coalescing tuning support for gianfar?-)
Yeah, there's coalescing tuning in gianfar.
Anton, those numbers aren't too surprising on a 400 MHz machine, I
think. But I'd be happy to see any analysis on performance
bottlenecks in the driver. And patches to fix those bottlenecks are
even better! :)
Andy
^ permalink raw reply
* Strange build error in boot/wrapper script
From: Gerhard Pircher @ 2008-05-06 20:52 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I get a rather strange error here with kernel v2.6.26-rc1 and gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (cross compile version).
This is the output of the build process:
> $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- zImage
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALL scripts/checksyscalls.sh
> CHK include/linux/compile.h
> CALL arch/powerpc/kernel/systbl_chk.sh
> CALL arch/powerpc/kernel/prom_init_check.sh
> WRAP arch/powerpc/boot/uImage
> Image Name: Linux-2.6.26-rc1
> Created: Tue May 6 22:43:54 2008
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1780300 Bytes = 1738.57 kB = 1.70 MB
> Load Address: 0x00000000
> Entry Point: 0x00000000
> arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/amigaone.dtb -b 0 /home/geri/AmigaOne/Linux/linux-2.6.26/arch/powerpc/boot/dts/amigaone.dts
> DTC: dts->dtb on file "/home/geri/AmigaOne/Linux/linux-2.6.26/arch/powerpc/boot/dts/amigaone.dts"
> WRAP arch/powerpc/boot/cuImage.amigaone
> powerpc-linux-gnu-objcopy: Warning: could not locate './vmlinux.strip'. reason: The value is too big for the defined data type (translated to English)
> Image Name: Linux-2.6.26-rc1
> Created: Tue May 6 22:43:54 2008
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 21675 Bytes = 21.17 kB = 0.02 MB
> Load Address: 0x00400000
> Entry Point: 0x00400444
> rm arch/powerpc/boot/amigaone.dtb
As you can see, the wrapper script generates an incomplete cuImage. The
vmlinux.strip file is there, but I wonder why it is so big:
> -rw-r--r-- 3225085348 2008-05-06 21:58 vmlinux.strip
Any ideas what is going wrong here? Broken compiler?
Thanks!
regards,
Gerhard
--
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de
^ permalink raw reply
* ifconfig MPC8313
From: Ronald Madrid @ 2008-05-06 21:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
Hello all,
I am working on porting linux 2.6.25 with a custom MPC8313 based board, but am having a little bit of trouble with the ethernet, more specifically ifconfig.
after typing "ifconfig eth0 10.196.31.84" I receive the following error
ifconfig: SIOCSIFFLAGS: Cannot assign requested address
after entering a MAC address via "ifconfig eth0 hw ether" I receive this error.
e0024520:01 not found
eth0: Could not attach to PHY
ifconfig: SIOCSIFFLAGS: No such device
which I have traced to bus_find_device, but I'm not sure what to make of this.
I'm not sure where I'm going wrong here, and I'm sure that it's something that I'm forgetting to do/include.
Sorry if this isn't enough information, but I don't know enough to know what other information would be needed.
Ron
_________________________________________________________________
Get Free (PRODUCT) RED™ Emoticons, Winks and Display Pics.
http://joinred.spaces.live.com?ocid=TXT_HMTG_prodredemoticons_052008
[-- Attachment #2: Type: text/html, Size: 1254 bytes --]
^ permalink raw reply
* Re: ifconfig MPC8313
From: Scott Wood @ 2008-05-06 21:19 UTC (permalink / raw)
To: Ronald Madrid; +Cc: linuxppc-dev
In-Reply-To: <BAY114-W949ADEBC809E7A60716CCF4D60@phx.gbl>
Ronald Madrid wrote:
> Hello all,
>
> I am working on porting linux 2.6.25 with a custom MPC8313 based board,
> but am having a little bit of trouble with the ethernet, more
> specifically ifconfig.
>
> after typing "ifconfig eth0 10.196.31.84" I receive the following error
> ifconfig: SIOCSIFFLAGS: Cannot assign requested address
>
> after entering a MAC address via "ifconfig eth0 hw ether" I receive
> this error.
> e0024520:01 not found
> eth0: Could not attach to PHY
> ifconfig: SIOCSIFFLAGS: No such device
It can't find the PHY for eth0. What does your device tree look like,
and what is the relevant PHY address?
-Scott
^ permalink raw reply
* RE: ifconfig MPC8313
From: Ronald Madrid @ 2008-05-06 21:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4820CB5D.3000703@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 9304 bytes --]
I'm guessing by device tree you mean the .dts file? I'm using a modified version of the mpc8313erdb.dts with minor changes (to the local bus only). Here is a copy of it./* * MPC8313E RDB Device Tree Source * * Copyright 2005, 2006, 2007 Freescale Semiconductor Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the * Free Software Foundation; either version 2 of the License, or (at your * option) any later version. *//dts-v1/;/ { model = "MPC8313ERDB"; compatible = "MPC8313ERDB", "MPC831xRDB", "MPC83xxRDB"; #address-cells = <1>; #size-cells = <1>; aliases { ethernet0 = &enet0; ethernet1 = &enet1; serial0 = &serial0; serial1 = &serial1; pci0 = &pci0; }; cpus { #address-cells = <1>; #size-cells = <0>; PowerPC,8313@0 { device_type = "cpu"; reg = <0x0>; d-cache-line-size = <32>; i-cache-line-size = <32>; d-cache-size = <16384>; i-cache-size = <16384>; timebase-frequency = <0>; // from bootloader bus-frequency = <0>; // from bootloader clock-frequency = <0>; // from bootloader }; }; memory { device_type = "memory"; reg = <0x00000000 0x08000000>; // 128MB at 0 }; localbus@e0005000 { #address-cells = <2>; #size-cells = <1>; compatible = "fsl,mpc8313-elbc", "fsl,elbc", "simple-bus"; reg = <0xe0005000 0x1000>; interrupts = <77 0x8>; interrupt-parent = <&ipic>; // CS0 and CS1 are swapped when // booting from nand, but the // addresses are the same.// ranges = <0x0 0x0 0xfe000000 0x00800000// 0x1 0x0 0xe2800000 0x00008000// 0x2 0x0 0xf0000000 0x00020000// 0x3 0x0 0xfa000000 0x00008000>; ranges = <0x0 0x0 0xe2800000 0x00008000>;// flash@0,0 {// #address-cells = <1>;// #size-cells = <1>;// compatible = "cfi-flash";// reg = <0x0 0x0 0x800000>;// bank-width = <2>;// device-width = <1>;// };// nand@1,0 { nand@0,0 { #address-cells = <1>; #size-cells = <1>; compatible = "fsl,mpc8313-fcm-nand", "fsl,elbc-fcm-nand";// reg = <0x1 0x0 0x2000>; reg = <0x0 0x0 0x2000>; u-boot@0 { reg = <0x0 0x100000>; read-only; }; kernel@100000 { reg = <0x100000 0x300000>; }; fs@400000 { reg = <0x400000 0x1c00000>; }; }; }; soc8313@e0000000 { #address-cells = <1>; #size-cells = <1>; device_type = "soc"; compatible = "simple-bus"; ranges = <0x0 0xe0000000 0x00100000>; reg = <0xe0000000 0x00000200>; bus-frequency = <0>; wdt@200 { device_type = "watchdog"; compatible = "mpc83xx_wdt"; reg = <0x200 0x100>; }; i2c@3000 { #address-cells = <1>; #size-cells = <0>; cell-index = <0>; compatible = "fsl-i2c"; reg = <0x3000 0x100>; interrupts = <14 0x8>; interrupt-parent = <&ipic>; dfsrr; rtc@68 { compatible = "dallas,ds1339"; reg = <0x68>; }; }; i2c@3100 { #address-cells = <1>; #size-cells = <0>; cell-index = <1>; compatible = "fsl-i2c"; reg = <0x3100 0x100>; interrupts = <15 0x8>; interrupt-parent = <&ipic>; dfsrr; }; spi@7000 { cell-index = <0>; compatible = "fsl,spi"; reg = <0x7000 0x1000>; interrupts = <16 0x8>; interrupt-parent = <&ipic>; mode = "cpu"; }; /* phy type (ULPI, UTMI, UTMI_WIDE, SERIAL) */ usb@23000 { compatible = "fsl-usb2-dr"; reg = <0x23000 0x1000>; #address-cells = <1>; #size-cells = <0>; interrupt-parent = <&ipic>; interrupts = <38 0x8>; phy_type = "utmi_wide"; }; mdio@24520 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,gianfar-mdio"; reg = <0x24520 0x20>; phy1: ethernet-phy@1 { interrupt-parent = <&ipic>; interrupts = <19 0x8>; reg = <0x1>; device_type = "ethernet-phy"; }; phy4: ethernet-phy@4 { interrupt-parent = <&ipic>; interrupts = <20 0x8>; reg = <0x4>; device_type = "ethernet-phy"; }; }; enet0: ethernet@24000 { cell-index = <0>; device_type = "network"; model = "eTSEC"; compatible = "gianfar"; reg = <0x24000 0x1000>; local-mac-address = [ 00 00 00 00 00 00 ]; interrupts = <37 0x8 36 0x8 35 0x8>; interrupt-parent = <&ipic>; phy-handle = < &phy1 >; }; enet1: ethernet@25000 { cell-index = <1>; device_type = "network"; model = "eTSEC"; compatible = "gianfar"; reg = <0x25000 0x1000>; local-mac-address = [ 00 00 00 00 00 00 ]; interrupts = <34 0x8 33 0x8 32 0x8>; interrupt-parent = <&ipic>; phy-handle = < &phy4 >; }; serial0: serial@4500 { cell-index = <0>; device_type = "serial"; compatible = "ns16550"; reg = <0x4500 0x100>; clock-frequency = <0>; interrupts = <9 0x8>; interrupt-parent = <&ipic>; }; serial1: serial@4600 { cell-index = <1>; device_type = "serial"; compatible = "ns16550"; reg = <0x4600 0x100>; clock-frequency = <0>; interrupts = <10 0x8>; interrupt-parent = <&ipic>; }; crypto@30000 { device_type = "crypto"; model = "SEC2"; compatible = "talitos"; reg = <0x30000 0x7000>; interrupts = <11 0x8>; interrupt-parent = <&ipic>; /* Rev. 2.2 */ num-channels = <1>; channel-fifo-len = <24>; exec-units-mask = <0x0000004c>; descriptor-types-mask = <0x0122003f>; }; /* IPIC * interrupts cell = <intr #, sense> * sense values match linux IORESOURCE_IRQ_* defines: * sense == 8: Level, low assertion * sense == 2: Edge, high-to-low change */ ipic: pic@700 { interrupt-controller; #address-cells = <0>; #interrupt-cells = <2>; reg = <0x700 0x100>; device_type = "ipic"; }; }; pci0: pci@e0008500 { cell-index = <1>; interrupt-map-mask = <0xf800 0x0 0x0 0x7>; interrupt-map = < /* IDSEL 0x0E -mini PCI */ 0x7000 0x0 0x0 0x1 &ipic 18 0x8 0x7000 0x0 0x0 0x2 &ipic 18 0x8 0x7000 0x0 0x0 0x3 &ipic 18 0x8 0x7000 0x0 0x0 0x4 &ipic 18 0x8 /* IDSEL 0x0F - PCI slot */ 0x7800 0x0 0x0 0x1 &ipic 17 0x8 0x7800 0x0 0x0 0x2 &ipic 18 0x8 0x7800 0x0 0x0 0x3 &ipic 17 0x8 0x7800 0x0 0x0 0x4 &ipic 18 0x8>; interrupt-parent = <&ipic>; interrupts = <66 0x8>; bus-range = <0x0 0x0>; ranges = <0x02000000 0x0 0x90000000 0x90000000 0x0 0x10000000 0x42000000 0x0 0x80000000 0x80000000 0x0 0x10000000 0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00100000>; clock-frequency = <66666666>; #interrupt-cells = <1>; #size-cells = <2>; #address-cells = <3>; reg = <0xe0008500 0x100>; compatible = "fsl,mpc8349-pci"; device_type = "pci"; };};Ron> Date: Tue, 6 May 2008 16:19:25 -0500> From: scottwood@freescale.com> To: ron_madrid@hotmail.com> CC: linuxppc-dev@ozlabs.org> Subject: Re: ifconfig MPC8313> > Ronald Madrid wrote:> > Hello all,> > > > I am working on porting linux 2.6.25 with a custom MPC8313 based board, > > but am having a little bit of trouble with the ethernet, more > > specifically ifconfig.> > > > after typing "ifconfig eth0 10.196.31.84" I receive the following error> > ifconfig: SIOCSIFFLAGS: Cannot assign requested address> > > > after entering a MAC address via "ifconfig eth0 hw ether" I receive > > this error.> > e0024520:01 not found> > eth0: Could not attach to PHY> > ifconfig: SIOCSIFFLAGS: No such device> > It can't find the PHY for eth0. What does your device tree look like, > and what is the relevant PHY address?> > -Scott
_________________________________________________________________
Windows Live SkyDrive lets you share files with faraway friends.
http://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_052008
[-- Attachment #2: Type: text/html, Size: 21642 bytes --]
^ permalink raw reply
* Re: ifconfig MPC8313
From: Scott Wood @ 2008-05-06 21:35 UTC (permalink / raw)
To: Ronald Madrid; +Cc: linuxppc-dev
In-Reply-To: <BAY114-W46AEF8E266395E333E7FCF4D60@phx.gbl>
Ronald Madrid wrote:
> I'm guessing by device tree you mean the .dts file? I'm using a
> modified version of the mpc8313erdb.dts with minor changes (to the local
> bus only). Here is a copy of it.
OK, according to that device tree, eth0 is associated with PHY address
1. Is that correct on your board?
-Scott
^ permalink raw reply
* Re: arch/ppc is broken
From: Segher Boessenkool @ 2008-05-06 21:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080506150955.0fdcaa85@zod.rchland.ibm.com>
> Every arch/ppc defconfig I built today failed. Someone broke it.
On a related note, arch/ppc defconfig doesn't even configure anymore;
common_defconfig was removed, but it is still the default. What config
should we use as default now?
Josh, I'll look into the build failure now.
Segher
^ permalink raw reply
* RE: ifconfig MPC8313
From: Ronald Madrid @ 2008-05-06 21:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4820CF2A.5040301@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
I don't know, where would I find that out?
Sorry, I'm still kind of new to this.
Ron
> Date: Tue, 6 May 2008 16:35:38 -0500
> From: scottwood@freescale.com
> To: ron_madrid@hotmail.com
> CC: linuxppc-dev@ozlabs.org
> Subject: Re: ifconfig MPC8313
>
> Ronald Madrid wrote:
> > I'm guessing by device tree you mean the .dts file? I'm using a
> > modified version of the mpc8313erdb.dts with minor changes (to the local
> > bus only). Here is a copy of it.
>
> OK, according to that device tree, eth0 is associated with PHY address
> 1. Is that correct on your board?
>
> -Scott
_________________________________________________________________
Stay in touch when you're away with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_messenger_052008
[-- Attachment #2: Type: text/html, Size: 1173 bytes --]
^ permalink raw reply
* Re: ifconfig MPC8313
From: Scott Wood @ 2008-05-06 21:43 UTC (permalink / raw)
To: Ronald Madrid; +Cc: linuxppc-dev
In-Reply-To: <BAY114-W4066C5694CA67654680FB7F4D60@phx.gbl>
Ronald Madrid wrote:
> I don't know, where would I find that out?
>
> Sorry, I'm still kind of new to this.
In the documentation/schematics/designer's-head of your custom board.
-Scott
^ permalink raw reply
* Re: arch/ppc is broken
From: Josh Boyer @ 2008-05-06 21:49 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <e568c51ffa5f865094b26827ef959aa1@kernel.crashing.org>
On Tue, 6 May 2008 23:39:34 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Every arch/ppc defconfig I built today failed. Someone broke it.
>
> On a related note, arch/ppc defconfig doesn't even configure anymore;
> common_defconfig was removed, but it is still the default. What config
> should we use as default now?
I'd be willing to guess that the answer is "nothing". You're welcome
to use ebony_defconfig but that's just as much unmaintained as the rest
of arch/ppc and only builds when someone doesn't break it.
> Josh, I'll look into the build failure now.
Masochist ;)
josh
^ permalink raw reply
* RE: ifconfig MPC8313
From: Ronald Madrid @ 2008-05-06 21:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4820D11D.1050005@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
I believe that it is zero. Is that valid?
Ron
> Date: Tue, 6 May 2008 16:43:57 -0500
> From: scottwood@freescale.com
> To: ron_madrid@hotmail.com
> CC: linuxppc-dev@ozlabs.org
> Subject: Re: ifconfig MPC8313
>
> Ronald Madrid wrote:
> > I don't know, where would I find that out?
> >
> > Sorry, I'm still kind of new to this.
>
> In the documentation/schematics/designer's-head of your custom board.
>
> -Scott
_________________________________________________________________
With Windows Live for mobile, your contacts travel with you.
http://www.windowslive.com/mobile/overview.html?ocid=TXT_TAGLM_WL_Refresh_mobile_052008
[-- Attachment #2: Type: text/html, Size: 984 bytes --]
^ permalink raw reply
* Re: ifconfig MPC8313
From: Scott Wood @ 2008-05-06 22:04 UTC (permalink / raw)
To: Ronald Madrid; +Cc: linuxppc-dev
In-Reply-To: <BAY114-W13CCF7FDD3C01260AC40A9F4D60@phx.gbl>
Ronald Madrid wrote:
> I believe that it is zero. Is that valid?
FWIH, it's not recommended, as it's interpreted as a broadcast address
in some cases. However, if that's the way the board is, then go ahead
and put a zero in the phy node's reg property.
-Scott
^ permalink raw reply
* Re: arch/ppc is broken
From: Segher Boessenkool @ 2008-05-06 22:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080506164915.3f15cfe8@zod.rchland.ibm.com>
>> On a related note, arch/ppc defconfig doesn't even configure anymore;
>> common_defconfig was removed, but it is still the default. What
>> config
>> should we use as default now?
>
> I'd be willing to guess that the answer is "nothing".
Plain "defconfig" should use _something_. Something that still exists,
even.
> You're welcome to use ebony_defconfig
Yeah, that's what I use again now.
> but that's just as much unmaintained as the rest
> of arch/ppc and only builds when someone doesn't break it.
That's more often than "never even starts to build" ;-)
>> Josh, I'll look into the build failure now.
>
> Masochist ;)
Sadist.
Segher
^ permalink raw reply
* RE: ifconfig MPC8313
From: Ronald Madrid @ 2008-05-06 22:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4820D5E5.9030509@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
Thank you, that seems to have worked. I can now ping and whatnot. One question though. I used the linux v2.6.20 that came with the BSP for the MPC8313ERDB and the ethernet worked. Was there a bug earlier that would have allowed this default .dts to work with my phy address of '0'? I was rather baffled with this problem as the two dts files seemed to be more or less functionally identical (2.6.20 from BSP vs. 2.6.25)
Ron
> Date: Tue, 6 May 2008 17:04:21 -0500
> From: scottwood@freescale.com
> To: ron_madrid@hotmail.com
> CC: linuxppc-dev@ozlabs.org
> Subject: Re: ifconfig MPC8313
>
> Ronald Madrid wrote:
> > I believe that it is zero. Is that valid?
>
> FWIH, it's not recommended, as it's interpreted as a broadcast address
> in some cases. However, if that's the way the board is, then go ahead
> and put a zero in the phy node's reg property.
>
> -Scott
_________________________________________________________________
Make Windows Vista more reliable and secure with Windows Vista Service Pack 1.
http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner
[-- Attachment #2: Type: text/html, Size: 1444 bytes --]
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Andy Fleming @ 2008-05-06 22:54 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080311114601.GA19189@netgate.macqel>
> Now back to the first an bigger problem :
> currently, I have an "old" U-boot and I have written myself a dts
> file.
>
> Problem is : ethernet does not work, but that's not a mac-address
> problem,
> but something else that I do not understand yet. The symptom is I get
>
> ip route add default via 192.168.85.33 dev eth0
> RTNETLINK answers: Network is unreachable
>
> I surmise this is because my eth0 does not become up, and I surmise
> again this is because there is no driver selected to drive the phy.
>
> In my arch/ppc setup this was automagically handled by fixed@100:1
> IIRC
>
> Is there something I can put in my dts file to activate a driver for
> my phy ?
>
> Best regards
This slipped under my radar, and I'm only just now finding it again.
Have your issues been resolved? If not, could you send a bit more of
the boot log? There should be a little more if the PHY was not
found. If you were operating with a fixed PHY setup before, then the
generic PHY driver (which will automatically bind to your PHY) should
suffice unless your MDIO bus is broken.
Andy
^ permalink raw reply
* [PATCH 2/3] ppc: Include <asm/cacheflush.h> in kernel/ppc_ksyms.c
From: Segher Boessenkool @ 2008-05-06 22:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cf74cd88187bdd9378fbb0a0ff7d53ac3a7b23d2.1210114487.git.segher@kernel.crashing.org>
It needs it:
arch/ppc/kernel/ppc_ksyms.c:152: error: '__flush_icache_range'
undeclared here (not in a function)
and a few more like that.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/ppc/kernel/ppc_ksyms.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index 16ac11c..602c268 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -24,6 +24,7 @@
#include <asm/checksum.h>
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
+#include <asm/cacheflush.h>
#include <linux/adb.h>
#include <linux/cuda.h>
#include <linux/pmu.h>
--
1.5.5.23.g2a5f.dirty
^ permalink raw reply related
* [PATCH 3/3] powerpc: Don't run prom_init_check for arch/ppc builds
From: Segher Boessenkool @ 2008-05-06 22:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cf74cd88187bdd9378fbb0a0ff7d53ac3a7b23d2.1210114487.git.segher@kernel.crashing.org>
arch/ppc doesn't have prom_init.o (anymore).
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/Makefile | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index d14cebf..2346d27 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -105,6 +105,9 @@ PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
+
+ifeq ($(CONFIG_PPC_MERGE),y)
+
$(obj)/built-in.o: prom_init_check
quiet_cmd_prom_init_check = CALL $<
@@ -114,4 +117,7 @@ PHONY += prom_init_check
prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o
$(call cmd,prom_init_check)
+endif
+
+
clean-files := vmlinux.lds
--
1.5.5.23.g2a5f.dirty
^ permalink raw reply related
* [PATCH 1/3] ppc: Use ebony_defconfig for defconfig
From: Segher Boessenkool @ 2008-05-06 22:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1210114730-5047-1-git-send-email-segher@kernel.crashing.org>
We used to use common_defconfig, but it was removed some time ago.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/ppc/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/Makefile b/arch/ppc/Makefile
index 8df7f0e..2352d13 100644
--- a/arch/ppc/Makefile
+++ b/arch/ppc/Makefile
@@ -43,7 +43,7 @@ KBUILD_AFLAGS += $(cpu-as-y)
KBUILD_CFLAGS += $(cpu-as-y)
# Default to the common case.
-KBUILD_DEFCONFIG := common_defconfig
+KBUILD_DEFCONFIG := ebony_defconfig
head-y := arch/ppc/kernel/head.o
head-$(CONFIG_8xx) := arch/ppc/kernel/head_8xx.o
--
1.5.5.23.g2a5f.dirty
^ permalink raw reply related
* Fix arch/ppc builds
From: Segher Boessenkool @ 2008-05-06 22:58 UTC (permalink / raw)
To: linuxppc-dev
These three trivial patches make arch/ppc build again.
Segher
^ permalink raw reply
* Re: [PATCH] Add support for Analogue & Micro ASP837E board
From: Bryan O'Donoghue @ 2008-05-06 23:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <8D90346B-3E16-4B77-BFF0-35F1FAA1B2B8@kernel.crashing.org>
On Tue, 6 May 2008 08:37:16 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
/;
> > +
> > +/ {
> > + model = "ASP8347E";
> > + compatible = "ASP8347E";
>
> "analogue-and-micro, ASP8347E";
Fair enough.
> > + memory {
> > + device_type = "memory";
> > + reg = <0x00000000 0x8000000>; // 128MB at 0
>
> is memory really fixed on this board or does the bootloader set this
> if, dynamic make it <0 0>
It's fixed as far as I know.
> > + soc8349@ff000000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + ranges = <0x0 0xff000000 0xff100000>;
>
> this is wrong, size should be like 0x100000
Agreed - typo !
> > + enet0: ethernet@24000 {
> > + cell-index = <0>;
> > + device_type = "network";
> > + model = "TSEC";
> > + compatible = "gianfar";
> > + reg = <0x24000 0x1000>;
> > + local-mac-address = [ 00 08 e5 11 32 33 ];
> > + interrupts = <32 0x8 33 0x8 34 0x8>;
> > + interrupt-parent = <&ipic>;
> > + phy-handle = <&phy0>;
> > + linux,network-index = <0>;
>
> you shouldn't need this anymore. we should be using the aliases.
Aliases sound good to me. Don't know too much about how this should be defined
in a dts though, do you have an example I could use as a base for reference ?
Cheers.
^ 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