Re: PCI Express error on MPC8641D-HPCN
Reinhard Weiss ha scritto: Hi, I try to get 2.6.25.6 running on Freescale's MPC8641D-HPCN (Processor is revision 1), but somehow the PCI express controller setup fails: PCI: Probing PCI hardware PCI: :00:00.0: class b20 doesn't match header type 01. Ignoring class. PCI: 0001:02:00.0: class b20 doesn't match header type 01. Ignoring class. PCI: Closing bogus Apple Firmware region 1 on bus 0x03 PCI: Closing bogus Apple Firmware region 2 on bus 0x03 PCI: Cannot allocate resource region 0 of device :01:1d.0, will remap PCI: Cannot allocate resource region 1 of device :01:1d.1, will remap PCI: Failed to allocate I/O resource #0:[EMAIL PROTECTED] for :01:1d.0 PCI: Failed to allocate I/O resource #1:[EMAIL PROTECTED] for :01:1d.1 PCI: not setting up bridge :00:00.0 for bus 1 PCI: Enabling device :00:00.0 (0106 -> 0107) PCI: not setting up bridge 0001:02:00.0 for bus 3 PCI: Enabling device 0001:02:00.0 (0106 -> 0107) - PCIe worked with 2.6.20.7 on this board, but unfortunately SMP support was not ready then. - on MPC8610-HPCD, PCIe works with 2.6.25.6, so I wonder what could be the difference. Any ideas? Best regards, Reinhard ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded I'm working with this board and I'm beginning to doubt that the pci express works well. You can see my problems in my previous posts in this mailing list sometimes ago. -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
On Wed, Jun 11, 2008 at 9:36 PM, Andrew Schmidt <[EMAIL PROTECTED]> wrote: > First off, thank you everyone for replying, I must admit I was only > expecting a few people to reply, but this is great. I certainly am > interested in any help I can get. I suspect my first task is to go over the > information given and then start to draft up a simple text file. I am more > experienced with the Xilinx PPC so initially the documentation may seems a > little biased, but if anyone with other areas of expertise (as is evident > from the emails received thus far) wants to help broaden it, that would be > great. I will get back to you shortly with my first "attempt." I'm currently working with a custom design on a Xilinx ML300 board to evaluate the realtime capabilities of the linux kernel with rt-patches. Since this is my first experience with embedded Linux I had the most trouble with understanding the coherences of the most general stuff like the difference between ppc and powerpc as well as the need for a device tree within powerpc but not ppc. Everything is documented very well for it's own, but I would appreciate to see a documentation that gives a bit more overview to the subject which is important for beginners. Well, I'm going to document my work from the system design using EDK and ISE through to creating a running linux from scratch based on this design. I'd like to support your documentation as much as I can. Regards, Jens Wirth ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
On Wednesday 11 June 2008 20:19:17 Scott Wood wrote:
> Please post patches to linuxppc-dev rather than linuxppc-embedded --
> you'll get a larger reviewing audience.
Ok, but I thought linuxppc-dev was for all non-embedded development only...
> PPC_CPM_NEW_BINDING is default y, and will be going away as an option as
> soon as arch/ppc does. In the meantime, instead of selecting it here,
> add FS_ENET_MPC5121_FEC to the depends list of PPC_CPM_NEW_BINDING -- or
> just remove the depends list altogether.
Good idea, done that.
> > +/*
> > + * Define the buffer descriptor structure.
> > + */
> > +typedef struct bufdesc {
> > + unsigned short cbd_sc; /* Control and status info */
> > + unsigned short cbd_datlen; /* Data length */
> > + unsigned long cbd_bufaddr;/* Buffer address */
> > +} cbd_t;
>
> This can be factored out into a common header -- along with most if not
> all of the flag defines.
Ok, I added the changes to ../fec.h inside an #if-#else.
> > +#define TX_ALIGN_WORKAROUND
> > +#ifdef TX_ALIGN_WORKAROUND
> > +static struct sk_buff *aligntxskb(struct net_device *dev, struct sk_buff
> > *skb) +{
> > + struct sk_buff *skbn;
> > + skbn = dev_alloc_skb(ENET_RX_FRSIZE+0x20);
> > + if (skbn)
> > + skb_align(skbn, 0x20);
> > +
> > + if (!skbn) {
> > + printk(KERN_WARNING DRV_MODULE_NAME
> > + ": %s Memory squeeze, dropping tx packet.\n",
> > + dev->name);
> > + dev_kfree_skb_any(skb);
> > + return NULL;
> > + }
> > +
> > + skb_copy_from_linear_data(skb, skbn->data, skb->len);
> > + skb_put(skbn, skb->len);
> > + dev_kfree_skb_any(skb);
> > + return skbn;
> > +}
> > +#else
> > +#define aligntxskb(skb) skb
> > +#endif
>
> Can we encode the required alignment for rx and tx in the device tree?
Hmmm... This actually is a silicon-bug workaround AFAIK.
I agree with you that this solution is not good, but I doubt resolving this
in the device-tree is much better. It will add run-time overhead just because
right now there are some buggy chips around. I think this could better
be a Kconfig option, so people can have faster kernels if they want later.
If you are concerned about multiplatform kernels, this shouldn't harm.
>[...]
> > + printk("<1> %s: %s (%d)\n",__FILE__,__FUNCTION__,__LINE__);
>
> Please use the KERN_ prefixes rather than hardcoding the number, and put
> spaces after commas. Of course, if this is to be here at all, this
> should be dev_dbg() rather than KERN_ALERT.
Ooops. This shouldn't be here. Removing it.
> > -#define __cbd_out32(addr, x) out_be32(addr, x)
> > -#define __cbd_out16(addr, x) out_be16(addr, x)
> > -#define __cbd_in32(addr) in_be32(addr)
> > -#define __cbd_in16(addr) in_be16(addr)
> > +#define __cbd_out32(addr, x) out_be32((volatile void __iomem *)addr,
> > x)
> > +#define __cbd_out16(addr, x) out_be16((volatile void __iomem *)addr,
> > x)
> > +#define __cbd_in32(addr) in_be32((volatile void __iomem *)addr)
> > +#define __cbd_in16(addr) in_be16((volatile void __iomem *)addr)
>
> NACK, please don't remove type checking.
Ok, but given the macro's further down, I'll have to cast there...
#define CBDR_BUFADDR(_cbd) __cbd_in32((volatile void __iomem
*)&(_cbd)->cbd_bufaddr)
> > +#ifndef CONFIG_FS_ENET_MPC5121_FEC
> > FW(fecp, r_hash, PKT_MAXBUF_SIZE);
> > +#endif
> >
> > /* get physical address */
> > rx_bd_base_phys = fep->ring_mem_addr;
> > @@ -320,10 +325,17 @@ static void restart(struct net_device *dev)
> >
> > fs_init_bds(dev);
> >
> > +#ifndef CONFIG_FS_ENET_MPC5121_FEC
> > /*
> > * Enable big endian and don't care about SDMA FC.
> > */
> > FW(fecp, fun_code, 0x7800);
> > +#else
> > + /*
> > +* Set DATA_BO and DESC_BO and leave the rest unchanged
> > +*/
> > + FS(fecp, dma_control, 0xc000);
> > +#endif
I have tried, but it is almost impossible, since both FEC types use a struct
named "fec_t" which very different betwen both types. That means that the code
would have enormous amounts of "if" statements all over.
Any suggestion?
Best regards,
--
David Jander
Protonic Holland.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
Made MPC5121_ADS board support generic:
Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported
boards.
For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use
the corresponding device-tree.
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prtlvt.dts | 272
arch/powerpc/platforms/512x/Kconfig| 14 +-
arch/powerpc/platforms/512x/Makefile |2 +-
.../512x/{mpc5121_ads.c => mpc5121_generic.c} | 38 ++-
4 files changed, 307 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
rename arch/powerpc/platforms/512x/{mpc5121_ads.c => mpc5121_generic.c} (73%)
diff --git a/arch/powerpc/boot/dts/prtlvt.dts b/arch/powerpc/boot/dts/prtlvt.dts
new file mode 100644
index 000..a011c8c
--- /dev/null
+++ b/arch/powerpc/boot/dts/prtlvt.dts
@@ -0,0 +1,272 @@
+/*
+ * Device tree source for PRTLVT based boards, base on:
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2008 Protonic Holland
+ *
+ * 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.
+ */
+
+ /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
dts/prtlvt.dts */
+
+/dts-v1/;
+
+/ {
+ model = "prtlvt";
+ compatible = "prt,prtlvt";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <0x20>; // 32 bytes
+ i-cache-line-size = <0x20>; // 32 bytes
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <5000>;// 50 MHz (csb/4)
+ bus-frequency = <2>;// 200 MHz csb bus
+ clock-frequency = <4>; // 400 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "amd,s29gl256n", "cfi-flash";
+ reg = <0xfe00 0x0200>;
+ bank-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "rootfs";
+ reg = <0x 0x0180>;
+ };
+ [EMAIL PROTECTED] {
+ label ="config0";
+ reg = <0x0180 0x0020>;
+ };
+ [EMAIL PROTECTED] {
+ label ="config1";
+ reg = <0x01a0 0x0020>;
+ };
+ [EMAIL PROTECTED] {
+ label ="kernel";
+ reg = <0x01c0 0x002e>;
+ };
+ [EMAIL PROTECTED] {
+ label ="devicetree";
+ reg = <0x01ee 0x0002>;
+ };
+ [EMAIL PROTECTED] {
+ label ="uboot";
+ reg = <0x01f0 0x0010>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-immr", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ ranges = <0x0 0x8000 0x40>;
+ reg = <0x8000 0x40>;
+ bus-frequency = <6600>; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell =
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: [EMAIL PROTECTED] {
+ compatible = "fsl,mpc5121-ipic", "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0xc00 0x100>;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ // PSC0 serial port aka ttyPSC0
+ [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "fsl,mpc5121-psc-uart";
+ port-number = <0>;
+ cell-index = <0>;
+ reg = <0x11000
[PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +-
drivers/net/fec.h | 43
drivers/net/fs_enet/Kconfig| 22 +-
drivers/net/fs_enet/fs_enet-main.c | 76 ++--
drivers/net/fs_enet/fs_enet.h | 17 +---
drivers/net/fs_enet/mac-fec.c | 22 +-
drivers/net/fs_enet/mii-fec.c | 10 -
7 files changed, 167 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..a96937f 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -288,7 +288,7 @@ config CPM2
config PPC_CPM_NEW_BINDING
bool
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
default y
config AXON_RAM
diff --git a/drivers/net/fec.h b/drivers/net/fec.h
index 292719d..5c9fe34 100644
--- a/drivers/net/fec.h
+++ b/drivers/net/fec.h
@@ -59,6 +59,7 @@ typedef struct fec {
} fec_t;
#else
+#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
/*
* Define device register set address map.
@@ -97,6 +98,48 @@ typedef struct fec {
unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
} fec_t;
+#else /* CONFIG_FS_ENET_MPC5121_FEC */
+
+typedef struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl;/* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl;/* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd;/* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high;/* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high;/* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound;/* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start;/* Receive descriptor ring */
+ u32 fec_x_des_start;/* Transmit descriptor ring */
+ u32 fec_r_buff_size;/* Maximum receive buff size */
+ u32 fec_dma_control;/* DMA Endian and other ctrl */
+} fec_t;
+
+#endif /* CONFIG_FS_ENET_MPC5121_FEC */
#endif /* CONFIG_M5272 */
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 562ea68..5e2520b 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -1,9 +1,23 @@
config FS_ENET
tristate "Freescale Ethernet Driver"
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
select MII
select PHYLIB
+config FS_ENET_MPC5121_FEC
+ bool "Freescale MPC512x FEC driver"
+ depends on PPC_MPC512x
+ select FS_ENET
+ select FS_ENET_HAS_FEC
+
+config FS_ENET_TX_ALIGN_WORKAROUND
+ bool "MPC5121 FEC driver TX alignment workaround"
+ depends on FS_ENET_MPC5121_FEC
+ help
+ Workaround for a problem with early Freescale MPC5121 chips.
+ If unsure say 'y'
+ default y
+
config FS_ENET_HAS_SCC
bool "Chip has an SCC usable for ethernet"
depends on FS_ENET && (CPM1 || CPM2)
@@ -16,13 +30,15 @@ config FS_ENET_HAS_FCC
config FS_ENET_HAS_FEC
bool "Chip has an FEC usable for ethernet"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
select FS_ENET_MDIO_FEC
default y
+
config FS_ENET_MDIO_FEC
tristate "MDIO driver for FEC"
- depends on FS_ENET && CPM1
+ depends on FS_ENET && (CPM1 || FS_ENET_MPC5121_FEC)
+
config FS_ENET_MDIO_FCC
tristate "MDIO driver for FCC"
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 31c9693..54f0079 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -592,6 +592,31 @@ void fs_cleanup_bds(struc
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
On Jun 12, 2008, at 6:45 AM, David Jander wrote:
Your commit message isn't exactly helpful as most people dont know
what LTIB is and its not terribly relevant. It just seems like you
are adding support for the FEC on MPC5121 and this point.
Signed-off-by: David Jander <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig |2 +-
drivers/net/fec.h | 43
drivers/net/fs_enet/Kconfig| 22 +-
drivers/net/fs_enet/fs_enet-main.c | 76 +++
+++--
drivers/net/fs_enet/fs_enet.h | 17 +---
drivers/net/fs_enet/mac-fec.c | 22 +-
drivers/net/fs_enet/mii-fec.c | 10 -
7 files changed, 167 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/
Kconfig
index 87454c5..a96937f 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -288,7 +288,7 @@ config CPM2
config PPC_CPM_NEW_BINDING
bool
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
default y
config AXON_RAM
diff --git a/drivers/net/fec.h b/drivers/net/fec.h
index 292719d..5c9fe34 100644
--- a/drivers/net/fec.h
+++ b/drivers/net/fec.h
@@ -59,6 +59,7 @@ typedef struct fec {
} fec_t;
#else
+#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
/*
* Define device register set address map.
@@ -97,6 +98,48 @@ typedef struct fec {
unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
} fec_t;
+#else /* CONFIG_FS_ENET_MPC5121_FEC */
+
+typedef struct fec {
+ u32 fec_reserved0;
+ u32 fec_ievent; /* Interrupt event reg */
+ u32 fec_imask; /* Interrupt mask reg */
+ u32 fec_reserved1;
+ u32 fec_r_des_active; /* Receive descriptor reg */
+ u32 fec_x_des_active; /* Transmit descriptor reg */
+ u32 fec_reserved2[3];
+ u32 fec_ecntrl; /* Ethernet control reg */
+ u32 fec_reserved3[6];
+ u32 fec_mii_data; /* MII manage frame reg */
+ u32 fec_mii_speed; /* MII speed control reg */
+ u32 fec_reserved4[7];
+ u32 fec_mib_ctrlstat; /* MIB control/status reg */
+ u32 fec_reserved5[7];
+ u32 fec_r_cntrl;/* Receive control reg */
+ u32 fec_reserved6[15];
+ u32 fec_x_cntrl;/* Transmit Control reg */
+ u32 fec_reserved7[7];
+ u32 fec_addr_low; /* Low 32bits MAC address */
+ u32 fec_addr_high; /* High 16bits MAC address */
+ u32 fec_opd;/* Opcode + Pause duration */
+ u32 fec_reserved8[10];
+ u32 fec_hash_table_high;/* High 32bits hash table */
+ u32 fec_hash_table_low; /* Low 32bits hash table */
+ u32 fec_grp_hash_table_high;/* High 32bits hash table */
+ u32 fec_grp_hash_table_low; /* Low 32bits hash table */
+ u32 fec_reserved9[7];
+ u32 fec_x_wmrk; /* FIFO transmit water mark */
+ u32 fec_reserved10;
+ u32 fec_r_bound;/* FIFO receive bound reg */
+ u32 fec_r_fstart; /* FIFO receive start reg */
+ u32 fec_reserved11[11];
+ u32 fec_r_des_start;/* Receive descriptor ring */
+ u32 fec_x_des_start;/* Transmit descriptor ring */
+ u32 fec_r_buff_size;/* Maximum receive buff size */
+ u32 fec_dma_control;/* DMA Endian and other ctrl */
+} fec_t;
+
+#endif /* CONFIG_FS_ENET_MPC5121_FEC */
#endif /* CONFIG_M5272 */
I'm not exactly clear as to why this was done this way but this not
acceptable as it means we can't build a multiplatform kernel that
needs this driver.
I'm also not clear to me if the MPC5121 FEC is really the same device
or close to it that it should be sharing this driver or have its own.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
On Thu, Jun 12, 2008 at 08:54:27AM +0200, David Jander wrote:
> On Wednesday 11 June 2008 19:58:32 Scott Wood wrote:
> > > + //[EMAIL PROTECTED] {
> > > + // compatible = "mpc512x-axe";
> > > + // reg = <2000 100>;
> > > + // interrupts = <2a 8>;
> > > + // interrupt-parent = < &ipic >;
> > > + //};
> >
> > Why is this here, but commented out?
>
> Hmm, I know we are going to use it, but there are no drivers still...
> I'll leave it out, and add it again later when axe-support has arrived.
Just uncomment it -- there's no harm in a device node for which Linux has
no driver, and it avoids problems with old device trees being used once a
driver is added.
Compatible should have "fsl," prepended, though, and ideally a concrete
chip should be represented rather than "512x".
> > > + [EMAIL PROTECTED] {
> > > + compatible = "fsl,mpc5121-dma2";
> >
> > Is this DMA controller compatible with drivers/dma/fsldma.c? If so,
> > follow the established binding.
>
> No, it's not compatible with any other dma controller AFAIK. It special for
> this chip. John Rigby is writing the driver for it right now.
OK.
> Btw, is it ok I just re-submit the fixed patches (with cc to linuxppc-dev)?
Yes.
-Scott
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
On Thu, Jun 12, 2008 at 12:33:12PM +0200, David Jander wrote: > On Wednesday 11 June 2008 20:19:17 Scott Wood wrote: > > Please post patches to linuxppc-dev rather than linuxppc-embedded -- > > you'll get a larger reviewing audience. > > Ok, but I thought linuxppc-dev was for all non-embedded development only... No, it's for all Linux/PowerPC development. linuxppc-embedded is more for user questions. > > Can we encode the required alignment for rx and tx in the device tree? > > Hmmm... This actually is a silicon-bug workaround AFAIK. > I agree with you that this solution is not good, but I doubt resolving this > in the device-tree is much better. It will add run-time overhead just because > right now there are some buggy chips around. I think this could better > be a Kconfig option, so people can have faster kernels if they want later. > If you are concerned about multiplatform kernels, this shouldn't harm. OK. > > > -#define __cbd_out32(addr, x) out_be32(addr, x) > > > -#define __cbd_out16(addr, x) out_be16(addr, x) > > > -#define __cbd_in32(addr) in_be32(addr) > > > -#define __cbd_in16(addr) in_be16(addr) > > > +#define __cbd_out32(addr, x) out_be32((volatile void __iomem *)addr, > > > x) > > > +#define __cbd_out16(addr, x) out_be16((volatile void __iomem *)addr, > > > x) > > > +#define __cbd_in32(addr) in_be32((volatile void __iomem *)addr) > > > +#define __cbd_in16(addr) in_be16((volatile void __iomem *)addr) > > > > NACK, please don't remove type checking. > > Ok, but given the macro's further down, I'll have to cast there... > > #define CBDR_BUFADDR(_cbd) __cbd_in32((volatile void __iomem > *)&(_cbd)->cbd_bufaddr) Why? cbd should already have an __iomem annotation, and the volatile is unnecessary. > > > +#ifndef CONFIG_FS_ENET_MPC5121_FEC > > > FW(fecp, r_hash, PKT_MAXBUF_SIZE); > > > +#endif > > > > > > /* get physical address */ > > > rx_bd_base_phys = fep->ring_mem_addr; > > > @@ -320,10 +325,17 @@ static void restart(struct net_device *dev) > > > > > > fs_init_bds(dev); > > > > > > +#ifndef CONFIG_FS_ENET_MPC5121_FEC > > > /* > > >* Enable big endian and don't care about SDMA FC. > > >*/ > > > FW(fecp, fun_code, 0x7800); > > > +#else > > > + /* > > > + * Set DATA_BO and DESC_BO and leave the rest unchanged > > > + */ > > > + FS(fecp, dma_control, 0xc000); > > > +#endif > > I have tried, but it is almost impossible, since both FEC types use a struct > named "fec_t" which very different betwen both types. That means that the code > would have enormous amounts of "if" statements all over. > Any suggestion? OK, I missed that this was FEC-specific code and not general fs-enet. 8xx/512x multiplatform is already unsupported due to core differences, but make sure that 82xx/512x multiplatform doesn't get broken. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
On Thu, Jun 12, 2008 at 6:12 AM, Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Jun 12, 2008, at 6:45 AM, David Jander wrote:
>
> Your commit message isn't exactly helpful as most people dont know what LTIB
> is and its not terribly relevant. It just seems like you are adding support
> for the FEC on MPC5121 and this point.
Agreed. Also, you need to CC: the netdev mailing list for network drivers.
>> Signed-off-by: David Jander <[EMAIL PROTECTED]>
>> ---
>> arch/powerpc/platforms/Kconfig |2 +-
>> drivers/net/fec.h | 43
>> drivers/net/fs_enet/Kconfig| 22 +-
>> drivers/net/fs_enet/fs_enet-main.c | 76
>> ++--
>> drivers/net/fs_enet/fs_enet.h | 17 +---
>> drivers/net/fs_enet/mac-fec.c | 22 +-
>> drivers/net/fs_enet/mii-fec.c | 10 -
>> 7 files changed, 167 insertions(+), 25 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/Kconfig
>> b/arch/powerpc/platforms/Kconfig
>> index 87454c5..a96937f 100644
>> --- a/arch/powerpc/platforms/Kconfig
>> +++ b/arch/powerpc/platforms/Kconfig
>> @@ -288,7 +288,7 @@ config CPM2
>>
>> config PPC_CPM_NEW_BINDING
>>bool
>> - depends on CPM1 || CPM2
>> + depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
>>default y
>>
>> config AXON_RAM
>> diff --git a/drivers/net/fec.h b/drivers/net/fec.h
>> index 292719d..5c9fe34 100644
>> --- a/drivers/net/fec.h
>> +++ b/drivers/net/fec.h
>> @@ -59,6 +59,7 @@ typedef struct fec {
>> } fec_t;
>>
>> #else
>> +#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
>>
>> /*
>> * Define device register set address map.
>> @@ -97,6 +98,48 @@ typedef struct fec {
>>unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
>> } fec_t;
>>
>> +#else /* CONFIG_FS_ENET_MPC5121_FEC */
>> +
>> +typedef struct fec {
>> + u32 fec_reserved0;
>> + u32 fec_ievent; /* Interrupt event reg */
>> + u32 fec_imask; /* Interrupt mask reg */
>> + u32 fec_reserved1;
>> + u32 fec_r_des_active; /* Receive descriptor reg */
>> + u32 fec_x_des_active; /* Transmit descriptor reg */
>> + u32 fec_reserved2[3];
>> + u32 fec_ecntrl; /* Ethernet control reg */
>> + u32 fec_reserved3[6];
>> + u32 fec_mii_data; /* MII manage frame reg */
>> + u32 fec_mii_speed; /* MII speed control reg */
>> + u32 fec_reserved4[7];
>> + u32 fec_mib_ctrlstat; /* MIB control/status reg */
>> + u32 fec_reserved5[7];
>> + u32 fec_r_cntrl;/* Receive control reg */
>> + u32 fec_reserved6[15];
>> + u32 fec_x_cntrl;/* Transmit Control reg */
>> + u32 fec_reserved7[7];
>> + u32 fec_addr_low; /* Low 32bits MAC address */
>> + u32 fec_addr_high; /* High 16bits MAC address */
>> + u32 fec_opd;/* Opcode + Pause duration */
>> + u32 fec_reserved8[10];
>> + u32 fec_hash_table_high;/* High 32bits hash table */
>> + u32 fec_hash_table_low; /* Low 32bits hash table */
>> + u32 fec_grp_hash_table_high;/* High 32bits hash table */
>> + u32 fec_grp_hash_table_low; /* Low 32bits hash table */
>> + u32 fec_reserved9[7];
>> + u32 fec_x_wmrk; /* FIFO transmit water mark */
>> + u32 fec_reserved10;
>> + u32 fec_r_bound;/* FIFO receive bound reg */
>> + u32 fec_r_fstart; /* FIFO receive start reg */
>> + u32 fec_reserved11[11];
>> + u32 fec_r_des_start;/* Receive descriptor ring */
>> + u32 fec_x_des_start;/* Transmit descriptor ring */
>> + u32 fec_r_buff_size;/* Maximum receive buff size */
>> + u32 fec_dma_control;/* DMA Endian and other ctrl */
>> +} fec_t;
>> +
>> +#endif /* CONFIG_FS_ENET_MPC5121_FEC */
>> #endif /* CONFIG_M5272 */
>
> I'm not exactly clear as to why this was done this way but this not
> acceptable as it means we can't build a multiplatform kernel that needs this
> driver.
>
> I'm also not clear to me if the MPC5121 FEC is really the same device or
> close to it that it should be sharing this driver or have its own.
Indeed. If it is not easy to isolate the differences for runtime
binding then it may be best to just clone the driver as a starting
point and make the 5121 specific changes.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
On Thu, Jun 12, 2008 at 5:45 AM, David Jander <[EMAIL PROTECTED]> wrote: > > > /* write */ > -#define CBDW_SC(_cbd, _sc) __cbd_out16(&(_cbd)->cbd_sc, (_sc)) > -#define CBDW_DATLEN(_cbd, _datlen) __cbd_out16(&(_cbd)->cbd_datlen, > (_datlen)) > -#define CBDW_BUFADDR(_cbd, _bufaddr) __cbd_out32(&(_cbd)->cbd_bufaddr, > (_bufaddr)) > +#define CBDW_SC(_cbd, _sc) __cbd_out16((volatile void __iomem > *)&(_cbd)->cbd_sc, (_sc)) > +#define CBDW_DATLEN(_cbd, _datlen) __cbd_out16((volatile void __iomem > *)&(_cbd)->cbd_datlen, (_datlen)) > +#define CBDW_BUFADDR(_cbd, _bufaddr) __cbd_out32((volatile void __iomem > *)&(_cbd)->cbd_bufaddr, (_bufaddr)) > > /* read */ > -#define CBDR_SC(_cbd) __cbd_in16(&(_cbd)->cbd_sc) > -#define CBDR_DATLEN(_cbd) __cbd_in16(&(_cbd)->cbd_datlen) > -#define CBDR_BUFADDR(_cbd) __cbd_in32(&(_cbd)->cbd_bufaddr) > +#define CBDR_SC(_cbd) __cbd_in16((volatile void __iomem > *)&(_cbd)->cbd_sc) > +#define CBDR_DATLEN(_cbd) __cbd_in16((volatile void __iomem > *)&(_cbd)->cbd_datlen) > +#define CBDR_BUFADDR(_cbd) __cbd_in32((volatile void __iomem > *)&(_cbd)->cbd_bufaddr) Another comment: This really doesn't look right. The _cbd pointer passed in should already be tagged with __iomem. Trying to fix it here is a band-aid and unsafe. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB
On Thu, Jun 12, 2008 at 7:29 AM, Scott Wood <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 12:33:12PM +0200, David Jander wrote: >> > > +#ifndef CONFIG_FS_ENET_MPC5121_FEC >> > > /* >> > >* Enable big endian and don't care about SDMA FC. >> > >*/ >> > > FW(fecp, fun_code, 0x7800); >> > > +#else >> > > + /* >> > > + * Set DATA_BO and DESC_BO and leave the rest unchanged >> > > + */ >> > > + FS(fecp, dma_control, 0xc000); >> > > +#endif >> >> I have tried, but it is almost impossible, since both FEC types use a struct >> named "fec_t" which very different betwen both types. That means that the >> code >> would have enormous amounts of "if" statements all over. >> Any suggestion? > > OK, I missed that this was FEC-specific code and not general fs-enet. > > 8xx/512x multiplatform is already unsupported due to core differences, > but make sure that 82xx/512x multiplatform doesn't get broken. Yeah, but the amount of #ifdefs required in this drivers adds a maintenance burden. I think I'd rather see it either refactored or cloned. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question on PowerPC's JTAG instruction
Hi John, On Friday 30 May 2008 03:14, John Zhou wrote: > Hi, > > We want to design a tool to speed up our hardware diagnostics via JTAG > port. > > So we have question to ask for your help: > > 1. How do we access PowerPC's internal GPRs and SPRs etc. via JTAG > instruction? > > We'v gone through IEEE.1149.1. There are no standard JTAG instruction to > access CPU's data bus, including internal or external data bus. Do we must > need private JTAG instruction to access CPU's internal resource? That's right. > if it is, could you share the documents with us? No public documentation is available. You will need to sign an NDA with Freescale (and probably pay ). I had to design a test bench to program the flash memory on our MPC8248-based hardware, and ended up using JTAG to bitbang the bus signals. Programming the processor through JTAG private instructions would have been faster. > 2. For 'BSDL' usage, you know, we have many components on one board and much > more signals are processed specically. So, how to integrate PowerPC's BSDL > with other components' 'BSDL'? Could you give us any hints on it? or any > document is also welcome! > > Your any help is appreciated! Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpspQNYg8rH9.pgp Description: PGP signature ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
Looking even better. Just a few more comments. I'll probably be able
to pick up the next one for inclusion in 2.6.27.
On Thu, Jun 12, 2008 at 5:44 AM, David Jander <[EMAIL PROTECTED]> wrote:
> Made MPC5121_ADS board support generic:
> Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported
> boards.
> For both MPC5121 ADS or PRTLVT support, just select "MPC5121_GENERIC" and use
> the corresponding device-tree.
>
> Signed-off-by: David Jander <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/prtlvt.dts | 272
>
> arch/powerpc/platforms/512x/Kconfig| 14 +-
> arch/powerpc/platforms/512x/Makefile |2 +-
> .../512x/{mpc5121_ads.c => mpc5121_generic.c} | 38 ++-
> 4 files changed, 307 insertions(+), 19 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
> rename arch/powerpc/platforms/512x/{mpc5121_ads.c => mpc5121_generic.c} (73%)
>
> diff --git a/arch/powerpc/boot/dts/prtlvt.dts
> b/arch/powerpc/boot/dts/prtlvt.dts
> new file mode 100644
> index 000..a011c8c
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/prtlvt.dts
> @@ -0,0 +1,272 @@
> +/*
> + * Device tree source for PRTLVT based boards, base on:
> + * MPC5121E MDS Device Tree Source
> + *
> + * Copyright 2007 Freescale Semiconductor Inc.
> + * Copyright 2008 Protonic Holland
> + *
> + * 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.
> + */
> +
> + /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
> dts/prtlvt.dts */
> +
> +/dts-v1/;
> +
> +/ {
> + model = "prtlvt";
> + compatible = "prt,prtlvt";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <0x20>; // 32 bytes
> + i-cache-line-size = <0x20>; // 32 bytes
> + d-cache-size = <0x8000>;// L1, 32K
> + i-cache-size = <0x8000>;// L1, 32K
> + timebase-frequency = <5000>;// 50 MHz (csb/4)
> + bus-frequency = <2>;// 200 MHz csb bus
> + clock-frequency = <4>; // 400 MHz ppc core
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x1000>; // 256MB at 0
> + };
> +
> + [EMAIL PROTECTED] {
There should probably be a node to describe the local bus that the
flash is attached to and this flash node should be a child of the bus.
> + compatible = "amd,s29gl256n", "cfi-flash";
> + reg = <0xfe00 0x0200>;
> + bank-width = <2>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + [EMAIL PROTECTED] {
> + label = "rootfs";
> + reg = <0x 0x0180>;
> + };
> + [EMAIL PROTECTED] {
> + label ="config0";
> + reg = <0x0180 0x0020>;
> + };
> + [EMAIL PROTECTED] {
> + label ="config1";
> + reg = <0x01a0 0x0020>;
> + };
> + [EMAIL PROTECTED] {
> + label ="kernel";
> + reg = <0x01c0 0x002e>;
> + };
> + [EMAIL PROTECTED] {
> + label ="devicetree";
> + reg = <0x01ee 0x0002>;
> + };
> + [EMAIL PROTECTED] {
> + label ="uboot";
> + reg = <0x01f0 0x0010>;
> + };
> + };
I'm still not all that keen on encoding the partition information into
the 'stock' device tree included with the kernel as it is more of a
configuration description that is more properly supplied by the
bootloader. This is a debate that has been going back and forth over
the last few months, so there isn't a solid concensus yet, but my
preference is to remove or comment out the partition information for
now.
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc5121-i2c-ctrl";
> + reg = <0x1760 0x8>;
> + };
> +
> + [EMAIL PROTECTED] {
(nitpick) There is a recommended practice that says node names should
be generic as much as possible, so I think this should probably be
[EMAIL PROTECTED] The compatib
Question on assigning interrupts in a dts
Hi All,
I'm building a dts for a custom 8360 based board. I'm looking at
the mpc8360_mds and mpc8360_rdk dts files, trying to figure out how the
UCCs (and all peripherals in general) got the values of their
"interrupts" properties chosen. And is there any relationship between
the choice of interrupts for ucc1 and the qeic controller.. Can anyone
point me some docs for this?
enet0: [EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <1>;
reg = <0x2000 0x200>;
interrupts = <32>;
..
};
enet1: [EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <2>;
reg = <0x3000 0x200>;
interrupts = <33>;
..
};
qeic: [EMAIL PROTECTED] {
#address-cells = <0>;
#interrupt-cells = <1>;
compatible = "fsl,qe-ic";
interrupt-controller;
reg = <0x80 0x80>;
big-endian;
interrupts = <32 8 33 8>;
interrupt-parent = <&ipic>;
};
Thanks
--
Michael Galea
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
Hello,
I am posting these patches mainly to test that my Linux email client can
handle preformat properly (without breaking the lines), but it may be of
use to anyone using 2.6.24 or 2.6.25 kernel with RT-Preemption on a 4xx
processor that has a UIC (just so I don't clutter the list with a
useless test post). This is all that was left to carry forward from
some much larger patches I received a while back for use with 2.6.23.
Use this patch with kernel 2.6.24
Index: linux-2.6.24.4/arch/powerpc/sysdev/uic.c
===
--- linux-2.6.24.4.orig/arch/powerpc/sysdev/uic.c
+++ linux-2.6.24.4/arch/powerpc/sysdev/uic.c
@@ -49,7 +49,7 @@ struct uic {
int index;
int dcrbase;
- spinlock_t lock;
+ raw_spinlock_t lock;
/* The remapper for this UIC */
struct irq_host *irqhost;
@@ -60,14 +60,19 @@ struct uic {
static void uic_unmask_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
- u32 er;
+ u32 er, sr;
+ sr = 1 << (31-src);
spin_lock_irqsave(&uic->lock, flags);
+ /* ack level-triggered interrupts here */
+ if (desc->status & IRQ_LEVEL)
+ mtdcr(uic->dcrbase + UIC_SR, sr);
er = mfdcr(uic->dcrbase + UIC_ER);
- er |= 1 << (31 - src);
+ er |= sr;
mtdcr(uic->dcrbase + UIC_ER, er);
spin_unlock_irqrestore(&uic->lock, flags);
}
@@ -99,6 +104,7 @@ static void uic_ack_irq(unsigned int vir
static void uic_mask_ack_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
@@ -109,7 +115,16 @@ static void uic_mask_ack_irq(unsigned in
er = mfdcr(uic->dcrbase + UIC_ER);
er &= ~sr;
mtdcr(uic->dcrbase + UIC_ER, er);
- mtdcr(uic->dcrbase + UIC_SR, sr);
+ /* On the UIC, acking (i.e. clearing the SR bit)
+* a level irq will have no effect if the interrupt
+* is still asserted by the device, even if
+* the interrupt is already masked. Therefore
+* we only ack the egde interrupts here, while
+* level interrupts are ack'ed after the actual
+* isr call in the uic_unmask_irq()
+*/
+ if (!(desc->status & IRQ_LEVEL))
+ mtdcr(uic->dcrbase + UIC_SR, sr);
spin_unlock_irqrestore(&uic->lock, flags);
}
@@ -173,6 +188,7 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
+#if 0
/**
* handle_uic_irq - irq flow handler for UIC
* @irq: the interrupt number
@@ -230,6 +246,7 @@ void fastcall handle_uic_irq(unsigned in
out_unlock:
spin_unlock(&desc->lock);
}
+#endif
static int uic_host_map(struct irq_host *h, unsigned int virq,
irq_hw_number_t hw)
@@ -239,7 +256,7 @@ static int uic_host_map(struct irq_host
set_irq_chip_data(virq, uic);
/* Despite the name, handle_level_irq() works for both level
* and edge irqs on UIC. FIXME: check this is correct */
- set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
+ set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
/* Set default irq type */
set_irq_type(virq, IRQ_TYPE_NONE);
Use this patch if using kernel 2.6.25
--- linux-2.6.25.4/arch/powerpc/sysdev/uic.c.theorig2008-05-15
08:00:12.0 -0700
+++ linux-2.6.25.4/arch/powerpc/sysdev/uic.c2008-05-20 12:37:39.0
-0700
@@ -49,7 +49,7 @@ struct uic {
int index;
int dcrbase;
- spinlock_t lock;
+ raw_spinlock_t lock;
/* The remapper for this UIC */
struct irq_host *irqhost;
Apply the selected patch after applying the RT-Preemption patch to your
kernel.
In terms of upstream projects - the 2.6.25 patch should eventually make
its way up into the RT preemption project patches (if not done already
for next release) but should not go to kernel.org since I don't know how
it would affect the kernel without RT-Preemption. Why the change above
didn't make it with the rest of the changes, I don't know - perhaps the
kernel oops it solves affected only a narrow range of processors (e.g.
PPC405EP).
--
Regards,
Darcy
--
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: PPC to PowerPC Migration
On Wed, Jun 11, 2008 at 1:36 PM, Andrew Schmidt <[EMAIL PROTECTED]> wrote: > First off, thank you everyone for replying, I must admit I was only > expecting a few people to reply, but this is great. I certainly am > interested in any help I can get. I suspect my first task is to go over the > information given and then start to draft up a simple text file. I am more > experienced with the Xilinx PPC so initially the documentation may seems a > little biased, but if anyone with other areas of expertise (as is evident > from the emails received thus far) wants to help broaden it, that would be > great. I will get back to you shortly with my first "attempt." Documentation/powerpc/booting-without-of.txt is the place to start adding additional documentation. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Reserving small amounts of memory with mem= (MPC85xx, 2.6.15 arch/ppc)
Hi, I ran into problems reserving small amounts of memory using command line argument 'mem'. Limiting a MPC8540 with 512MB physical available memory down to 256MB has been successfully done using U-Boot: => setenv bootargs console=ttyS0,115200 mem=256M => setenv initrd_high 1000 => bootm 0x0210 ## Booting image at 0210 ... Image Name: Linux 2.6.15 Image Type: PowerPC Linux Multi-File Image (gzip compressed) Data Size:6965022 Bytes = 6.6 MB Load Address: Entry Point: Contents: Image 0: 1099550 Bytes = 1 MB Image 1: 5865458 Bytes = 5.6 MB Verifying Checksum ... OK Uncompressing Multi-File Image ... OK [...] Loading Ramdisk to 0fa68000, end 0ff2 ... OK Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb Linux version 2.6.15 ([EMAIL PROTECTED]) (gcc version 3.4.3) #21 PREEMPT Fri Nov 30 16:47:32 CET 2007 [...] [EMAIL PROTECTED]:/# cat /proc/meminfo MemTotal: 257272 kB MemFree:226332 kB [...] When a larger size for 'mem' (say 508M for reserving 4M) and appropriate 'initrd_high' is used, U-Boot is still able to load the ramdisk to its correct place in RAM. However Linux seems to not accept that memory region and removes the memory using mem_pieces_remove(), which leads to a crash since it cannot access area used for the ramdisk(?). In that case output of "residual" for CAM mapping shows a value != 0. My assumption is that these CAM mappings cannot be used for memory portions less than a certain size. I need to dig into that, please correct me if I'm wrong. Linux 2.6.15 build for arch/ppc on custom MPC8540 board (Linux BSP similar to MPC8540ads). U-Boot 1.2.0. Thanks for any suggestions. Florian ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Question on assigning interrupts in a dts
Michael,
I'm familiar with the powerpc 5200 scheme. Under Documents there is a
mpc52xx-device-tree-bindings.txt. In the section titled, "Interrupt
mapping" there is a description of the interrupt values in the dts.
I'm not too familiar with the 8360. The 5200 has different "categories"
(main, crit, perph, and SDMA) of interupts and then numbers within each
category. To support this the 52xx DTS uses a triplet to represent
interrupts in the dts: .
Taking a quick look at the MPC8360E PowerQUICC II reference manual (Rev
2) I can at least map some of the fields in mpc836x_mds.dts to valuel in
the datasheet (The IPIC looks a little flat compared to the pic in the
5200 so it looks like this is why you don't need the triplet format).
For example, the i2c on-chip peripherals in the dts ([EMAIL PROTECTED] and
[EMAIL PROTECTED]) specify interrupts= and , respectively. The 'e' and
the 'f' agree with the interrupt ID numbers associated with these I2C
peripherals on page 8-10 of the reference manual.
The '8' could be some sort of interrupt 'level' spec for the devices
that rely on the ipic (note that most of the devices that rely on ipic
as the interrupt-parent specify the '8' after the interrupt ID number).
So, I think we're close to understanding how to specify interrupts under
ipic (so long as you figure out what 8 means), but I don't think it
directly addresses your question. As for your device snippet below,
those look like devices on the QUICC Engine port. In the Reference
manual I do see this at ipic interrupt ID 32 and 33 which agrees.
It looks like the qeic is an interrupt controller beneath the ipic
controller: below you specify qeic as an interrupt controller and assign
the ipic interrupt ids to it (again, I see 32 and 33 in the reference
manual).
In your dts, do you have devices that specify interrupt-parent=<&qeic>?
I see a few of them in mpc836x_mds.dts. In turn, these devices indicate
only a single value for "interrupts" (interrupts=<21>, for example).
I think this must be the bit position for whatever QUICC interrupt port
is associated with the device. Look around in section 8.5 of the
reference manual and see if you can make sense of it.
I decoded the device tree syntax by finding drivers for devices in the
tree, refering to the reference manual(s), and identifying how the
device tree mapped to the chip. Although I'm not well versed on the
8360, just the few minutes I spent above got me pretty close to making
sense of the syntax below. Dig in this direction and it will become
clear.
-Mike
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Michael Galea
Sent: Thursday, June 12, 2008 9:12 AM
To: linuxppc-embedded@ozlabs.org
Subject: Question on assigning interrupts in a dts
Hi All,
I'm building a dts for a custom 8360 based board. I'm looking at
the mpc8360_mds and mpc8360_rdk dts files, trying to figure out how the
UCCs (and all peripherals in general) got the values of their
"interrupts" properties chosen. And is there any relationship between
the choice of interrupts for ucc1 and the qeic controller.. Can anyone
point me some docs for this?
enet0: [EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <1>;
reg = <0x2000 0x200>;
interrupts = <32>;
..
};
enet1: [EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <2>;
reg = <0x3000 0x200>;
interrupts = <33>;
..
};
qeic: [EMAIL PROTECTED] {
#address-cells = <0>;
#interrupt-cells = <1>;
compatible = "fsl,qe-ic";
interrupt-controller;
reg = <0x80 0x80>;
big-endian;
interrupts = <32 8 33 8>;
interrupt-parent = <&ipic>;
};
Thanks
--
Michael Galea
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question on assigning interrupts in a dts
Michael Galea wrote: Hi All, I'm building a dts for a custom 8360 based board. I'm looking at the mpc8360_mds and mpc8360_rdk dts files, trying to figure out how the UCCs (and all peripherals in general) got the values of their "interrupts" properties chosen. As someone else pointed out, you get the values from the manual. The second cell of the IPIC interrupt specifier is the level/sense information (8 == level triggered, active low, 2 == rising edge). And is there any relationship between the choice of interrupts for ucc1 and the qeic controller.. No. All QE interrupts are multiplexed over either IPIC 32 or IPIC 33. UCC0 and UCC1 just happen to be QEIC 32 and QEIC 33, respectively. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Reserving small amounts of memory with mem= (MPC85xx, 2.6.15 arch/ppc)
Hi, Residual memory size is what Linux couldn't map with its three CAM entries. The main figure you can check is the sum of the three first CAMs plus residual is what you specified (CAM0+CAM1+CAM2+residuak == 'mem'). It's not weird to get a residual != 0 when specified memory size isn't a good combination of power of 2. Stupid question: have you tried mem=512M and a correct RAM disk address ? No more comments... -- sj 2008/6/12 Florian Boelstler <[EMAIL PROTECTED]>: > Hi, > > I ran into problems reserving small amounts of memory using command line > argument 'mem'. > Limiting a MPC8540 with 512MB physical available memory down to 256MB has > been successfully done using U-Boot: > > => setenv bootargs console=ttyS0,115200 mem=256M > => setenv initrd_high 1000 > => bootm 0x0210 > > ## Booting image at 0210 ... > Image Name: Linux 2.6.15 > Image Type: PowerPC Linux Multi-File Image (gzip compressed) > Data Size:6965022 Bytes = 6.6 MB > Load Address: > Entry Point: > Contents: > Image 0: 1099550 Bytes = 1 MB > Image 1: 5865458 Bytes = 5.6 MB > Verifying Checksum ... OK > Uncompressing Multi-File Image ... OK > [...] > Loading Ramdisk to 0fa68000, end 0ff2 ... OK > > Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb > Linux version 2.6.15 ([EMAIL PROTECTED]) (gcc version 3.4.3) #21 PREEMPT Fri > Nov 30 > 16:47:32 CET 2007 > [...] > > [EMAIL PROTECTED]:/# cat /proc/meminfo > MemTotal: 257272 kB > MemFree:226332 kB > [...] > > When a larger size for 'mem' (say 508M for reserving 4M) and appropriate > 'initrd_high' is used, U-Boot is still able to load the ramdisk to its > correct place in RAM. However Linux seems to not accept that memory region > and removes the memory using mem_pieces_remove(), which leads to a crash > since it cannot access area used for the ramdisk(?). > In that case output of "residual" for CAM mapping shows a value != 0. > > My assumption is that these CAM mappings cannot be used for memory portions > less than a certain size. > I need to dig into that, please correct me if I'm wrong. > > Linux 2.6.15 build for arch/ppc on custom MPC8540 board (Linux BSP similar > to MPC8540ads). U-Boot 1.2.0. > > Thanks for any suggestions. > > Florian > > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > -- -- Sylvain JOYEAU Freelance Engineer Software RT-OS R&D [EMAIL PROTECTED] Tél: +33-(0)667 477 052 "A good idea is one side of the coin. The other side is the practical usefulness". J. Liedke. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Question on assigning interrupts in a dts
Mike Timmons wrote:
Michael,
I'm familiar with the powerpc 5200 scheme. Under Documents there is a
mpc52xx-device-tree-bindings.txt. In the section titled, "Interrupt
mapping" there is a description of the interrupt values in the dts.
I'm not too familiar with the 8360. The 5200 has different "categories"
(main, crit, perph, and SDMA) of interupts and then numbers within each
category. To support this the 52xx DTS uses a triplet to represent
interrupts in the dts: .
Taking a quick look at the MPC8360E PowerQUICC II reference manual (Rev
2) I can at least map some of the fields in mpc836x_mds.dts to valuel in
the datasheet (The IPIC looks a little flat compared to the pic in the
5200 so it looks like this is why you don't need the triplet format).
For example, the i2c on-chip peripherals in the dts ([EMAIL PROTECTED] and
[EMAIL PROTECTED]) specify interrupts= and , respectively. The 'e' and
the 'f' agree with the interrupt ID numbers associated with these I2C
peripherals on page 8-10 of the reference manual.
The '8' could be some sort of interrupt 'level' spec for the devices
that rely on the ipic (note that most of the devices that rely on ipic
as the interrupt-parent specify the '8' after the interrupt ID number).
So, I think we're close to understanding how to specify interrupts under
ipic (so long as you figure out what 8 means), but I don't think it
directly addresses your question. As for your device snippet below,
those look like devices on the QUICC Engine port. In the Reference
manual I do see this at ipic interrupt ID 32 and 33 which agrees.
It looks like the qeic is an interrupt controller beneath the ipic
controller: below you specify qeic as an interrupt controller and assign
the ipic interrupt ids to it (again, I see 32 and 33 in the reference
manual).
In your dts, do you have devices that specify interrupt-parent=<&qeic>?
I see a few of them in mpc836x_mds.dts. In turn, these devices indicate
only a single value for "interrupts" (interrupts=<21>, for example).
I think this must be the bit position for whatever QUICC interrupt port
is associated with the device. Look around in section 8.5 of the
reference manual and see if you can make sense of it.
I decoded the device tree syntax by finding drivers for devices in the
tree, refering to the reference manual(s), and identifying how the
device tree mapped to the chip. Although I'm not well versed on the
8360, just the few minutes I spent above got me pretty close to making
sense of the syntax below. Dig in this direction and it will become
clear.
-Mike
Thanks Mike,
I'm beginning to grok it now.
Where the interrupt parent is the IPIC, the interrupt property specifies
the Interrupt ID (from pg 8-10) and that interrupts level/sense
information (which matches defines in ).
Where the interrupt parent is the QE interrupt controller (i.e. UCCs and
spi) the number is the QEIC interrupt number (pg 19-21).
And the QE interrupt controller itself is a client of the IPIC that can
generate both a HIGH (32) and LOW (33) Interrupt_ID to the IPIC.
This is good, as my real question was "what interrupt do I use for UCCs
5,6 and 7. And now I know..
And thanks to Scott as well, who pointed out the difference between IPIC
interrupt IDs and QE interrupt numbers.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Michael Galea
Sent: Thursday, June 12, 2008 9:12 AM
To: linuxppc-embedded@ozlabs.org
Subject: Question on assigning interrupts in a dts
Hi All,
I'm building a dts for a custom 8360 based board. I'm looking at
the mpc8360_mds and mpc8360_rdk dts files, trying to figure out how the
UCCs (and all peripherals in general) got the values of their
"interrupts" properties chosen. And is there any relationship between
the choice of interrupts for ucc1 and the qeic controller.. Can anyone
point me some docs for this?
enet0: [EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <1>;
reg = <0x2000 0x200>;
interrupts = <32>;
..
};
enet1: [EMAIL PROTECTED] {
device_type = "network";
compatible = "ucc_geth";
cell-index = <2>;
reg = <0x3000 0x200>;
interrupts = <33>;
..
};
qeic: [EMAIL PROTECTED] {
#address-cells = <0>;
#interrupt-cells = <1>;
compatible = "fsl,qe-ic";
interrupt-controller;
reg = <0x80 0x80>;
big-endian;
interrupts = <32 8 33 8>;
interrupt-parent = <&ipic>;
};
Thanks
--
Michael Galea
30 Whitmore Road
Woodbridge, Ontario, Canada, L4L 7Z4
Ph: (905) 266-1745
Fx: (905) 856-1995
www.ruggedcom.com
NOTICE OF CONFIDENTIALITY:
This e-mail and any attac
Freescale MPC8321 support
This processor is described as an e300c2 core. I found that e300c2 is listed in the arch/powerpc/kernel/cputypes.c file. Does this mean that it is supported, or is that just a place holder? If it is supported (as a core) what about the peripherals built into the MPC8321 are they likely to be supported? How about Flash support, or is this very board dependant? Any ideas? David ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Freescale MPC8321 support
David Goodenough wrote: This processor is described as an e300c2 core. I found that e300c2 is listed in the arch/powerpc/kernel/cputypes.c file. Does this mean that it is supported, or is that just a place holder? Yes, it is supported. If it is supported (as a core) what about the peripherals built into the MPC8321 are they likely to be supported? The more commonly used ones should be. How about Flash support, or is this very board dependant? Yes, flash (I assume you mean NOR) should work. See the localbus nodes in existing device trees. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Correct way to adjust PCI resource allocations?
Hi, I'm hoping somebody can tell me the correct way to change the memory resources allocated to particular PCI buses/devices at startup? I'm developing a card (MPC8641D, 2.6.25 kernel) that includes a PCI/X-VMEBus bridge, and the driver requires that it have a chunk of [prefetchable] PCI memory space available to it. There is nothing on the chip that says so: it has a single BAR that covers its configuration registers, but nothing else. So: I need a way to declare an additional memory requirement for this particular device that will wend its way back through the chain of PCIe and PCIX buses to the root. So far I've been using a platform-specific "pcibios_fixup_resources" function that simply writes-in my new requirement, in conjunction with "ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC", as a new resource entry in the device's pci_device structure. And this has been working well, so far. But I've discovered that fitting an XMC/PMC card to my board mucks things up - the resource allocations fail. The XMC/PMC card appears on the same PCI/X bus as the VME bridge. This leads me to think I've not been using the correct method all along, but happened to hit lucky until now. What is the right way to do this? Is pcibios_fixup_resources even meant to do something like this? Any help gratefully welcomed. Cheers, - Trevor Anderson <[EMAIL PROTECTED]> -- View this message in context: http://www.nabble.com/Correct-way-to-adjust-PCI-resource-allocations--tp17810852p17810852.html Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
On Thu, Jun 12, 2008 at 08:10:47AM -0600, Grant Likely wrote:
[snip]
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,mpc5121-i2c-ctrl";
> > + reg = <0x1760 0x8>;
> > + };
> > +
> > + [EMAIL PROTECTED] {
>
> (nitpick) There is a recommended practice that says node names should
> be generic as much as possible, so I think this should probably be
> [EMAIL PROTECTED] The compatible value is fine.
If this is a video display device, the recommended generic name is
"[EMAIL PROTECTED]", not "[EMAIL PROTECTED]".
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH 1/2] Added support for PRTLVT based boards (MPC5121)
On Thu, Jun 12, 2008 at 10:19 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 08:10:47AM -0600, Grant Likely wrote:
> [snip]
>> > + [EMAIL PROTECTED] {
>> > + compatible = "fsl,mpc5121-i2c-ctrl";
>> > + reg = <0x1760 0x8>;
>> > + };
>> > +
>> > + [EMAIL PROTECTED] {
>>
>> (nitpick) There is a recommended practice that says node names should
>> be generic as much as possible, so I think this should probably be
>> [EMAIL PROTECTED] The compatible value is fine.
>
> If this is a video display device, the recommended generic name is
> "[EMAIL PROTECTED]", not "[EMAIL PROTECTED]".
heh; oops. I should know better and I stand corrected. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
