Re: interrupt handlers PowerPC via GCC
Tehn Yit Chin wrote: > Hey Scott, > > Thanks for the reply, I shall investigate further. > > I wasn't talking about interrupt handlers in Linux as such, but using > powerpc-eabi-gcc to write an ISR for the MPC5516. (I guess that could be > off-topic on this mailing list, but I thought the folks on this mailing list > would probably know the answer pretty easily). I was hoping that gcc would > generate the prologue and epilogue code for me via the interrupt attributes. I know nothing about GCC's interrupt attributes, however, there is no problem writing ISR's from scratch (no OS) for the ppc. There are several boot loaders, monitors etc. out there with examples. There is even one inside the Linux Kernel source - though it i probably far more complex than you need. Somewhere I have something for the ppc405 I can send you - but most ppc's are similar. -- Dave Lynch DLA Systems Software Development:Embedded Linux 717.627.3770 [EMAIL PROTECTED] http://www.dlasys.net fax: 1.253.369.9244Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I Need to Reset a PPC405EP PCI Bridge From a Kernel Driver Without Reboot
Hello, I have a peculiar problem dealing with an mPCI wireless network card on an AMCC405EP based system (spin-off of a Taihu). The task is to load the FPGA firmware in the card, reset the PCI card (to reset an ASIC, get it to reload from EEPROM but without resetting the PowerPC and of course without clearing the firmware in the FPGA), then to rescan (using a fake hotplug scheme) to find the PCI device, then finally upload a secondary firmware file to a flash device on the card. I need this for two reasons. One is to solve a chicken-and-egg type problem to recover a failed radio card after a botched up upgrade. The other is to avoid reboots (and wasted time per radio card) as they are programmed and calibrated in a jig on a manufacturing production line. I tried setting and then clearing the CPC0_SRR (software reset register) bit to reset the PCI bridge. I think that this wipes out the PCI bus completely. Since PCI is initialized by U-Boot, the kernel doesn't appear to know what to do. I get a data machine check oops at the point where the device drivers load up and start. I tried simply saving the 16 words of PCIL0 register content before toggling the SRR bit, and then restoring them afterwards. No difference. Next I notice a whole bank of configuration registers and am wondering just what needs to explicitly be preserved. Before I go into saving and restoring more registers, or cloning the 4xx_pci.c code from u-Boot into my fake hotplug rescan driver to reinitialize the PCI subsystem, does anyone have suggestions? Regards, Darcy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D PCI-Express problem
Kumar Gala ha scritto: On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote: Hi, do you remember my problem with the pci-express? I have an mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm observing this strange behavior: 1) I turn on the board and I stop the U-boot 2) I load the FPGA microcode 3) I start the system 4) I load the driver module and I read a version register in the FPGA 5) The system crashes with a "machine check exception: transfer error ack signal" 6) reboot 7) same procedure (without load the FPGA again) 8) now I can read the registers! If I repeat the procedure again it doesn't work anymore. I think it's a problem with pci-express controller. Have you got any suggestions? Thanks. Where are you loading the FPGA microcode (linux, u-boot)? Also, is the FPGA the only device connected over PCIe? - k I load the FPGA with JTAG and with a Xilinx program without a specific linux driver or u-boot. Yes, it is the only device connected over PCIe. \Marco ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MPC8641D PCI-Express problem
On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote: Hi, do you remember my problem with the pci-express? I have an mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm observing this strange behavior: 1) I turn on the board and I stop the U-boot 2) I load the FPGA microcode 3) I start the system 4) I load the driver module and I read a version register in the FPGA 5) The system crashes with a "machine check exception: transfer error ack signal" 6) reboot 7) same procedure (without load the FPGA again) 8) now I can read the registers! If I repeat the procedure again it doesn't work anymore. I think it's a problem with pci-express controller. Have you got any suggestions? Thanks. Where are you loading the FPGA microcode (linux, u-boot)? Also, is the FPGA the only device connected over PCIe? - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Joakim Tjernlund
> > Sent: Tuesday, March 18, 2008 11:11 PM
> >> To: Netdev; Li Yang
> >> Cc: Joakim Tjernlund
> >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> >>
> >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to
> >> the frame and the HW controller is not prepared to TX a frame
> >> bigger than 1518 bytes which is 4 bytes too small for a full
> >> VLAN frame. Also add 4 extra bytes for future expansion.
> >
> > IMO, VLAN and Jumbo packet support is not general case of Ethernet.
> > Could you make this change optional? Thanks.
> >
> > - Leo
>
> hmm, I do not agree. VLAN is common today.
>
> If you were to enable HW support for VLAN then the ethernet controller
> would inject an extra 4 bytes into the frame.
> This change does not change the visible MTU for the user. As is now,
> soft VLAN is silently broken. Do you
> really want the user to find and turn on a controller specific feature
> to use VLAN?
>
> What does netdev people think?
>
> Jocke
hmm, I misread the HW specs. The change has nothing to do with TX, it is
the MAX RX frame size that was too small for VLAN and that is what the
patch addresses. I see that tg3.c adds 4 bytes to MAX RX pkgs:
/* MTU + ethernet header + FCS + optional VLAN tag */
tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8);
So I don't think this change should be hidden behind a new CONFIG
option. Updated patch below with changed description.
Jocke
>From ec8ca3c9666bdc72652e403ea5f252b38e5a076b Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <[EMAIL PROTECTED]>
Date: Tue, 18 Mar 2008 15:40:59 +0100
Subject: [PATCH] ucc_geth: Add 8 bytes to max RX frame for VLANs
Creating a VLAN interface on top of ucc_geth adds 4 bytes
to the frame and the HW controller is not prepared to
receive a frame bigger than 1518 bytes which is 4 bytes too
small for a full VLAN frame. Also add 4 extra bytes for future
expansion.
Signed-off-by: Joakim Tjernlund <[EMAIL PROTECTED]>
---
drivers/net/ucc_geth.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 348892b..038ec75 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -114,10 +114,10 @@ static struct ucc_geth_info ugeth_primary_info = {
.maxGroupAddrInHash = 4,
.maxIndAddrInHash = 4,
.prel = 7,
- .maxFrameLength = 1518,
+ .maxFrameLength = 1518+8, /* Add 4 bytes for VLAN tags and 4 extra
bytes */
.minFrameLength = 64,
- .maxD1Length = 1520,
- .maxD2Length = 1520,
+ .maxD1Length = 1520+8,
+ .maxD2Length = 1520+8,
.vlantype = 0x8100,
.ecamptr = ((uint32_t) NULL),
.eventRegMask = UCCE_OTHER,
--
1.5.4.3
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MPC8641D PCI-Express problem
Hi, do you remember my problem with the pci-express? I have an mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm observing this strange behavior: 1) I turn on the board and I stop the U-boot 2) I load the FPGA microcode 3) I start the system 4) I load the driver module and I read a version register in the FPGA 5) The system crashes with a "machine check exception: transfer error ack signal" 6) reboot 7) same procedure (without load the FPGA again) 8) now I can read the registers! If I repeat the procedure again it doesn't work anymore. I think it's a problem with pci-express controller. Have you got any suggestions? Thanks. Marco ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
