* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:05 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602100847.54363.sr@denx.de>
Hi Stefan,
Thanks for confirming my analysis.
There's actually an additional issue with the 440EP
for my application. I'll be using it in a 5V PCI
environment (due to the reuse of the existing host
CPUs). Since the 440EP is not 5V tolerant, I figured
I would add clamps or buffers to the board design.
However, given the meager host-to-host communications
features, I think I would be better off putting an
Intel 21555 non-transparent bridge on the board.
That will provide 5V tolerance, and a full set of
messaging unit and I2O facilities. All for $50-80
or so according to the single-piece pricing from
Digikey. I'm not so happy to need to add another
chip, but if the 440EP passes all the other
benchmark requirements, then it seems the least
painful way to proceed.
Has anyone reading this list had good or bad experiences
with the Intel 21555 or perhaps some of the PLX offers,
eg. PCI 6254?
If only the GX/SP had an FPU ...
Of course there is also the option of finding another
PowerPC that matches my requirements;
- 300-500MHz CPU
- ~2W
- FPU
- three independent buses; SDRAM, PCI, external
- the external bus will contain multiple FPGAs
that generate 128kB of data every 10ms or so.
The data needs to be DMAed to SDRAM, where
the host CPU can convert it to float, FFT
it, process, and average the data. Transfers
to host over PCI occur every 100ms.
FPGA-to-SDRAM should occur in ~1ms;
128kB/1ms = 128MB/s
There will be up to 20 boards in a crate,
and transfers from all 20 boards need to
complete in 100ms, so
FPGA-to-host should occur in ~5ms;
128kB/5ms = 25MB/s
So I don't need stunning PCI performance, but
I do need a reasonable external memory bus
bandwidth.
The 440EP 16bit/66MHz 132MB/s would just meet
my requirement (and I can handle a 50% drop
in bus bandwidth if benchmarks go that way).
The PCI performance hits 50MB/s, so its ok.
I don't want to use a local-bus PCI interface
with the FPGAs, since then I'd need a PCI core
in each. I typically pack the FPGAs to 90%
with processing logic, so can't afford the
space for a complex host-to-FPGA interface.
I think I've shown you the current boards (that
use a TI DSP);
http://www.ovro.caltech.edu/~dwh/correlator
I had looked at the MPC8245 processor a while back,
but its SDRAM interface is multiplexed with its external
memory bus, so DMA from the external bus to SDRAM
would likely be pretty poor.
Do you have any experience with features of the PowerQUICC
processors? I've tried to avoid a full-up G4/G5 processor
since they typically also require a system controller
chip, and consume a lot more power.
I had also considered using a ColdFire processor, but
went with the PowerPC since I'll be using some Virtex
FPGAs with the PowerPC in a future project.
Anyway, just thought I'd give you an idea of what I'm
trying to figure out.
Cheers,
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:26 UTC (permalink / raw)
To: Andrew Armitage; +Cc: linuxppc-embedded
In-Reply-To: <43ECCB4D.9080602@varisys.co.uk>
> We've used the 21555 on a couple of our designs (mated to a 7457/107
> pair) and have never had too many problems with them. The messaging
> unit has been very helpful.
>
> Just my $0.02,
Hey Andrew,
Thanks!
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Wolfgang Denk @ 2006-02-10 17:31 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Dear David,
in message <43ECC7CE.1010409@ovro.caltech.edu> you wrote:
>
> Of course there is also the option of finding another
> PowerPC that matches my requirements;
...
MPC834x comes to mind. But I have to admit that we never tried using
this as a PCI device yet...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I can type faster than I can move a mouse, so I find menu-driven
drawing packages time consuming and frustrating. - W. R. Stevens
^ permalink raw reply
* Stability of MPC5200 FEC
From: Asier Llano Palacios @ 2006-02-10 17:20 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Sylvain Munaut, John Rigby
We are working with MPC5200 cpu.=20
We've been using it since early 2.6 kernel versions.
We're currently quite stabilished with the version of the kernel Sylvain
had before the Platform Device rework. But the problem is that we are
experiencing that the FEC stops working after a long uptime.
So, do you think that the current git version is more stable than the
one we are using? Do you think that there is anything that could stop us
upgrading to the latest version?
The problem is that we have a custom board, with some custom devices, so
it is not so easy to upgrade. We need to know that a new version, is
more stable than the previous one, before we upgrade. As soon as we
upgrade, we can help if we find any problem.
Thank you,
Asier Llano
--=20
Asier Llano Palacios
ZIV I+D Smart Energy Networks
Dpto. Ingenier=EDa de Desarrollo.
ZIV, Aplicaciones y Tecnolog=EDa.
Parque Tecnol=F3gico, 210
48170 ZAMUDIO (Bizkaia)
E-mail: a.llano@ziv.es
Tlfno: (+34)944037400=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060210173133.964B53525CC@atlas.denx.de>
>>Of course there is also the option of finding another
>>PowerPC that matches my requirements;
>
> ...
>
> MPC834x comes to mind. But I have to admit that we never tried using
> this as a PCI device yet...
>
Thanks Wolfgang, I'll take a look at the user manual.
Regarding PowerPC devices that can be (uselessly) configured
as PCI agents/targets/peripherals;
- the Artesyn PMC board I got from eBay contains the
IBM CPC700 bridge - it can never generate PCI interrupts
as a target (non-monarch mode).
- the MPC5200 PowerPC, can also be configured as a target,
but will never generate PCI interrupts.
Gee, who knew. I didn't :)
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Andrew Armitage @ 2006-02-10 17:20 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Hi David,
> However, given the meager host-to-host communications
> features, I think I would be better off putting an
> Intel 21555 non-transparent bridge on the board.
> That will provide 5V tolerance, and a full set of
> messaging unit and I2O facilities. All for $50-80
> or so according to the single-piece pricing from
> Digikey. I'm not so happy to need to add another
> chip, but if the 440EP passes all the other
> benchmark requirements, then it seems the least
> painful way to proceed.
>
> Has anyone reading this list had good or bad experiences
> with the Intel 21555 or perhaps some of the PLX offers,
> eg. PCI 6254?
We've used the 21555 on a couple of our designs (mated to a 7457/107
pair) and have never had too many problems with them. The messaging
unit has been very helpful.
Just my $0.02,
Andrew
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-10 17:59 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ECC7CE.1010409@ovro.caltech.edu>
Hi David,
On Friday 10 February 2006 18:05, David Hawkins wrote:
> There's actually an additional issue with the 440EP
> for my application. I'll be using it in a 5V PCI
> environment (due to the reuse of the existing host
> CPUs).
Autsch! Those must be pretty old CPU's! Is this standard desktop PCI or
CompactPCI or PMC?
> Since the 440EP is not 5V tolerant, I figured
> I would add clamps or buffers to the board design.
I would be careful here, since you easily can violate the pci specs. Do you
have other pci devices on this pci bus?
Just use newer host CPU's! ;-)
Best regards,
Stefan
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 17:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43ECCF7C.9070701@ovro.caltech.edu>
Hey Travis,
>> Not great, so any suggestions for whats better?
>>
> Everyone uses them because they're easy and just work. Sometimes
> you may need to tweak the setup eeprom, but in general they just work.
> We use a pericom 7300 (can't remember and working from home
> today), that is quite nice. Not an issue with it at all. HW
> guy just plunked it down and it worked. They have an eval board to.
I was going to take a look around TIs site, I'd forgotten Pericom
makes bridges too, I'll read the data book.
> ... I've not had a need to use it, my work is 90% PCI
> (forwarding engine, queueing engine, etc) for 10G ethernet, so
> FPU stuff is very rare, and not time critical (used for setting
> up policing/rate limiting etc). Basically, set it and forget it
> calculations.
I figured that was probably the case - and the reason the majority
of the embedded processors are sans-FPU. I didn't want to use a
TI DSP again, there's just no 'community spirit' like with Linux.
So, I'll take a look at the PowerQUICC that Wolfgang mentioned, and
see if I want to change to that processor, another look at the ColdFire
(I have an MCF5485 eval board), and a look at the bridge data sheets
and see where that leaves me.
Personally, I want to stay with the PowerPC, the developer mailing
list is great!
Thanks,
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 18:11 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602101859.24830.sr@denx.de>
>>There's actually an additional issue with the 440EP
>>for my application. I'll be using it in a 5V PCI
>>environment (due to the reuse of the existing host
>>CPUs).
>
> Autsch! Those must be pretty old CPU's! Is this standard desktop PCI or
> CompactPCI or PMC?
They're not too old ... but at $2k a piece, you don't want
to just throw them away.
The CPUs are Force Computers 735AR2 devices. They contain
a Force Sentinel PCI-to-PCI bridge. The bridges can operate
at 3.3V or 5V, but they decided to hardwire them for 5V
operation to implement hot-swap.
The other newer CPUs are Trenton CPLEs.
http://www.trentontechnology.com/products/singleboards/5932.php4
The system uses cPCI crates. In some cases 21152 bridges are
used to make larger backplanes, in other cases SBS bridges
containing 21152's are used to link crates.
>>Since the 440EP is not 5V tolerant, I figured
>>I would add clamps or buffers to the board design.
>
> I would be careful here, since you easily can violate the pci
> specs. Do you have other pci devices on this pci bus?
Yeah, I'd make sure that I had others check my work. However,
the 21555 would take care of it, and the only PCI bus
on the board would be the one between the 440EP and the
bridge.
> Just use newer host CPU's! ;-)
Ah, the words of a true engineer :)
Of course the project manager wouldn't appreciate me doing that.
However, its not totally out of the question ... $50 per 21555
and 20 per crate, thats $1000, about half the price of
a CPU. But of course, without the I20 unit on the 440EP,
I might need the 21555 anyway.
Cheers
Dave
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: John Rigby @ 2006-02-10 18:22 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <1139592010.14894.22.camel@localhost.localdomain>
Do you have a lite5200 board that exhibits the same bad FEC behavior.
If so you could try the new
version on it and see if things improve.
Asier Llano Palacios wrote:
>We are working with MPC5200 cpu.
>We've been using it since early 2.6 kernel versions.
>We're currently quite stabilished with the version of the kernel Sylvain
>had before the Platform Device rework. But the problem is that we are
>experiencing that the FEC stops working after a long uptime.
>
>So, do you think that the current git version is more stable than the
>one we are using? Do you think that there is anything that could stop us
>upgrading to the latest version?
>
>The problem is that we have a custom board, with some custom devices, so
>it is not so easy to upgrade. We need to know that a new version, is
>more stable than the previous one, before we upgrade. As soon as we
>upgrade, we can help if we find any problem.
>
>Thank you,
>Asier Llano
>
>
>
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 18:19 UTC (permalink / raw)
To: Mark Chambers, linuxppc-embedded
In-Reply-To: <001701c62e6c$09c48ea0$6401a8c0@CHUCK2>
Hi Mark,
> Some unsolicited brainstorming
Brainstorm away!
> if you go with a QUICC based processor you could bring
> the data into SDRAM via a serial port. That gets you DMA
> and some extra buffer management help from the co-processor.
Ooooh I like it.
> Some extra logic in the FPGA (but less pins), but you've got
> a lot of flexibility in what you can do with SCCs or I2C.
But do I have the bandwidth? (I'll look in the data book).
> I'm currently working on an MPC8247 based design, btw.
> It has a PC104+ header and is directly connected to a
> T.I. 6205 (which, at $10, is a lot of crunch for the buck).
But the you have to program it with Code Composer and
the horrid TI DSP tools. Yeah, ok I've got the older
C31 version, not the newer 6x-based DSPs. I'm trying
to move the system to Linux, so that others round
here can 'share the burden'. I'm designing the boards,
drivers, and host software (ACE/C++) at the moment.
I need a break! :)
I want to avoid spending $20k on the TI tools and an
emulator ... hey, call me cheap.
However, I like the SCC idea. They sound very similar
to the multi-processor links on the Analog Devices
SHARC DSPs.
More reading :)
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-10 19:13 UTC (permalink / raw)
To: Travis B. Sawyer, linuxppc-embedded
In-Reply-To: <43ECD19E.8010604@sandburst.com>
Hi Travis,
>>> Ah, the ol' dec 21555, everyone has had to use one in their lifetime...
>>> Not bad, not great...
>>
>> Not great, so any suggestions for whats better?
>>
> Everytone uses them because they're easy and just work. Sometimes you
> may need to tweak the setup eeprom, but in general they just work.
> We use a pericom 7300 (can't remember and working from home today), that
> is quite nice. Not an issue with it at all. HW guy just plunked it down
> and it worked. They have an eval board to.
The 7300 is a PCI-to-PCI bridge that only operates in transparent
mode, it does not have any I2O capabilities. I used the Pericom
cross-reference guide and they don't have a replacement part
for the 21555, or the PLX6254 or PLX6540. So, thanks for the
suggestion, but the 21555 still has it.
I didn't find any Pericom bridge that was non-transparent.
Dave
^ permalink raw reply
* Re: mv-linux: Problem to implement custom driver interrupt handling
From: Andrei Konovalov @ 2006-02-10 19:13 UTC (permalink / raw)
To: Eckart Göhler; +Cc: linuxppc-embedded
In-Reply-To: <43ECB078.4080209@ifen.com>
Eckart Göhler wrote:
>
> Andrei Konovalov wrote:
> > Hi,
> >
> > In the Linux driver you should not access the interrupt controller
> > directly.
> > The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c
> code.
> > E.g. the particular interrupt is unmasked when one calls request_irq().
> >
> > Few more comments below.
>
>
> Hi,
>
> Thanks a lot. Actually I inserted the low-level code below after
> request_irq() did not work. The note about xilinx_pic.c code (that is
> located in my implementation in arch/ppc/kernel/xilinx_pic.c) lead me to
Correct. arch/ppc/syslib/xilinx_pic.c is the 2.6 kernel case.
> the problem origin that should be reported here for the community (which
> I presume already know the very fact):
> The interrupt numbering generated by the EDK is opposite to the one used
> by linux, i.e. interrupt number 4 reported in EDK-generated
> xparameters.h/xparameters_ml300.h becomes 31-4 = 27 when using request_irq.
Yes, this is true for 2.4 kernels.
In 2.6 the "natural" irq numbering is used.
I.e. for irq number of 4 (as per xparameters.h) one should pass
to request_irq()
31-4 = 27 if using 2.4 kernel
and
4 if using 2.6 kernel.
Thanks,
Andrei
> Therefore the handler was not called because he was attached to the
> wrong interrupt, and also was not able to reset the interrupt pending
> flag, that must be done as you noted below.
>
> cheers
>
> eckart
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Pat Gefre @ 2006-02-10 20:57 UTC (permalink / raw)
To: Russell King; +Cc: linux-mips, Linux Kernel List, linuxppc-dev
In-Reply-To: <20060210084445.GA1947@flint.arm.linux.org.uk>
Yeah this is something I should've fixed up... thanks
Acked-by: pfg@sgi.com
On Fri February 10 2006 2:44 am, Russell King wrote:
> On Sat, Jan 21, 2006 at 09:14:07PM +0000, Russell King wrote:
> > The ioc4_serial driver is worse. It assumes that it can set/clear
> > ASYNC_CTS_FLOW in the uart_info flags field, which is private to
> > serial_core. It also seems to set TTY_IO_ERROR followed by immediately
> > clearing it (pointless), and then it writes to tty->alt_speed... which
> > isn't used by the serial layer so is also pointless.
>
> Okay, the only remaining part of this patch which hasn't been applied
> is this - can anyone ack it?
>
> diff --git a/drivers/serial/ioc4_serial.c b/drivers/serial/ioc4_serial.c
> --- a/drivers/serial/ioc4_serial.c
> +++ b/drivers/serial/ioc4_serial.c
> @@ -1717,11 +1717,9 @@ ioc4_change_speed(struct uart_port *the_
> }
>
> if (cflag & CRTSCTS) {
> - info->flags |= ASYNC_CTS_FLOW;
> port->ip_sscr |= IOC4_SSCR_HFC_EN;
> }
> else {
> - info->flags &= ~ASYNC_CTS_FLOW;
> port->ip_sscr &= ~IOC4_SSCR_HFC_EN;
> }
> writel(port->ip_sscr, &port->ip_serial_regs->sscr);
> @@ -1760,18 +1758,6 @@ static inline int ic4_startup_local(stru
>
> info = the_port->info;
>
> - if (info->tty) {
> - set_bit(TTY_IO_ERROR, &info->tty->flags);
> - clear_bit(TTY_IO_ERROR, &info->tty->flags);
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
> - info->tty->alt_speed = 57600;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
> - info->tty->alt_speed = 115200;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_SHI)
> - info->tty->alt_speed = 230400;
> - if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_WARP)
> - info->tty->alt_speed = 460800;
> - }
> local_open(port);
>
> /* set the speed of the serial port */
^ permalink raw reply
* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Russell King @ 2006-02-10 21:52 UTC (permalink / raw)
To: Pat Gefre; +Cc: linux-mips, Linux Kernel List, linuxppc-dev
In-Reply-To: <200602101457.45847.pfg@sgi.com>
On Fri, Feb 10, 2006 at 02:57:45PM -0600, Pat Gefre wrote:
> Yeah this is something I should've fixed up... thanks
>
> Acked-by: pfg@sgi.com
Thanks, applied.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-02-10 22:31 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
Just 4 commits this time. Log and diffstat follow.
Thanks,
Paul.
Becky Bruce:
powerpc: Add FSL USB node to documentation
JANAK DESAI:
powerpc: unshare system call registration
Kumar Gala:
powerpc: Add CONFIG_DEFAULT_UIMAGE for embedded boards
Paul Mackerras:
ppc: Use the system call table from arch/powerpc/kernel/systbl.S
Documentation/powerpc/booting-without-of.txt | 60 +++++-
arch/powerpc/Kconfig | 6 +
arch/powerpc/Makefile | 1
arch/powerpc/kernel/Makefile | 6 -
arch/powerpc/kernel/systbl.S | 3
arch/ppc/kernel/misc.S | 283 --------------------------
include/asm-powerpc/unistd.h | 3
7 files changed, 72 insertions(+), 290 deletions(-)
^ permalink raw reply
* denx 2.4 kernel doesn't compile amd_flash.c
From: dibacco @ 2006-02-10 23:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I downloaded denx 2.4 kernel via cvs. I tried to compile it for a MBX boa=
rd but I get the following problem:
amd_flash.c:143: error: structure has no member named `buswidth'
I was successful using the kernel included in ELDK 3.1.1.
Someone could help?
^ permalink raw reply
* [PATCH] Add PCI support for 8540 ADS to powerpc tree
From: Andy Fleming @ 2006-02-10 23:01 UTC (permalink / raw)
To: linuxppc-embedded
This patch applies on top off Becky's cleanup patches
Signed-off-by: Andy Fleming <afleming@freescale.com>
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 70e1190..ffc4139 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -1,4 +1,5 @@
#
# Makefile for the PowerPC 85xx linux kernel.
#
-obj-$(CONFIG_PPC_85xx) += misc.o mpc85xx_ads.o
+obj-$(CONFIG_PPC_85xx) += misc.o pci.o
+obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/powerpc/platforms/85xx/mpc8540_ads.h
index b3ec88c..16976bd 100644
--- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
+++ b/arch/powerpc/platforms/85xx/mpc8540_ads.h
@@ -39,7 +39,7 @@
#define MPC85XX_PCI1_IO_BASE 0xe2000000
#define MPC85XX_PCI1_MEM_OFFSET 0x00000000
-#define MPC85XX_PCI1_IO_SIZE 0x01000000
+#define MPC85XX_PCI1_IO_SIZE 0x00100000
/* PCI config */
#define PCI1_CFG_ADDR_OFFSET (0x8000)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
index be75abb..b44db62 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx.h
+++ b/arch/powerpc/platforms/85xx/mpc85xx.h
@@ -15,3 +15,4 @@
*/
extern void mpc85xx_restart(char *);
+extern int add_bridge(struct device_node *dev);
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index e14cd20..3a4b409 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -67,6 +67,62 @@ static u_char mpc85xx_ads_openpic_initse
0x0, /* External 11: */
};
+#ifdef CONFIG_PCI
+/*
+ * interrupt routing
+ */
+
+int
+mpc85xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
+{
+ static char pci_irq_table[][4] =
+ /*
+ * This is little evil, but works around the fact
+ * that revA boards have IDSEL starting at 18
+ * and others boards (older) start at 12
+ *
+ * PCI IDSEL/INTPIN->INTLINE
+ * A B C D
+ */
+ {
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 2 */
+ {PIRQD, PIRQA, PIRQB, PIRQC},
+ {PIRQC, PIRQD, PIRQA, PIRQB},
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 5 */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 12 */
+ {PIRQD, PIRQA, PIRQB, PIRQC},
+ {PIRQC, PIRQD, PIRQA, PIRQB},
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 15 */
+ {0, 0, 0, 0}, /* -- */
+ {0, 0, 0, 0}, /* -- */
+ {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 18 */
+ {PIRQD, PIRQA, PIRQB, PIRQC},
+ {PIRQC, PIRQD, PIRQA, PIRQB},
+ {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 21 */
+ };
+
+ const long min_idsel = 2, max_idsel = 21, irqs_per_slot = 4;
+ return PCI_IRQ_TABLE_LOOKUP;
+}
+
+int
+mpc85xx_exclude_device(u_char bus, u_char devfn)
+{
+ if (bus == 0 && PCI_SLOT(devfn) == 0)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ else
+ return PCIBIOS_SUCCESSFUL;
+}
+
+#endif /* CONFIG_PCI */
+
+
void __init mpc85xx_ads_pic_init(void)
{
struct mpic *mpic1;
@@ -110,6 +166,7 @@ void __init mpc85xx_ads_pic_init(void)
static void __init mpc85xx_ads_setup_arch(void)
{
struct device_node *cpu;
+ struct device_node *np;
if (ppc_md.progress)
ppc_md.progress("mpc85xx_ads_setup_arch()", 0);
@@ -125,6 +182,16 @@ static void __init mpc85xx_ads_setup_arc
loops_per_jiffy = 50000000 / HZ;
of_node_put(cpu);
}
+
+#ifdef CONFIG_PCI
+ for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
+ add_bridge(np);
+
+ ppc_md.pci_swizzle = common_swizzle;
+ ppc_md.pci_map_irq = mpc85xx_map_irq;
+ ppc_md.pci_exclude_device = mpc85xx_exclude_device;
+#endif
+
#ifdef CONFIG_ROOT_NFS
ROOT_DEV = Root_NFS;
#else
diff --git a/arch/powerpc/platforms/85xx/pci.c b/arch/powerpc/platforms/85xx/pci.c
new file mode 100644
index 0000000..93b0bb1
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/pci.c
@@ -0,0 +1,96 @@
+/*
+ * FSL SoC setup code
+ *
+ * Maintained by Kumar Gala (see MAINTAINERS for contact information)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/delay.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+
+#include <asm/system.h>
+#include <asm/atomic.h>
+#include <asm/io.h>
+#include <asm/pci-bridge.h>
+#include <asm/prom.h>
+#include <sysdev/fsl_soc.h>
+
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(x...) printk(x)
+#else
+#define DBG(x...)
+#endif
+
+int mpc85xx_pci2_busno = 0;
+
+#ifdef CONFIG_PCI
+int __init add_bridge(struct device_node *dev)
+{
+ int len;
+ struct pci_controller *hose;
+ struct resource rsrc;
+ int *bus_range;
+ int primary = 1, has_address = 0;
+ phys_addr_t immr = get_immrbase();
+
+ DBG("Adding PCI host bridge %s\n", dev->full_name);
+
+ /* Fetch host bridge registers address */
+ has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
+
+ /* Get bus range if any */
+ bus_range = (int *) get_property(dev, "bus-range", &len);
+ if (bus_range == NULL || len < 2 * sizeof(int)) {
+ printk(KERN_WARNING "Can't get bus-range for %s, assume"
+ " bus 0\n", dev->full_name);
+ }
+
+ hose = pcibios_alloc_controller();
+ if (!hose)
+ return -ENOMEM;
+ hose->arch_data = dev;
+ hose->set_cfg_type = 1;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ /* PCI 1 */
+ if ((rsrc.start & 0xfffff) == 0x8000) {
+ setup_indirect_pci(hose, immr + 0x8000, immr + 0x8004);
+ }
+ /* PCI 2*/
+ if ((rsrc.start & 0xfffff) == 0x9000) {
+ setup_indirect_pci(hose, immr + 0x9000, immr + 0x9004);
+ primary = 0;
+ hose->bus_offset = hose->first_busno;
+ mpc85xx_pci2_busno = hose->first_busno;
+ }
+
+ printk(KERN_INFO "Found MPC85xx PCI host bridge at 0x%08lx. "
+ "Firmware bus number: %d->%d\n",
+ rsrc.start, hose->first_busno, hose->last_busno);
+
+ DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
+ hose, hose->cfg_addr, hose->cfg_data);
+
+ /* Interpret the "ranges" property */
+ /* This also maps the I/O region and sets isa_io/mem_base */
+ pci_process_bridge_OF_ranges(hose, dev, primary);
+
+ return 0;
+}
+
+#endif
^ permalink raw reply related
* SPI support for MPC8xx in ELDK 3.1.1?
From: dibacco @ 2006-02-10 23:04 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
the support for SPI device for MPC8xx (MPC880) is present in the ELDK 3.1=
.1 ?
Thank you,
Antonio.
^ permalink raw reply
* Re: [PATCH] Add PCI support for 8540 ADS to powerpc tree
From: Kumar Gala @ 2006-02-10 22:56 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0602101654580.8978@ld0175-tx32.am.freescale.net>
Ok, How far off is 8555 CDS?
- kumar
On Fri, 10 Feb 2006, Andy Fleming wrote:
> This patch applies on top off Becky's cleanup patches
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
>
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index 70e1190..ffc4139 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -1,4 +1,5 @@
> #
> # Makefile for the PowerPC 85xx linux kernel.
> #
> -obj-$(CONFIG_PPC_85xx) += misc.o mpc85xx_ads.o
> +obj-$(CONFIG_PPC_85xx) += misc.o pci.o
> +obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
> diff --git a/arch/powerpc/platforms/85xx/mpc8540_ads.h b/arch/powerpc/platforms/85xx/mpc8540_ads.h
> index b3ec88c..16976bd 100644
> --- a/arch/powerpc/platforms/85xx/mpc8540_ads.h
> +++ b/arch/powerpc/platforms/85xx/mpc8540_ads.h
> @@ -39,7 +39,7 @@
> #define MPC85XX_PCI1_IO_BASE 0xe2000000
> #define MPC85XX_PCI1_MEM_OFFSET 0x00000000
>
> -#define MPC85XX_PCI1_IO_SIZE 0x01000000
> +#define MPC85XX_PCI1_IO_SIZE 0x00100000
>
> /* PCI config */
> #define PCI1_CFG_ADDR_OFFSET (0x8000)
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx.h b/arch/powerpc/platforms/85xx/mpc85xx.h
> index be75abb..b44db62 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx.h
> +++ b/arch/powerpc/platforms/85xx/mpc85xx.h
> @@ -15,3 +15,4 @@
> */
>
> extern void mpc85xx_restart(char *);
> +extern int add_bridge(struct device_node *dev);
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> index e14cd20..3a4b409 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
> @@ -67,6 +67,62 @@ static u_char mpc85xx_ads_openpic_initse
> 0x0, /* External 11: */
> };
>
> +#ifdef CONFIG_PCI
> +/*
> + * interrupt routing
> + */
> +
> +int
> +mpc85xx_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
> +{
> + static char pci_irq_table[][4] =
> + /*
> + * This is little evil, but works around the fact
> + * that revA boards have IDSEL starting at 18
> + * and others boards (older) start at 12
> + *
> + * PCI IDSEL/INTPIN->INTLINE
> + * A B C D
> + */
> + {
> + {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 2 */
> + {PIRQD, PIRQA, PIRQB, PIRQC},
> + {PIRQC, PIRQD, PIRQA, PIRQB},
> + {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 5 */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 12 */
> + {PIRQD, PIRQA, PIRQB, PIRQC},
> + {PIRQC, PIRQD, PIRQA, PIRQB},
> + {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 15 */
> + {0, 0, 0, 0}, /* -- */
> + {0, 0, 0, 0}, /* -- */
> + {PIRQA, PIRQB, PIRQC, PIRQD}, /* IDSEL 18 */
> + {PIRQD, PIRQA, PIRQB, PIRQC},
> + {PIRQC, PIRQD, PIRQA, PIRQB},
> + {PIRQB, PIRQC, PIRQD, PIRQA}, /* IDSEL 21 */
> + };
> +
> + const long min_idsel = 2, max_idsel = 21, irqs_per_slot = 4;
> + return PCI_IRQ_TABLE_LOOKUP;
> +}
> +
> +int
> +mpc85xx_exclude_device(u_char bus, u_char devfn)
> +{
> + if (bus == 0 && PCI_SLOT(devfn) == 0)
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + else
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +#endif /* CONFIG_PCI */
> +
> +
> void __init mpc85xx_ads_pic_init(void)
> {
> struct mpic *mpic1;
> @@ -110,6 +166,7 @@ void __init mpc85xx_ads_pic_init(void)
> static void __init mpc85xx_ads_setup_arch(void)
> {
> struct device_node *cpu;
> + struct device_node *np;
>
> if (ppc_md.progress)
> ppc_md.progress("mpc85xx_ads_setup_arch()", 0);
> @@ -125,6 +182,16 @@ static void __init mpc85xx_ads_setup_arc
> loops_per_jiffy = 50000000 / HZ;
> of_node_put(cpu);
> }
> +
> +#ifdef CONFIG_PCI
> + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> + add_bridge(np);
> +
> + ppc_md.pci_swizzle = common_swizzle;
> + ppc_md.pci_map_irq = mpc85xx_map_irq;
> + ppc_md.pci_exclude_device = mpc85xx_exclude_device;
> +#endif
> +
> #ifdef CONFIG_ROOT_NFS
> ROOT_DEV = Root_NFS;
> #else
> diff --git a/arch/powerpc/platforms/85xx/pci.c b/arch/powerpc/platforms/85xx/pci.c
> new file mode 100644
> index 0000000..93b0bb1
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/pci.c
> @@ -0,0 +1,96 @@
> +/*
> + * FSL SoC setup code
> + *
> + * Maintained by Kumar Gala (see MAINTAINERS for contact information)
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/config.h>
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/pci.h>
> +#include <linux/delay.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +
> +#include <asm/system.h>
> +#include <asm/atomic.h>
> +#include <asm/io.h>
> +#include <asm/pci-bridge.h>
> +#include <asm/prom.h>
> +#include <sysdev/fsl_soc.h>
> +
> +#undef DEBUG
> +
> +#ifdef DEBUG
> +#define DBG(x...) printk(x)
> +#else
> +#define DBG(x...)
> +#endif
> +
> +int mpc85xx_pci2_busno = 0;
> +
> +#ifdef CONFIG_PCI
> +int __init add_bridge(struct device_node *dev)
> +{
> + int len;
> + struct pci_controller *hose;
> + struct resource rsrc;
> + int *bus_range;
> + int primary = 1, has_address = 0;
> + phys_addr_t immr = get_immrbase();
> +
> + DBG("Adding PCI host bridge %s\n", dev->full_name);
> +
> + /* Fetch host bridge registers address */
> + has_address = (of_address_to_resource(dev, 0, &rsrc) == 0);
> +
> + /* Get bus range if any */
> + bus_range = (int *) get_property(dev, "bus-range", &len);
> + if (bus_range == NULL || len < 2 * sizeof(int)) {
> + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> + " bus 0\n", dev->full_name);
> + }
> +
> + hose = pcibios_alloc_controller();
> + if (!hose)
> + return -ENOMEM;
> + hose->arch_data = dev;
> + hose->set_cfg_type = 1;
> +
> + hose->first_busno = bus_range ? bus_range[0] : 0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> +
> + /* PCI 1 */
> + if ((rsrc.start & 0xfffff) == 0x8000) {
> + setup_indirect_pci(hose, immr + 0x8000, immr + 0x8004);
> + }
> + /* PCI 2*/
> + if ((rsrc.start & 0xfffff) == 0x9000) {
> + setup_indirect_pci(hose, immr + 0x9000, immr + 0x9004);
> + primary = 0;
> + hose->bus_offset = hose->first_busno;
> + mpc85xx_pci2_busno = hose->first_busno;
> + }
> +
> + printk(KERN_INFO "Found MPC85xx PCI host bridge at 0x%08lx. "
> + "Firmware bus number: %d->%d\n",
> + rsrc.start, hose->first_busno, hose->last_busno);
> +
> + DBG(" ->Hose at 0x%p, cfg_addr=0x%p,cfg_data=0x%p\n",
> + hose, hose->cfg_addr, hose->cfg_data);
> +
> + /* Interpret the "ranges" property */
> + /* This also maps the I/O region and sets isa_io/mem_base */
> + pci_process_bridge_OF_ranges(hose, dev, primary);
> +
> + return 0;
> +}
> +
> +#endif
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: SPI support for MPC8xx in ELDK 3.1.1?
From: Wolfgang Denk @ 2006-02-10 23:26 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUHUQX$E3BAE7D116850E80B61395D5308F6B3C@libero.it>
In message <IUHUQX$E3BAE7D116850E80B61395D5308F6B3C@libero.it> you wrote:
>
> the support for SPI device for MPC8xx (MPC880) is present in the ELDK 3.1.1 ?
Yes, if you use the ELDK in combination with a kernel tree that
supports SPI on your board.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When some people discover the truth, they just can't understand why
everybody isn't eager to hear it.
^ permalink raw reply
* Re: denx 2.4 kernel doesn't compile amd_flash.c
From: Wolfgang Denk @ 2006-02-10 23:27 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUHULD$E8FF06F7D3BACC0D72A90B39E3254D5F@libero.it>
In message <IUHULD$E8FF06F7D3BACC0D72A90B39E3254D5F@libero.it> you wrote:
>
> I downloaded denx 2.4 kernel via cvs. I tried to compile it for a MBX board but I get the following problem:
>
> amd_flash.c:143: error: structure has no member named `buswidth'
You probably misconfigured your kernel.
The standard sequence of
-> make mbx_config ; make oldconfig && make dep && make -j8 uImage
works without problems here.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I will not say that women have no character; rather, they have a new
one every day. -- Heine
^ permalink raw reply
* kernel startup
From: dibacco @ 2006-02-10 23:33 UTC (permalink / raw)
To: linuxppc-embedded
Normally is it the uboot that uncompresses the kernel or the kernel uncom=
press itself?
The function called by uboot when I type boot is _start?
What does it mean that the load address is 0x00000000?
^ permalink raw reply
* Re: kernel startup
From: Kumar Gala @ 2006-02-10 23:32 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUHW4N$47B2C300D721E9A22AAA3B454F79F6F4@libero.it>
On Sat, 11 Feb 2006, dibacco@inwind.it wrote:
> Normally is it the uboot that uncompresses the kernel or the kernel uncompress itself?
How would something compressed uncompress itself? If u-boot is being used
it will uncompress a compressed kernel and put the image at physical 0.
> The function called by uboot when I type boot is _start?
Are you asking about u-boot's _start or the kernel's?
> What does it mean that the load address is 0x00000000?
its the address u-boot's going to jump to and start executing kernel code
from.
- kumar
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-10 23:53 UTC (permalink / raw)
To: galak, dibacco; +Cc: linuxppc-embedded
> Normally is it the uboot that uncompresses the kernel or the kernel
uncompress itself?=20
>>How would something compressed uncompress itself? If u-boot is being
used=20
>>it will uncompress a compressed kernel and put the image at physical
0.
Small correction. Just like a self extracting binary, a kernel can have
a decompression code prepended to the start of kernel which can
decompress the=20
Kernel. This is how redboot for xscale is structured or syslinux /lilo
for x86.=20
Although u-boot has simplified this step by doing the CRC checksum of
the
uiMage header as well as data and also decompress the kernel. Based on
load
address, entry point, the kernel can start executing. =20
Now, whether cache is enable or not, MMU is enabled/disabled depends on
the
Developer. In current u-boot, the MMU is not used. I-Cache is On and
D-cache
is off.
Best Regards,
Atul
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox