* [PATCH] kprobes/powerpc: Fix possible system crash during out-of-line single-stepping
From: Ananth N Mavinakayanahalli @ 2006-08-11 11:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: willschm, Paul Mackerras, Anton Blanchard
- On archs that have no-exec support, we vmalloc() a executable scratch
area of PAGE_SIZE and divide it up into an array of slots of maximum
instruction size for that arch
- On a kprobe registration, the original instruction is copied to the
first available free slot, so if multiple kprobes are registered, chances
are, they get contiguous slots
- On POWER4, due to not having coherent icaches, we could hit a situation
where a probe that is registered on one processor, is hit immediately on
another. This second processor could have fetched the stream of text from
the out-of-line single-stepping area *before* the probe registration
completed, possibly due to an earlier (and a different) kprobe hit and
hence would see stale data at the slot.
Executing such an arbitrary instruction lead to a problem as reported
in LTC bugzilla 23555.
The correct solution is to call flush_icache_range() as soon as the
instruction is copied for out-of-line single-stepping, so the correct
instruction is seen on all processors.
Thanks to Will Schmidt who tracked this down.
Ananth
---
Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
---
arch/powerpc/kernel/kprobes.c | 2 ++
1 files changed, 2 insertions(+)
Index: linux-2.6.18-rc4/arch/powerpc/kernel/kprobes.c
===================================================================
--- linux-2.6.18-rc4.orig/arch/powerpc/kernel/kprobes.c
+++ linux-2.6.18-rc4/arch/powerpc/kernel/kprobes.c
@@ -61,6 +61,8 @@ int __kprobes arch_prepare_kprobe(struct
if (!ret) {
memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
p->opcode = *p->addr;
+ flush_icache_range((unsigned long)p->ainsn.insn,
+ (unsigned long)p->ainsn.insn + sizeof(kprobe_opcode_t));
}
return ret;
^ permalink raw reply
* Re: [PATCH 1/6] ehea: interface to network stack
From: Jan-Bernd Themann @ 2006-08-11 11:02 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <200608091108.51774.borntrae@de.ibm.com>
Hi Christian,
thanks for your comments, we'll send an updated patch set soon.
Jan-Bernd
Christian Borntraeger wrote:
> Hi Jan-Bernd,
>
> I had some minutes, here are some finding after a quick look.
>
> On Wednesday 09 August 2006 10:38, you wrote:
>> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
>> +{
>> + int i;
>> + u64 hret = H_HARDWARE;
>> + u64 rx_packets = 0;
>> + struct ehea_port *port = (struct ehea_port*)dev->priv;
>
> dev->priv is a void pointer, this cast is unnecessary. When we are at it, have
> you considered the netdev_priv macro? This will require some prep in
> alloc_netdev and might not always pe possible.
good point, we'll use alloc_etherdev / netdev_priv
>> +
>> + EDEB_DMP(7, (u8*)cb2,
>> + sizeof(struct hcp_query_ehea_port_cb_2), "After HCALL");
>> +
>> + for (i = 0; i < port->num_def_qps; i++) {
>> + rx_packets += port->port_res[i].rx_packets;
>> + }
>> +
>> + stats->tx_packets = cb2->txucp + cb2->txmcp + cb2->txbcp;
>> + stats->multicast = cb2->rxmcp;
>> + stats->rx_errors = cb2->rxuerr;
>> + stats->rx_bytes = cb2->rxo;
>> + stats->tx_bytes = cb2->txo;
>> + stats->rx_packets = rx_packets;
>> +
>> +get_stat_exit:
>> + EDEB_EX(7, "");
>> + return stats;
>> +}
>
> again, cb2 is not freed.
> [...]
yep, done
>
>> +static inline u64 get_swqe_addr(u64 tmp_addr, int addr_seg)
>> +{
>> + u64 addr;
>> + addr = tmp_addr;
>> + return addr;
>> +}
>
> This is suppsed to change in the future? If not you can get rid of it.
>
>> +
>> +static inline u64 get_rwqe_addr(u64 tmp_addr)
>> +{
>> + return tmp_addr;
>> +}
>
> same here.
removed
>> + ehea_poll()
>
> The poll function seems too long and therefore hard to review. Please consider
> splitting it.
>
>
done
^ permalink raw reply
* Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
From: Kumar Gala @ 2006-08-11 12:37 UTC (permalink / raw)
To: Prashant Yendigeri; +Cc: linuxppc-embedded
In-Reply-To: <OF8FBDC92D.1A664660-ON652571C7.003DFE8F-652571C7.003E60DC@lntinfotech.com>
On Aug 11, 2006, at 6:21 AM, Prashant Yendigeri wrote:
>
> Hi,
>
> Downloaded 2.6.16.26 and booted up and got this :
>
> / # ifconfig eth0 172.28.8.254 up
> [ 34.034596] 0:00 not found
> [ 34.037330] eth0: Could not attach to PHY
> [ 34.041809] 0:00 not found
> SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
> such device
> SIOCSIFFLAGS: No such device
>
> I had enabled all the PHY devices in .config and also tried only
> with Marvell phy enabled.
Are you doing this on a custom board? If so what is the PHY address
for the Marvell phy you are using?
- k
>
> Kernel boot messages :
> [ 2.296555] Gianfar MII Bus: probed
> [ 2.301789] eth0: Gianfar Ethernet Controller Version 1.2,
> 00:01:af:07:9b:8a
>
> [ 2.309039] eth0: Running with NAPI disabled
> [ 2.313307] eth0: 64/64 RX/TX BD ring size
> [ 2.318498] eth1: Gianfar Ethernet Controller Version 1.2,
> 00:00:00:00:72:6f
>
> [ 2.325738] eth1: Running with NAPI disabled
> [ 2.330006] eth1: 64/64 RX/TX BD ring size
> [ 2.335198] eth2: Gianfar Ethernet Controller Version 1.2, 6f:
> 74:3d:2f:64:65
>
> [ 2.342377] eth2: Running with NAPI disabled
> [ 2.346662] eth2: 64/64 RX/TX BD ring size
> [ 2.351586] Marvell 88E1101: Registered new driver
> [ 2.357010] Davicom DM9161E: Registered new driver
> [ 2.362443] Davicom DM9131: Registered new driver
> [ 2.367775] Cicada Cis8204: Registered new driver
> [ 2.373136] LXT970: Registered new driver
> [ 2.377794] LXT971: Registered new driver
> [ 2.382461] QS6612: Registered new driver
>
>
> Regards,
> Prashant
>
>
>
>
>
> Kumar Gala <galak@kernel.crashing.org>
> 08/11/2006 09:40 AM
>
> To
> Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
> cc
> linuxppc-embedded@ozlabs.org
> Subject
> Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different
> outputs
>
>
>
>
>
>
> On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
>
> >
> > Hi,
> >
> > The gianfar driver of 2.6.12 and 2.4.20 give different outputs on
> > the same PPC 8540 board.
> >
> > What could be the reason ?
> >
> > Output on 2.4.20 :
> > /root # ifconfig eth0 172.28.8.254 up
> > eth0: PHY is Marvell 88E1011S (1410c62)
> > eth0: Auto-negotiation done
> > eth0: Half Duplex
> > eth0: Speed 10BT
> > eth0: Link is up
> >
> > Output on 2.6.12
> > / # ifconfig eth0 172.28.8.254 up
> > eth0: PHY is Generic MII (ffffffff)
>
> It looks like your 2.6.12 kernel isn't handling the PHY correctly.
> I'd recommend upgrading to something newer which has the phylib
> (can't remember which 2.6 that went into).
>
> - kumar
>
> ______________________________________________________________________
>
>
> ______________________________________________________________________
^ permalink raw reply
* Re: PCI driver on EB8347
From: Kumar Gala @ 2006-08-11 12:42 UTC (permalink / raw)
To: rajan rai; +Cc: Gala Kumar K.-galak, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <4DA89577C33E194ABEBC978921E858541B8E3B@exchange.ingenient.net>
On Aug 11, 2006, at 4:15 AM, rajan rai wrote:
>
> I'm using polling mechanism and not
> interrupts in my driver. Although I'm not using polling I see
> strange behavior When I do lspci -v I don't see any interrupts
> being allocated to PCI device behind PCI bridge !!!! But when I use
> same card directly on primary bus I do see interrupt being
> allocated to PCI device. Any advise why IRQ's being not allocated
> in case its attached to PCI bridge ?
>
> Do I need to take care of any extra
> configuration in case of PCI card is attached to PCI bridge ?
You need to make sure that the pci_map_irq/mpc83xx_map_irq function
handles the right swizziling for the P2P bridge for your setup. If
you are just connected directly its pretty straight forward. However
IRQ assignment behind the bridge can be very board specific and so
you need to make sure that the code is doing the right think for you.
What ever strangeness do you see from lspci?
- k
^ permalink raw reply
* Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
From: Prashant Yendigeri @ 2006-08-11 12:43 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-embedded-bounces+prashant.yendigeri=lntinfotech.com,
linuxppc-embedded
In-Reply-To: <CFF33627-951D-495D-8DBB-B0AC7F9D13D7@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]
Hi,
This is a standard board designed by GDA technologies Inc.
(www.gdatech.com) and eth on 2.4.20 works very much.
U-Boot messages :
U-Boot 1.1.0(pq3-20040423-r1) (May 5 2006 - 08:56:54)
Freescale PowerPC
Core: E500, Version: 2.0, (0x80200020)
System: 8540, Version: 2.0, (0x80300020)
Clocks: CPU: 660 MHz, CCB: 264 MHz, DDR: 132 MHz, LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
Board: Freescale EVAL8540 Board
CPU: 660 MHz
CCB: 264 MHz
DDR: 132 MHz
LBC: 66 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DRAM: 256 MB
FLASH: 8 MB
L2 cache enabled: 256KB
In: serial
Out: serial
Err: serial
Net: Freescale ENET0: PHY is Marvell 88E1011S (1410c62)
Freescale ENET1: PHY is Marvell 88E1011S (1410c62)
Freescale ENET2: PHY is Intel LXT971A (1378e2)
Freescale ENET0, Freescale ENET1, Freescale ENET2
Hit any key to stop autoboot: 0
MPC8540EVAL=>
-prashant
Kumar Gala <galak@kernel.crashing.org>
Sent by:
linuxppc-embedded-bounces+prashant.yendigeri=lntinfotech.com@ozlabs.org
08/11/2006 06:07 PM
To
Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
cc
linuxppc-embedded@ozlabs.org
Subject
Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
On Aug 11, 2006, at 6:21 AM, Prashant Yendigeri wrote:
>
> Hi,
>
> Downloaded 2.6.16.26 and booted up and got this :
>
> / # ifconfig eth0 172.28.8.254 up
> [ 34.034596] 0:00 not found
> [ 34.037330] eth0: Could not attach to PHY
> [ 34.041809] 0:00 not found
> SIOCSIFFLAGS: No[ 34.044526] eth0: Could not attach to PHY
> such device
> SIOCSIFFLAGS: No such device
>
> I had enabled all the PHY devices in .config and also tried only
> with Marvell phy enabled.
Are you doing this on a custom board? If so what is the PHY address
for the Marvell phy you are using?
- k
>
> Kernel boot messages :
> [ 2.296555] Gianfar MII Bus: probed
> [ 2.301789] eth0: Gianfar Ethernet Controller Version 1.2,
> 00:01:af:07:9b:8a
>
> [ 2.309039] eth0: Running with NAPI disabled
> [ 2.313307] eth0: 64/64 RX/TX BD ring size
> [ 2.318498] eth1: Gianfar Ethernet Controller Version 1.2,
> 00:00:00:00:72:6f
>
> [ 2.325738] eth1: Running with NAPI disabled
> [ 2.330006] eth1: 64/64 RX/TX BD ring size
> [ 2.335198] eth2: Gianfar Ethernet Controller Version 1.2, 6f:
> 74:3d:2f:64:65
>
> [ 2.342377] eth2: Running with NAPI disabled
> [ 2.346662] eth2: 64/64 RX/TX BD ring size
> [ 2.351586] Marvell 88E1101: Registered new driver
> [ 2.357010] Davicom DM9161E: Registered new driver
> [ 2.362443] Davicom DM9131: Registered new driver
> [ 2.367775] Cicada Cis8204: Registered new driver
> [ 2.373136] LXT970: Registered new driver
> [ 2.377794] LXT971: Registered new driver
> [ 2.382461] QS6612: Registered new driver
>
>
> Regards,
> Prashant
>
>
>
>
>
> Kumar Gala <galak@kernel.crashing.org>
> 08/11/2006 09:40 AM
>
> To
> Prashant Yendigeri <Prashant.Yendigeri@lntinfotech.com>
> cc
> linuxppc-embedded@ozlabs.org
> Subject
> Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different
> outputs
>
>
>
>
>
>
> On Aug 10, 2006, at 6:18 AM, Prashant Yendigeri wrote:
>
> >
> > Hi,
> >
> > The gianfar driver of 2.6.12 and 2.4.20 give different outputs on
> > the same PPC 8540 board.
> >
> > What could be the reason ?
> >
> > Output on 2.4.20 :
> > /root # ifconfig eth0 172.28.8.254 up
> > eth0: PHY is Marvell 88E1011S (1410c62)
> > eth0: Auto-negotiation done
> > eth0: Half Duplex
> > eth0: Speed 10BT
> > eth0: Link is up
> >
> > Output on 2.6.12
> > / # ifconfig eth0 172.28.8.254 up
> > eth0: PHY is Generic MII (ffffffff)
>
> It looks like your 2.6.12 kernel isn't handling the PHY correctly.
> I'd recommend upgrading to something newer which has the phylib
> (can't remember which 2.6 that went into).
>
> - kumar
>
> ______________________________________________________________________
>
>
> ______________________________________________________________________
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
______________________________________________________________________
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 7544 bytes --]
^ permalink raw reply
* Re: how to apply a PowerPC patch to linux 2.4 kernel and port to memec board with vertex II pro FPGA?
From: Ameet Patil @ 2006-08-11 13:08 UTC (permalink / raw)
To: Ujwal; +Cc: linuxppc-embedded
In-Reply-To: <b47d45990608110402i6dc0dba7idcb189a7026e8bdd@mail.gmail.com>
Ujwal,
Have a look at:
http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html
http://linux.get2knowmore.com/
U might get some idea.
-Ameet
Ujwal wrote:
>
>
> hi all,
>
> im new to porting of Linux to PowerPC . Could anyone let me know
>
> 1) the procedure of how to Port a linux OS to PowerPC for a VirtexII Pro
> memec board??
>
> whats are the steps that i need to follow?
>
> 2) where can i find the power-pc patch for linux 2.4 kernel?
>
>
> Thanks and Regards,
> Ujwal
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 3/6] ehea: queue management
From: Jan-Bernd Themann @ 2006-08-11 13:04 UTC (permalink / raw)
To: Michael Neuling
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <20060811000540.200CE67B6B@ozlabs.org>
Hi,
>
>> +#define EHEA_EQE_SM_MECH_NUMBER EHEA_BMASK_IBM(48, 55)
>> +#define EHEA_EQE_SM_PORT_NUMBER EHEA_BMASK_IBM(56, 63)
>> +
>> +struct ehea_eqe {
>> + u64 entry;
>> +};
>
> ehea_ege.. what is that and why a struct if only 1 item? Comments
> please.
>
There are send / receive queue elements (ehea_swqe, ehea_rwqe),
completion queue elements (ehea_cqe) and event queue elements (ehea_eqe).
We introduced struct ehea_eqe to get a consistent description for all
queue elements.
Jan-Bernd
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-08-11 13:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3140C9D90FB6D911ABD7000F206DC92603D6E0FC@zhk08exm40.ap.freescale.net>
Hi Jeffrey,
I got one more question.
Is it enough to jumper the MPC8548 to an endpoint device?
Or is some additional code required (like your U-Boot commands) to make
a MPC8548 work as an EP.
Up to now I was assuming there is a certain EEPROM that contains a
sufficient PCIe EP configuration.
Thanks,
Florian
^ permalink raw reply
* PCI DMA_MR Problem
From: jimmy liu @ 2006-08-11 13:57 UTC (permalink / raw)
To: linuxppc-embedded
I got a problem when I set the pci dmamr for MPC8250
for DMA PCI transfering data on linux kernel 2.6.17.
When I set the values for the pci_dmamr registers,
then print the register values back, some bits can not
be set. Did anybody know what are the problem, or I
have to set other stuff.
Thanks.
The code like this:
volatile cpm2_map_t *immap = cpm2_immr;
immap->im_pci.pci_dmamr0 = 0x0042b00c;
immap->im_pci.pci_dmamr1 = 0x0042b00c;
immap->im_pci.pci_dmamr2 = 0x0042b00c;
immap->im_pci.pci_dmamr3 = 0x0042b00c;
printk("DMA0 MR = 0x%08x\n",
immap->im_pci.pci_dmamr0);
printk("DMA1 MR (0x%08x) = 0x%08x\n",
immap->im_pci.pci_dmamr1);
printk("DMA2 MR (0x%08x) = 0x%08x\n",
immap->im_pci.pci_dmamr2);
printk("DMA3 MR (0x%08x) = 0x%08x\n",
immap->im_pci.pci_dmamr3);
The results are following:
DMA0 MR (0xf0010500) = 0x0040b000
DMA1 MR (0xf0010580) = 0x0040b000
DMA2 MR (0xf0010600) = 0x0040b000
DMA3 MR (0xf0010680) = 0x0040b000
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
From: Matthew McClintock @ 2006-08-11 14:30 UTC (permalink / raw)
To: Prashant Yendigeri; +Cc: linuxppc-embedded
In-Reply-To: <OF1D72900B.401371DD-ON652571C7.0045AB5D-652571C7.0045E5FC@lntinfotech.com>
On Fri, 2006-08-11 at 18:13 +0530, Prashant Yendigeri wrote:
> Hi,
>
> This is a standard board designed by GDA technologies Inc.
> (www.gdatech.com) and eth on 2.4.20 works very much.
I used a 8540 GDA board once upon a time and all I needed to do was to
change the PHY address. Lookat your 2.4 source and determine what the
correct value is and double check.
-Matthew
^ permalink raw reply
* Re: Realtime preemption patch on PPC
From: Brent Cook @ 2006-08-11 14:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1155251072.5950.80.camel@localhost>
On Thursday 10 August 2006 18:04, Ben Weintraub wrote:
> Howdy,
>
> I'm wondering if anyone has had success getting Ingo Molnar's realtime
> preemption patch (the one here:
> http://people.redhat.com/mingo/realtime-preempt/ ) working on the ppc
> arch.
I have gotten them to work with MPC7448 boards, but it has hardware floating
point, so no math-emu problems.
> Anyhow, when I boot on an MPC8555 with my hack, I get an endless stream
> of:
>
> BUG: sleeping function called from invalid context init(1) at
> arch/powerpc/math-emu/math.c:226
> in_atomic():0 [00000000], irqs_disabled():1
> Call Trace:
> [A0BB3E90] [A000934C] show_stack+0x48/0x194 (unreliable)
> [A0BB3EC0] [A001B7DC] __might_sleep+0xe8/0xf4
> [A0BB3EE0] [A00136C0] do_mathemu+0x30/0x8c8
> [A0BB3F00] [A00036AC] program_check_exception+0x1ac/0x514
> [A0BB3F40] [A0002A08] ret_from_except_full+0x0/0x4c
>
> Line 226 in arch/powerpc/math-emu/math.c is part of the do_mathemu()
> function, and contains a call to get_user(), which calls
> __might_sleep(), causing this problem.
>
^ permalink raw reply
* Re: U-boot on ML403
From: Frank D Lombardo @ 2006-08-11 15:14 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F31F8E978C237CACA6523FB24A0@phx.gbl>
Ming Liu wrote:
> Dear Frank,
> I know you are using U-boot on ML403 now. So can you say something
> about how to configure U-boot as ML403 board? I noticed that in U-boot
> 1.1.4, there is only ML300 supported. So if I want to configure the
> board as ML403 and some other customed options(e.g. no EEPROM), what
> shall I do? Thanks for your help.
>
> Regards
> Ming
>
Ming,
I received an updated version of the Xilinx xapp542 directly from
Xilinx. We had to sign a non-disclosure agreement before they would send
it to me. This update provided the necessary pieces to allow XPS to
generate a U-Boot "BSP" and a modified U-Boot tree with support for
additional mlXXX boards.
I would recommend contacting Xilinx for this. Sorry I can't be of
greater assistance.
Frank
^ permalink raw reply
* Re: U-boot on ML403
From: Ming Liu @ 2006-08-11 15:28 UTC (permalink / raw)
To: lombardo; +Cc: linuxppc-embedded
In-Reply-To: <44DC9ECF.7030301@mdivac.com>
Dear Frank,
So you mean, you built your ML403 system with U-Boot supported according to
the updated version of xapp542, right? There are NOT some patches open to
everyone to include ML403 support into the U-Boot tree, right?
If both answers for the two questions are yes, then I have to contact
Xilinx to ask for help. Anyway, thanks for your information and reply.
Regards
Ming
>From: Frank D Lombardo <lombardo@mdivac.com>
>To: Ming Liu <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: U-boot on ML403
>Date: Fri, 11 Aug 2006 11:14:23 -0400
>
>Ming Liu wrote:
> > Dear Frank,
> > I know you are using U-boot on ML403 now. So can you say something
> > about how to configure U-boot as ML403 board? I noticed that in U-boot
> > 1.1.4, there is only ML300 supported. So if I want to configure the
> > board as ML403 and some other customed options(e.g. no EEPROM), what
> > shall I do? Thanks for your help.
> >
> > Regards
> > Ming
> >
>
>Ming,
>
>I received an updated version of the Xilinx xapp542 directly from
>Xilinx. We had to sign a non-disclosure agreement before they would send
>it to me. This update provided the necessary pieces to allow XPS to
>generate a U-Boot "BSP" and a modified U-Boot tree with support for
>additional mlXXX boards.
>
>I would recommend contacting Xilinx for this. Sorry I can't be of
>greater assistance.
>
>Frank
>
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* [RFC] Adding MTD to device tree
From: Sergei Shtylyov @ 2006-08-11 15:31 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded, linux-mtd
In-Reply-To: <20060709001435.7a94294e@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
Hello.
Here's the proposal for the representation of the MTD (optionally having
some partitions) in the device tree, along with the sample code that parses
the MTD node and hands the necessary information to the 'physmap' driver using
the 'platform_device' method. The representation was fitted to the current
Linux MTD driver model, so it doesn't bear any information on the chip models
or the flash interflace, letting the MTD probing code figure all that out
(this part might need some changes I suspect).
To me, however, this method seems too limiting: we have to look thru the
device tree for each particular kind MTDs (assuming that there could be
different ones that 'physmap' can't drive) and register each of them its own
way. If we teach 'physmap' to register on the 'of_platform_device' bus, we
may look up the device tree for *any* MTD nodes somewhere in arch/powerpc/
tree, register them all, and leave it up to the particular driver to claim
them and get the information the driver needs from their node's properties.
That would require introducing another MTD partition pasrsing module (so the
code that parses the partitions in this patch will move into the separate
module under drivers/mtd/).
Opinions on what way should be taken and what needs to be added from both
PowerPC and MTD communities are very welcome.
WBR, Sergei
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: OF-physmap-device.patch --]
[-- Type: text/plain, Size: 5358 bytes --]
Index: powerpc/Documentation/powerpc/booting-without-of.txt
===================================================================
--- powerpc.orig/Documentation/powerpc/booting-without-of.txt
+++ powerpc/Documentation/powerpc/booting-without-of.txt
@@ -6,6 +6,8 @@
IBM Corp.
(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
Freescale Semiconductor, FSL SOC and 32-bit additions
+(c) 2006 MontaVista Software, Inc.
+ MTD node definition
May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
@@ -1442,6 +1444,42 @@ platforms are moved over to use the flat
};
+ h) MTD nodes
+
+ Memory Technology Devices are flash, ROM, and similar chips, often used
+ for solid state file systems on embedded devices.
+
+ Required properties:
+
+ - device_type : has to be "mtd"
+ - compatible : Should be the name of the MTD driver. Currently, this is
+ most likely to be "physmap".
+ - reg : Offset and length of the register set for the device.
+
+ Recommended properties :
+
+ - bank-width : Width of the flash data bus in bytes. Must be specified
+ for the NOR flashes.
+ - partitions : Several pairs of 32-bit values where the first value is
+ partition's offset from the start of the MTD device and the second
+ one is partition size in bytes with LSB used to signify a read only
+ partititon (so, the parition size should always be an even number).
+ - partition-names : The list of concatenated zero terminated strings
+ representing the partition names.
+
+ Example:
+
+ flash@ff000000 {
+ device_type = "mtd";
+ compatible = "physmap";
+ reg = <ff000000 01000000>;
+ bank-width = <4>;
+ partitions = <00000000 00f80000
+ 00f80000 00080001>;
+ partition-names = "fs\0firmware";
+ };
+
+
More devices will be defined as this spec matures.
Index: powerpc/arch/powerpc/sysdev/Makefile
===================================================================
--- powerpc.orig/arch/powerpc/sysdev/Makefile
+++ powerpc/arch/powerpc/sysdev/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PPC_83xx) += ipic.o
obj-$(CONFIG_FSL_SOC) += fsl_soc.o
obj-$(CONFIG_PPC_TODC) += todc.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
+obj-$(CONFIG_MTD) += flash.o
ifeq ($(CONFIG_PPC_MERGE),y)
obj-$(CONFIG_PPC_I8259) += i8259.o
Index: powerpc/arch/powerpc/sysdev/flash.c
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/sysdev/flash.c
@@ -0,0 +1,104 @@
+/*
+ * arch/powerpc/sysdev/flash.c
+ *
+ * Flash memory registration
+ *
+ * (C) 2006 MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/physmap.h>
+#include <linux/mtd/partitions.h>
+#include <linux/platform_device.h>
+#include <asm/prom.h>
+
+static void parse_flash_partitions(struct device_node *node,
+ struct physmap_flash_data *physmap_data)
+{
+#ifdef CONFIG_MTD_PARTITIONS
+ int i, plen, num_parts;
+ const u32 *part;
+ const char *name;
+
+ part = get_property(node, "partitions", &plen);
+ if (part == NULL)
+ return;
+
+ physmap_data->nr_parts = num_parts = plen / (2 * sizeof(u32));
+ physmap_data->parts = kcalloc(num_parts, sizeof(struct mtd_partition),
+ GFP_KERNEL);
+ if (physmap_data->parts == NULL) {
+ printk(KERN_ERR "Can't allocate the flash partition data!\n");
+ return;
+ }
+
+ name = get_property(node, "partition-names", &plen);
+
+ for (i = 0; i < num_parts; i++) {
+ physmap_data->parts[i].offset = *part++;
+ physmap_data->parts[i].size = *part & ~1;
+ if (*part++ & 1) /* bit 0 set signifies read only partition */
+ physmap_data->parts[i].mask_flags = MTD_WRITEABLE;
+
+ if (name != NULL && plen > 0) {
+ int len = strlen(name) + 1;
+
+ physmap_data->parts[i].name = (char *)name;
+ plen -= len;
+ name += len;
+ } else
+ physmap_data->parts[i].name = "unnamed";
+ }
+#endif
+}
+
+static int __init powerpc_flash_init(void)
+{
+ struct device_node *node = NULL;
+ int num = 0;
+
+ while ((node = of_find_compatible_node(node, "mtd", "physmap")) != NULL) {
+ struct platform_device *physmap_flash;
+ struct physmap_flash_data physmap_data;
+ struct resource res;
+ const u32 *width;
+
+ if (of_address_to_resource(node, 0, &res)) {
+ printk(KERN_ERR "Can't get the flash mapping!\n");
+ continue;
+ }
+
+ width = get_property(node, "bank-width", NULL);
+ if (width == NULL) {
+ printk(KERN_ERR "Can't get the flash bank width!\n");
+ continue;
+ }
+
+ physmap_flash = platform_device_register_simple("physmap-flash",
+ num, &res, 1);
+ if (IS_ERR(physmap_flash)) {
+ printk(KERN_ERR "Can't register the \"physmap-flash\" "
+ "platform device!\n");
+ continue;
+ }
+
+ memset(&physmap_data, 0, sizeof(physmap_data));
+ physmap_data.width = *width;
+
+ parse_flash_partitions(node, &physmap_data);
+
+ if (platform_device_add_data(physmap_flash, &physmap_data,
+ sizeof(struct physmap_flash_data))) {
+ printk(KERN_ERR "Can't pass data to physmap driver!\n");
+ platform_device_unregister(physmap_flash);
+ continue;
+ }
+ ++num;
+ }
+ return 0;
+}
+
+arch_initcall(powerpc_flash_init);
^ permalink raw reply
* Re: U-boot on ML403
From: Frank D Lombardo @ 2006-08-11 15:39 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F24ECE4A31BC21F098B510B24B0@phx.gbl>
Ming Liu wrote:
> Dear Frank,
> So you mean, you built your ML403 system with U-Boot supported
> according to the updated version of xapp542, right? There are NOT some
> patches open to everyone to include ML403 support into the U-Boot
> tree, right?
> If both answers for the two questions are yes, then I have to contact
> Xilinx to ask for help. Anyway, thanks for your information and reply.
> Regards
> Ming
>
>
>
Ming,
There may be public patches available, but I don't know where to obtain
them. I used the patches from Xilinx.
Frank
^ permalink raw reply
* Re: U-boot on ML403
From: Ming Liu @ 2006-08-11 15:54 UTC (permalink / raw)
To: lombardo; +Cc: linuxppc-embedded
In-Reply-To: <44DCA4CF.4090607@mdivac.com>
Dear Frank,
OK then.
I have tried to find the patch. But I failed. So maybe it's better to
contact Xilinx.
Thanks for your help anyway.
Regards
Ming
>From: Frank D Lombardo <lombardo@mdivac.com>
>To: Ming Liu <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: U-boot on ML403
>Date: Fri, 11 Aug 2006 11:39:59 -0400
>
>Ming Liu wrote:
> > Dear Frank,
> > So you mean, you built your ML403 system with U-Boot supported
> > according to the updated version of xapp542, right? There are NOT some
> > patches open to everyone to include ML403 support into the U-Boot
> > tree, right?
> > If both answers for the two questions are yes, then I have to contact
> > Xilinx to ask for help. Anyway, thanks for your information and reply.
> > Regards
> > Ming
> >
> >
> >
>Ming,
>
>There may be public patches available, but I don't know where to obtain
>them. I used the patches from Xilinx.
>
>Frank
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: Realtime preemption patch on PPC
From: Kim Phillips @ 2006-08-11 15:54 UTC (permalink / raw)
To: Brent Cook; +Cc: linuxppc-embedded
In-Reply-To: <200608110938.45385.bcook@bpointsys.com>
On Fri, 11 Aug 2006 09:38:45 -0500
Brent Cook <bcook@bpointsys.com> wrote:
> On Thursday 10 August 2006 18:04, Ben Weintraub wrote:
> I have gotten them to work with MPC7448 boards, but it has hardware floating
> point, so no math-emu problems.
>
> > Anyhow, when I boot on an MPC8555 with my hack, I get an endless stream
> > of:
if you can, you might want to rebuild your binaries with -msoft-float
Kim
^ permalink raw reply
* Re: [PATCH 3/6] ehea: queue management
From: Thomas Klein @ 2006-08-11 16:09 UTC (permalink / raw)
To: Michael Neuling
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Thomas Klein, linux-ppc, Marcus Eder
In-Reply-To: <20060811000540.200CE67B6B@ozlabs.org>
Mikey,
first of all thanks a lot for the effort you invested to review our code.
We're quite happy about the improvements we made due to your comments.
See our answers below.
Kind regards
Thomas
Michael Neuling wrote:
> Please add comments to make the code more readable, especially at the
> start of functions/structures to describe what they do. A large readme
> at the start of ehea_main.c which gave an overview of the driver design
> would be really useful.
We'll improve comments over the next patch iterations.
>> +static int ipz_queue_ctor(struct ipz_queue *queue,
>> + const u32 nr_of_pages,
>> + const u32 pagesize, const u32 qe_size,
>> + const u32 nr_of_sg)
>> +{
>> + int f;
>> + EDEB_EN(7, "nr_of_pages=%x pagesize=%x qe_size=%x",
>> + nr_of_pages, pagesize, qe_size);
>> + queue->queue_length = nr_of_pages * pagesize;
>> + queue->queue_pages = vmalloc(nr_of_pages * sizeof(void *));
>
>> + if (!queue->queue_pages) {
>> + EDEB(4, "ERROR!! didn't get the memory");
>> + return 0;
>> + }
>> + memset(queue->queue_pages, 0, nr_of_pages * sizeof(void *));
>> +
>> + for (f = 0; f < nr_of_pages; f++) {
>> + (queue->queue_pages)[f] =
>> + (struct ipz_page *)get_zeroed_page(GFP_KERNEL);
>> + if (!(queue->queue_pages)[f]) {
>> + break;
>> + }
>> + }
>> + if (f < nr_of_pages) {
>> + int g;
>> + EDEB_ERR(4, "couldn't get 0ed pages queue=%p f=%x "
>> + "nr_of_pages=%x", queue, f, nr_of_pages);
>> + for (g = 0; g < f; g++) {
>> + free_page((unsigned long)(queue->queue_pages)[g]);
>> + }
>> + return 0;
>
> If you return here when calling from ehea_create_eq, I think you are
> leaking the queue->queue_pages allocation (the pages they point to are
> freed correctly).
You're right. Fixed it.
>> +void ehea_cq_delete(struct ehea_cq *cq)
>> +{
>> + vfree(cq);
>> +}
>
> This is used in only two places. Do we need it?
No. The ehea_?q_new()/ehea_?q_delete() functions were entirely removed.
>
> If we do... can we static inline?
>
>> + hret = ehea_h_alloc_resource_cq(adapter->handle,
>> + cq,
>> + &cq->attr,
>> + &cq->ipz_cq_handle, &cq->galpas);
>
> hret set twice...
Fixed.
>
>
>
>> + if (hret != H_SUCCESS) {
>> + EDEB_ERR(4, "ehea_h_alloc_resource_cq failed. hret=%lx", hret);
>> + goto create_cq_exit1;
>> + }
>> +
>> + ipz_rc = ipz_queue_ctor(&cq->ipz_queue, cq->attr.nr_pages,
>> + EHEA_PAGESIZE, sizeof(struct ehea_cqe), 0);
>> + if (!ipz_rc)
>> + goto create_cq_exit2;
>> +
>> + hret = H_SUCCESS;
>> +
>> + for (counter = 0; counter < cq->attr.nr_pages; counter++) {
>> + vpage = ipz_qpageit_get_inc(&cq->ipz_queue);
>
> vpga set twice...
vpage gets assigned to rpage via the virt_to_abs() call. So using
it again afterwards is ok.
>
>> + if (!vpage) {
>> + EDEB_ERR(4, "ipz_qpageit_get_inc() "
>> + "returns NULL adapter=%p", adapter);
>> + goto create_cq_exit3;
>> + }
>> +
>> + rpage = virt_to_abs(vpage);
>> +
>> + hret = ehea_h_register_rpage_cq(adapter->handle,
>> + cq->ipz_cq_handle,
>> + 0,
>> + HIPZ_CQ_REGISTER_ORIG,
>> + rpage, 1, cq->galpas.kernel);
>> +
>> + if (hret < H_SUCCESS) {
>> + EDEB_ERR(4, "ehea_h_register_rpage_cq() failed "
>> + "ehea_cq=%p hret=%lx "
>> + "counter=%i act_pages=%i",
>> + cq, hret, counter, cq->attr.nr_pages);
>> + goto create_cq_exit3;
>> + }
>> +
>> + if (counter == (cq->attr.nr_pages - 1)) {
>> + vpage = ipz_qpageit_get_inc(&cq->ipz_queue);
>> +
>> + if ((hret != H_SUCCESS) || (vpage)) {
>> + EDEB_ERR(4, "Registration of pages not "
>> + "complete ehea_cq=%p hret=%lx",
>> + cq, hret)
>> + goto create_cq_exit3;
>> + }
>> + } else {
>> + if ((hret != H_PAGE_REGISTERED) || (vpage == 0)) {
>> + EDEB_ERR(4, "Registration of page failed "
>> + "ehea_cq=%p hret=%lx"
>> + "counter=%i act_pages=%i",
>> + cq, hret, counter, cq->attr.nr_pages);
>> + goto create_cq_exit3;
>> + }
>> + }
>> + }
>> +void ehea_eq_delete(struct ehea_eq *eq)
>> +{
>> + vfree(eq);
>> +}
>
> Again, is this really needed and what about static inline?
removed. see above.
>> +struct ehea_qp *ehea_qp_new(void) {
>> + struct ehea_qp *qp = vmalloc(sizeof(*qp));
>> + if (qp != 0) {
>
> if (qp) ??
removed. see above.
>> +static inline u32 map_swqe_size(u8 swqe_enc_size)
>> +{
>> + return 128 << swqe_enc_size;
>> +}
>> +
>> +static inline u32 map_rwqe_size(u8 rwqe_enc_size)
>> +{
>> + return 128 << rwqe_enc_size;
>> +}
>
> Snap! These are identical...
Agreed. Functions were replaced by a single map_wqe_size() function.
>> + hret = ehea_h_register_rpage_mr(adapter->handle,
>> + adapter->mr.handle,
>> + 0,
>> + 0,
>> + (u64)pt_abs,
>> + num_pages);
>
> They probably don't all need their own line.
Agreed.
>
>> + nr_pages -= num_pages;
>> + } else {
>> + u64 abs_adr = virt_to_abs((void *)(((u64)start)
>> + + (k * PAGE_SIZE)));
>> + hret = ehea_h_register_rpage_mr(adapter->handle,
>> + adapter->mr.handle,
>> + 0,
>> + 0,
>> + abs_adr,
>> + 1);
>
> Ditto.
Agreed.
>> + if (nr_pages > 1)
>> + hret = ehea_h_register_rpage_mr(adapter->handle,
>> + mr->handle,
>> + 0,
>> + 0,
>> + (u64)pt_abs,
>> + nr_pages);
>> + else
>> + hret = ehea_h_register_rpage_mr(adapter->handle,
>> + mr->handle,
>> + 0,
>> + 0,
>> + first_page,
>> + 1);
>
> hret = ehea_h_register_rpage_mr(adapter->handle, mr->handle, 0,
> 0, (nr_pages > 1)?(u64)pt_abs:first_page,
> nr_pages);
> Simpler?
It would have to be
hret = ehea_h_register_rpage_mr(adapter->handle, mr->handle, 0,
0, (nr_pages > 1)?(u64)pt_abs:first_page,
(nr_pages > 1)?nr_pages:1);
It's more sophisticated but surely not more readable to have this in a function call.
>
> Or get ehea_h_register_rpage_mr to do this for you? You seem to do this
> same decode twice?
You're basically right, but the ehea_h_*() function are by design not supposed
to contain such logic but to simply execute the hcall with the given parameters.
I confess we need a few more lines of code doing it our way but we prefer to
be consistent in this case.
>> +/* tx control flags for swqe */
>> +#define EHEA_SWQE_CRC 0x8000
>> +#define EHEA_SWQE_IP_CHECKSUM 0x4000
>> +#define EHEA_SWQE_TCP_CHECKSUM 0x2000
>> +#define EHEA_SWQE_TSO 0x1000
>> +#define EHEA_SWQE_SIGNALLED_COMPLETION 0x0800
>> +#define EHEA_SWQE_VLAN_INSERT 0x0400
>> +#define EHEA_SWQE_IMM_DATA_PRESENT 0x0200
>> +#define EHEA_SWQE_DESCRIPTORS_PRESENT 0x0100
>> +#define EHEA_SWQE_WRAP_CTL_REC 0x0080
>> +#define EHEA_SWQE_WRAP_CTL_FORCE 0x0040
>> +#define EHEA_SWQE_BIND 0x0020
>> +#define EHEA_SWQE_PURGE 0x0010
>> +
>> +#define SWQE_HEADER_SIZE 32
>
> This is never used...
Used in ehea_main.c in function ehea_post_nwqe()
>
> Would be nice to document some of the names here. What are SWQE, RWQE,
> WQE, CQE, IPZ etc?
Agreed. Added comment sections which explains the abbreviations.
>> +#define EHEA_EQE_VALID EHEA_BMASK_IBM(0, 0)
>> +#define EHEA_EQE_IS_CQE EHEA_BMASK_IBM(1, 1)
>> +#define EHEA_EQE_IDENTIFIER EHEA_BMASK_IBM(2, 7)
>> +#define EHEA_EQE_QP_CQ_NUMBER EHEA_BMASK_IBM(8, 31)
>> +#define EHEA_EQE_QP_TOKEN EHEA_BMASK_IBM(32, 63)
>> +#define EHEA_EQE_CQ_TOKEN EHEA_BMASK_IBM(32, 63)
>> +#define EHEA_EQE_KEY EHEA_BMASK_IBM(32, 63)
>
> 3 the same here?
Yes, it's correct. Those defines are used to operate on different data
sources, so it's possible that the same bits have to be accessed.
>
>> +#define EHEA_EQE_PORT_NUMBER EHEA_BMASK_IBM(56, 63)
>> +#define EHEA_EQE_EQ_NUMBER EHEA_BMASK_IBM(48, 63)
>> +#define EHEA_EQE_SM_ID EHEA_BMASK_IBM(48, 63)
>
> 2 the same here?
ditto
>
>> +#define EHEA_EQE_SM_MECH_NUMBER EHEA_BMASK_IBM(48, 55)
>> +#define EHEA_EQE_SM_PORT_NUMBER EHEA_BMASK_IBM(56, 63)
>> +
>> +struct ehea_eqe {
>> + u64 entry;
>> +};
>
> ehea_ege.. what is that and why a struct if only 1 item? Comments
> please.
Already answered in separate mail.
>
> In ehea_main.c you use this with a ehea_poll_eq which returns a void *
> Mostly you cast to a (struct ehea_eqe *) but you don't need to.
Agreed. Done.
>> +static inline struct ehea_cqe *ehea_poll_rq1(struct ehea_qp *qp, int *wqe_in
>> +static inline void ehea_inc_rq1(struct ehea_qp *qp)
>> +static inline struct ehea_cqe *ehea_poll_cq(struct ehea_cq *my_cq)
>
> Can we stick all these functions in the .c and put only the prototypes here?
These functions must be inline due to performance considerations and therefore
have to stay in the header file.
>> +/*
>> + * linux/drivers/net/ehea/ehea_ethtool.c
>> + *
>> + * eHEA ethernet device driver for IBM eServer System p
>> + *
>> + * (C) Copyright IBM Corp. 2006
>> + *
>> + * Authors:
>> + * Christoph Raisch <raisch@de.ibm.com>
>> + * Jan-Bernd Themann <themann@de.ibm.com>
>> + * Heiko-Joerg Schick <schickhj@de.ibm.com>
>> + * Thomas Klein <tklein@de.ibm.com>
>> + *
>> + *
>> + * 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, or (at your option)
>> + * any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>> + */
>> +
>> +static int netdev_nway_reset(struct net_device *dev)
>> +{
>> + printk("nway reset\n");
>> + return 0;
>> +}
>> +
>> +static void netdev_get_pauseparam(struct net_device *dev,
>> + struct ethtool_pauseparam *pauseparam)
>> +{
>> + printk("get pauseparam\n");
>> +}
>> +
>> +static int netdev_set_pauseparam(struct net_device *dev,
>> + struct ethtool_pauseparam *pauseparam)
>> +{
>> + printk("set pauseparam\n");
>> + return 0;
>> +}
>> +
>> +static u32 netdev_get_rx_csum(struct net_device *dev)
>> +{
>> + printk("set rx_csum\n");
>> + return 0;
>> +}
>> +
>> +static int netdev_set_rx_csum(struct net_device *dev, u32 value)
>> +{
>> + printk("set rx_csum\n");
>> + return 0;
>> +}
>> +
>> +static int netdev_self_test_count(struct net_device *dev)
>> +{
>> + printk("self test count\n");
>> + return 0;
>> +}
>> +
>> +static void netdev_self_test(struct net_device *dev, struct ethtool_test *te
> st,
>> + u64 *value)
>> +{
>> + printk("self test\n");
>> +}
>> +
>> +static int netdev_phys_id(struct net_device *dev, u32 value)
>> +{
>> + printk("physical id\n");
>> + return 0;
>> +}
>
> These are yet to be done?
Exactly.
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
> I hope this helps...
It helped a lot! Thank you very much :-)
^ permalink raw reply
* Re: how to apply a PowerPC patch to linux 2.4 kernel and port to memec board with vertex II pro FPGA?
From: Ameet Patil @ 2006-08-11 16:23 UTC (permalink / raw)
To: Ujwal, linuxppc-embedded
In-Reply-To: <b47d45990608110817u2d4ac4d9na4e23af44a92bb09@mail.gmail.com>
Hi Ujwal,
Linux has support for Xilinx Virtex II Pro FPGA with PPC405. I am
sure you can compile for your specific board (MEMEC). Long time back I
had come across a doc. related to Linux on MEMEC. Try googling for it...
may be its still there.
The key is to configure (or set the defines of) the Linux BSP parameters
that are specific to your board!
cheers,
-Ameet
Ujwal wrote:
> hi amit,
> which are the common development/evaluation boards does this PowerPC
> work ???
>
> can i use the MEMEC design board with Virtex II Pro FPGA and run the
> crosscompiled image of linux for powerpc on this board?????
>
>
> pls reply .... as im right now bowled out .
>
> Thanks,
> Ujwal
>
>
>
>
> On 8/11/06, *Ameet Patil* < ammubhai@gmail.com
> <mailto:ammubhai@gmail.com>> wrote:
>
> Ujwal,
>
> Have a look at:
> http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm
> http://www.crhc.uiuc.edu/IMPACT/gsrc/hardwarelab/docs/kernel-HOWTO.html
> http://linux.get2knowmore.com/
>
> U might get some idea.
>
> -Ameet
>
> Ujwal wrote:
> >
> >
> > hi all,
> >
> > im new to porting of Linux to PowerPC . Could anyone let me know
> >
> > 1) the procedure of how to Port a linux OS to PowerPC for a
> VirtexII Pro
> > memec board??
> >
> > whats are the steps that i need to follow?
> >
> > 2) where can i find the power-pc patch for linux 2.4 kernel?
> >
> >
> > Thanks and Regards,
> > Ujwal
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org <mailto:Linuxppc-embedded@ozlabs.org>
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> <https://ozlabs.org/mailman/listinfo/linuxppc-embedded>
>
>
^ permalink raw reply
* RE: Debugging with no serial port
From: Martin, Tim @ 2006-08-11 16:30 UTC (permalink / raw)
To: bwarren; +Cc: linuxppc-embedded
=20
> > =09
> > I tried this as well and have the same GDB synchronization=20
> problem e.g.
> >=20
> > break log_stuff
> > commands
> > silent
> > if (variable_logging_enabled)
> > printf "(%d,%d)\n",stuff1_variable,stuff2_variable
> > end
> > cont
> > end
> >=20
> That's too bad. I wonder if you could run gdb from expect or=20
> some other auto-scripting language and have it issue the=20
> 'cont' once all data is printed (Have your code spit out a=20
> special 'end of data' delimiter).=20
>=20
> Just a thought - no idea if it would work. =20
>=20
What a brilliant idea! I tried this and it works perfectly. Having no
previous expect experience, I was able to generate and modify the expect
script with "autoexpect" in about 10 minutes.
Thanks!
Tim
^ permalink raw reply
* [PATCH 0/4]: powerpc/cell spidernet ethernet driver fixes
From: Linas Vepstas @ 2006-08-11 17:03 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: James K Lewis, Arnd Bergmann, Jens Osterkamp
The following series of patches implement some fixes and performance
improvements for the Spedernet ethernet device driver. The high point
of the patch series is some code to implement a low-watermark interrupt
on the transmit queue. The bundle of patches raises transmit performance
from some embarassingly low value to a reasonable 730 Megabits per
second for 1500 byte packets.
Please note that the spider is an ethernet controller that is
integrated into the south bridge, and is thus available only on
Cell-based platforms.
These have been well-tested over the last few weeks. Please apply.
--linas
^ permalink raw reply
* [PATCH 1/4]: powerpc/cell spidernet burst alignment patch.
From: Linas Vepstas @ 2006-08-11 17:06 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
This patch increases the Burst Address alignment from 64 to 1024 in the
Spidernet driver. This improves transmit performance for large packets
from about 100Mbps to 300-400Mbps.
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-07 14:37:10.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:09:57.000000000 -0500
@@ -209,7 +209,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003
/* to set TX_DMA_EN */
#define SPIDER_NET_TX_DMA_EN 0x80000000
-#define SPIDER_NET_GDTDCEIDIS 0x00000002
+#define SPIDER_NET_GDTDCEIDIS 0x00000302
#define SPIDER_NET_DMA_TX_VALUE SPIDER_NET_TX_DMA_EN | \
SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
^ permalink raw reply
* [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-11 17:08 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
Implement basic low-watermark support for the transmit queue.
The basic idea of a low-watermark interrupt is as follows.
The device driver queues up a bunch of packets for the hardware
to transmit, and then kicks he hardware to get it started.
As the hardware drains the queue of pending, untransmitted
packets, the device driver will want to know when the queue
is almost empty, so that it can queue some more packets.
This is accomplished by setting the DESCR_TXDESFLG flag in
one of the packets. When the hardware sees this flag, it will
interrupt the device driver. Because this flag is on a fixed
packet, rather than at fixed location in the queue, the
code below needs to move the flag as more packets are
queued up. This implementation attempts to keep te flag
at about 3/4's of the way into the queue.
This patch boosts driver performance from about
300-400Mbps for 1500 byte packets, to about 710-740Mbps.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 56 ++++++++++++++++++++++++++++++++++++++++++-----
drivers/net/spider_net.h | 6 +++--
2 files changed, 55 insertions(+), 7 deletions(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-07 14:39:38.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:23:24.000000000 -0500
@@ -700,6 +700,39 @@ spider_net_release_tx_descr(struct spide
dev_kfree_skb_any(skb);
}
+static void
+spider_net_set_low_watermark(struct spider_net_card *card)
+{
+ int status;
+ int cnt=0;
+ int i;
+ struct spider_net_descr *descr = card->tx_chain.tail;
+
+ /* Measure the length of the queue. */
+ while (descr != card->tx_chain.head) {
+ status = descr->dmac_cmd_status & SPIDER_NET_DESCR_NOT_IN_USE;
+ if (status == SPIDER_NET_DESCR_NOT_IN_USE)
+ break;
+ descr = descr->next;
+ cnt++;
+ }
+ if (cnt == 0)
+ return;
+
+ /* Set low-watermark 3/4th's of the way into the queue. */
+ descr = card->tx_chain.tail;
+ cnt = (cnt*3)/4;
+ for (i=0;i<cnt; i++)
+ descr = descr->next;
+
+ /* Set the new watermark, clear the old wtermark */
+ descr->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
+ if (card->low_watermark && card->low_watermark != descr)
+ card->low_watermark->dmac_cmd_status =
+ card->low_watermark->dmac_cmd_status & ~SPIDER_NET_DESCR_TXDESFLG;
+ card->low_watermark = descr;
+}
+
/**
* spider_net_release_tx_chain - processes sent tx descriptors
* @card: adapter structure
@@ -717,6 +750,7 @@ spider_net_release_tx_chain(struct spide
{
struct spider_net_descr_chain *chain = &card->tx_chain;
int status;
+ int rc=0;
spider_net_read_reg(card, SPIDER_NET_GDTDMACCNTR);
@@ -729,8 +763,10 @@ spider_net_release_tx_chain(struct spide
break;
case SPIDER_NET_DESCR_CARDOWNED:
- if (!brutal)
- return 1;
+ if (!brutal) {
+ rc = 1;
+ goto done;
+ }
/* fallthrough, if we release the descriptors
* brutally (then we don't care about
* SPIDER_NET_DESCR_CARDOWNED) */
@@ -747,12 +783,15 @@ spider_net_release_tx_chain(struct spide
default:
card->netdev_stats.tx_dropped++;
- return 1;
+ rc = 1;
+ goto done;
}
spider_net_release_tx_descr(card);
}
-
- return 0;
+done:
+ if (rc == 1)
+ spider_net_set_low_watermark(card);
+ return rc;
}
/**
@@ -1453,6 +1492,10 @@ spider_net_interrupt(int irq, void *ptr,
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
+ if (status_reg & SPIDER_NET_TXINT ) {
+ spider_net_cleanup_tx_ring(card);
+ netif_wake_queue(netdev);
+ }
if (status_reg & SPIDER_NET_ERRINT )
spider_net_handle_error_irq(card, status_reg);
@@ -1615,6 +1658,9 @@ spider_net_open(struct net_device *netde
card->descr,
PCI_DMA_TODEVICE, tx_descriptors))
goto alloc_tx_failed;
+
+ card->low_watermark = NULL;
+
if (spider_net_init_chain(card, &card->rx_chain,
card->descr + tx_descriptors,
PCI_DMA_FROMDEVICE, rx_descriptors))
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-11 11:09:57.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:19:47.000000000 -0500
@@ -47,7 +47,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_TX_DESCRIPTORS_MIN 16
#define SPIDER_NET_TX_DESCRIPTORS_MAX 512
-#define SPIDER_NET_TX_TIMER 20
+#define SPIDER_NET_TX_TIMER (HZ/5)
#define SPIDER_NET_RX_CSUM_DEFAULT 1
@@ -209,7 +209,7 @@ extern char spider_net_driver_name[];
#define SPIDER_NET_DMA_RX_FEND_VALUE 0x00030003
/* to set TX_DMA_EN */
#define SPIDER_NET_TX_DMA_EN 0x80000000
-#define SPIDER_NET_GDTDCEIDIS 0x00000302
+#define SPIDER_NET_GDTDCEIDIS 0x00000300
#define SPIDER_NET_DMA_TX_VALUE SPIDER_NET_TX_DMA_EN | \
SPIDER_NET_GDTDCEIDIS
#define SPIDER_NET_DMA_TX_FEND_VALUE 0x00030003
@@ -349,6 +349,7 @@ enum spider_net_int2_status {
#define SPIDER_NET_DESCR_FORCE_END 0x50000000 /* used in rx and tx */
#define SPIDER_NET_DESCR_CARDOWNED 0xA0000000 /* used in rx and tx */
#define SPIDER_NET_DESCR_NOT_IN_USE 0xF0000000
+#define SPIDER_NET_DESCR_TXDESFLG 0x00800000
struct spider_net_descr {
/* as defined by the hardware */
@@ -424,6 +425,7 @@ struct spider_net_card {
struct spider_net_descr_chain tx_chain;
struct spider_net_descr_chain rx_chain;
+ struct spider_net_descr *low_watermark;
struct net_device_stats netdev_stats;
^ permalink raw reply
* [PATCH 3/4]: powerpc/cell spidernet stop error printing patch.
From: Linas Vepstas @ 2006-08-11 17:09 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
Turn off mis-interpretation of the queue-empty interrupt
status bit as an error. This bit is set as a part of
the previous low-watermark patch.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
----
drivers/net/spider_net.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-11 11:23:24.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:34:16.000000000 -0500
@@ -1275,12 +1275,15 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_PHYINT:
case SPIDER_NET_GMAC2INT:
case SPIDER_NET_GMAC1INT:
- case SPIDER_NET_GIPSINT:
case SPIDER_NET_GFIFOINT:
case SPIDER_NET_DMACINT:
case SPIDER_NET_GSYSINT:
break; */
+ case SPIDER_NET_GIPSINT:
+ show_error = 0;
+ break;
+
case SPIDER_NET_GPWOPCMPINT:
/* PHY write operation completed */
show_error = 0;
@@ -1339,9 +1342,10 @@ spider_net_handle_error_irq(struct spide
case SPIDER_NET_GDTDCEINT:
/* chain end. If a descriptor should be sent, kick off
* tx dma
- if (card->tx_chain.tail == card->tx_chain.head)
+ if (card->tx_chain.tail != card->tx_chain.head)
spider_net_kick_tx_dma(card);
- show_error = 0; */
+ */
+ show_error = 0;
break;
/* case SPIDER_NET_G1TMCNTINT: not used. print a message */
@@ -1455,8 +1459,9 @@ spider_net_handle_error_irq(struct spide
}
if ((show_error) && (netif_msg_intr(card)))
- pr_err("Got error interrupt, GHIINT0STS = 0x%08x, "
+ pr_err("Got error interrupt on %s, GHIINT0STS = 0x%08x, "
"GHIINT1STS = 0x%08x, GHIINT2STS = 0x%08x\n",
+ card->netdev->name,
status_reg, error_reg1, error_reg2);
/* clear interrupt sources */
^ permalink raw reply
* [PATCH 4/4]: powerpc/cell spidernet ethtool -i version number info.
From: Linas Vepstas @ 2006-08-11 17:11 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: Jens Osterkamp, James K Lewis, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
This patch adds version information as reported by
ethtool -i to the Spidernet driver.
Signed-off-by: James K Lewis <jklewis@us.ibm.com>
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
----
drivers/net/spider_net.c | 3 +++
drivers/net/spider_net.h | 2 ++
drivers/net/spider_net_ethtool.c | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-11 11:34:16.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-11 11:38:48.000000000 -0500
@@ -55,6 +55,7 @@ MODULE_AUTHOR("Utz Bacher <utz.bacher@de
"<Jens.Osterkamp@de.ibm.com>");
MODULE_DESCRIPTION("Spider Southbridge Gigabit Ethernet driver");
MODULE_LICENSE("GPL");
+MODULE_VERSION(VERSION);
static int rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_DEFAULT;
static int tx_descriptors = SPIDER_NET_TX_DESCRIPTORS_DEFAULT;
@@ -2293,6 +2294,8 @@ static struct pci_driver spider_net_driv
*/
static int __init spider_net_init(void)
{
+ printk("spidernet Version %s.\n",VERSION);
+
if (rx_descriptors < SPIDER_NET_RX_DESCRIPTORS_MIN) {
rx_descriptors = SPIDER_NET_RX_DESCRIPTORS_MIN;
pr_info("adjusting rx descriptors to %i.\n", rx_descriptors);
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-11 11:19:47.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-11 11:38:48.000000000 -0500
@@ -24,6 +24,8 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
+#define VERSION "1.1 A"
+
#include "sungem_phy.h"
extern int spider_net_stop(struct net_device *netdev);
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net_ethtool.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net_ethtool.c 2006-06-17 20:49:35.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net_ethtool.c 2006-08-11 11:38:48.000000000 -0500
@@ -55,7 +55,7 @@ spider_net_ethtool_get_drvinfo(struct ne
/* clear and fill out info */
memset(drvinfo, 0, sizeof(struct ethtool_drvinfo));
strncpy(drvinfo->driver, spider_net_driver_name, 32);
- strncpy(drvinfo->version, "0.1", 32);
+ strncpy(drvinfo->version, VERSION, 32);
strcpy(drvinfo->fw_version, "no information");
strncpy(drvinfo->bus_info, pci_name(card->pdev), 32);
}
^ 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