Re: Regarding select() on PPC
For negetive value of n (first argument to select) select fails with EINVAL error, But for the same when I tested for PowerPC it was giving EFAULT, Its on 2.6.16 kernel. Please let me know, If this is fixed or it's a issue in PPC. For other archs its working fine. Interesting. The man page for select says that select should return EINVAL when the first argument is negative. By that, only ppc32 is correct. :) -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Regarding select() on PPC
I wrote: Interesting. The man page for select says that select should return EINVAL when the first argument is negative. By that, only ppc32 is correct. :) Sorry. I should read before posting. Please ignore my extraneous comment above. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: mpc744x, Marvell mv6446x kernel guidance please
On Wed, Jul 30, 2008 at 08:56:18AM -0500, Stephen Horton wrote: Thanks for your kind encouragement. I now have a mostly booting kernel. I have just a few remaining issues to resolve; perhaps you (or others) can give me some tips regarding these: 1. In your prpmc2800 .dts configuration, in the PCI bus configuration section, you lay-out the IRQ mappings like this: interrupt-map = /* IDSEL 0x0a */ 5000 0 0 1 /mv64x60/pic 50 5000 0 0 2 /mv64x60/pic 51 I've read the Open Firmware document on Interrupt Mapping, but I still don't really understand the first 3 columns (5000 0 0), especially where the first column comes from. Is this just some arbitrarily selected offset address for that device on the pci bus? An address on the PCI bus is represented by 3 cells (96 bits). Take a look at page 4 of http://www.openbios.org/data/docs/bus.pci.pdf You'll see that the PCI device is contained in bits 15-11, selected by the 0xf800 in interrupt-map-mask. The 0x5000 corresponds to device 0xa. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Booting Linux Kernel on MPC8560
Deepak Gaur wrote: I have a task to boot Mvista kernel on MPC8560 based board. The bootloader in U-boot. After decompression my final image is located at address 0x1fff0040 in SDRAM That's your problem. This code only works when loaded at address 0. Fix your bootloader configuration. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Use 2G RAM in 8548, vmalloc fail, adjust_total_lowmem
I am using a MCP8548 board with 2.6.14.5 kernel. And I would like to upgrade memory from 512MB to 2048MB. Finally, I realize this is not so easy as I think. I encounter several problems. :~~ First, I change mem=512M to mem=2048M. 1. vmalloc fail problem So, I change kernel config in advanced setup Change Set maximum low memory from 0x3000 to 0x8000. Change Virtual address of kernel base from 0xC000 to 0x6000. Change Set custom user task size from 0x8000 to 0x6000 Just enable CONFIG_HIGHMEM=y to use your 2GB. It's not worth the effort to try making it all accessible as lowmem. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: The question about the high memory support on MPC8360?
Robert lazarski wrote: On Nov 29, 2007 2:29 AM, vijay baskar [EMAIL PROTECTED] wrote: How to make the linux find the total 2GB memory? Hi Friend, I hope u had tracked the conversion that has been going on. The max mem that the kernel can show is only 768 MB because only that of memory is directly mapped with your ram.. No matter how much ram 768 MB (in powerpc.. it varies in other architectures) u have, the kernel will show only 768 MB.. This is called low mem.. How t o use high mem?? scott can probably guide us on this.. I also have lot of confusions about high mem.. Also i would suggest you a bit of reading on virtual memory management on linux to get a grasp about how things are done Rest for scott regards, vijai I also have a requirement to use more than 768MB and 0x3000. I have other problems at the moment, so I haven't tested this completely yet. My limited understanding, though, is that to use more than 768MB you have to change your kernel configuration, including shifting the kernel start address. This is what I plan on testing for 1GB when I have time: CONFIG_ADVANCED_OPTIONS=y CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 # CONFIG_CONSISTENT_START_BOOL is not set # CONFIG_CONSISTENT_SIZE_BOOL is not set # CONFIG_BOOT_LOAD_BOOL is not set If that works for current kernels, please respond to the list ;-) . Can't answer that question, but before trying that, have you tried CONFIG_HIGHMEM=y ? -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
I wrote: Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect. I tried this with the current powerpc.git tree on my mpc8548cds, and the reboot command works for me. The system rebooted just fine. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 85xx software reset problems from paulus.git
On Tue, Nov 27, 2007 at 10:26:59AM -0600, Kumar Gala wrote: On Nov 27, 2007, at 8:54 AM, Dale Farnsworth wrote: I wrote: Kumar Gala wrote: Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when calling 'reboot' in the shell, it just hangs. Using the same dts and resets in 2.6.23.1 reboots fine. I don't have a cds reference, but someone who does should be able to confirm whether the issue exists or not by just attempting to reboot via bash. Can someone do a git-bisect and find the patch that breaks things? I'll see if I can reproduce it on my 8548cds. If so, I'll then git- bisect. I tried this with the current powerpc.git tree on my mpc8548cds, and the reboot command works for me. The system rebooted just fine. I'm wondering if there is an issue rebooting if we are in an oops. I still can't reproduce it. Current powerpc.git reboots OK after an oops on my 8548cds. As long as I make it to Rebooting in 180 seconds.., it resets 3 minutes later. It may be hw-dependent as well as sw-dependent. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Kexec on powerpc
On Thu, Nov 15, 2007 at 01:14:27PM +, [EMAIL PROTECTED] wrote: I'm using the latest kernel and I need the kexec support for 85xx processor. When I use the menuconfig with ARCH=ppc and the 85xx and e500 support, I have the kexec support, but when I use ARCH=powerpc I haven't it, but I'm selecting the same processor!! Is it a bug in kconfig? Somebody can explain to me why? I don't think kexec works for ppc-32 arch/powerpc at the present. We have been working on kexec/kdump support for 32-bit arch/powerpc. It requires changes both to the kernel and to the kexec-tools package. I plan to post a first round of patches to linuxppc-dev early next week. -Dale Farnsworth ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] PPC 85xx failure with odd memory sizes and CONFIG_HIGHMEM
From: Dale Farnsworth [EMAIL PROTECTED] The CONFIG_FSL_BOOKE mmu setup code fails when CONFIG_HIGHMEM=y and the 3 fixed TLB entries cannot exactly map the lowmem size. Each TLB entry can map 4MB, 16MB, 64MB or 256MB, so the failure is observed when the kernel lowmem size is not equal to the sum of up to 3 of those values. Normally, memory is sized in nice numbers, but I observed this problem while testing a crash dump kernel. The failure can also be observed by artificially reducing the kernel's main memory via the mem= kernel command line parameter. This commit fixes the problem by setting __initial_memory_limit in adjust_total_lowmem(). Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] --- arch/powerpc/mm/fsl_booke_mmu.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6.21/arch/powerpc/mm/fsl_booke_mmu.c === --- linux-2.6.21.orig/arch/powerpc/mm/fsl_booke_mmu.c 2007-10-02 01:18:10.0 + +++ linux-2.6.21/arch/powerpc/mm/fsl_booke_mmu.c2007-10-03 16:40:24.0 + @@ -60,6 +60,7 @@ unsigned int num_tlbcam_entries; static unsigned long __cam0, __cam1, __cam2; extern unsigned long total_lowmem; extern unsigned long __max_low_memory; +extern unsigned long __initial_memory_limit; #define MAX_LOW_MEMCONFIG_LOWMEM_SIZE #define NUM_TLBCAMS(16) @@ -233,4 +234,5 @@ adjust_total_lowmem(void) __cam0 20, __cam1 20, __cam2 20, (total_lowmem - __cam0 - __cam1 - __cam2) 20); __max_low_memory = max_low_mem = __cam0 + __cam1 + __cam2; + __initial_memory_limit = __max_low_memory; } ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] PPC 85xx failure with odd memory sizes and CONFIG_HIGHMEM
On Wed, Oct 03, 2007 at 02:34:42PM -0500, Rune Torgersen wrote: From: Dale Farnsworth The CONFIG_FSL_BOOKE mmu setup code fails when CONFIG_HIGHMEM=y and the 3 fixed TLB entries cannot exactly map the lowmem size. Each TLB entry can map 4MB, 16MB, 64MB or 256MB, so the failure is observed when the kernel lowmem size is not equal to the sum of up to 3 of those values. Does this mean you cannot run 1G of lowmem on a 85xx? I think you can, and maybe I should have added 1GB to my list of sizes above. But, my 85xx system only has 256MB, so I can't test it. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [linux kernel 2.6.19] ethernet driver for Marvell bridge GT-64260
I am porting linux kernel 2.6.19 on a platform based on PPC750FX together with a Marvell GT64260. I use a patched 643xx driver which is back ported to 64260 by Steven J. Hill. I have ethernet now up and running, but only if I switch debug on, which generates a big bunch of screen messages. As soon as I switch debug off, I get the message Virtual device %s asks to queue packet! on every transmission request. This happens on ping an other system. Has anyone experience in such an event? Is there anything how I can speed up performance with the 64260? Is there a similar problem known with the 64360? No, this does not happen on the mv64360. As I recall, that message occurs when something attempts to queue a packet to a driver that has called netif_stop_queue() but hasn't yet called netif_wake_queue(). I would guess that when you turn debug on, you are changing the driver logic in addition to the timing. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board. My Linux runs completely except for Ethernet. I don't find any Ethernet driver for my bridge. Do you know if there is an Ethernet driver for the Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260 ethernet driver in the kernel 2.4.34 for MIPS processor, will it be possible to port it in a 2.6 kernel? I believe that Steve Hill [EMAIL PROTECTED] has patched the mv643xx_eth driver to work with the 64260 and plans to submit the patches. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [kernel-2.6.19]Marvell GT-64260 and Ethernet
On Tue, Jul 10, 2007 at 03:41:25PM +0200, ThomasB wrote: It's nevertheless odd, I read about a file named gt64260_eth.c during my search on the internet.But I wasn't able to find it :(. It was in the (now obsolete) linuxppc_2_4_devel kernel. I can send you a copy, but a merged mv64x60 driver will be much better. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: help on dts compiler please.
$ dtc -f -I dts -O dtb mpc8541cds.dts DTC: dts-dtb on file mpc8541cds.dts syntax error at line 15 FATAL ERROR: Couldn't read input tree Where did you get your dtc version from? Sorry I answered the question wrong. I downloaded the gzip tar file from David Gibson web page. That same web page says that the latest version of the web page is at git://www.jdl.com/software/dtc.git Try the current version available there. -Dale Farnsworth ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Xilinx git tree at source.mvista.com
In article [EMAIL PROTECTED] you write: On Thu, 24 May 2007, Andrei Konovalov wrote: Hello, My Xilinx Virtex Development tree is now alive again. Please use the dev branch (master is just the ko copy): http://source.mvista.com/git/gitweb.cgi?p=linux-xilinx-26.git;a=shortlog;h=dev I can not access the git-tree there: No such project :-( Oops. I misconfigured gitweb while updating it. I've fixed it, so please try again. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: RFC: MPC52xx serial port configuration from DT blob
Bartlomiej wrote:
We have a MPC5200B-based board running an arch/powerpc kernel and we
need the ability to configure a non-console serial port for a particular
baud rate during system start-up. It seems that the UART driver in
drivers/serial/mpc52xx_uart.c does not support this. It only allows to
set parameters for a port that is used as a console, and for which those
parameters are passed in the kernel command line. We would like to
extend the mpc52xx_uart.c driver to be able to retrieve port options
from the DT blob and configure a given port accordingly. A new
port-specific property called options would be used for this. It would
have syntax following its namesake in console kernel parameter, as
described in Documentation/kernel-parameters.txt.
For example, the following settings in the .dts file would make UART5 to
be configured at 115200 baud, no parity, 8 bits.
[EMAIL PROTECTED] { // PSC5
device_type = serial;
compatible = mpc5200b-psc-uart\0mpc5200-psc-uart;
port-number = 4; // Logical port assignment
options = 115200n8
cell-index = 4;
reg = 2800 100;
interrupts = 2 c 0;
interrupt-parent = 500;
};
In case a console port has conflicting options given in the kernel
command line and in the DT blob, the command line values would be used.
Any comments on the above will be appreciated.
The device tree is intended to be an OS-independent description of the
state of the platform hardware as left by firmware (or bootwrapper).
It is not intended to contain kernel configuration parameters or options,
though there are a few exceptions.
So, this kind of change is unlikely to be accepted.
-Dale
___
Linuxppc-embedded mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: What is the difference between Montavista Kernel Source and Kernel.Org Source
I'm Going to use linux on ML403. I want to know, what is the difference between the linux kernel source, that we download from source.mvista.com ( using git ) and the original kernel source code that we download from kernel.org? The multiple git trees hosted at source.mvista.com/git are development trees similar to the trees hosted at www.kernel.org/git. Contact the individual developers for details on each tree. Dale Farnsworth ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: MV64360 ethernet controller
[EMAIL PROTECTED] wrote: I recently got a few Force/Motorola PowerPMC-280 PMC modules consisting mainly of a MPC7447 G4 an the Marvell MV64360 system controller. Since this a hobbyist project only I don't have Montavista Linux which seems to already support the board. Instead I ported the stock Linux kernel. Works quite well so far. The only thing I did not get to work is the integrated ethernet. The mv64360_eth driver loads fine and sees both ports. It does not get any interrupts for incoming packets (activity led blinks though). Only unplugging the cable generates an interrupt. Since I do not have any documentation on the Marvell chip and the company does not answer my request I am quite lost. The PHY interrupts are routed to one of the GPIO/interrupt pins. I did not find any code in the ethernet driver that would be able to use it though. Is it needed at all? Any hint is appreciated! Sebastian Hi Sebastian, Yes, the driver needs receive and transmit interrupts. However, the same irq number is used for PHY status change as well as for packet receive and transmit. I don't see how you could see PHY status change interrupts and not rx/tx interrupts. mv643xx_eth_int_handler() should be called for all ethernet-related interrupts*. Are you certain that you're not seeing rx and tx interrupts? * You may not see an interrupt on every packet because of the transmit irq coalescing mechanism and the use of NAPI on receive. Mark Greer and I are starting on arch/powerpc support for the mv64x60 and ppmc280. We will submit it as when we have something useful. In the meantime, the arch/ppc code below may serve as a hint. (Just to be clear, I didn't write this code and don't mean to take credit for it.) -Dale /* * arch/ppc/platforms/ppmc280.h * * Definitions for Motorola PPMC280 board * * Based on db64360.h, Written by Rabeeh Khoury - [EMAIL PROTECTED] * Based on code done by Mark A. Greer [EMAIL PROTECTED] * * 2001-2002 (c) 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. */ /* * The MV64x60 has 2 PCI buses each with 1 window from the CPU bus to * PCI I/O space and 4 windows from the CPU bus to PCI MEM space. * We'll only use one PCI MEM window on each PCI bus. * * This is the CPU physical memory map (windows must be at least 1MB and start * on a boundary that is a multiple of the window size): * * 0xf204-0x - Unused * 0xf200-0xf203 - Integrated SRAM * 0xf101-0xf1ff - Unused * 0xf100-0xf100 - MV64360 Registers * 0xc080-0xf0ff - Unused * 0xc000-0xc07f - Boot flash (BootCS#) * 0xb200-0xb2ff - User flash 1 ( CS1) * 0xb000-0xb1ff - User flash 0 ( CS0) * 0xa800-0x9fff - Unused * 0xa800-0xa7ff - PCI 1 I/O (defined in mv64360.h) * 0xa000-0xa7ff - PCI 0 I/O (defined in mv64360.h) * 0x9000-0x9fff - PCI 1 MEM (defined in mv64360.h) * 0x8000-0x8fff - PCI 0 MEM (defined in mv64360.h) * 0x2000-0x7fff - Reserved for SDRAM expansion * 0x-0x1fff - On Board SDRAM ( CS0) */ #ifndef __PPC_PLATFORMS_PPMC280 #define __PPC_PLATFORMS_PPMC280 /* PCI mappings */ #define PPMC280_PCI0_IO_CPU_BASE0xa000 #define PPMC280_PCI0_IO_PCI_BASE0x #define PPMC280_PCI0_IO_SIZE0x0100 #define PPMC280_PCI0_MEM_CPU_BASE 0x8000 #define PPMC280_PCI0_MEM_PCI_BASE 0x8000 #define PPMC280_PCI0_MEM_SIZE 0x1000 #define PPMC280_PCI1_IO_CPU_BASE(PPMC280_PCI0_IO_CPU_BASE + \ PPMC280_PCI0_IO_SIZE) #define PPMC280_PCI1_IO_PCI_BASE(PPMC280_PCI0_IO_PCI_BASE + \ PPMC280_PCI0_IO_SIZE) #define PPMC280_PCI1_IO_SIZE0x0100 #define PPMC280_PCI1_MEM_CPU_BASE (PPMC280_PCI0_MEM_CPU_BASE + \ PPMC280_PCI0_MEM_SIZE) #define PPMC280_PCI1_MEM_PCI_BASE (PPMC280_PCI0_MEM_PCI_BASE + \ PPMC280_PCI0_MEM_SIZE) #define PPMC280_PCI1_MEM_SIZE 0x1000 /* CPU Physical Memory Map setup (other than PCI) */ #define PPMC280_EXT_FLASH_BASE_10xb000 #define PPMC280_EXT_FLASH_BASE_20xb200 #define PPMC280_BOOT_FLASH_BASE 0xc000 /* BOOT FLASH Base */ #define PPMC280_INTERNAL_SRAM_BASE 0xf200 #if defined(CONFIG_MTD_PPMC2800D_FLASH) || defined(CONFIG_MTD_PPMC2800D_FLASH_MODULE) #define PPMC280_EXT_FLASH_SIZE_ACTUAL 0x0400 #define
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
In article [EMAIL PROTECTED] Nicolas wrote: --- a/arch/powerpc/sysdev/mpc52xx_pic.c 1970-01-01 01:00:00.0 +0100 +++ b/arch/powerpc/sysdev/mpc52xx_pic.c 2006-11-01 21:16:40.0 +0100 @@ -0,0 +1,566 @@ +/* + * + * Programmable Interrupt Controller functions for the Freescale MPC52xx. + * + * Copyright (C) 2006 bplan GmbH + * + * This file is licensed under the terms of the GNU General Public License Once again, please restore the copyright lines you removed from this file. Dale Farnsworth ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH/RFC] powerpc: Add MPC5200 Interrupt Controller support.
On Wed, Nov 01, 2006 at 11:07:08PM +0100, Sven Luther wrote: On Wed, Nov 01, 2006 at 10:05:43PM -, Dale Farnsworth wrote: In article [EMAIL PROTECTED] Nicolas wrote: --- a/arch/powerpc/sysdev/mpc52xx_pic.c 1970-01-01 01:00:00.0 +0100 +++ b/arch/powerpc/sysdev/mpc52xx_pic.c 2006-11-01 21:16:40.0 +0100 @@ -0,0 +1,566 @@ +/* + * + * Programmable Interrupt Controller functions for the Freescale MPC52xx. + * + * Copyright (C) 2006 bplan GmbH + * + * This file is licensed under the terms of the GNU General Public License Once again, please restore the copyright lines you removed from this file. Hehe, you are aware that, IIRW, someone suggested to cut them earlier in this thread ? I think people called for removing the Maintained by and the changelog-like commentary, but not the copyrights. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
In article [EMAIL PROTECTED] Nicolas wrote: This patch add MPC52xx Interrupt controller for ARCH=powerpc. It includes the main code in arch/powerpc/sysdev/ ad well as an header file in include/asm-powerpc. Signed-off-by: Nicolas DET [EMAIL PROTECTED] NAK. Two requests: 1. Please include patches inline so that they may be easily reviewed. 2. Please do not remove copyright lines from files you modify. -Dale ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Add MPC52xx Interrupt controller support for ARCH=powerpc
In article [EMAIL PROTECTED] Nicolas wrote:
This patch add MPC52xx Interrupt controller for ARCH=powerpc.
It includes the main code in arch/powerpc/sysdev/ ad well as an header file in
include/asm-powerpc.
Signed-off-by: Nicolas DET [EMAIL PROTECTED]
Wow, the source code size sure ballooned in this revision.
I'd like to see us go the other direction, with something like the
following (untested code).
-Dale Farnsworth
(BTW, I sent a patch containing these changes to Nicolas last week.)
---
static inline void io_be_setbit(u32 __iomem *addr, int bitno)
{
out_be32(addr, in_be32(addr) | 1 bitno);
}
static inline void io_be_clrbit(u32 __iomem *addr, int bitno)
{
out_be32(addr, in_be32(addr) ~(1 bitno));
}
static void mpc52xx_ic_mask(unsigned int virq)
{
u32 val;
int irq;
int l1irq;
int l2irq;
irq = irq_map[virq].hwirq;
l1irq = (irq MPC52xx_IRQ_L1_MASK) MPC52xx_IRQ_L1_OFFSET;
l2irq = (irq MPC52xx_IRQ_L2_MASK) MPC52xx_IRQ_L2_OFFSET;
pr_debug(%s: irq=%x. l1=%d, l2=%d\n, __func__, irq, l1irq, l2irq);
switch (l1irq) {
case MPC52xx_IRQ_L1_CRIT:
case MPC52xx_IRQ_L1_MAIN:
if (l2irq = 3)
io_be_clrbit(intr-ctrl, 11 - l2irq);
else
io_be_setbit(intr-main_mask, 16 - l2irq);
break;
case MPC52xx_IRQ_L1_PERP:
io_be_setbit(intr-per_mask, 31 - l2irq);
break;
case MPC52xx_IRQ_L1_SDMA:
io_be_setbit(sdma-IntMask, l2irq);
break;
}
}
static void mpc52xx_ic_unmask(unsigned int virq)
{
u32 val;
int irq;
int l1irq;
int l2irq;
irq = irq_map[virq].hwirq;
l1irq = (irq MPC52xx_IRQ_L1_MASK) MPC52xx_IRQ_L1_OFFSET;
l2irq = (irq MPC52xx_IRQ_L2_MASK) MPC52xx_IRQ_L2_OFFSET;
pr_debug(%s: irq=%x. l1=%d, l2=%d\n, __func__, irq, l1irq, l2irq);
switch (l1irq) {
case MPC52xx_IRQ_L1_CRIT:
case MPC52xx_IRQ_L1_MAIN:
if (l2irq = 3)
io_be_setbit(intr-ctrl, 11 - l2irq);
else
io_be_clrbit(intr-main, 16 - l2irq);
break;
case MPC52xx_IRQ_L1_PERP:
io_be_setbit(intr-per_mask, 31 - l2irq);
break;
case MPC52xx_IRQ_L1_SDMA:
io_be_clrbit(sdma-IntMask, l2irq);
break;
}
}
static void mpc52xx_ic_ack(unsigned int virq)
{
u32 val;
int irq;
int l1irq;
int l2irq;
irq = irq_map[virq].hwirq;
l1irq = (irq MPC52xx_IRQ_L1_MASK) MPC52xx_IRQ_L1_OFFSET;
l2irq = (irq MPC52xx_IRQ_L2_MASK) MPC52xx_IRQ_L2_OFFSET;
pr_debug(%s: irq=%x. l1=%d, l2=%d\n, __func__, irq, l1irq, l2irq);
switch (l1irq) {
case MPC52xx_IRQ_L1_CRIT:
case MPC52xx_IRQ_L1_MAIN:
if (l2irq = 3)
io_be_setbit(intr-ctrl, 27 - l2irq);
break;
case MPC52xx_IRQ_L1_PERP:
io_be_clrbit(intr-per_mask, 31 - l2irq);
break;
case MPC52xx_IRQ_L1_SDMA:
out_be32(sdma-IntPend, 1 l2irq);
break;
}
}
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
IBM OCP GPIO driver for linux 2.6
In article 1154603751.17247.10.camel at jb-portable you write:
I'm porting a custom PPC 405GP card based on a Walnut from Montavista
Linux 3.0 (kernel 2.4.18) to linux 2.6, and I was wondering if there is
a port of the IBM OCP GPIO driver (a char driver providing
device /dev/gpio, major 10 minor 185). The driver was written by Armin
Kuster, and it doesn't exist in the stock kernel 2.6.17.7.
Let me known if a port exists, or if there is a new way of accessing the
PPC 405GP GPIO under linux 2.6.
The recommended way of accessing GPIO registers is to mmap them
and manipulate them directly in user space.
Below, I've included a quick hack that blinks a LED on a Walnut-like
board.
-Dale
#include stdint.h
#include stdio.h
#include sys/mman.h
#include sys/types.h
#include unistd.h
#include sys/stat.h
#include fcntl.h
#define GPIO_PAGE_ADDR 0xef60
#define OUTPUT_REG 0x0700
#define TRISTATE_REG0x0704
#define OPENDRAIN_REG 0x0718
#define INPUT_REG 0x071c
#define MEDIA_LED_BIT 0x2000
#define reg_addr(p, o) ((uint32_t *)((void *)p + o))
int main(int argc, char *argv[])
{
int i;
uint32_t *p;
char *filename = /dev/mem;
void *addr = 0;
size_t length = 4096;
int prot= PROT_READ | PROT_WRITE;
int flags = MAP_SHARED;
int fd = open(filename, O_RDWR);
off_t offset= (off_t)GPIO_PAGE_ADDR;
if (fd 0) {
perror(open);
return 1;
}
p = mmap(addr, length, prot, flags, fd, offset);
if (p == MAP_FAILED) {
perror(mmap);
return 4;
}
/* drive led output */
*reg_addr(p, TRISTATE_REG) |= MEDIA_LED_BIT;
/* blink media led 10 times */
for (i = 0; i 10; i++) {
/* turn media led on */
*reg_addr(p, OUTPUT_REG) = ~MEDIA_LED_BIT;
sleep(1);
/* turn media led off */
*reg_addr(p, OUTPUT_REG) |= MEDIA_LED_BIT;
sleep(1);
}
return 0;
}
Kernel for MPC Lite 5200 will not compile
Jon Rigby jcrigby at gmail.com wrote: After thinking about this moreI don't want to push getting the official Freescale code into the tree. If Dale's code works as well as the Freescale code then lets stay with it because it is a lot cleaner. Thanks. The effort of porting other drivers will hopefully be easier now that I have the experience of having done ATA. Would Freescale be amenable to working toward a revised, common, API? Unfortunately, I didn't find the Freescale Bestcomm API to be clean enough for acceptance into Linux, so changes would be needed. -Dale
boot failure on lite5200b board
From article 84A109BF918D934CB46ACF33BCE187C002D54D7B at mail02.student.main.ntu.edu.sg: I have actually tried both kernel with both console configurations. It = gave the same output, thus I presume that the problem lies somewhere = else. I attached the log to this email.=20 the board is Lite5200B Version 1.0. Which .config file do you want? Sylvain, we have ordered a debugging set but we are still waiting for = delivery, the leaking time is said to be one month, tant pis. And the = log I attached here are booting from a higher address (0x50). My current u-boot args: setconsole=setenv bootargs console=ttyPSC0, 115200n8 console=tty1 This is incorrect. There can be no space before the baud rate, and I don't think you want console=tty1. -Dale
[PATCH] ppc32: handle Book E debug exceptions on kernel stack
On Fri, Feb 24, 2006 at 10:49:45AM +1100, David Gibson wrote: On Wed, Feb 22, 2006 at 10:19:54PM -0600, Kumar Gala wrote: On Tue, 14 Feb 2006, Dale Farnsworth wrote: From: Dale Farnsworth dale at farnsworth.org On PPC Book E processsors, we currently handle debug exceptions on the critical exception stack (debug stack for E200). This causes problems with the kgdb single step handler, which calls smp_processor_id() and spin_lock(), which reference current_thread_info(), which only works when we are on the kernel stack. We address this by switching to the kernel stack early while handling debug exceptions. Note that the entry values of r10 and r11 are still saved on the critical exception (or debug) stack. Signed-off-by: Dale Farnsworth dale at farnsworth.org Paul, We were wondering if you or David remember why a specific critical exception stack was added in the 40x port from 2.4 to 2.6? I don't, in any detail. But did it have to do with a possible race with a critical exception in just the wrong part of the normal exception exit path. ISTR BenH was worried about something in that area. There's a race between a critical exception and the normal exception entry path. If a normal exception occurs in user mode and then a critical exception occurs before the normal exception handler has set r1 to the kernel stack area, we end up with r1 containing the user sp, though the critical exception occurred in kernel mode. I haven't yet come up with a way to detect this case and reliably use the kernel stack on a critical exception. -Dale
[PATCH] ppc32: handle Book E debug exceptions on kernel stack
On Thu, Feb 23, 2006 at 10:54:02AM +, Josh Boyer wrote: On Wed, 2006-02-22 at 22:19 -0600, Kumar Gala wrote: On Tue, 14 Feb 2006, Dale Farnsworth wrote: From: Dale Farnsworth dale at farnsworth.org On PPC Book E processsors, we currently handle debug exceptions on the critical exception stack (debug stack for E200). This causes problems with the kgdb single step handler, which calls smp_processor_id() and spin_lock(), which reference current_thread_info(), which only works when we are on the kernel stack. We address this by switching to the kernel stack early while handling debug exceptions. Note that the entry values of r10 and r11 are still saved on the critical exception (or debug) stack. Signed-off-by: Dale Farnsworth dale at farnsworth.org Paul, We were wondering if you or David remember why a specific critical exception stack was added in the 40x port from 2.4 to 2.6? I think Matt did that. And if I remember correctly, it was to avoid corruption if you were in the middle of handling a normal interrupt and a critical interrupt came in. Thanks Josh, Matt was one of the we who were wondering. If indeed you are remembering correctly, then I think we're safe to use the normal kernel stack rather than the critical exception stack. -Dale
ppc32: mpc85xx: set pcibios_fixup only #ifdef CONFIG_PCI
On Tue, Feb 21, 2006 at 11:44:15PM -0600, Kumar Gala wrote: On Fri, 17 Feb 2006, Dale Farnsworth wrote: From: Dale Farnsworth dale at farnsworth.org Signed-off-by: Dale Farnsworth dale at farnsworth.org --- This change is already in the kernel tree. - kumar Indeed it is. Sorry for the noise. -Dale arch/ppc/platforms/85xx/mpc85xx_cds_common.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c === --- linux-2.6.10.orig/arch/ppc/platforms/85xx/mpc85xx_cds_common.c +++ linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c @@ -456,9 +456,6 @@ mpc85xx_cds_setup_arch(void) mtspr(SPRN_DBCR0, (DBCR0_IDM)); mtspr(SPRN_DBSR, 0x); #endif - - /* VIA IDE configuration */ - ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup; #ifdef CONFIG_CPM2 cpm2_reset(); @@ -480,6 +477,9 @@ mpc85xx_cds_setup_arch(void) loops_per_jiffy = freq / HZ; #ifdef CONFIG_PCI + /* VIA IDE configuration */ + ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup; + /* setup PCI host bridges */ mpc85xx_setup_hose(); #endif
ppc32: mpc85xx: set pcibios_fixup only #ifdef CONFIG_PCI
From: Dale Farnsworth [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth dale at farnsworth.org --- arch/ppc/platforms/85xx/mpc85xx_cds_common.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c === --- linux-2.6.10.orig/arch/ppc/platforms/85xx/mpc85xx_cds_common.c +++ linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c @@ -456,9 +456,6 @@ mpc85xx_cds_setup_arch(void) mtspr(SPRN_DBCR0, (DBCR0_IDM)); mtspr(SPRN_DBSR, 0x); #endif - - /* VIA IDE configuration */ - ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup; #ifdef CONFIG_CPM2 cpm2_reset(); @@ -480,6 +477,9 @@ mpc85xx_cds_setup_arch(void) loops_per_jiffy = freq / HZ; #ifdef CONFIG_PCI + /* VIA IDE configuration */ + ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup; + /* setup PCI host bridges */ mpc85xx_setup_hose(); #endif
[PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Dale Farnsworth [EMAIL PROTECTED] On PPC Book E processsors, we currently handle debug exceptions on the critical exception stack (debug stack for E200). This causes problems with the kgdb single step handler, which calls smp_processor_id() and spin_lock(), which reference current_thread_info(), which only works when we are on the kernel stack. We address this by switching to the kernel stack early while handling debug exceptions. Note that the entry values of r10 and r11 are still saved on the critical exception (or debug) stack. Signed-off-by: Dale Farnsworth dale at farnsworth.org --- This is low level code and needs careful review. I've only tested it on mpc8548cds. I didn't find the corresponding code in arch/powerpc, so I assume Book E support hasn't been merged yet. arch/ppc/kernel/head_booke.h | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h index f3d274c..a5eec51 100644 --- a/arch/ppc/kernel/head_booke.h +++ b/arch/ppc/kernel/head_booke.h @@ -92,7 +92,8 @@ * registers as the normal prolog above. Instead we use a portion of the * critical/machine check exception stack at low physical addresses. */ -#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \ +#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, \ + exc_level_srr1, kernel_sp_reg)\ mtspr exc_level##_SPRG,r8; \ BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level stack*/ \ stw r10,GPR10-INT_FRAME_SIZE(r8);\ @@ -100,7 +101,7 @@ mfcrr10;/* save CR in r10 for now */\ mfspr r11,exc_level_srr1; /* check whether user or kernel*/\ andi. r11,r11,MSR_PR; \ - mr r11,r8; \ + mr r11,kernel_sp_reg; \ mfspr r8,exc_level##_SPRG; \ beq 1f; \ /* COMING FROM USER MODE */ \ @@ -128,11 +129,13 @@ SAVE_2GPRS(7, r11) #define CRITICAL_EXCEPTION_PROLOG \ - EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1) + EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r8) +#define CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG \ + EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r1) #define DEBUG_EXCEPTION_PROLOG \ - EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1) + EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1, r1) #define MCHECK_EXCEPTION_PROLOG \ - EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1) + EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1, r8) /* * Exception vectors. @@ -268,7 +271,7 @@ label: #else #define DEBUG_EXCEPTION \ START_EXCEPTION(Debug); \ - CRITICAL_EXCEPTION_PROLOG;\ + CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG;\ \ /*\ * If there is a single step or branch-taken exception in an \
[PATCH] ppc32: handle Book E debug exceptions on kernel stack
On Tue, Feb 14, 2006 at 03:57:58PM -0600, Kumar Gala wrote: Let me look at this a little, however, I'm amused by the Thanks. smp_processor_id() usage on 8548. Its a single core SoC, so any reason SMP is turned on in your kernel? I haven't turned on SMP in my 8548 kernel. The kgdb singlestep code calls smp_processor_id() even on UP. It doesn't really need to call it on UP, but smp_processor_id() still should work. I would have preferred seeing #ifdef CONFIG_SMP scattered throughout that code, but it's not my code. Anyway, the smp_processor_id() calls happen to return the correct value on UP, even on the critical exception stack, since that stack area is initialized to 0. The issue I actually hit is that for CONFIG_PREEMPT, the calls to spin_lock() and spin_unlock() increment and decrement current_thread_info()-preempt_count. This breaks things when the preempt_count goes negative. Not, that your patch, isn't needed for a SMP Book-E, just wondering. Yes, I'm looking forward to trying out a dual-core processor. -Dale On Tue, 14 Feb 2006, Dale Farnsworth wrote: From: Dale Farnsworth dale at farnsworth.org On PPC Book E processsors, we currently handle debug exceptions on the critical exception stack (debug stack for E200). This causes problems with the kgdb single step handler, which calls smp_processor_id() and spin_lock(), which reference current_thread_info(), which only works when we are on the kernel stack. We address this by switching to the kernel stack early while handling debug exceptions. Note that the entry values of r10 and r11 are still saved on the critical exception (or debug) stack. Signed-off-by: Dale Farnsworth dale at farnsworth.org
Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian?
In article 20060202090827.GA12810 at gate.ebshome.net you write:
On Thu, Feb 02, 2006 at 09:09:17AM +0100, Peter Korsgaard wrote:
On 2/2/06, Kumar Gala galak at kernel.crashing.org wrote:
What is the preferred way of accessing non-PCI devices then? Direct
pointer access?
No direct pointer access is bad. On PPC You can use
in_be{8,16,32}/out_be{8,16,32}
What about arch independent drivers? Are there any generic approach
for this or do you have to stick to ugly #ifdefs to decide between
in_be32/inl ?
I'm curious, could you give an example of such arch independent
driver?
Such #ifdefs are found in drivers/net/smc91x.h
-Dale
[PATCH] Add fec support for mpc52xx
In article 43E24DA6.9 at freescale.com John Rigby wrote: Adds fec support, requires bestcom patch. Applies to Sylvains git tree. Hmm, I thought that fec support was already in Sylvain's git tree. I'm sure Sylvain intended it to be there. From http://ozlabs.org/pipermail/linuxppc-embedded/2005-June/018887.html: Date: Sun, 19 Jun 2005 00:15:32 +0200 From: Sylvain Munaut tnt at 246tNt.com Following the obvious demand for it : rsync://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.git http://gitbits.246tNt.com/gitweb.cgi?p=linux-2.6-mpc52xx.git;a=summary Hopefully the server is setup correctly ... It's not _heavily_ tested but it seems to works fine in the few test I made. What in there : - I2C patches that are already sent upstream but not yet in Linus tree - Change of the mpc52xx uart device name and device ids to a range in the low density serial port major. Also it's now named ttyPSC? so you need to update you kernel command line (else you won't see any console). Note that the ids and names choosed are NOT YET OFFICIAL, I just included it in this release because some people were seeing conflict with the other ids. So the name and ids may change ... - Some other patches that will soon be sent upstream, just waiting for you to test see if it has any negative impact. - FEC and BestComm rewrite from Dale, with some improvement. For eg, the FEC task now handle misaligment so the manual alignment code has been removed, ... I hope Sylvain can resurrect the 2.6 FEC code that he, I and others worked on. -Dale
[PATCH 1/3] ppc32: Fix a few issues in Yucca PCIe functionality
On Mon, Nov 21, 2005 at 02:25:52PM +, Ruslan V. Sushko wrote:
This patch includes following changes:
1) Fix wrong PCIe config space address calculation for slot #3 (Using an
signed integer for port numbering will cause wrong address accessing)
2) Fix the PCI bus numbering assignment. This will be an issues if more
than one PCI card is inserted.
3) Add verbose error checking.
4) Remove commented or unused lines.
Signed-off-by: Ruslan V. Sushko rsushko at ru.mvista.com
There are a couple of whitespace/style problems in these 3 patches.
Please clean them up and re-submit.
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -280,12 +276,14 @@ yucca_setup_hoses(void)
IORESOURCE_MEM,
name);
- hose-first_busno = 0;
- hose-last_busno = 15;
+ hose-first_busno = bus_no;
+ hose-last_busno = 0xFF;
hose_type[hose-index] = HOSE_PCIE0 + i;
ppc440spe_setup_pcie(hose, i);
hose-last_busno = pciauto_bus_scan(hose, hose-first_busno);
+bus_no = hose-last_busno + 1;
+printk(KERN_INFO %s: resources allocated\n, name);
The above two lines have leading spaces instead of tabs. The same
problem exists in several other lines added by the patches.
diff --git a/arch/ppc/syslib/ppc440spe_pcie.c b/arch/ppc/syslib/ppc440spe_pcie.c
--- a/arch/ppc/syslib/ppc440spe_pcie.c
+++ b/arch/ppc/syslib/ppc440spe_pcie.c
@@ -157,33 +162,37 @@ int ppc440spe_init_pcie(void)
/* Set PLL clock receiver to LVPECL */
SDR_WRITE(PESDR0_PLLLCT1, SDR_READ(PESDR0_PLLLCT1) | 1 28);
- check_error();
-
- printk(KERN_INFO PCIE initialization OK\n);
-
- if (!(SDR_READ(PESDR0_PLLLCT2) 0x1))
- printk(KERN_INFO PESDR_PLLCT2 resistance calibration failed
(0x%08x)\n,
+ if (check_error()) {
+return -1;
+}
The above braces aren't needed.
+
+ if (!(SDR_READ(PESDR0_PLLLCT2) 0x1)) {
+ printk(KERN_INFO PCIE: PESDR_PLLCT2 resistance calibration
+failed (0x%08x)\n,
SDR_READ(PESDR0_PLLLCT2));
+return -1;
+}
/* De-assert reset of PCIe PLL, wait for lock */
SDR_WRITE(PESDR0_PLLLCT1, SDR_READ(PESDR0_PLLLCT1) ~(1 24));
udelay(3);
+ printk(KERN_INFO PCIE initialization OK\n);
return 0;
}
-int ppc440spe_init_pcie_rootport(int port)
+int ppc440spe_init_pcie_rootport(u32 port)
{
static int core_init;
void __iomem *utl_base;
+int attempts;
u32 val = 0;
- int i;
if (!core_init) {
+ if(ppc440spe_init_pcie()) {
+ return -1;
+}
Again, the above braces are unnecessary.
Thanks,
-Dale Farnsworth
USB IRQ Handling in IBMSTBx25xx
On Sat, Oct 08, 2005 at 10:06:36AM +, Vijesh VH wrote: Has any one worked on Interrupt handling in PPC 405 for STBx25xx. I am working in interfacing USB devices for STB. The Device Driver is getting stuck or runs unconditional in calling ISR. I Identified that that the spin_unlock_irqrestore function call in the kernel does it. So i am unable to go ahead and could not find what to do further. If any one is aware or worked on this kind of problem plz help me. On which kernel? It works for me in linux-2.6.13. -Dale
Marvell MV64360 interrupt question
On Fri, Sep 09, 2005 at 05:31:32PM +, Walter L. Wimer III wrote:
I'm looking at arch/ppc/syslib/mv64360_pic.c in the 2.6.13 kernel and I
see the following code:
int
mv64360_get_irq(struct pt_regs *regs)
{
.
.
.
if (irq == -1) {
irq = mv64x60_read(bh, MV64360_IC_MAIN_CAUSE_HI);
irq = __ilog2((irq 0x1f0003f7) ppc_cached_irq_mask[1]);
if (irq == -1)
irq = -2; /* bogus interrupt, should never happen */
else {
if ((irq = 24) (irq MV64x60_IRQ_DOORBELL)) {
irq_gpp = mv64x60_read(bh, MV64x60_GPP_INTR_CAUSE);
irq_gpp = __ilog2(irq_gpp ppc_cached_irq_mask[2]);
if (irq_gpp == -1)
irq = -2;
else {
irq = irq_gpp + 64;
mv64x60_write(bh,
MV64x60_GPP_INTR_CAUSE,
(1 (irq - 64)));
You dropped a ~ on the above line. It confused me for a bit.
}
}
else
irq += 32;
}
}
(void)mv64x60_read(bh, MV64x60_GPP_INTR_CAUSE);
.
.
.
}
Does anybody know what the last mv64x60_read() is intended to do? It
*looks* like it's clearing/acknowledging the interrupt, but I don't see
anything in the Marvell documentation that suggests that *reading* the
interrupt cause register has such an effect. From my reading, the
documentation says that you should write a '0' into the appropriate bit
position to clear the interrupt.
Hmmm... There's an mv64x60_write() a little earlier in the code... Is
the extra mv64x60_read() here to enforce ordering? If so, should it
be moved inside the if statement so that it's only executed when
actually necessary?
Yes. It's there to make sure that the clearing of the GPP interrupt
is seen by the hardware and takes effect before we return from the function.
And what about locking? The mv64x60_() functions are protected by a
spinlock, but if we're trying to enforce ordering, shouldn't we hold the
lock during the entire write+read operation, rather than dropping and
reacquiring the lock in between?
No additional locking is necessary. In fact, it seems to me that the 32-bit
register reads and writes are already atomic and all of the locking using
mv64x60_lock is superfluous.
At the moment, I'm not running into any actual problems here; this just
caught my eye and I started wondering about it.
BTW, the reason I'm looking at this code is that the board I'm working
on has a cascaded interrupt controller (implemented in an FPGA) feeding
into the MV64360 interrupt controller. I'm thinking about adding a
cascade mechanism to mv64360_pic.c similar to the one in the OpenPIC
code (i.e. like the openpic_hookup_cascade() function). Any opinions on
whether this is a good idea or a bad one?
Sounds reasonable to me.
-Dale
Marvell MV64360 interrupt question
On Fri, Sep 09, 2005 at 08:20:20PM +, Walter L. Wimer III wrote: On Fri, 2005-09-09 at 12:27 -0700, Dale Farnsworth wrote: No additional locking is necessary. In fact, it seems to me that the 32-bit register reads and writes are already atomic and all of the locking using mv64x60_lock is superfluous. Ah ha. mv64x60.h also defines an mv64x60_modify() function that isn't intrinsically atomic, so it needs the spinlock. That in turn requires mv64x60_read() and mv64x60_write() to play along too. Yes, the lock is needed for mv64x60_modify(), mv64x60_write(). I still don't think it's needed for mv64x60_read(). -Dale
Redwood-6 and 2.6
On Wed, Aug 17, 2005 at 03:13:36AM +, Dale Farnsworth wrote: I added smc9 support for redwood5 and redwood6 many months ago. See the reference to CONFIG_REDWOOD_5 in smc91x.h. I haven't tested it recently though. I'll give it a try tomorrow. Just following up. I verified that current linux-2.6.git netboots fine on redwood5 using the SMC9. -Dale
Redwood-6 and 2.6
On Wed, Aug 17, 2005 at 02:47:45AM +, Otto Solares wrote: On Tue, Aug 16, 2005 at 02:19:08PM -0700, Matt Porter wrote: On Tue, Aug 16, 2005 at 03:12:59PM -0600, Otto Solares wrote: Now, when 'make znetboot' in 2.4 there was a zImage.embedded, is the same thing as zImage.treebot that appears now in 2.6? Yes, this is the image that boots on the stock OpenBIOS firmware. It has the standard tree header on it. Thank you, just one more thing, do you know if the smc91x driver works for PPC? I added smc9 support for redwood5 and redwood6 many months ago. See the reference to CONFIG_REDWOOD_5 in smc91x.h. I haven't tested it recently though. I'll give it a try tomorrow. If your machine is not a redwood5 or redwood6, you'll also have to add platform device initialization in your platform code. See arch/ppc/platforms/4xx/redwood6.c. -Dale
[00/02] MPC5200 Bestcomm platform driver
On Mon, Aug 15, 2005 at 03:05:37PM +, Andrey Volkov wrote: Sylvain Munaut wrote: Obviously I haven't yet had the time to review all the code but the glance I had looked good ! I'll review it deeper and test it and come back to you asap. As you could see it was only first step (I hope at not so long way :)): bring Dale's code to the current kernel, and make point from which everyone could start dance. Andrey, thanks for keeping this alive. I agree with Sylvain's other comments. The main thing I would like to see happen to this driver (other than getting it in mainline :-) is an attempt to replace the ugly phy code with calls to the new phy abstraction layer. On the other hand, I'm glad to see progress on any front. -Dale
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
On Wed, Aug 10, 2005 at 07:44:50PM +, Thomas S. wrote: thanks for the Info, that helps. Do you know if in this kernel Version the MPC5200 USB Bug is already handled? I refer to errata document MPC5200E.pdf (I think rev. 06/2005) in which its stated that the frame_no and pad1 words are swapped in the processors OHCI Area. I saw in some earlier 2.4 kernel that in /drivers/usb/host/ohci.h the members frame_no and pad1 of struct ohci_hcca were swapped. maybe thats not necessary anymore ? Im using this driver to support our embedded system modules equipped with the 5200 (see the EM1 board on www.men.de for specs). Yes, the swapped frame_no issue is handled in the 2.6 MPC5200 usb driver. -Dale
[linuxppc] 2.6.12-3 header asm/usb.h missing ?
On Tue, Aug 09, 2005 at 02:50:50PM +, Kumar Gala wrote:
Why are we bothering with asm-ppc/usb.h anyways?
The structure defn only appears to be used once. If this is true,
why not just define it in the .c file.
- kumar
I previously added asm-ppc/usb.h.
It provides platform-specific callback functions for when the usb HC is
probed and removed. I attempted to use them for power management on the
ibmstb4 (redwood5) platform, but that code was bogus so I retracted it.
Also, I saw that there are currently several (non-ppc) usb HC drivers
that differ only in platform-specific code at probe and remove time,
so I wanted to avoid that kind of code duplication in the ppc world.
The callback functions are unused today though. I think we should
remove them. We can always add them back if they are needed later.
No need to add asm-ppc/usb.h
Instead, apply the following patch. I'll submit it to linux-usb-devel
tomorrow if no one here complains.
-Dale
This patch removes the reference to asm/usb.h and to the
usb_hcd_platform_data structure it contains. This structure
is currently unused. If we decide it's needed later, we can
add it back.
Signed-off-by: Dale Farnsworth dale at farnsworth.org
--- linux-2.6/drivers/usb/host/ohci-ppc-soc.c.old 2005-08-09
10:46:37.0 -0700
+++ linux-2.6/drivers/usb/host/ohci-ppc-soc.c 2005-08-09 11:03:44.0
-0700
@@ -14,8 +14,6 @@
* This file is licenced under the GPL.
*/
-#include asm/usb.h
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -23,9 +21,7 @@
* usb_hcd_ppc_soc_probe - initialize On-Chip HCDs
* Context: !in_interrupt()
*
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
+ * Allocates basic resources for this USB host controller.
*
* Store this function in the HCD's struct pci_driver as probe().
*/
@@ -37,7 +33,6 @@
struct ohci_hcd *ohci;
struct resource *res;
int irq;
- struct usb_hcd_platform_data *pd = pdev-dev.platform_data;
pr_debug(initializing PPC-SOC USB Controller\n);
@@ -73,9 +68,6 @@
goto err2;
}
- if (pd-start (retval = pd-start(pdev)))
- goto err3;
-
ohci = hcd_to_ohci(hcd);
ohci-flags |= OHCI_BIG_ENDIAN;
ohci_hcd_init(ohci);
@@ -85,9 +77,7 @@
return retval;
pr_debug(Removing PPC-SOC USB Controller\n);
- if (pd pd-stop)
- pd-stop(pdev);
- err3:
+
iounmap(hcd-regs);
err2:
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
@@ -105,21 +95,17 @@
* @pdev: USB Host Controller being removed
* Context: !in_interrupt()
*
- * Reverses the effect of usb_hcd_ppc_soc_probe(), first invoking
- * the HCD's stop() method. It is always called from a thread
+ * Reverses the effect of usb_hcd_ppc_soc_probe().
+ * It is always called from a thread
* context, normally rmmod, apmd, or something similar.
*
*/
static void usb_hcd_ppc_soc_remove(struct usb_hcd *hcd,
struct platform_device *pdev)
{
- struct usb_hcd_platform_data *pd = pdev-dev.platform_data;
-
usb_remove_hcd(hcd);
pr_debug(stopping PPC-SOC USB Controller\n);
- if (pd pd-stop)
- pd-stop(pdev);
iounmap(hcd-regs);
release_mem_region(hcd-rsrc_start, hcd-rsrc_len);
[PATH] ppc32: Add usb support to IBM stb04xxx platforms
[ I previously submitted this on March 31st. Though I received a copy
back from the linuxppc-embedded mailing list, I don't find a copy in
the archive. (The same thing happend to my submission of asm-ppc/usb.h.)
So I'm resending. ]
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -72,12 +72,43 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+* Set up USB interrupt as positive polarity and level-sensitive.
+* Firmware should do this, but apparently does not.
+*/
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+
#ifdef CONFIG_DEBUG_BRINGUP
printk(\n);
printk(machine\t: %s\n, PPC4xx_MACHINE_NAME);
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] ppc32: Add usb support to IBM stb04xxx platforms
On Tue, Aug 09, 2005 at 12:03:19PM -0700, Eugene Surovegin wrote:
On Tue, Aug 09, 2005 at 11:53:27AM -0700, Dale Farnsworth wrote:
[snip]
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+* Set up USB interrupt as positive polarity and level-sensitive.
+* Firmware should do this, but apparently does not.
+*/
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+
Please, DO NOT DO THIS.
There is a way to configure UIC settings without messing with UIC
registers directly. Refer to asm-ppc/ppc4xx_pic.h and other 4xx board
ports for more information.
Eugene
Deja vu all over again, eh Eugene? I re-submitted the wrong old patch.
Correct (I hope) patch follows.
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include linux/init.h
#include asm/ocp.h
+#include asm/ppc4xx_pic.h
#include platforms/4xx/ibmstb4.h
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7f01,
+ .triggering = 0x,
+ .ext_irq_mask = 0x007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include linux/ioport.h
#include asm/io.h
#include asm/machdep.h
+#include asm/ppc4xx_pic.h
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
___
Linuxppc-embedded mailing list
Linuxppc-embedded at ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc
MPC5200/Lite5200 and ethernet
On Fri, Jun 17, 2005 at 02:28:23PM +0400, Andrey Volkov wrote: I sent patches to Sylvain in August 2004 with 5200 FEC support, including my rewrite of the bestcomm FEC code. I've bugged him about it a few times, and I don't know why he hasn't made it available. I haven't done much with the 5200 since then. I'm traveling now and have some other pressing issues, but I'll try to post what I have in the next couple of weeks. -Dale Dale, don't worry, Sylvain public your patches in himself src tree (http://www.246tnt.com/mpc52xx/) at August/September,2004. But, after that, OCP infra was dropped in kernel, and, hence, this driver was not sent to Andrew Morton (Bestcomm stuff, until now, OCP depended). And no one find time to convert Bestcomm to platform bus model :(. I planned start this job at July/August, so if someone wish to do it NOW (June) - welcome. Thank you Andrey, and my apologies to Sylvain. I didn't realize that they were available. I'll take a look at converting to the platform bus model, but it will be at least a week before I start. -Dale
MPC5200/Lite5200 and ethernet
On Thu, Jun 16, 2005 at 10:55:15PM +0400, Andrey Volkov wrote: Grant Likely wrote: On 6/16/05, Andrey Volkov avolkov at varma-el.com wrote: AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in vanilla kernel. Except, bestcomm, certainly :(. FEC is missing too. Is anybody even working on bestcomm at the moment? It may be Dale Farnsworth or smb. quietly in Freescale. I sent patches to Sylvain in August 2004 with 5200 FEC support, including my rewrite of the bestcomm FEC code. I've bugged him about it a few times, and I don't know why he hasn't made it available. I haven't done much with the 5200 since then. I'm traveling now and have some other pressing issues, but I'll try to post what I have in the next couple of weeks. -Dale
Getting ownership for various boards/platforms configs
On Fri, Jun 03, 2005 at 12:18:22AM +, Matt Porter wrote: redwood5 redwood6 um...dfarnsworth, want them formally? Sure, put me down for redwood5 and redwood6 -Dale
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -72,12 +72,43 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -52,8 +52,18 @@
void __init
redwood5_setup_arch(void)
{
+ u32 mask;
+
ppc4xx_setup_arch();
+ /*
+* Set up USB interrupt as positive polarity and level-sensitive.
+* Firmware should do this, but apparently does not.
+*/
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+
#ifdef CONFIG_DEBUG_BRINGUP
printk(\n);
printk(machine\t: %s\n, PPC4xx_MACHINE_NAME);
[PATCH 2.6.10-rc2] ppc32: Add platform data definition used by ohci-ppc-soc.c
This structure allows for callbacks into platform-specific code when the
driver is started or stopped. This file is currently included by
drivers/usb/host/ohci-ppc-soc.c, so it's needed for USB on the stb04xxx,
mpc52xx, and 440EP.
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/include/asm-ppc/usb.h
===
--- /dev/null
+++ linux-2.5-usb-405/include/asm-ppc/usb.h
@@ -0,0 +1,13 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms
On Thu, Mar 31, 2005 at 01:08:07PM -0800, Eugene Surovegin wrote: Dale, please, don't mess with UIC registers directly, there is a cleaner way to set this up. Take a look at how this is done in other 4xx ports (ppc4xx_core_uic_cfg ppc4xx_uic_ext_irq_cfg). Thanks for the heads up Eugene. I'll submit an updated patch shortly. -Dale
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms (v3)
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include linux/init.h
#include asm/ocp.h
+#include asm/ppc4xx_pic.h
#include platforms/4xx/ibmstb4.h
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,51 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Polarity and triggering settings for internal interrupt sources */
+struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
+ { .polarity = 0x7f01,
+ .triggering = 0x,
+ .ext_irq_mask = 0x007e, /* IRQ0 - IRQ5 */
+ }
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -18,6 +18,19 @@
#include linux/ioport.h
#include asm/io.h
#include asm/machdep.h
+#include asm/ppc4xx_pic.h
+
+/*
+ * Define external IRQ senses and polarities.
+ */
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 0 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 1 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 2 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 3 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 4 */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* Ext Int 5 */
+};
static struct resource smc91x_resources[] = {
[0] = {
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms including Redwood5
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include linux/init.h
#include asm/ocp.h
+#include asm/usb.h
#include platforms/4xx/ibmstb4.h
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,70 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr= USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Power up the USB subsection */
+static int enable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+ return 0;
+}
+
+/* Power down the USB subsection */
+static void disable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) ~mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) | mask);
+}
+
+static struct usb_hcd_platform_data pd = {
+ .start = enable_usb,
+ .stop = disable_usb,
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end= USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end= USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = ppc-soc-ohci,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev= {
+ .dma_mask = dma_mask,
+ .coherent_dma_mask = 0xULL,
+ .platform_data = pd,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x4000
#define GPIO0_BASE 0x4006
+#define USB0_BASE 0x4001
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x4001)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/include/asm-ppc/usb.h
===
--- /dev/null
+++ linux-2.5-usb-405/include/asm-ppc/usb.h
@@ -0,0 +1,14 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ char *name;
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
[PATCH 2.6.10-rc2] ppc32: Call redwood5_platform_add_devices before driver init
Use arch_initcall to call redwood5_platform_add_devices, ensuring
that platform_add_devices is called before drivers are initialized.
Signed-off-by: Dale Farnsworth dale at farnsworth.org
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -48,6 +48,7 @@
{
return platform_add_devices(redwood5_devs, ARRAY_SIZE(redwood5_devs));
}
+arch_initcall(redwood5_platform_add_devices);
void __init
redwood5_setup_arch(void)
@@ -76,7 +77,6 @@
printk(\n);
#endif
- device_initcall(redwood5_platform_add_devices);
}
void __init
[PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms including Redwood5
On Wed, Mar 30, 2005 at 05:07:47PM -0800, Eugene Surovegin wrote:
On Wed, Mar 30, 2005 at 05:05:21PM -0700, Dale Farnsworth wrote:
[snip]
+/* Power up the USB subsection */
+static int enable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) ~mask);
+ return 0;
+}
+
+/* Power down the USB subsection */
+static void disable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) ~mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) | mask);
+}
Dale, I'm curious, what's going on here :) ?.
How changing polarity and triggering setting could power-down USB
unit? Some STB funkiness?
No. It's brown paper bag time. Looks bogus to me now, too.
Please ignore the patch. I'll redo it and resubmit.
Thanks Eugene,
-Dale
[RFC] MPC5200 Kernel/UBoot PCI problem
On Fri, Mar 25, 2005 at 12:32:34PM +, Andrey Volkov wrote: Board started, after I add udelay(7) in read/write config. Really strange. Sylvain, answer was in PCI2.2 specification, not in manual. Wolfgang, as I see, you use same trick in u-boot, as Sylvain suggested to me. IMHO this trick is wrong. Below I explain why. When I insert udelay(1000) after deassertion of RST# (write 0 to PR of PCIGSCR), AND remove ALL delays from read/write config, board started too ;). Hence problem not in the MPC, but in slow board(s) (re)start (I was lucky with my board, because udelay must be 100). Good catch Andrey! -Dale
[PATCH 2/2] MPC52xx updates : PCI Support
The first hunk of arch/ppc/platforms/lite5200.c looks corrupted.
See the line beginning fdef CONFIG_PCI.
-Dale
On Fri, Mar 11, 2005 at 08:08:26PM +, Sylvain Munaut wrote:
And here's the second patch :
[ deleted lines ]
diff -Nru a/arch/ppc/platforms/lite5200.c b/arch/ppc/platforms/lite5200.c
--- a/arch/ppc/platforms/lite5200.c 2005-03-11 20:41:56 +01:00
+++ b/arch/ppc/platforms/lite5200.c 2005-03-11 20:41:56 +01:00
@@ -35,6 +35,8 @@
#include asm/ocp.h
#include asm/mpc52xx.h
+#include syslib/mpc52xx_pci.h
+
extern int powersave_nap;
fdef CONFIG_PCI
+static int
+lite5200_map_irq(struct pci_dev *dev, unsigned char idsel,
+ unsigned char pin) {
+ return (pin == 1) (idsel==24) ? MPC52xx_IRQ0 : -1;
+}
+#endif
[ more deleted lines ]
[PATCH][PPC32] mv64x60 updates
On Sun, Mar 06, 2005 at 08:02:48AM +0100, Sven Luther wrote: On Sat, Mar 05, 2005 at 03:51:28PM -0700, Dale Farnsworth wrote: By all means, try it. Several people are using it without complaints, but I'd appreciate your feedback. There isn't anything dangerous in there. Gigabit works for me. I'm not sure what Kconfig parts would be needed specifically for gigabit support. I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to build it, and even insmod it, but the module doesn't do a thing, and not even a single line shows up in dmesg. I guess i am either missing a part of the patch or there is something wrong with the probe code. I have gotten the diff against : include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig, adding : config MV643XX_ETH tristate MV-643XX Ethernet support - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP help This driver supports the gigabit Ethernet on the Marvell MV643XX - chipset which is used in the Momenco Ocelot C and Jaguar ATX. + chipset which is used in the Momenco Ocelot C and Jaguar ATX and + Pegasos II, amongst other PPC and MIPS boards. I have no idea where your MV64360 comes from, it seems to be not existent in any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find combo :/ Will have to look more. MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and CHESTNUT. If I understand correctly, it should be defined for any board using the MV64360. I don't think we want the PPC_CHRP dependency. Anyway, how do you probe for the chip ? On the pegasos we used to map on the marvell pci id : :00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362 System Controller (rev 03) too bad Marvell didn't do the logical thing and made the ethernet port appear as separated devices on a third internal pci bus. The mv643xx_eth probe is dependent on having the appropriate platform device entry. See eth0_device and mv64x60_add_pds() in arch/ppc/syslib/mv643x60.c . -Dale
[PATCH][PPC32] mv64x60 updates
On Sun, Mar 06, 2005 at 08:10:34PM +0100, Sven Luther wrote: On Sun, Mar 06, 2005 at 03:29:24AM -0700, Dale Farnsworth wrote: MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and CHESTNUT. If I understand correctly, it should be defined for any board using the MV64360. I don't think we want the PPC_CHRP dependency. Ah, i guess that was the missing bit. Basically i need to set MV64360 for my board, but since it is a generic PPC_CHRP, how is that supposed to work ? Could you send me maybe a list of files which need merging yet, compared to 2.6.11 ? I guess it just doesn't work because i am missing pieces. I would be guessing, since I've focused on the ethernet driver. Mark Greer mgreer at mvista.com has done the core mv64[34]60 core support. Nicholas is working with regarding Pegasos II support. The pegasos has the mv64360 registers mapped at 0xf100, and the ports (only port1 is wired though) mapped at interrupt 9, shared with other devices. I guess that would be the only real difference with the other currently supported hardware, right ? Nicholas implied that the PCI IRQs are different as well. -Dale
[PATCH][PPC32] mv64x60 updates
On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote: On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote: All of my changes to the mv643xx ethernet driver have been posted to LKML or the netdev list. I have removed all arch-specific code from the ethernet driver itself. What is the status of this with regard to the 2.6.11 mainline kernel ? I'm hopeful they will go in this week to make 2.6.12 See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be direct related code between the ppc specific mv64x60 stuff, and the mips related ethernet one. Yes. Well, as i am doing the powerpc debian 2.6.11 kernel, i really would like to port your work to the pegasos, but what i have seen from the code in the mainline kernel doesn't really make sense. Benh also mentioned porting it to pegasos, but I haven't heard that he's gotten to it. -Dale
[PATCH][PPC32] mv64x60 updates
On Sat, Mar 05, 2005 at 09:32:54PM +0100, Sven Luther wrote: On Sat, Mar 05, 2005 at 08:27:52PM +0100, Sven Luther wrote: On Thu, Feb 24, 2005 at 10:24:20AM -0700, Dale Farnsworth wrote: See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be direct related code between the ppc specific mv64x60 stuff, and the mips related ethernet one. Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of those are just 64340- 643xx replacements though. Yes, renames and Lindent make for big diffs. What are your plans for mainline inclusion of the rest of those, and is it ok I've submitted it for mainline inclusion. Jeff Garzik put it in netdev-2.6 (and thus in the mm patches) for testing and it's on track for going into mainline. I hope it will happen in the next few days, but that's up to Jeff. to work directly with your stuff ? Do you have any experimental or dangerous parts in the above ? And did you ever get the gigabit ethernet port working on a powerpc board ? Or are there some Kconfig parts i have missed ? By all means, try it. Several people are using it without complaints, but I'd appreciate your feedback. There isn't anything dangerous in there. Gigabit works for me. I'm not sure what Kconfig parts would be needed specifically for gigabit support. Updates are coming though. James Chapman has sent me several patches that provide: use of the mii library for phy management, additional ethtool support, message level support, compile fix for non-NAPI, and much cleanup. We're working the kinks out now and I expect to submit these patches in the next few days. Thanks, -Dale
FEC_IEVENT_RFIFO_ERROR
On Thu, Mar 03, 2005 at 01:14:54PM +, Babarovic Ivica wrote:
I run 2.6.10-rc2 kernel (http://www.246tNt.com/mpc52xx/)
for MPC5200 chip on a custom board that is almost lite5200 compatible.
I noticed a couple of times I have a strange error at bootup.
It was FEC_IEVENT_RFIFO_ERROR. Most of the times this
went trough without problems but since today system just hangs.
Sometimes with several printouts of this error.
---boot sequence --
FEC_IEVENT_RFIFO_ERROR
FEC_IEVENT_RFIFO_ERROR
FEC_IEVENT_RFIFO_ERROR
I traced a problem a bit and found that this happenes at
mpc52xx_fec_probe() function in fec.c at this point:
--
/* Get the IRQ we need one by one */
/* Control */
dev-irq = ocp-def-irq;
-- if (request_irq(dev-irq, fec_interrupt, SA_INTERRUPT,
mpc52xx_fec_ctrl, dev)) {
printk(KERN_ERR mpc52xx_fec: ctrl interrupt request
failed\n);
ret = -EBUSY;
dev-irq = -1; /* Don't try to free it */
goto probe_error;
}
--
It looks like the bootloader left the FEC enabled. You might try
the following (untested) patch which resets the FEC and disables
its interrupts before requesting the irq.
-Dale
= drivers/net/fec_mpc52xx/fec.c 1.1 vs edited =
--- 1.1/drivers/net/fec_mpc52xx/fec.c 2004-11-20 15:26:33 -07:00
+++ edited/drivers/net/fec_mpc52xx/fec.c2005-03-03 09:43:08 -07:00
@@ -85,18 +85,13 @@
return 0;
}
-/* This function is called to start or restart the FEC during a link
- * change. This happens on fifo errors or when switching between half
- * and full duplex.
- */
-static void fec_restart(struct net_device *dev, int duplex)
+static void fec_reset(struct net_device *dev)
{
struct fec_priv *priv = (struct fec_priv *)dev-priv;
struct mpc52xx_fec *fec = priv-fec;
- u32 rcntrl;
- u32 tcntrl;
int i;
+ out_be32(priv-fec-imask, 0); /* mask all interrupts */
out_be32(fec-rfifo_status, in_be32(fec-rfifo_status) 0x70);
out_be32(fec-tfifo_status, in_be32(fec-tfifo_status) 0x70);
out_be32(fec-reset_cntrl, 0x100);
@@ -110,6 +105,20 @@
}
if (i == FEC_RESET_DELAY)
printk (KERN_ERR FEC Reset timeout!\n);
+}
+
+/* This function is called to start or restart the FEC during a link
+ * change. This happens on fifo errors or when switching between half
+ * and full duplex.
+ */
+static void fec_restart(struct net_device *dev, int duplex)
+{
+ struct fec_priv *priv = (struct fec_priv *)dev-priv;
+ struct mpc52xx_fec *fec = priv-fec;
+ u32 rcntrl;
+ u32 tcntrl;
+
+ fec_reset(dev);
/* Set station address. */
fec_set_paddr(dev, dev-dev_addr);
@@ -645,6 +654,8 @@
ret = sdma_fec_tx_init(priv-tx_sdma, priv-tx_fifo);
if (ret 0)
goto probe_error;
+
+ fec_reset(dev);
/* Get the IRQ we need one by one */
/* Control */
linuxppc tree with mv64xxx included?
On Wed, Mar 02, 2005 at 06:47:43PM +, James Chapman wrote: The latest ethernet code can be obtained from bk://farnsworth.bkbits.net/linux-2.5-mv643xx-enet Make that bk://dfarnsworth at bkbits.net/linux-2.5-mv643xx-enet -Dale
Lite5200 full duplex support
On Thu, Feb 17, 2005 at 10:35:14PM +, Grant Likely wrote:
On Thu, 17 Feb 2005 15:13:33 -0700, Grant Likely glikely at gmail.com wrote:
On Wed, 16 Feb 2005 21:46:09 +0100, Sylvain Munaut tnt at 246tnt.com
wrote:
Grant Likely wrote:
BTW, here's what I changed:
drivers/net/fec_mpc52xx/fec_phy.c line 294 (phy_info_lxt971)
from:
{ mk_mii_write(MII_REG_ANAR, 0x0A1), NULL }, /* 10/100, HD */
to:
{ mk_mii_write(MII_REG_ANAR, 0x1E1), NULL }, /* 10/100, HD */
I'm not sure actually. I also wondered and forgot to ask the author. I
guess
I always tought there was a problem with it without checking.
I've played around with it a bit more and I have discovered one
problem. When in full duplex the carrier detect seems to bounce up
and down for every frame received off the wire. I've beaten the tar
out of it with netperf and it doesn't seem to be causeing any
instability (yet)... Still investigating.
Update: The error seems to be carrier sense loss during transmit. The
FEC documentation states that carrier loss errors are counted, but the
frame is not retransmitted and no interrupt is generated. The driver
copies the value directly out of the counter register when reporting
status.
I do not know yet if it affects received frames...
I've used the Lite5200 ethernet in either full-duplex mode or
half-duplex mode. However, the change quoted above is insufficient.
You also need to change the call to fec_restart in fec.c to be something like:
fec_restart(dev, 1);/* always use full duplex mode only */
There is currently no mechanism for the driver to detect if the PHY
negotiated full or half duplex. There is no PHY interrupt and no
routine has been coded to poll for PHY status. Therefore, the lite5200
can't automatically work with either full or half duplex. You have
to select one or the other. I selected half duplex as the least common
denominator.
-Dale Farnsworth
Lite5200 FEC Driver on linux 2.6 broken? (again)
On Tue, Nov 16, 2004 at 10:26:09AM -0800, roger blofeld wrote: Retransmissions from the lite5200 work OK now, but the occasional ACK packet is sent from the lite5200 with a bad checksum causing retransmissions. Perhaps another patch would fix this problem too? I too have seen occasional errors, but I don't think it's a software issue. -Dale
Lite5200 FEC Driver on linux 2.6 broken?
On Mon, Nov 15, 2004 at 04:32:43PM +, roger blofeld wrote:
I'm trying to get a simple app running on a Lite5200 and am having a
TCP/IP problem. Using tcpdump/ethereal I have learned that the Lite5200
ethernet works fine until the client sends a TCP retransmission
request. Then the Lite5200 replies with packets having incorrect
checksums. Each successive Lite5200 packet appears to also lose two
bytes of data (i.e., the packet size is correct, but the data is not
the same for each retransmission because two bytes have been dropped
from the start of the payload).
Could this be a problem with the FEC driver? Bestcomm? How can I figure
out what is broken here? Any help gladly accepted!
I started with Sylvain Munaut's kernel at
http://www.246tnt.com/mpc52xx/ and have also tried starting with the
linux-2.5 tree and pulling Sylvain's tree into it to see if newer
kernels worked better. I also tried using the recently updated bestcomm
interface from denx.de with these kernels with the same result.
Try the following patch on top of Sylvain's tree. I sent it (and others)
to Sylvain a while back, but he must be busy with other things.
-Dale
--- linux-2.5-mpc52xx-devel/drivers/net/fec_mpc52xx/fec.c 2004-10-12
11:26:55.0 -0700
+++ linux-2.5-mpc52xx-devel-df/drivers/net/fec_mpc52xx/fec.c2004-11-12
10:20:18.0 -0700
@@ -202,6 +202,41 @@
return -EAGAIN;
}
+/* The BestComm hardware requires data to be 32-bit aligned.
+ * We also pad to minimum ethernet packet length, ETH_ZLEN.
+ */
+static inline struct sk_buff *fec_skb_align_and_pad(struct sk_buff *skb)
+{
+ void *data = skb-data;
+ int len = skb-len;
+ int pad = (int)data 0x3;
+ struct sk_buff *nskb;
+ int nlen;
+
+ if (pad == 0)
+ return skb;
+
+ if (!skb_cloned(skb)) {
+ skb_push(skb, pad);
+ memmove(skb-data, data, len);
+ skb_trim(skb, len);
+ skb = skb_padto(skb, ETH_ZLEN);
+ return skb;
+ }
+
+ /* ensure skb_padto doesn't have to reallocate */
+ nlen = (len = ETH_ZLEN) ? len : ETH_ZLEN;
+
+ nskb = alloc_skb(nlen, GFP_ATOMIC);
+ if (nskb) {
+ skb_put(nskb, len);
+ memcpy(nskb-data, data, len);
+ nskb = skb_padto(nskb, ETH_ZLEN);
+ }
+ kfree_skb(skb);
+ return nskb;
+}
+
/* This will only be invoked if your driver is _not_ in XOFF state.
* What this means is that you need not check it, and that this
* invariant will hold if you make sure that the netif_*_queue()
@@ -210,30 +245,16 @@
static int fec_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct fec_priv *priv = (struct fec_priv *)dev-priv;
- int pad;
void *data;
- short length;
if (sdma_queue_full(priv-tx_sdma))
panic(MPC52xx transmit queue overrun\n);
- /* the BestComm hardware requires data to be 32-bit aligned */
- pad = (int)skb-data 0x3;
- if (pad) {
- void *old_data = skb-data;
- length = skb-len;
-
- skb_push(skb, pad);
- memcpy(skb-data, old_data, length);
- skb_trim(skb, length);
- }
-
- /* Zero out up to the minimum length ethernet packet size,
-* so we don't inadvertently expose sensitive data
-*/
- skb = skb_padto(skb, ETH_ZLEN);
- if (skb == 0)
+ skb = fec_skb_align_and_pad(skb);
+ if (!skb) {
+ priv-stats.tx_dropped++;
return 0;
+ }
spin_lock_irq(priv-lock);
dev-trans_start = jiffies;
@@ -294,7 +315,8 @@
break;
rskb = sdma_retrieve_buffer(priv-rx_sdma, length);
- skb_trim(rskb, length);
+ /* length included sizeof CRC32 */
+ skb_trim(rskb, length - sizeof(u32));
/* allocate replacement skb */
skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
@@ -309,6 +331,7 @@
priv-stats.rx_dropped++;
skb_trim(rskb, 0);
+ skb = rskb;
}
skb-dev = dev;
Problem with user-space programs on 405GP: linux 2.6 oops
I suspect you're missing this patch, which is in the current tree. -Dale = setup.c 1.59 vs 1.60 = --- 1.59/arch/ppc/kernel/setup.c2004-07-26 15:27:53 -07:00 +++ 1.60/arch/ppc/kernel/setup.c2004-08-16 09:04:08 -07:00 @@ -744,6 +744,10 @@ if ( ppc_md.progress ) ppc_md.progress(ocp: exit, 0x3eab); #endif +#ifdef CONFIG_DUMMY_CONSOLE + conswitchp = dummy_con; +#endif + ppc_md.setup_arch(); if ( ppc_md.progress ) ppc_md.progress(arch: exit, 0x3eab); On Tue, Nov 02, 2004 at 07:24:11PM +, Vladimir wrote: On Tuesday 02 November 2004 03:54, Vladimir wrote: Hello All ! I'm trying to run linux (2.4.22) on embedded PowerPC (405GP). It boots nice, but when it tries to execute /sbin/init it hangs. Last console messages are: VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 56k init 4k prep I've tried to replace /sbin/init by my own executable - it's definitely have not been executed. I've traced it to the last point in kernel-mode (instruction rfi in file arch/ppc/kernel/entry.S:389). Before this point everything is all right. But after this instruction kernel just hangs. After this sysrq-t prints that process init are running at c0007190 (this is in the arch_kernel_thread). sysrq-p does not print any registers, just the line SysRq : Show Regs. Could someone give me any tips how to fix this trouble ? Hello All ! I've tried linux 2.6.8.1 and it gives me the following oops: VFS: Mounted root (nfs filesystem) readonly. Freeing unused kernel memory: 68k init Oops: kernel access of bad area, sig: 11 [#1] NIP: C00C032C LR: C00C0518 SP: C3F87D90 REGS: c3f87ce0 TRAP: 0300Not tainted MSR: 00029230 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: , DSISR: TASK = c3f859c0[1] 'init' THREAD: c3f86000Last syscall: 5 PLB0: bear= 0x00a2f48e acr= 0x besr= 0x PLB0 to OPB: bear= 0x0a201000 besr0= 0x besr1= 0x GPR00: C3F87D90 C3F859C0 0001 C027EF50 C3FED0D0 GPR08: 0080 C027EE00 C027EE00 2222 1001F0B8 03FE3200 007FFF2B GPR16: 0001 007FFF00 03FDE850 03F9FE88 0001 GPR24: 0102 10005844 C01D1410 0001 C01D1794 NIP [c00c032c] visual_init+0xa0/0x1c4 LR [c00c0518] vc_allocate+0xc8/0x150 Call trace: [c00c0518] vc_allocate+0xc8/0x150 [c00c42c0] con_open+0x50/0xc0 [c00b200c] tty_open+0x2a4/0x548 [c0057c44] chrdev_open+0xf0/0x184 [c004cc74] dentry_open+0x164/0x26c [c004cb0c] filp_open+0x68/0x6c [c004d030] sys_open+0x68/0xa0 [c0004540] ret_from_syscall+0x0/0x48 Kernel panic: Attempted to kill init! 0Rebooting in 180 seconds..
Merge 8xx to Linus tree?
On Sun, Oct 17, 2004 at 11:03:52AM +, Robert P. J. Day wrote: Once upstream, new changes won't (unless not-fully-baked) go into linuxppc-2.5. um ... sorry, i'm still not sure what this means. does it mean that, at some point (to be determined/announced?), the linuxppc-2.5 tree will be put to the side, and all further mods should be done directly against the 2.5 tree? Yes, that's already the case for most ppc platforms. The only thing that keeps it from being true for 8xx is that it doesn't work yet in the linux-2.5 tree. -Dale
smc91111
On Mon, Oct 04, 2004 at 10:28:26PM +, Jon Masters wrote: Who is using the SMC9 family of MACs and if so which driver do you use? On the redwood5 and redwood6 boards I use the smc91x driver from bk://linux.bkbits.net/linux-2.6/drivers/net/smc91x.[ch]. I had to add redwood-specific in/out macros to smc91x.h, and use the platform_device interface rather than OCP, but it's nice to have a single smc91x driver. -Dale
[RFC] Re: BestComm and fec
On Tue, Aug 24, 2004 at 08:07:07AM +, Andrey Volkov wrote: Hi all, Andrey: Gabor has a working fec.c implementation. Apparently, you've both worked out a version of bestcomm for 2.6. But you both based it on old code. (even non GPL). Terrible, may be its time to create special project for MPC5200 (if it doesn't exist in somewhere in I-net)? First intention - sourceforge. Comments/suggestions? Yes, useless duplication of work is sad, especially if it is using obsolete code. However, the use of special source tree for MPC5200 is neither necessary nor sufficient to avoid that. It could have been avoided by talking with Sylvain or me. I have learned that it is almost essential to discuss linux ppc development on #mklinux on IRC. BTW, the code you ported looks like an early development version that I never intended for distribution. Motorola begged me to let them use it for a demo, then distributed it without notifying me. Sylvain, Wolfgang I know you already have projects. But in case of Sylvain, as I understand, his project on his homepage. In case of Wolfgang, I'm not sure that DENX will happy to share their internal CVS with all I-net for write access. Am I right? Write access is overrated and not necessary, particularly with bitkeeper's ability to pull changesets from other trees. Sylvain and I have each maintainend our own list of patches pending to the official trees, and have shared those patches back and forth. However, with more than 2 active developers, it may be useful to have a temporary tree in which pending support for the various mpc5200 peripherals is coalesced. If so, I think it makes sense for Sylvain to do that if he's willing, since he's the mpc5200 maintainer. I've just tried just taking the newer one and stick it in 2.6 with the fec Gabor sent, but it just crashes so it need more work ;) Dale Farnsworth just said it'll look into it and porting new bestcomm as well. My fec port work ok. It may appear to work, but from previous discussions here and on linuxppc-devel, the fec and bestcomm code is not good enough to be accepted into the main linux trees. The BestComm API code, in particular, is hopeless and a complete rewrite will be required. I'm addressing that now. I have separated out fec code that interfaces to the BestComm API code in preparation for replacement of the BestComm API code. I'm now separating out and cleaning up the PHY support code. Next, I plan to replace the BestComm API code, but I may hand that back to Sylvain if he's available and willing. Anyway, the fec code will be a lot cleaner in a couple of weeks. I guarantee I'll post something before then. To resume the close future I'm planning : I'm busy for two weeks ( I was planning on finishing other stuff earlier and didn't work out finally ;( ). So I work less on the MPC but after that, that's a full time assignment. - USB: Dale's patch are on their way to the official kernel. Once they are in, He or I will send the necessary MPC5200 dependent stuff. - PCI: I'm working on that now, just brushing it up then I'll put it on my tree and require testing - I2C: Waiting Adrian Cox patches to be in official tree ( they are in -mm ), then apply mpc5200 specifics. - BestComm : Dale (the original fec writing among other things) is adapting the newer bestcommcode and cleaning the fec driver as well. - IDE: Once I get PCI in my tree, I'll look at IDE, a DMA-less version at first. And CAN, RTC, and possible CRC32/16 (if it will fast enough) :). Best regards, Andrey Volkov Welcome to the team Andrey. There is plenty of work to go around. Check with Sylvain if there's something not being done that you'd like to take on. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
2.6 networking support for Redwood[56]
I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6.
It looks like the best supported driver for the smc9 chip
is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch]
This driver recently went into the linux-2.5 tree.
I moved these two files into drivers/net so they are available for
PPC as well as ARM and added some Redwood-specific support. That
was straightforward. This driver calls a couple of ARM-specific
functions platform_get_resource() and platform_get_irq(). ARM
implements these functions in arch/arm/common/platform.c. I
copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c
which works fine, but I don't care for duplicated code. Maybe a
better approach would be to add these functions to drivers/base/platform.c
Comments? Suggestions on how to go about getting this into linux-2.5?
Thanks,
-Dale Farnsworth
Do mv drivers/net/arm/smc91x.[ch] drivers/net before applying
the following patch.
= drivers/net/smc91x.h 1.2 vs edited =
--- 1.2/drivers/net/smc91x.h2004-06-21 10:16:40 -07:00
+++ edited/drivers/net/smc91x.h 2004-06-21 10:26:08 -07:00
@@ -59,6 +59,43 @@
#define SMC_insw(a, r, p, l) readsw((a) + (r), p, l)
#define SMC_outsw(a, r, p, l) writesw((a) + (r), p, l)
+#elif defined(CONFIG_REDWOOD_5) || defined(CONFIG_REDWOOD_6)
+
+/* We can only do 16-bit reads and writes in the static memory space. */
+#define SMC_CAN_USE_8BIT 0
+#define SMC_CAN_USE_16BIT 1
+#define SMC_CAN_USE_32BIT 0
+#define SMC_NOWAIT 1
+
+#define SMC_IO_SHIFT 0
+
+#define SMC_inw(a, r) in_be16((volatile u16 *)((a) + (r)))
+#define SMC_outw(v, a, r) out_be16((volatile u16 *)((a) + (r)), v)
+#define SMC_insw(a, r, p, l) \
+ do {\
+ unsigned long __port = (a) + (r); \
+ u16 *__p = (u16 *)(p); \
+ int __l = (l); \
+ insw(__port, __p, __l); \
+ while (__l 0) { \
+ *__p = swab16(*__p);\
+ __p++; \
+ __l--; \
+ } \
+ } while (0)
+#define SMC_outsw(a, r, p, l) \
+ do {\
+ unsigned long __port = (a) + (r); \
+ u16 *__p = (u16 *)(p); \
+ int __l = (l); \
+ while (__l 0) { \
+ /* Believe it or not, the swab isn't needed. */ \
+ outw( /* swab16 */ (*__p++), __port); \
+ __l--; \
+ } \
+ } while (0)
+#define set_irq_type(irq, type)
+
#elif defined(CONFIG_SA1100_ASSABET)
diff -Nru a/arch/ppc/platforms/4xx/redwood5.c
b/arch/ppc/platforms/4xx/redwood5.c
--- a/arch/ppc/platforms/4xx/redwood5.c 2004-06-21 13:52:45 -07:00
+++ b/arch/ppc/platforms/4xx/redwood5.c 2004-06-21 13:52:45 -07:00
@@ -14,8 +14,41 @@
#include linux/config.h
#include linux/init.h
#include linux/pagemap.h
+#include linux/device.h
+#include linux/ioport.h
#include asm/io.h
#include asm/machdep.h
+#include syslib/platform.h
+
+static struct resource smc91x_resources[] = {
+ [0] = {
+ .start = SMC9_BASE_ADDR,
+ .end= SMC9_BASE_ADDR + SMC9_REG_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = SMC9_IRQ,
+ .end= SMC9_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device smc91x_device = {
+ .name = smc91x,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(smc91x_resources),
+ .resource = smc91x_resources,
+};
+
+static struct platform_device *redwood5_devs[] __initdata = {
+ smc91x_device,
+};
+
+static int __init
+redwood5_platform_add_devices(void)
+{
+ return platform_add_devices(redwood5_devs, ARRAY_SIZE(redwood5_devs));
+}
void __init
redwood5_setup_arch(void)
@@ -44,7 +77,7 @@
printk(\n);
#endif
-
+ device_initcall(redwood5_platform_add_devices);
}
void __init
diff -Nru a/arch/ppc/platforms/4xx/redwood5.h
b/arch/ppc/platforms/4xx/redwood5.h
--- a/arch/ppc/platforms/4xx/redwood5.h 2004-06-21 13:52:45 -07:00
+++ b/arch/ppc/platforms/4xx/redwood5.h 2004-06
2.6 networking support for Redwood[56]
On Mon, Jun 21, 2004 at 11:12:14PM +, Matt Porter wrote: On Mon, Jun 21, 2004 at 02:39:48PM -0700, Dale Farnsworth wrote: I'm adding network support for the IBM Redwood5 and Redwood6 in 2.6. It looks like the best supported driver for the smc9 chip is used by the ARM folks and is found in drivers/net/arm/smc91x.[ch] This driver recently went into the linux-2.5 tree. I moved these two files into drivers/net so they are available for PPC as well as ARM and added some Redwood-specific support. That was straightforward. This driver calls a couple of ARM-specific functions platform_get_resource() and platform_get_irq(). ARM implements these functions in arch/arm/common/platform.c. I copied arch/arm/common/platform.c into arch/ppc/syslib/platform.c which works fine, but I don't care for duplicated code. Maybe a better approach would be to add these functions to drivers/base/platform.c How about wrapping each arch-specific call up in something more abstract and then using OCP to get the PPC info? roughly... #ifdef CONFIG_PPC_OCP TO_SMC_DEVto_ocp_device() SMC_GET_BASE_ADDR dev-def-paddr ... #else /* ARM */ TO_SMC_DEVto_platform_device() SMC_GET_BASE_ADDR platform_get_resource(dev, IORESOURCE_MEM, 1) ... #endif There's only about 4 places in the probe/remove calls to do this. Add an ocp_add_one_device in your redwood*.c to enable the smc9111 device with the board-specific attributes. You may have to play a bit with the prove/remove calls since they want to deal with a resource struct, but it might be worth looking at. Sounds like a better approach. I'll modify the driver to present either the ARM interface or the PPC_OCP interface. Muddles the driver a bit, but should keep both archs happy. Comments? Suggestions on how to go about getting this into linux-2.5? Send a two part patch, 1/2 (file moves) 2/2 PPC changes to Nicolas and cc jgarzik Yes without architectural changes, should be easier to get in. Thanks, -Dale ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on MPC5200 - LITE5200EVAL
On Sat, Feb 14, 2004 at 02:53:03PM +, Wolfgang Denk wrote: In message 402E0D8C.4080801 at 246tNt.com you wrote: The weird problem with u-boot ( not booting If I set bootargs manually ) and the kernel crash are both solved. It was a compiler issue. I used a toolchain I used to build binaries for a normal mac based on gcc 3.4 ( cvs ) and it was a really bad idea. I see. - The PCI slot is 3.3 v and apparently I don't have a single PCI card that seems to work on it ... When I plug one ( that I thought was 3.3v ), nothing boot, sometimes even the led don't power on ... Be careful to put it correctly. The slot bracket has to be on the side where the UART / USB / CAN connctors are. Do not insert the card with the slot bracket pointing to the IDE connector. Also be VERY carefully which card you insert. make sure it is _really_ a 3.3V compatible card. [I fried a board by trying a Digitus DC SER2 Rev. 2.0 Serial PCI I/O Card - this card has the key slots for a 3.3/5V combi card, but the V_I/O pins are connected to the 5V rail. The RAM chips didn't like to see 5V ...] - When I change options in the kernel to support new stuff I need, like activating USB host IDE controller, the kernel don't boot at all ( or at least, I don't see on the serial console it does ). It's the same problem with activating drivers for the PCI bus ... What is weird is that it's not an error on boot, it's just that after u-boot messages, there is nothing at all. Can you attach a debugger? Or even try a post-mortem dump of the logbif area? Both PCI and USB are working fine for me. I'm not sure my hardware is fully OK, but I did mtest on u-boot for about 10 hours and it didn't complained. It's a fresh new board from motorola... Maybe you can ask for a replacement. Your problems don't look normal to me. I've seen the same symptoms Sylvain described on the five Lite5200 boards that I have tried. Eepro100 network cards work fine, but the 3 brands of IDE cards I tried are not even visible in PCI config space. U-boot doesn't see them and Linux doesn't see them, booted either from dBUG or U-boot. Actually, one Lite5200/IDE combo comes close. Parts of the IDE cards PCI config info do read correctly sometimes. Different parts each time. I think this is likely a hardware issue with Lite5200 boards. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux on a Motorola MPC5200 ?
On Tue, Jan 27, 2004 at 05:28:38PM +, Sylvain Munaut wrote: Hello I'd like to run linux on a future custom board based on a motorola MPC5200 and I have a few questions : - What is the current support for it ? Stable ... I'd need the DMA ( well, their 'special DMA fancy stuff' ;) ), ATA, DDR, I2S, AC97 mainly. - I'd really like to run a 2.6 kernel on it. If it's not yet ported to the 2.6 what is the current ppc support for 2.6 ? Would I only need to port MPC specifics ? - Where can I find the current stuff ? I've taken what is in ppc.bkbits.net/linux-2.4-mpc5xxx, is there other things I should consider ? Thanks for any informations Munaut Sylvain I think you've found pretty much what's available. I haven't seen a 2.6 port for the 5200 yet. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Shared Interrupts Question (2.4)
On Thu, May 08, 2003 at 08:08:56PM +, Kent Borg wrote: I am trying to understand kinda shared interrupts. There are various interrupts in my not-yet-released CPU, and I have interrupt code that knows how to talk to them. So far so good. I also have an external interrupt controller that groups together 18 external interrupt sources and sends them in one CPU pin. This external controller has a register for enabling interrupts, and a register for status/acknowledge. Pretty standard. The CPU code doesn't know about the external controller. It seems silly to rewrite the CPU-specific interrput code to accommodate this board-specific detail (besides then my code won't match Dale's). So I figure I tell the kernel I am doing shared interrupts. So where do I enable, disable, and acknowledge these external bits? Specifically, I am trying to get a couple of serial ports working. I can put conditional code in serial.c startup() to enable these interrupts, but how do I know which serial port? Add a conditionally compiled sub-IRQ number to serial_state structure? Is there a cleaner way? Create and register a board-specific interrupt driver. Assign it a range of irqs (non-conflicting with the main interrupt driver). When called with an irq outside its range, the board-specific driver routines forward the call to the main driver. The board-specific driver does a request_irq at init time for the one main irq it is multiplexing. -Dale ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Busybox of Hardhat preview 2.1 for sandpoint 74xx ?
On Mon, May 05, 2003 at 08:31:34PM +, Yu Bo-BOYU1 wrote: Did anyone know if busybox of hardhat preview 2.1 for sandpoint 74xx work or not ? I got error Bad trap at PC: 300162fc, SR: f032, vector=f00Not tainted no matter the root is mounted on NFS or ramfs. It's been a while since I last saw it, but this reminds me of what happens when running the 74xx userspace on a kernel that doesn't have altivec support enabled. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
booting MGT5100?
On Thu, Apr 24, 2003 at 03:31:42PM +, Chris Heintzelman wrote: Thanks for the info! I'm also using an icecube board. I'll grab the code from mv when you post it there. Do you use a bootloader or do you just use dbug to run a zImage? -Chris H. I'm using the boot_simple boot wrapper code. -Dale ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
booting MGT5100?
On Wed, Apr 23, 2003 at 09:55:42PM +, Chris Heintzelman wrote: I noticed that a few months ago someone mentioned booting Linux on one of these boards (MGT5100). There didn't seem to be much discussion though; I have one of these boards and would also like to boot linux on it, I'm wondering if anyone can point me to a good starting point on this? Any help is appreciated. I've got a toolchain and kernel built but am having no luck with it. Thanks, Chris H. I've been working with Kent Borg to bring up linux on the mgt5100. As Peter said, they're running it on an icecube, while I have a glacier system. The serial driver seems reasonably solid. I've been working on an ethernet driver and started testing it today. It has sent and received a few packets but lots of cleanup remains. I plan to put up a bk repository on source.mvista.com in a couple of weeks. I could send you a tarball if you'd rather not wait. -Dale Farnsworth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] Fix prep boot in linuxppc_2_4_devel
On Sat, Apr 19, 2003 at 02:32:38AM +, Tom Rini wrote: On Fri, Apr 18, 2003 at 02:02:31PM -0700, Tom Rini wrote: On Wed, Apr 16, 2003 at 11:38:30AM -0600, Cort Dougan wrote: This fixes the prep boot code so it will actually create a good SMP boot image. The wrong variable was being used. Urk. Can we kill znetboot / znetboot.initrd instead please? Or, for the potentially silent masses of you out there who do use this, please speak up. I'm not really aware of anyone other than Cort who does use this target but am more than willing to stand corrected. I find it convenient and use it quite often. -Dale ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
