* [PATCH] ehea: PPC - New hcall opcode defines
From: Thomas Klein @ 2006-08-11 9:40 UTC (permalink / raw)
To: linux-ppc; +Cc: Thomas Klein, Christoph Raisch, Marcus Eder, Jan-Bernd Themann
Hi,
this patch adds additional hcall opcode defines in asm-powerpc/hvcall.h
which are required for the IBM eHEA Ethernet Device Driver which is
targeted for kernel inclusion in the near future.
Including those defines in hvcall.h was a request we got in reply to
posting our driver.
Driver post: http://ozlabs.org/pipermail/linuxppc-dev/2006-August/024947.html
Reply: http://ozlabs.org/pipermail/linuxppc-dev/2006-August/024971.html
I'm aware this does not fix a bug and we're already at rc4 but since it
adds only a few innocent defines it would be great if it could be included
in 2.6.18-rc5.
This patch replaces yesterday's patch with the same title. It contains
the modification requested by a comment I got.
Kind regards
Thomas
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
Changelog-by: Thomas Klein <tklein@de.ibm.com>
Differences to patch
http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025000.html
Changelog:
- New defines rearranged according to their numerical value
include/asm-powerpc/hvcall.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff -Nurp -X dontdiff linux-2.6.18-rc4/include/asm-powerpc/hvcall.h patched_kernel/include/asm-powerpc/hvcall.h
--- linux-2.6.18-rc4/include/asm-powerpc/hvcall.h 2006-08-06 11:20:11.000000000 -0700
+++ patched_kernel/include/asm-powerpc/hvcall.h 2006-08-11 01:54:49.696514466 -0700
@@ -198,6 +198,19 @@
#define H_MANAGE_TRACE 0x1C0
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
+#define H_MODIFY_HEA_QP 0x250
+#define H_QUERY_HEA_QP 0x254
+#define H_QUERY_HEA 0x258
+#define H_QUERY_HEA_PORT 0x25C
+#define H_MODIFY_HEA_PORT 0x260
+#define H_REG_BCMC 0x264
+#define H_DEREG_BCMC 0x268
+#define H_REGISTER_HEA_RPAGES 0x26C
+#define H_DISABLE_AND_GET_HEA 0x270
+#define H_GET_HEA_INFO 0x274
+#define H_ALLOC_HEA_RESOURCE 0x278
+#define H_ADD_CONN 0x284
+#define H_DEL_CONN 0x288
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
^ permalink raw reply
* Re: [PATCH] ehea: PPC - New hcall opcode defines
From: Thomas Klein @ 2006-08-11 9:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: tklein, themann, Thomas Klein, linuxppc-dev, raisch, meder
In-Reply-To: <20060811012044.1c8fcd20.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Thu, 10 Aug 2006 17:05:28 +0200 Thomas Klein <osstklei@de.ibm.com> wrote:
>
>> diff -Nurp -X dontdiff linux-2.6.18-rc4/include/asm-powerpc/hvcall.h patched_kernel/include/asm-powerpc/hvcall.h
>> --- linux-2.6.18-rc4/include/asm-powerpc/hvcall.h 2006-08-06 11:20:11.000000000 -0700
>> +++ patched_kernel/include/asm-powerpc/hvcall.h 2006-08-10 06:26:33.018907062 -0700
>> @@ -201,6 +201,19 @@
>> #define H_JOIN 0x298
>> #define H_VASI_STATE 0x2A4
>> #define H_ENABLE_CRQ 0x2B0
>> +#define H_ALLOC_HEA_RESOURCE 0x278
>> +#define H_MODIFY_HEA_QP 0x250
>> +#define H_QUERY_HEA_QP 0x254
>> +#define H_QUERY_HEA 0x258
>> +#define H_QUERY_HEA_PORT 0x25C
>> +#define H_MODIFY_HEA_PORT 0x260
>> +#define H_REG_BCMC 0x264
>> +#define H_DEREG_BCMC 0x268
>> +#define H_REGISTER_HEA_RPAGES 0x26C
>> +#define H_DISABLE_AND_GET_HEA 0x270
>> +#define H_GET_HEA_INFO 0x274
>> +#define H_ADD_CONN 0x284
>> +#define H_DEL_CONN 0x288
>>
>
> This patch appears to be whitespace damaged and it would be preferable if
> the new defines were in there correct places in numerical order.
>
> Thanks.
>
>
I agree. I posted a new patch
(http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025032.html)
where I rearranged the defines to fit in the numerical order with the
other defines.
The whitespaces are not damaged although they appear to be. This is due
to the usage of
TAB characters to align the hex values. TAB characters are used in the
whole file to align the
numerical values. I applied the patch and the result looks okay.
^ permalink raw reply
* mpc8xx usb controller on linux 2.6
From: Josef Angermeier @ 2006-08-11 10:39 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am using linux 2.6.18 on a MPC875, which runs on a custom board. Some changes to the official kernel allow me to get the mpc8xx internal usb host controller working and access an usb stick successfully. I just used Brad Parkers 2.4 patch, ported it to linux 2.6 and merged
it with the cpm2usb project. Until now it just worked for my board. Maybe any skilled programmer would like to test the patch also on his own board, fix some bugs and give me some confidence that the patch is somehow stable so that it once can be added to official linux source tree. I would appreciate that and try to help to get it working.
You can find the patch at
http://wwwcip.informatik.uni-erlangen.de/~sijoange/
Because of a bug in the m8xx USB CPM (read m8xx errata) you must feed a 1khz signal out and feed it at the DREQ pin in again on your board. Then you have to patch the kernel, configure linux to use the m8xx usb sof patch and the m8xx usb host controller, startup the compiled linux, fix some bugs, give me some feedback.
Regards,
Josef
^ permalink raw reply
* Re: SystemAce Driver.
From: sudheer @ 2006-08-11 10:42 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
In-Reply-To: <44DC4F34.1070308@gmail.com>
Hi Ameet,
Firstly, thanks for the mail.
I am able to compile the linux-2.6.16 and got the ace support files with
the patch.
While compiling got some errors with xparameters, but am rectify them.
I need to wait for the hardware to test the source.
Thanks & Regards
Sudheer
Ameet Patil wrote:
> Hi Sudheer,
> Frank has already answered your questions. If you have any problems
> with the SysAce patch... do let me know. I have written a small
> tutorial here if it helps...
>
> http://linux.get2knowmore.com
>
>
> -Ameet
>
> sudheer wrote:
>> Hello Ameet Patil
>>
>> I am looking for linux kernel source 2.6.16 with system ace
>> controller support. I downloaded the linux-2.6.16 and linux-2.6.17-1
>> source from kernel.org but could not find any files related to system
>> ace controller ( No xilinx_sysace directory in drivers/block/) . I
>> have checked penguinppc.org also but could not get it.
>>
>> Can you please send to me the link where i could download the
>> linuxppc-2.6.16 source with system ace support.
>>
>> Thanks & Regards
>> Sudheer
>>
>> Ameet Patil wrote:
>>> Hi Raja,
>>> I have ported the Xilinx System ACE driver to 2.6 kernel. Find
>>> the latest one here:
>>> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>>>
>>>
>>> NOTE: this patch wouldn't work if you are using the TEMAC driver. In
>>> which case use the -after-TEMAC patch found in the patches folder
>>> above.
>>>
>>> Check the following discussions (threads) for more details:
>>> 1. "Xilinx SystemACE driver for 2.6"
>>> 2. "Xilinx BSP for linux 2.6"
>>> 3. "Kernel hangs after "Now booting the kernel"."
>>>
>>> cheers,
>>> -Ameet
>>>
>>> Raja Chidambaram wrote:
>>>
>>>> Hi all,
>>>> We are working on customized board with amcc 440SPe
>>>> processor & xilinx System Ace controller. The System
>>>> Ace controller is connected to compact flash driver.
>>>>
>>>> We use u-boot 1.2 as bootloader & linux kernel
>>>> 2.6.16-2.
>>>>
>>>> On the process the u-boot is able to detect compact
>>>> flash through Xilinx SystemAce controller & able to
>>>> load the kernel image into compact flash.But when the
>>>> linux boot's up it not able to detect the System Ace
>>>> controller or compact flash.
>>>>
>>>> Note:we need to have the root file system in compact
>>>> flash.
>>>>
>>>> Is their any drivers available for SystemAce
>>>> controller on linux 2.6,if their how to get it.please
>>>> help me in this
>>>> with regards
>>>> raja
>>>>
>>>>
>>>>
>>>> __________________________________________________
>>>> Do You Yahoo!?
>>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>>> http://mail.yahoo.com _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>
>
^ permalink raw reply
* how to apply a PowerPC patch to linux 2.4 kernel and port to memec board with vertex II pro FPGA?
From: Ujwal @ 2006-08-11 11:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <b47d45990608102310l4cba891fnce5ee8d60c7134ef@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 570 bytes --]
^ permalink raw reply
* Re: Gianfar eth driver on 8540 ppc - for 2.4 and 2.6 : different outputs
From: Prashant Yendigeri @ 2006-08-11 11:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <E5C22C0A-45C9-4FA8-B10D-8F3EBDA03878@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]
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.
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
______________________________________________________________________
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 4795 bytes --]
^ permalink raw reply
* [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
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