* Re: Flattened device tree for Pegasos
From: Kumar Gala @ 2006-02-11 0:46 UTC (permalink / raw)
To: Mark A. Greer, Benjamin Herrenschmidt, Paul Mackerras,
Segher Boessenkool
Cc: linuxppc-dev
In-Reply-To: <20060211004814.GB22539@mag.az.mvista.com>
On Fri, 10 Feb 2006, Mark A. Greer wrote:
> If anyone happens to have a Pegasos running the merged powerpc kernel
> handy, I would greatly appreciate a dump of flattened device tree that
> it uses.
We really need to put OF tree's somewhere that people can get to, maybe
penguinppc.org.
Ben, Segher, Paul:
You guys have either access to HW or tree dump's already. Would you be
willing to share them?
- kumar
^ permalink raw reply
* RE: kernel startup
From: Kumar Gala @ 2006-02-11 0:23 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2089@us-bv-m23.global.tektronix.net>
On Fri, 10 Feb 2006 atul.sabharwal@exgate.tek.com wrote:
> >>I'm not that familiar with 8xx, but can't you move IMMR?
>
> Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
> Or 0xFFF00000.
>
> Flash is from 0xfe000000 thru 0xffffffff. Now on POR,
> Processor goes to offset 0x100 on CS0. So, if IMMR is overlapping with
> flash, it might not boot.
>
> On 870, it seems that reset value for BR0/OR0 is undefined.
> Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
> Are remapped. So, I could put flash at a non-standard address like
> 0xDE000000 and move IMMR to 0xFF000000.
>
> The problem this creates is that I can set IIP to 0 or 1. So, exception
> Vector prefix can be 0 or 0xfff. Since no flash at 0xfff00000 base
> Address I cannot have any exceptions in my code till the u-boot code
> has relocated to RAM. Which should be acceptable as what can I do
> if there is exception so early in the system.
>
> Unless there is a better design ?
It sounds like you should move this discussion to the u-boot list since it
has very little to do with the kernel.
- k
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:28 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
>>I'm not that familiar with 8xx, but can't you move IMMR?
Not much choice with IMMR as it can be 0x0 or 0x00f00000 or 0xFF000000
Or 0xFFF00000. =20
Flash is from 0xfe000000 thru 0xffffffff. Now on POR,
Processor goes to offset 0x100 on CS0. So, if IMMR is overlapping with
flash, it might not boot.
On 870, it seems that reset value for BR0/OR0 is undefined.
Data fetch goes on CS0 and then in cpu_init_f BR0 & OR0
Are remapped. So, I could put flash at a non-standard address like
0xDE000000 and move IMMR to 0xFF000000.
The problem this creates is that I can set IIP to 0 or 1. So, exception
Vector prefix can be 0 or 0xfff. Since no flash at 0xfff00000 base=20
Address I cannot have any exceptions in my code till the u-boot code
has relocated to RAM. Which should be acceptable as what can I do
if there is exception so early in the system.=20
Unless there is a better design ?
Thanks,
Atul
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:19 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>>The RAM "is" where you map it. The mapping is done in software. The
>>software is implementing your design.
>>In other words, your design is broken when you put the RAM at such a
>>strange address instead of the natural location, starting from 0x0000.
Memory is not on the local bus but across a third party memory
controller.
Two processors loosely coupled. So, the RAM is at non zero address.
This seems to be the critical problem in this design but need to
convince
the design engineers. I don't know the reason why they want memory at
non zero address but that's the requirement.
--
Atul
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 0:12 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2081@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA2081@us-bv-m23.global.tektronix.net> you wrote:
>
> I am using PPC 870 and u-boot 1.1.2. Which architecture should I look
> for as a reference example. On my system, the RAM is not at address 0x0 but at
> 0x10000000. Since the exception table does not take full 32 bit address,
The phrase "the RAM is at address 0x10000000" is bogus.
The RAM "is" where you map it. The mapping is done in software. The
software is implementing your design.
In other words, your design is broken when you put the RAM at such a
strange adress instead of the natural location, starting from 0x0000.
> I am not sure how to tell the processor about the relocated location.
You don't; just fix your memory map.
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
If God had a beard, he'd be a UNIX programmer.
^ permalink raw reply
* RE: kernel startup
From: Kumar Gala @ 2006-02-11 0:03 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA2084@us-bv-m23.global.tektronix.net>
On Fri, 10 Feb 2006 atul.sabharwal@exgate.tek.com wrote:
> Since I have set IIP to 1, reset vector is at 0xfff00100. IMMR is
> 0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
> at address 0x0 (ISA style).
I'm not that familiar with 8xx, but can't you move IMMR?
- kumar
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:10 UTC (permalink / raw)
To: atul.sabharwal, galak; +Cc: linuxppc-embedded
Since I have set IIP to 1, reset vector is at 0xfff00100. IMMR is
0x00f00000. So, putting RAM at address 0x0 allows only 15MB of RAM
at address 0x0 (ISA style).=20
As memory and internal processor registers would conflict, I would have
a memory hole. Hence, the logical choice of putting RAM at a different
location. So, if MMU allows shadowing (which I have not read), it could
solve my problem.
Regards,
Atul
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 0:08 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net> you wrote:
>
> >>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.
>
> 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
> Kernel. This is how redboot for xscale is structured or syslinux /lilo
No, this is not the kernel, but some additional component, often
called "bootstrap loader" or so, which wraps the kernel as payload in
it's own image.
> 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.
This may be correct on some specific boards, but it's wrong on
others.
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
The existence of god implies a violation of causality.
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 0:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602101730210.31619-100000@gate.crashing.org>
In message <Pine.LNX.4.44.0602101730210.31619-100000@gate.crashing.org> you wrote:
>
> > 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.
No. U-Boot will load (copy) the image to the load address but start
executing kernel code at the entry point address which may be
different.
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
"Am besten betrachten Sie Fehlermeldungen als eine Art Psycho-Test,
mit dem herausgefunden werden soll, wie belastbar Sie sind."
- Dr. R. Wonneberger, Kompaktführer LaTeX, Kap. 1.6: Fehlermeldungen
^ permalink raw reply
* RE: kernel startup
From: atul.sabharwal @ 2006-02-11 0:02 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
>>I'm not sure what sub-arch we are talking about, but some do have the
MMU=20
on.
I am using PPC 870 and u-boot 1.1.2. Which architecture should I look
for as a reference example. On my system, the RAM is not at address 0x0
but at
0x10000000. Since the exception table does not take full 32 bit address,
I am not sure how to tell the processor about the relocated location.
On this custom board with 870, is it necessary to have RAM at address
0x0
(or shadow it) or the 870 supports configuration for different base
addresses for memory. =20
Thanks,
Atul
^ permalink raw reply
* RE: kernel startup
From: Kumar Gala @ 2006-02-10 23:46 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA207A@us-bv-m23.global.tektronix.net>
> > 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.
>
> 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
> Kernel. This is how redboot for xscale is structured or syslinux /lilo
> for x86.
This also happens with the boot wrapper that is in arch/{ppc,powerpc}/boot
>
> 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.
>
> 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.
I'm not sure what sub-arch we are talking about, but some do have the MMU
on.
- 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
* 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
* 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: 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
* 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: [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
* 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
* [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
* 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
* 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
* 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
* 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: 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: 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
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