* 回复:Re: Fw: Anyone using CodeWarrior USB TAP?
From: zengshuai @ 2005-12-06 6:55 UTC (permalink / raw)
To: York Sun; +Cc: ppc
I have a question too.
Can we use CodeWarrior USB TAP in GDB?
The CodeWarrior IDE is really expensive.
----- 原文 -----
From: York Sun
To: Kim Phillips
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Fw: Anyone using CodeWarrior USB TAP?
Sent: Tue Dec 06 03:37:22 CST 2005
> Addison,
>
> I don't know if you can receive this reply since I am not in the mailing
> list.
>
> The answer is that the USB TAP can work under Linux. You will need
> CodeWarrior Linux version. The current version is 2.6. Please contact
> the sales of channels where you got your board.
>
> No specific driver is required for Linux. Just kindly remind you to
> check the writing privilege of /proc/bus/usb/001/* if you not the root
> user.
>
> York
>
>
> On Mon, 2005-12-05 at 13:22 -0600, Kim Phillips wrote:
> > York, know anything about this? If you're subscribed, could you answer directly to the list?
> >
> > Kim
> >
> > Begin forwarded message:
> >
> > Date: Mon, 5 Dec 2005 17:05:39 +0000
> > From: Addison Baldwin <addison.baldwin@gmail.com>
> > To: linuxppc-embedded@ozlabs.org
> > Subject: Anyone using CodeWarrior USB TAP?
> >
> >
> > Hi
> >
> > I received a MPC8272ADS board from Freescale, and I'm trying to use a
> > CodeWarrior USB TAB that has been provided with the board. It seems that
> > such a device only works under Windows, as I didn't find a driver to make it
> > works under Linux.
> >
> > I would like to know if anyone have got the CodeWarrior USB working under
> > Linux.
> >
> > Thanks,
> > Addison
> >
> >
> >
> --
> York Sun
>
> This email, and any associated attachments have been classified as:
> [x] Freescale Semiconductor General Business
> [ ] Freescale Semiconductor Internal Use Only
> [ ] Freescale Semiconductor Confidential Proprietary
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=&FullName=&Email=&verify=e197bd6dbd1fc7f8d6a035729df08d63
^ permalink raw reply
* [PATCH 1/5] ppc32: Removes dead code from original Yucca PCIE initialization sequence
From: Ruslan V. Sushko @ 2005-12-06 12:48 UTC (permalink / raw)
To: rolandd; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 121 bytes --]
This patch removes dead code from PCIE initialization sequence
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_pcie_rdead_code.patch --]
[-- Type: text/x-patch, Size: 1869 bytes --]
This patch removes dead code from Yucca PCIE initialization sequence
---
commit 27304e1086e96f8110626096a75cf4783a5512bb
tree 5d002bc97c0edcc2646ebd941a9f2b321a4777fc
parent e4f5c82a92c2a546a16af1614114eec19120e40a
author Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 12:33:57 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 12:33:57 +0300
arch/ppc/platforms/4xx/yucca.c | 5 -----
arch/ppc/syslib/ppc440spe_pcie.c | 16 ----------------
2 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -242,11 +242,6 @@ yucca_setup_hoses(void)
char name[20];
int i;
- if (0 && ppc440spe_init_pcie()) {
- printk(KERN_WARNING "PPC440SPe PCI Express initialization failed\n");
- return;
- }
-
for (i = 0; i <= 2; ++i) {
if (!yucca_pcie_card_present(i))
continue;
diff --git a/arch/ppc/syslib/ppc440spe_pcie.c b/arch/ppc/syslib/ppc440spe_pcie.c
--- a/arch/ppc/syslib/ppc440spe_pcie.c
+++ b/arch/ppc/syslib/ppc440spe_pcie.c
@@ -47,8 +47,6 @@ pcie_read_config(struct pci_bus *bus, un
break;
}
- if (0) printk("%s: read %x(%d) @ %x\n", __func__, *val, len, offset);
-
return PCIBIOS_SUCCESSFUL;
}
@@ -353,20 +351,6 @@ int ppc440spe_init_pcie_rootport(int por
break;
}
-#if 0
- /* Dump all config regs */
- for (i = 0x300; i <= 0x320; ++i)
- printk("[%04x] 0x%08x\n", i, SDR_READ(i));
- for (i = 0x340; i <= 0x353; ++i)
- printk("[%04x] 0x%08x\n", i, SDR_READ(i));
- for (i = 0x370; i <= 0x383; ++i)
- printk("[%04x] 0x%08x\n", i, SDR_READ(i));
- for (i = 0x3a0; i <= 0x3a2; ++i)
- printk("[%04x] 0x%08x\n", i, SDR_READ(i));
- for (i = 0x3c0; i <= 0x3c3; ++i)
- printk("[%04x] 0x%08x\n", i, SDR_READ(i));
-#endif
-
mdelay(100);
return 0;
^ permalink raw reply
* [PATCH 2/5] ppc32: verbose error checking for Yucca PCIE initialization
From: Ruslan V. Sushko @ 2005-12-06 12:49 UTC (permalink / raw)
To: rollandd; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
> > +
> > + attempts = 10;
> > switch (port) {
> > case 0:
> > - if (!(SDR_READ(PESDR0_RCSSTS) & (1 << 16)))
> > - printk(KERN_WARNING "PCIE0: VC0 not active\n");
> > + while(!(SDR_READ(PESDR0_RCSSTS) & (1 << 16))) {
> > + if (!(attempts--)) {
> > + printk(KERN_WARNING "PCIE0: VC0 not active\n");
> > + return -1;
> > + }
> > + mdelay(1000);
> > + }
> > SDR_WRITE(PESDR0_RCSSET, SDR_READ(PESDR0_RCSSET) | 1 << 20);
>
> what lead you to add 10 tries here? Did this fix an issue you saw
> with a device?
I haven't saw any error but this is potential issue because this flag
asserts only then PCI Express port initialization is completed. I guess
the initialization sequences assumes time using. Therefore the error may
appears in future revision of the boards if Core clock will grow up.
Nevertheless I do not know the time which is necessary for completeness,
so I add this just to be safe.
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_pcie_err_chk.patch --]
[-- Type: text/x-patch, Size: 5232 bytes --]
This patch adds verbose error checking for Yucca PCIE initialization
---
commit 18b959b9ab80f8cb2fa1eff0a68cca3b5aa2f642
tree 632d445c219c2a3ff1d56023485efe23e7fd196d
parent 27304e1086e96f8110626096a75cf4783a5512bb
author Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 12:56:36 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 12:56:36 +0300
arch/ppc/syslib/ppc440spe_pcie.c | 74 +++++++++++++++++++++++++-------------
1 files changed, 49 insertions(+), 25 deletions(-)
diff --git a/arch/ppc/syslib/ppc440spe_pcie.c b/arch/ppc/syslib/ppc440spe_pcie.c
--- a/arch/ppc/syslib/ppc440spe_pcie.c
+++ b/arch/ppc/syslib/ppc440spe_pcie.c
@@ -91,9 +91,10 @@ enum {
LNKW_X8 = 0x8
};
-static void check_error(void)
+static int check_error(void)
{
u32 valPE0, valPE1, valPE2;
+ int err = 0;
/* SDR0_PEGPLLLCT1 reset */
if (!(valPE0 = SDR_READ(PESDR0_PLLLCT1) & 0x01000000)) {
@@ -109,6 +110,7 @@ static void check_error(void)
!(valPE1 & 0x01000000) ||
!(valPE2 & 0x01000000)) {
printk(KERN_INFO "PCIE: SDR0_PExRCSSET rstgu error\n");
+ err = -1;
}
/* SDR0_PExRCSSET rstdl */
@@ -116,6 +118,7 @@ static void check_error(void)
!(valPE1 & 0x00010000) ||
!(valPE2 & 0x00010000)) {
printk(KERN_INFO "PCIE: SDR0_PExRCSSET rstdl error\n");
+ err = -1;
}
/* SDR0_PExRCSSET rstpyn */
@@ -123,6 +126,7 @@ static void check_error(void)
(valPE1 & 0x00001000) ||
(valPE2 & 0x00001000)) {
printk(KERN_INFO "PCIE: SDR0_PExRCSSET rstpyn error\n");
+ err = -1;
}
/* SDR0_PExRCSSET hldplb */
@@ -130,6 +134,7 @@ static void check_error(void)
(valPE1 & 0x10000000) ||
(valPE2 & 0x10000000)) {
printk(KERN_INFO "PCIE: SDR0_PExRCSSET hldplb error\n");
+ err = -1;
}
/* SDR0_PExRCSSET rdy */
@@ -137,6 +142,7 @@ static void check_error(void)
(valPE1 & 0x00100000) ||
(valPE2 & 0x00100000)) {
printk(KERN_INFO "PCIE: SDR0_PExRCSSET rdy error\n");
+ err = -1;
}
/* SDR0_PExRCSSET shutdown */
@@ -144,7 +150,9 @@ static void check_error(void)
(valPE1 & 0x00000100) ||
(valPE2 & 0x00000100)) {
printk(KERN_INFO "PCIE: SDR0_PExRCSSET shutdown error\n");
+ err = -1;
}
+ return err;
}
/*
@@ -155,17 +163,20 @@ int ppc440spe_init_pcie(void)
/* Set PLL clock receiver to LVPECL */
SDR_WRITE(PESDR0_PLLLCT1, SDR_READ(PESDR0_PLLLCT1) | 1 << 28);
- check_error();
+ if (check_error())
+ return -1;
- printk(KERN_INFO "PCIE initialization OK\n");
-
- if (!(SDR_READ(PESDR0_PLLLCT2) & 0x10000))
- printk(KERN_INFO "PESDR_PLLCT2 resistance calibration failed (0x%08x)\n",
+ if (!(SDR_READ(PESDR0_PLLLCT2) & 0x10000)) {
+ printk(KERN_INFO "PCIE: PESDR_PLLCT2 resistance calibration "
+ "failed (0x%08x)\n",
SDR_READ(PESDR0_PLLLCT2));
+ return -1;
+ }
/* De-assert reset of PCIe PLL, wait for lock */
SDR_WRITE(PESDR0_PLLLCT1, SDR_READ(PESDR0_PLLLCT1) & ~(1 << 24));
udelay(3);
+ printk(KERN_INFO "PCIE initialization OK\n");
return 0;
}
@@ -174,14 +185,13 @@ int ppc440spe_init_pcie_rootport(int por
{
static int core_init;
void __iomem *utl_base;
+ int attempts;
u32 val = 0;
- int i;
if (!core_init) {
+ if(ppc440spe_init_pcie())
+ return -1;
++core_init;
- i = ppc440spe_init_pcie();
- if (i)
- return i;
}
/*
@@ -252,15 +262,10 @@ int ppc440spe_init_pcie_rootport(int por
case 2: val = SDR_READ(PESDR2_RCSSTS); break;
}
- if (!(val & (1 << 20)))
- printk(KERN_INFO "PCIE%d: PGRST inactive\n", port);
- else
- printk(KERN_WARNING "PGRST for PCIE%d failed %08x\n", port, val);
-
- switch (port) {
- case 0: printk(KERN_INFO "PCIE0: LOOP %08x\n", SDR_READ(PESDR0_LOOP)); break;
- case 1: printk(KERN_INFO "PCIE1: LOOP %08x\n", SDR_READ(PESDR1_LOOP)); break;
- case 2: printk(KERN_INFO "PCIE2: LOOP %08x\n", SDR_READ(PESDR2_LOOP)); break;
+ if (val & (1 << 20)) {
+ printk(KERN_WARNING "PGRST for PCIE%d failed %08x\n",
+ port, val);
+ return -1;
}
/*
@@ -333,20 +338,39 @@ int ppc440spe_init_pcie_rootport(int por
/*
* Check for VC0 active and assert RDY.
*/
+
+ attempts = 10;
switch (port) {
case 0:
- if (!(SDR_READ(PESDR0_RCSSTS) & (1 << 16)))
- printk(KERN_WARNING "PCIE0: VC0 not active\n");
+ while(!(SDR_READ(PESDR0_RCSSTS) & (1 << 16))) {
+ if (!(attempts--)) {
+ printk(KERN_WARNING "PCIE0: VC0 not active\n");
+ return -1;
+ }
+ mdelay(1000);
+ }
SDR_WRITE(PESDR0_RCSSET, SDR_READ(PESDR0_RCSSET) | 1 << 20);
break;
case 1:
- if (!(SDR_READ(PESDR1_RCSSTS) & (1 << 16)))
- printk(KERN_WARNING "PCIE0: VC0 not active\n");
+ while(!(SDR_READ(PESDR1_RCSSTS) & (1 << 16))) {
+ if (!(attempts--)) {
+ printk(KERN_WARNING "PCIE1: VC0 not active\n");
+ return -1;
+ }
+ mdelay(1000);
+ }
+
SDR_WRITE(PESDR1_RCSSET, SDR_READ(PESDR1_RCSSET) | 1 << 20);
break;
case 2:
- if (!(SDR_READ(PESDR2_RCSSTS) & (1 << 16)))
- printk(KERN_WARNING "PCIE0: VC0 not active\n");
+ while(!(SDR_READ(PESDR2_RCSSTS) & (1 << 16))) {
+ if (!(attempts--)) {
+ printk(KERN_WARNING "PCIE2: VC0 not active\n");
+ return -1;
+ }
+ mdelay(1000);
+ }
+
SDR_WRITE(PESDR2_RCSSET, SDR_READ(PESDR2_RCSSET) | 1 << 20);
break;
}
^ permalink raw reply
* [PATCH 3/5] ppc32: Fix config space address calculation for Yucca PCIE initialization
From: Ruslan V. Sushko @ 2005-12-06 12:50 UTC (permalink / raw)
To: rollandd; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 338 bytes --]
Fix config space address calculation for Yucca PCIE initialization. The
problem was in signed integer using. The size of each config space
segment is 0x40000000 so the offset of config space for third hose will
be calculated as negative number if number of hose signed integer.
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_pciecfg_fix.patch --]
[-- Type: text/x-patch, Size: 1852 bytes --]
Fix config space address calculation for Yucca PCIE initialization. The problem
was in signed integer using. The size of each config space segment is
0x40000000 so the offset of config space for 3d hose will be calculated as
negative number if number of hose signed integer.
---
commit 4776902accd7c0721532168f73dc7618675bda1e
tree 770f0d58f4a6598028fe2dfd16b5226c7bcd0c27
parent 18b959b9ab80f8cb2fa1eff0a68cca3b5aa2f642
author Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 13:01:57 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 13:01:57 +0300
arch/ppc/syslib/ppc440spe_pcie.c | 4 ++--
arch/ppc/syslib/ppc440spe_pcie.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/ppc/syslib/ppc440spe_pcie.c b/arch/ppc/syslib/ppc440spe_pcie.c
--- a/arch/ppc/syslib/ppc440spe_pcie.c
+++ b/arch/ppc/syslib/ppc440spe_pcie.c
@@ -181,7 +181,7 @@ int ppc440spe_init_pcie(void)
return 0;
}
-int ppc440spe_init_pcie_rootport(int port)
+int ppc440spe_init_pcie_rootport(u32 port)
{
static int core_init;
void __iomem *utl_base;
@@ -380,7 +380,7 @@ int ppc440spe_init_pcie_rootport(int por
return 0;
}
-void ppc440spe_setup_pcie(struct pci_controller *hose, int port)
+void ppc440spe_setup_pcie(struct pci_controller *hose, u32 port)
{
void __iomem *mbase;
diff --git a/arch/ppc/syslib/ppc440spe_pcie.h b/arch/ppc/syslib/ppc440spe_pcie.h
--- a/arch/ppc/syslib/ppc440spe_pcie.h
+++ b/arch/ppc/syslib/ppc440spe_pcie.h
@@ -143,7 +143,7 @@
#define PECFG_POM0LAH 0x384
int ppc440spe_init_pcie(void);
-int ppc440spe_init_pcie_rootport(int port);
-void ppc440spe_setup_pcie(struct pci_controller *hose, int port);
+int ppc440spe_init_pcie_rootport(u32 port);
+void ppc440spe_setup_pcie(struct pci_controller *hose, u32 port);
#endif /* __PPC_SYSLIB_PPC440SPE_PCIE_H */
^ permalink raw reply
* [PATCH 4/5] ppc32: Fix the PCI bus numbering assignment for Yucca PCI initialization.
From: Ruslan V. Sushko @ 2005-12-06 12:50 UTC (permalink / raw)
To: rollandd; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 161 bytes --]
Fix the PCI bus numbering assignment. This will be an issue if more
than one PCI card will be inserted.
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_pci_bus_num.patch --]
[-- Type: text/x-patch, Size: 1331 bytes --]
Fix the PCI bus numbering assignment for PCI initialization for Yucca board.
This will be an issue if more than one PCI card is inserted.
---
commit 9bc85a59a27ae0559a59a852f3ce58a49368d3dd
tree cb2b3d77931e4bbc8e98f5ea776514c23e1b50ca
parent 4776902accd7c0721532168f73dc7618675bda1e
author Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 13:14:17 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 13:14:17 +0300
arch/ppc/platforms/4xx/yucca.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -240,6 +240,7 @@ yucca_setup_hoses(void)
{
struct pci_controller *hose;
char name[20];
+ int bus_no = 0;
int i;
for (i = 0; i <= 2; ++i) {
@@ -275,12 +276,14 @@ yucca_setup_hoses(void)
IORESOURCE_MEM,
name);
- hose->first_busno = 0;
- hose->last_busno = 15;
+ hose->first_busno = bus_no;
+ hose->last_busno = 0xFF;
hose_type[hose->index] = HOSE_PCIE0 + i;
ppc440spe_setup_pcie(hose, i);
hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+ bus_no = hose->last_busno + 1;
+ printk(KERN_INFO "%s: resources allocated\n", name);
}
ppc_md.pci_swizzle = common_swizzle;
^ permalink raw reply
* [PATCH 5/5] ppc32: Add PCI-X support for Yucca board
From: Ruslan V. Sushko @ 2005-12-06 12:50 UTC (permalink / raw)
To: rollandd; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 177 bytes --]
This patch is cleaned (all whitespace fixes of original code has been
removed) version old PCI-X patch for Yucca board.
Signed-off-by: Ruslan V. Sushko <rsushko@ru.mvista.com>
[-- Attachment #2: yucca_pcix.patch --]
[-- Type: text/x-patch, Size: 8454 bytes --]
This patch is cleaned (all whitespace fixes of original code has been removed) version old PCIX patch for yucca board.
---
commit c9e322aa17237167d6355fb2e55028d51271f1df
tree ef967150a7445cc54f234e18fe7a83ca06142a46
parent 9bc85a59a27ae0559a59a852f3ce58a49368d3dd
author Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 13:30:13 +0300
committer Ruslan V. Sushko <rsushko@ru.mvista.com> Tue, 06 Dec 2005 13:30:13 +0300
arch/ppc/platforms/4xx/yucca.c | 168 ++++++++++++++++++++++++++++++++--------
include/asm-ppc/ibm44x.h | 9 ++
2 files changed, 142 insertions(+), 35 deletions(-)
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -58,6 +58,25 @@ extern bd_t __res;
static struct ibm44x_clocks clocks __initdata;
+unsigned char ppc4xx_uic_ext_irq_cfg[] __initdata = {
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ15: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ14: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ13: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ12: PCI-X slot */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ11: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ10: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ9: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ8: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ7: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ6: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ5: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ4: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ3: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ2: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ1: EXT */
+ (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* IRQ0: EXT */
+};
+
static void __init
yucca_calibrate_decr(void)
{
@@ -80,13 +99,83 @@ yucca_show_cpuinfo(struct seq_file *m)
return 0;
}
-static enum {
- HOSE_UNKNOWN,
+static void __init yucca_set_emacdata(void)
+{
+ struct ocp_def *def;
+ struct ocp_func_emac_data *emacdata;
+
+ /* Set phy_map, phy_mode, and mac_addr for the EMAC */
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
+ emacdata = def->additions;
+ emacdata->phy_map = 0x00000001; /* Skip 0x00 */
+ emacdata->phy_mode = PHY_MODE_GMII;
+ memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
+}
+
+enum yucca_hoses {
HOSE_PCIX,
HOSE_PCIE0,
HOSE_PCIE1,
- HOSE_PCIE2
-} hose_type[4];
+ HOSE_PCIE2,
+ HOSE_MAX
+};
+
+static enum yucca_hoses hose_type[4];
+
+#define is_pcix_hose(_hs_) ((_hs_) == HOSE_PCIX)
+#define is_pcie_hose(_hs_) (((_hs_) >= HOSE_PCIE0) && ((_hs_) <= HOSE_PCIE2))
+#define pcie_hose_num(_hs_) ((_hs_) - HOSE_PCIE0)
+
+#define PCIX_READW(offset) \
+ (readw((void *)((u32)pcix_reg_base+offset)))
+
+#define PCIX_WRITEW(value, offset) \
+ (writew(value, (void *)((u32)pcix_reg_base+offset)))
+
+#define PCIX_WRITEL(value, offset) \
+ (writel(value, (void *)((u32)pcix_reg_base+offset)))
+
+static void __init
+ppc440spe_setup_pcix(struct pci_controller *hose)
+{
+ void *pcix_reg_base;
+
+ pcix_reg_base = ioremap64(PCIX0_REG_BASE, PCIX_REG_SIZE);
+
+ /* Disable all windows */
+ PCIX_WRITEL(0, PCIX0_POM0SA);
+ PCIX_WRITEL(0, PCIX0_POM1SA);
+ PCIX_WRITEL(0, PCIX0_POM2SA);
+ PCIX_WRITEL(0, PCIX0_PIM0SA);
+ PCIX_WRITEL(0, PCIX0_PIM0SAH);
+ PCIX_WRITEL(0, PCIX0_PIM1SA);
+ PCIX_WRITEL(0, PCIX0_PIM2SA);
+ PCIX_WRITEL(0, PCIX0_PIM2SAH);
+
+ /*
+ * Setup 512MB PLB->PCI outbound mem window
+ * (a_n000_0000->0_n000_0000)
+ * */
+ PCIX_WRITEL(0x0000000d, PCIX0_POM0LAH);
+ PCIX_WRITEL(hose->mem_space.start, PCIX0_POM0LAL);
+ PCIX_WRITEL(0x00000000, PCIX0_POM0PCIAH);
+ PCIX_WRITEL(hose->mem_space.start, PCIX0_POM0PCIAL);
+ PCIX_WRITEL(~(hose->mem_space.end - hose->mem_space.start) | 1 ,
+ PCIX0_POM0SA);
+
+ /* Setup 1GB PCI->PLB inbound memory window at 0, enable MSIs */
+ PCIX_WRITEL(0x00000000, PCIX0_PIM0LAH);
+ PCIX_WRITEL(0x00000000, PCIX0_PIM0LAL);
+ PCIX_WRITEL(0xc0000007, PCIX0_PIM0SA);
+ PCIX_WRITEL(0xffffffff, PCIX0_PIM0SAH);
+
+ /* Enable PCIX0 I/O, Mem, and Busmaster cycles */
+ PCIX_WRITEW(PCIX_READW(PCIX0_COMMAND) | PCI_COMMAND_MEMORY |
+ PCI_COMMAND_MASTER, PCIX0_COMMAND);
+
+ iounmap(pcix_reg_base);
+ eieio();
+}
static inline int
yucca_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
@@ -100,7 +189,7 @@ yucca_map_irq(struct pci_dev *dev, unsig
* A B C D
*/
{
- { 81, -1, -1, -1 }, /* IDSEL 1 - PCIX0 Slot 0 */
+ { 49, -1, -1, -1 }, /* IDSEL 1 - PCIX0 Slot 0 */
};
const long min_idsel = 1, max_idsel = 1, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
@@ -141,19 +230,6 @@ yucca_map_irq(struct pci_dev *dev, unsig
return -1;
}
-static void __init yucca_set_emacdata(void)
-{
- struct ocp_def *def;
- struct ocp_func_emac_data *emacdata;
-
- /* Set phy_map, phy_mode, and mac_addr for the EMAC */
- def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
- emacdata = def->additions;
- emacdata->phy_map = 0x00000001; /* Skip 0x00 */
- emacdata->phy_mode = PHY_MODE_GMII;
- memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
-}
-
static int __init yucca_pcie_card_present(int port)
{
void __iomem *pcie_fpga_base;
@@ -240,35 +316,44 @@ yucca_setup_hoses(void)
{
struct pci_controller *hose;
char name[20];
+ enum yucca_hoses hs;
int bus_no = 0;
- int i;
- for (i = 0; i <= 2; ++i) {
- if (!yucca_pcie_card_present(i))
- continue;
-
- printk(KERN_INFO "PCIE%d: card present\n", i);
- yucca_setup_pcie_fpga_rootpoint(i);
- if (ppc440spe_init_pcie_rootport(i)) {
- printk(KERN_WARNING "PCIE%d: initialization failed\n", i);
- continue;
+ for (hs = HOSE_PCIX; hs < HOSE_MAX; ++hs) {
+ if (is_pcie_hose(hs)) {
+ if (!yucca_pcie_card_present(pcie_hose_num(hs)))
+ continue;
+
+ printk(KERN_INFO "PCIE%d: card present\n",
+ pcie_hose_num(hs));
+
+ yucca_setup_pcie_fpga_rootpoint(pcie_hose_num(hs));
+ if (ppc440spe_init_pcie_rootport(pcie_hose_num(hs))) {
+ printk(KERN_ERR "PCIE%d: initialization "
+ "failed\n", pcie_hose_num(hs));
+ continue;
+ }
}
hose = pcibios_alloc_controller();
+
if (!hose)
return;
- sprintf(name, "PCIE%d host bridge", i);
+ sprintf(name, "PCI%s%d host bridge",
+ is_pcix_hose(hs) ? "X" : "E",
+ is_pcie_hose(hs) ? pcie_hose_num(hs) : 0
+ );
pci_init_resource(&hose->io_resource,
YUCCA_PCIX_LOWER_IO,
YUCCA_PCIX_UPPER_IO,
IORESOURCE_IO,
name);
- hose->mem_space.start = YUCCA_PCIE_LOWER_MEM +
- i * YUCCA_PCIE_MEM_SIZE;
+ hose->mem_space.start = YUCCA_PCIX_LOWER_MEM +
+ hs * YUCCA_PCIX_MEM_SIZE;
hose->mem_space.end = hose->mem_space.start +
- YUCCA_PCIE_MEM_SIZE - 1;
+ YUCCA_PCIX_MEM_SIZE - 1;
pci_init_resource(&hose->mem_resources[0],
hose->mem_space.start,
@@ -278,9 +363,24 @@ yucca_setup_hoses(void)
hose->first_busno = bus_no;
hose->last_busno = 0xFF;
- hose_type[hose->index] = HOSE_PCIE0 + i;
+ hose_type[hose->index] = hs;
+
+ if (is_pcix_hose(hs)) {
+ hose->io_space.start = YUCCA_PCIX_LOWER_IO;
+ hose->io_space.end = YUCCA_PCIX_UPPER_IO;
+ isa_io_base =
+ (unsigned long)
+ ioremap64(PCIX0_IO_BASE, PCIX_IO_SIZE);
+ hose->io_base_virt = (void *)isa_io_base;
+
+ ppc440spe_setup_pcix(hose);
+
+ setup_indirect_pci(hose, PCIX0_CFGA, PCIX0_CFGD);
+ hose->set_cfg_type = 1;
+ } else {
+ ppc440spe_setup_pcie(hose, pcie_hose_num(hs));
+ }
- ppc440spe_setup_pcie(hose, i);
hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
bus_no = hose->last_busno + 1;
printk(KERN_INFO "%s: resources allocated\n", name);
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -557,12 +557,19 @@
#define PCIX1_CFGD 0x1ec00004UL
#define PCIX2_CFGD 0x2ec00004UL
+#if defined (CONFIG_440SPE)
+#define PCIX0_IO_BASE 0x0000000C08000000ULL
+#else
#define PCIX0_IO_BASE 0x0000000908000000ULL
#define PCIX1_IO_BASE 0x0000000908000000ULL
#define PCIX2_IO_BASE 0x0000000908000000ULL
+#endif
+
#define PCIX_IO_SIZE 0x00010000
-#ifdef CONFIG_440SP
+#if defined (CONFIG_440SPE)
+#define PCIX0_REG_BASE 0x0000000c0ec80000ULL
+#elif defined(CONFIG_440SP)
#define PCIX0_REG_BASE 0x000000090ec80000ULL
#else
#define PCIX0_REG_BASE 0x000000020ec80000ULL
^ permalink raw reply
* no IRQ from USB on MPC8248
From: Nathael PAJANI @ 2005-12-06 15:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051206125102.1FC7F68888@ozlabs.org>
Hi all!
As I said previously I started a backport of the hcd driver from
sourceforge (http://cpm2usb.sourceforge.net/) to linux 2.6.9 for an
actis board (VSBC6848) based on a MPC8248 (MPC8272 family)
I have a running 2.6.9 kernel for this board, and no other, that's why
I'm doing a backport of the driver. (for those who might wonder)
I managed to have the core up:
---> insmod usbcore.ko
Using usbcore.ko
usbcore: registered new driver usbfs
usbcore: registered new driver hub
---> mount /proc/bus/usb
---> insmod m82xx-hcd.ko
Using m82xx-hcd.ko
=> driver mpc82xx-hcd, 0.02
mpc82xx-hcd mpc82xx-hcd3: PQ2 intergrated USB controller v0.1
mpc82xx-hcd mpc82xx-hcd3: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
PQ2USB: debug file creation
---> Done
~ #
so this is OK
then, when plugging a device, I got this:
usb 1-1: new full speed USB device using address 2
usb 1-1: control timeout on ep0out
mpc82xx-hcd mpc82xx-hcd3: Unlink after no-IRQ? Different ACPI or APIC
settings may help.
usb 1-1: control timeout on ep0out
usb 1-1: device not accepting address 2, error -110
usb 1-1: new full speed USB device using address 3
usb 1-1: control timeout on ep0out
usb 1-1: control timeout on ep0out
usb 1-1: device not accepting address 3, error -110
which means the hub detects a device, and tries to configure it.
On the device (MP3player) I have an LCD display, and the text switches
to "USB-C" and comes back, which means something has been received.
Let's consider the device is working fine, I have then two possibilities:
first: the device receives incoherent stuff, and does not dare
responding, but I got no way to check on the device. (I consider the
usbcore tries to send cohenrent stuff!)
second: the device is happy to see a request and replies correctly....
but there's no interrupt fired, whether using SUI_INT_USB (==11) or the
SCC3 interrupt (==42)
I've been looking for many things allready, but did not find a clue of
what might happen... If you have some, I'll be pleased to hear about them.
I also had a look at the debug file:
~ # cat /proc/driver/m8xxhci_privateh
===> Misc stats:
sof = 0 isrs = 0 cpm_irqs = 0 overrun = 0
rxb = 0 txb = 0 bsy = 0 sof = 0
txe[0] = 0 txe[1] = 0 txe[2] = 0 txe[3] = 0
nak[0] = 0 nak[1] = 0 nak[2] = 0 nak[3] = 0
to[0] = 0 to[1] = 0 to[2] = 0 to[3] = 0
stall[0] = 0 stall[1] = 0 stall[2] = 0 stall[3] = 0
tx_err = 0 tx_nak = 0 tx_stal = 0 tx_to = 0 tx_un = 0
enqs[ISO] = 0 enqs[INTR] = 0 enqs[CTRL] = 4 enqs[BULK] = 0
cpls[ISO] = 0 cpls[INTR] = 0 cpls[CTRL] = 4 cpls[BULK] = 0
===> Periodic schedule:
~ #
but as I do not know what might be expected, I do not know what to think
about it.
The sof, isrs, and cpm_irqs counters confirm that there have been no
irqs ...
please, help me if you can.
and anyway, have fun :) :)
^ permalink raw reply
* Re: 回复:Re: Fw: Anyone using CodeWarrior USB TAP?
From: York Sun @ 2005-12-06 15:18 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <31839904.1133852113796.JavaMail.postfix@mx3.mail.sohu.com>
No, you can't. It doesn't support GDB protocol so far.
York
On Tue, 2005-12-06 at 14:55 +0800, zengshuai@sogou.com wrote:
> I have a question too.
> Can we use CodeWarrior USB TAP in GDB?
> The CodeWarrior IDE is really expensive.
>=20
> ----- =E5=8E=9F=E6=96=87 -----
> From: York Sun=20
> To: Kim Phillips=20
> Cc: linuxppc-embedded@ozlabs.org=20
> Subject: Re: Fw: Anyone using CodeWarrior USB TAP?
> Sent: Tue Dec 06 03:37:22 CST 2005
>=20
> > Addison,
> >=20
> > I don't know if you can receive this reply since I am not in the mailin=
g
> > list.
> >=20
> > The answer is that the USB TAP can work under Linux. You will need
> > CodeWarrior Linux version. The current version is 2.6. Please contact
> > the sales of channels where you got your board.
> >=20
> > No specific driver is required for Linux. Just kindly remind you to
> > check the writing privilege of /proc/bus/usb/001/* if you not the root
> > user.
> >=20
> > York
> >=20
> >=20
> > On Mon, 2005-12-05 at 13:22 -0600, Kim Phillips wrote:
> > > York, know anything about this? If you're subscribed, could you answ=
er directly to the list?
> > >=20
> > > Kim
> > >=20
> > > Begin forwarded message:
> > >=20
> > > Date: Mon, 5 Dec 2005 17:05:39 +0000
> > > From: Addison Baldwin <addison.baldwin@gmail.com>
> > > To: linuxppc-embedded@ozlabs.org
> > > Subject: Anyone using CodeWarrior USB TAP?
> > >=20
> > >=20
> > > Hi
> > >=20
> > > I received a MPC8272ADS board from Freescale, and I'm trying to use a
> > > CodeWarrior USB TAB that has been provided with the board. It seems t=
hat
> > > such a device only works under Windows, as I didn't find a driver to =
make it
> > > works under Linux.
> > >=20
> > > I would like to know if anyone have got the CodeWarrior USB working u=
nder
> > > Linux.
> > >=20
> > > Thanks,
> > > Addison
> > >=20
> > >=20
> > >=20
> > --=20
> > York Sun
> > =20
> > This email, and any associated attachments have been classified as:
> > [x] Freescale Semiconductor General Business
> > [ ] Freescale Semiconductor Internal Use Only
> > [ ] Freescale Semiconductor Confidential Proprietary
> >=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
> ------------------------------
> =E6=88=91=E7=8E=B0=E5=9C=A8=E4=BD=BF=E7=94=A8Sogou.com=E7=9A=842G=E9=82=
=AE=E7=AE=B1=E4=BA=86=EF=BC=8C=E4=BD=A0=E4=B9=9F=E6=9D=A5=E8=AF=95=E8=AF=95=
=E5=90=A7!=20
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=3Dsogouinv=
itation&s_EMAIL=3Dzengshuai%40sogou.com&username=3D&FullName=3D&Email=3D&ve=
rify=3De197bd6dbd1fc7f8d6a035729df08d63
>=20
--=20
York Sun
=20
This email, and any associated attachments have been classified as:
[x] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
^ permalink raw reply
* Re: 回复:Re: Fw: Anyone using CodeWarrior USB TAP?
From: York Sun @ 2005-12-06 15:22 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <31839904.1133852113796.JavaMail.postfix@mx3.mail.sohu.com>
No. It doesn't support GDB protocol.
York
On Tue, 2005-12-06 at 14:55 +0800, zengshuai@sogou.com wrote:
> I have a question too.
> Can we use CodeWarrior USB TAP in GDB?
> The CodeWarrior IDE is really expensive.
>=20
> ----- =E5=8E=9F=E6=96=87 -----
> From: York Sun=20
> To: Kim Phillips=20
> Cc: linuxppc-embedded@ozlabs.org=20
> Subject: Re: Fw: Anyone using CodeWarrior USB TAP?
> Sent: Tue Dec 06 03:37:22 CST 2005
>=20
> > Addison,
> >=20
> > I don't know if you can receive this reply since I am not in the mailin=
g
> > list.
> >=20
> > The answer is that the USB TAP can work under Linux. You will need
> > CodeWarrior Linux version. The current version is 2.6. Please contact
> > the sales of channels where you got your board.
> >=20
> > No specific driver is required for Linux. Just kindly remind you to
> > check the writing privilege of /proc/bus/usb/001/* if you not the root
> > user.
> >=20
> > York
> >=20
> >=20
> > On Mon, 2005-12-05 at 13:22 -0600, Kim Phillips wrote:
> > > York, know anything about this? If you're subscribed, could you answ=
er directly to the list?
> > >=20
> > > Kim
> > >=20
> > > Begin forwarded message:
> > >=20
> > > Date: Mon, 5 Dec 2005 17:05:39 +0000
> > > From: Addison Baldwin <addison.baldwin@gmail.com>
> > > To: linuxppc-embedded@ozlabs.org
> > > Subject: Anyone using CodeWarrior USB TAP?
> > >=20
> > >=20
> > > Hi
> > >=20
> > > I received a MPC8272ADS board from Freescale, and I'm trying to use a
> > > CodeWarrior USB TAB that has been provided with the board. It seems t=
hat
> > > such a device only works under Windows, as I didn't find a driver to =
make it
> > > works under Linux.
> > >=20
> > > I would like to know if anyone have got the CodeWarrior USB working u=
nder
> > > Linux.
> > >=20
> > > Thanks,
> > > Addison
> > >=20
> > >=20
> > >=20
> > --=20
> > York Sun
> > =20
> > This email, and any associated attachments have been classified as:
> > [x] Freescale Semiconductor General Business
> > [ ] Freescale Semiconductor Internal Use Only
> > [ ] Freescale Semiconductor Confidential Proprietary
> >=20
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
> ------------------------------
> =E6=88=91=E7=8E=B0=E5=9C=A8=E4=BD=BF=E7=94=A8Sogou.com=E7=9A=842G=E9=82=
=AE=E7=AE=B1=E4=BA=86=EF=BC=8C=E4=BD=A0=E4=B9=9F=E6=9D=A5=E8=AF=95=E8=AF=95=
=E5=90=A7!=20
> http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=3Dsogouinv=
itation&s_EMAIL=3Dzengshuai%40sogou.com&username=3D&FullName=3D&Email=3D&ve=
rify=3De197bd6dbd1fc7f8d6a035729df08d63
>=20
--=20
York Sun
=20
This email, and any associated attachments have been classified as:
[x] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
^ permalink raw reply
* Re: Does this Bug fixed ?
From: Hollis Blanchard @ 2005-12-06 15:31 UTC (permalink / raw)
To: sairam k; +Cc: linuxppc-dev
In-Reply-To: <c6be647f0512052129s2afd4c1vf4442192ea6d5c28@mail.gmail.com>
On Dec 5, 2005, at 11:29 PM, sairam k wrote:
>
> 1) I used linuxppc_2_4_devel PowerPC development tree source(from
> ppc.bkbits.net) to build kernel for PowerPC
> IBM405EP(evb405ep_defconfig) and montavista's gcc cross compiler for
> ppc_405-
...
> Does anyone fixed this bug........if so why it is not reflected in
> bkbits
I don't know if this has been fixed, but bkbits has not been used for
over six months. Instead you should get your source from kernel.org .
Also, there are many embedded developers on the linuxppc-embedded list;
you might try asking there instead of here.
Finally, please do not send HTML email to these lists.
Good luck.
-Hollis
^ permalink raw reply
* Re: [PATCH] Support 8xx based Silicon Turnkey XTc
From: Marcelo Tosatti @ 2005-12-06 15:36 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Robert Applebaum, linuxppc-embedded
In-Reply-To: <200512052115.45858.pantelis.antoniou@gmail.com>
Hi Panto!
On Mon, Dec 05, 2005 at 09:15:43PM +0200, Pantelis Antoniou wrote:
> Support of Silicon Turnkey's XTc.
>
> ---
> commit fac9bbd80d8f8ab3c6af5a417f804dbf8537c700
> tree 7863f94249651a26ca3eb29aed4c65c214968dda
> parent e4f5c82a92c2a546a16af1614114eec19120e40a
> author Pantelis Antoniou <pantelis.antoniou@gmail.com> Mon, 05 Dec 2005 21:13:56 +0200
> committer Pantelis Antoniou <pantelis.antoniou@gmail.com> Mon, 05 Dec 2005 21:13:56 +0200
>
> arch/ppc/Kconfig | 5
> arch/ppc/configs/stxxtc_defconfig | 804 +++++++++++++++++++++++++++++++++++++
> arch/ppc/platforms/Makefile | 1
> arch/ppc/platforms/stxxtc.h | 285 +++++++++++++
> arch/ppc/platforms/stxxtc_setup.c | 193 +++++++++
> arch/ppc/syslib/m8xx_setup.c | 14 +
> drivers/mtd/maps/Kconfig | 6
> drivers/mtd/maps/Makefile | 1
> drivers/mtd/maps/stxxtc_nor.c | 326 +++++++++++++++
> drivers/mtd/nand/Kconfig | 8
> drivers/mtd/nand/Makefile | 1
> drivers/mtd/nand/stxxtc_nand.c | 277 +++++++++++++
> include/asm-ppc/mpc8xx.h | 4
> 13 files changed, 1922 insertions(+), 3 deletions(-)
>
> +# CONFIG_PIN_TLB is not set
Might want to enable by default?
> diff --git a/arch/ppc/platforms/stxxtc.h b/arch/ppc/platforms/stxxtc.h
> new file mode 100644
> --- /dev/null
> +++ b/arch/ppc/platforms/stxxtc.h
> @@ -0,0 +1,285 @@
> +/*
> + * A collection of structures, addresses, and values associated with
> + * the STXXTC systems.
> + *
> + * Copyright (c) 2005 Pantelis Antoniou <pantelis.antoniou@gmail.com>
> + * Dan Malek <dan@embeddedalley.com>
> + *
> + */
> +#ifndef __MACH_STXXTC_DEFS
> +#define __MACH_STXXTC_DEFS
> +
> +#include <linux/config.h>
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <asm/ppcboot.h>
> +
> +#include <asm/8xx_immap.h>
> +#include <asm/commproc.h>
> +#include <asm/mpc8xx.h>
> +#include <asm/delay.h>
> +
> +#endif
> +
> +#define IMAP_ADDR 0xFF000000 /* physical base address of IMMR area */
Extra TAB (or missing tab below, whatever you prefer ;)
> +#define IMAP_SIZE (64 * 1024) /* mapped size of IMMR area */
> +
> +/* We don't use the 8259.
> +*/
> +#define NR_8259_INTS 0
> +
> +#define NAND_SIZE 0x00010000
> +#define NAND_BASE 0xF1000000
> +
> +/*-----------------------------------------------------------------------
> + * PCMCIA stuff
> + *-----------------------------------------------------------------------
> + *
> + */
> +#define PCMCIA_MEM_SIZE ( 64 << 20 )
> +
> +#define MAX_HWIFS 1 /* overwrite default in include/asm-ppc/ide.h */
> +
> +/*
> + * Definitions for IDE0 Interface
> + */
> +#define IDE0_BASE_OFFSET 0
> +#define IDE0_DATA_REG_OFFSET (PCMCIA_MEM_SIZE + 0x320)
> +#define IDE0_ERROR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 1)
> +#define IDE0_NSECTOR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 2)
> +#define IDE0_SECTOR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 3)
> +#define IDE0_LCYL_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 4)
> +#define IDE0_HCYL_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 5)
> +#define IDE0_SELECT_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 6)
> +#define IDE0_STATUS_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 7)
> +#define IDE0_CONTROL_REG_OFFSET 0x0106
> +#define IDE0_IRQ_REG_OFFSET 0x000A /* not used */
> +
> +#define IDE0_INTERRUPT 13
> +
> +/* XXX FUCK!, for IDE disk set to 0, for normal PCMCIA set to 1 */
> +/* XXX don't ask me why.. */
Can you make the comment a bit nicer? :)
> +#if 1
> +/* define IO_BASE for PCMCIA */
> +#define _IO_BASE 0x80000000
> +#define _IO_BASE_SIZE (64<<10)
> +#endif
> +
> +/***********************************************************************/
> +
> +/* shorthand for the ports data registers */
> +#define PORTA (((volatile immap_t *)IMAP_ADDR)->im_ioport.iop_padat)
> +#define PORTB (((volatile immap_t *)IMAP_ADDR)->im_cpm.cp_pbdat)
> +#define PORTC (((volatile immap_t *)IMAP_ADDR)->im_ioport.iop_pcdat)
> +#define PORTD (((volatile immap_t *)IMAP_ADDR)->im_ioport.iop_pddat)
> +#define PORTE (((volatile immap_t *)IMAP_ADDR)->im_cpm.cp_pedat)
> +
> +/********************************************************************************/
> +
> +#define PIN_PORT_EQ(p, x) ((void *) & x ## _PORT == (void *) & p)
> +#define PIN_PORT_NE(p, x) ((void *) & x ## _PORT != (void *) & p)
> +
> +#define PIN_PORT_RW(x) (PIN_PORT_NE(PORTXWO, x) && PIN_PORT_NE(PORTXRO, x))
> +#define PIN_PORT_RO(x) PIN_PORT_EQ(PORTXRO, x)
> +#define PIN_PORT_WO(x) PIN_PORT_EQ(PORTXWO, x)
> +
> +/********************************************************************************/
> +
> +#define PIN_SFT(x) ((sizeof(x ## _PORT) * 8 - 1) - x ## _BIT)
> +#define PIN_MSK(x) (1U << PIN_SFT(x))
> +
> +/********************************************************************************/
> +
> +/* normal m8xx pins */
> +#define _PIN_HI(x) \
> + do { \
> + x ## _PORT |= PIN_MSK(x); \
> + } while(0)
> +
> +#define _PIN_LO(x) \
> + do { \
> + x ## _PORT &= ~PIN_MSK(x); \
> + } while(0)
> +
> +#define _PIN_TGL(x) \
> + do { \
> + x ## _PORT ^= PIN_MSK(x); \
> + } while(0)
> +
> +#define _PIN_GET(x) \
> + (!!(x ## _PORT & PIN_MSK(x)))
> +
> +#define _PIN_SET(x, v) \
> + do { \
> + if (__builtin_constant_p(v)) { \
> + if ((v) != 0) \
> + _PIN_HI(x); \
> + else \
> + _PIN_LO(x); \
> + } else \
> + x ## _PORT = ( x ## _PORT & ~PIN_MSK(x)) | (!!(v) << PIN_SFT(x)); \
> + } while(0)
> +
> +#define _PIN_CFG_IN(x) \
> + do { \
> + if (PIN_PORT_EQ(PORTA, x)) \
> + PORTA_config(PIN_MSK(x), 0, 0); \
> + if (PIN_PORT_EQ(PORTB, x)) \
> + PORTB_config(PIN_MSK(x), 0, 0); \
> + if (PIN_PORT_EQ(PORTC, x)) \
> + PORTC_config(PIN_MSK(x), 0, 0); \
> + if (PIN_PORT_EQ(PORTD, x)) \
> + PORTD_config(PIN_MSK(x), 0, 0); \
> + if (PIN_PORT_EQ(PORTE, x)) \
> + PORTE_config(PIN_MSK(x), 0, 0); \
> + } while(0)
> +
> +#define _PIN_CFG_INT_ANY(x) \
> + do { \
> + if (PIN_PORT_EQ(PORTC, x)) \
> + PORTC_config(PIN_MSK(x), 0, 0); \
> + } while(0)
> +
> +#define _PIN_CFG_INT_FALL(x) \
> + do { \
> + if (PIN_PORT_EQ(PORTC, x)) \
> + PORTC_config(PIN_MSK(x), 0, 0); \
> + } while(0)
> +
> +#define _PIN_CFG_OUT(x, v) \
> + do { \
> + _PIN_SET(x, v); \
> + if (PIN_PORT_EQ(PORTA, x)) \
> + PORTA_config(0, PIN_MSK(x), 0); \
> + if (PIN_PORT_EQ(PORTB, x)) \
> + PORTB_config(0, PIN_MSK(x), 0); \
> + if (PIN_PORT_EQ(PORTC, x)) \
> + PORTC_config(0, PIN_MSK(x), 0); \
> + if (PIN_PORT_EQ(PORTD, x)) \
> + PORTD_config(0, PIN_MSK(x), 0); \
> + if (PIN_PORT_EQ(PORTE, x)) \
> + PORTE_config(0, PIN_MSK(x), 0); \
> + } while(0)
> +
> +#define _PIN_CFG_OUT_HI(x) _PIN_CFG_OUT(x, 1)
> +#define _PIN_CFG_OUT_LO(x) _PIN_CFG_OUT(x, 0)
> +
> +#ifndef __ASSEMBLY__
> +
> +static inline void PORTA_config(uint inmsk, uint outmsk, uint dummy)
> +{
> + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> + ushort msk = (ushort)inmsk | (ushort)outmsk;
> +
> + imap->im_ioport.iop_padir = (imap->im_ioport.iop_padir & ~(ushort)inmsk) | (ushort)outmsk;
> + imap->im_ioport.iop_paodr &= ~msk;
> + imap->im_ioport.iop_papar &= ~msk;
> +}
> +
> +static inline void PORTB_config(uint inmsk, uint outmsk, uint dummy)
> +{
> + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> + uint msk = inmsk | outmsk;
> +
> + imap->im_cpm.cp_pbdir = (imap->im_cpm.cp_pbdir & ~inmsk) | outmsk;
> + imap->im_cpm.cp_pbodr &= ~msk;
> + imap->im_cpm.cp_pbpar &= ~msk;
> +}
> +
> +static inline void PORTC_config(uint inmsk, uint outmsk, uint fallmsk)
> +{
> + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> + ushort msk = (ushort)inmsk | (ushort)outmsk;
> +
> + imap->im_ioport.iop_pcdir = (imap->im_ioport.iop_pcdir & ~(ushort)inmsk) | (ushort)outmsk;
> + imap->im_ioport.iop_pcso &= ~msk;
> + imap->im_ioport.iop_pcint = (imap->im_ioport.iop_pcint & ~(ushort)inmsk) | ((ushort)fallmsk & (ushort)inmsk);
> + imap->im_ioport.iop_pcpar &= ~msk;
> +}
> +
> +static inline void PORTD_config(uint inmsk, uint outmsk, uint dummy)
> +{
> + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> + ushort msk = (ushort)inmsk | (ushort)outmsk;
> +
> + imap->im_ioport.iop_pddir = (imap->im_ioport.iop_pddir & ~(ushort)inmsk) | (ushort)outmsk;
> + imap->im_ioport.iop_pdpar &= ~msk;
> +}
> +
> +static inline void PORTE_config(uint inmsk, uint outmsk, uint dummy)
> +{
> + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> + uint msk = inmsk | outmsk;
> +
> + imap->im_cpm.cp_pedir = (imap->im_cpm.cp_pedir & ~inmsk) | outmsk;
> + imap->im_cpm.cp_peodr &= ~msk;
> + imap->im_cpm.cp_pepar &= ~msk;
> +}
I don't like this macros being board specific - can't you simplify/beautify
this all?
> +
> +/**********************************************/
> +
> +unsigned long pin_lock(void);
> +void pin_unlock(unsigned long flags);
> +
> +#endif /* __ASSEMBLY */
> +
> +/******************************************************************************/
> +
> +/* NAND flash pins */
> +
> +#define F_ALE_PORT PORTC
> +#define F_ALE_BIT 15
> +
> +#define F_CLE_PORT PORTB
> +#define F_CLE_BIT 23
> +
> +#define F_CE_PORT PORTA
> +#define F_CE_BIT 7
> +
> +#define F_RY_BY_PORT PORTA
> +#define F_RY_BY_BIT 6
> +
> +/***********************************************************************/
> +
> +/* SPI pin definitions */
> +
> +#define SPI_RXD_PORT PORTB
> +#define SPI_RXD_BIT 28
> +
> +#define SPI_TXD_PORT PORTB
> +#define SPI_TXD_BIT 29
> +
> +#define SPI_CLK_PORT PORTB
> +#define SPI_CLK_BIT 30
> +
> +#define SPI_DELAY() udelay(1)
> +
> +#ifndef __ASSEMBLY__
> +
> +static inline unsigned int spi_transfer(unsigned int tx)
> +{
> + unsigned int rx;
> + int i;
> +
> + rx = 0;
> + for (i = 0; i < 8; i++) {
> + _PIN_SET(SPI_TXD, tx & 0x80);
> + tx <<= 1;
> + _PIN_TGL(SPI_CLK);
> + SPI_DELAY();
> + rx <<= 1;
> + rx |= _PIN_GET(SPI_RXD);
> + _PIN_TGL(SPI_CLK);
> + SPI_DELAY();
> + }
> +
> + return rx;
> +}
> +
> +#endif
> +
> +#define BOARD_CHIP_NAME "MPC870"
> +
> +#endif /* __MACH_STXXTC_DEFS */
> +
> diff --git a/arch/ppc/platforms/stxxtc_setup.c b/arch/ppc/platforms/stxxtc_setup.c
> new file mode 100644
> --- /dev/null
> +++ b/arch/ppc/platforms/stxxtc_setup.c
> @@ -0,0 +1,193 @@
> +/*
> + * arch/ppc/platforms/stxxtc.c
> + *
> + * Platform setup for the Silicon Turnkey eXpress XTc
> + */
> +
> +#include <linux/config.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/param.h>
> +#include <linux/string.h>
> +#include <linux/ioport.h>
> +#include <linux/device.h>
> +
> +#include <asm/delay.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/page.h>
> +#include <asm/processor.h>
> +#include <asm/system.h>
> +#include <asm/time.h>
> +#include <asm/ppcboot.h>
> +#include <asm/ppc_sys.h>
> +
> +#include <linux/stddef.h>
> +
> +#include <linux/fs_enet_pd.h>
> +
> +#include <platforms/stxxtc.h>
> +
> +/***********************************************************************/
> +
> +#ifdef CONFIG_FW_ENV
> +#include <syslib/fw_env.h>
> +
> +static const char *ro_vars[] = {
> + "ethaddr", "eth1addr", "adsladdr", "serial#", "usbaddr", "usb1addr", "ver", "board",
> + NULL
> +};
> +#endif
> +
> +/***********************************************************************/
> +
> +static spinlock_t port_spinlock;
> +
> +unsigned long pin_lock(void)
> +{
> + unsigned long flags;
> +
> + spin_lock_irqsave(&port_spinlock, flags);
> + return flags;
> +}
> +EXPORT_SYMBOL(pin_lock);
> +
> +void pin_unlock(unsigned long flags)
> +{
> + spin_unlock_irqrestore(&port_spinlock, flags);
> +}
> +EXPORT_SYMBOL(pin_unlock);
Unused? Why do you need this?
> +
> +/***********************************************************************/
> +
> +static struct fs_mii_bus_info fec_mii_bus_info = {
> + .method = fsmii_fec,
> + .id = 0,
> +};
> +
> +static struct fs_platform_info mpc8xx_fec_pdata[2] = {
> + [0] = {
> + .phy_addr = 0x01,
> + .phy_irq = -1,
> + .fs_no = fsid_fec1,
> + .rx_ring = 128,
> + .tx_ring = 16,
> + .napi_weight = 17,
> + .bus_info = &fec_mii_bus_info,
> + .rx_copybreak = 240,
> + .use_napi = 1,
> + .use_rmii = 0,
> + },
> + [1] = {
> + .phy_addr = 0x03,
> + .phy_irq = -1,
> + .fs_no = fsid_fec2,
> + .rx_ring = 128,
> + .tx_ring = 16,
> + .napi_weight = 17,
> + .bus_info = &fec_mii_bus_info,
> + .rx_copybreak = 240,
> + .use_napi = 1,
> + .use_rmii = 0,
> + }
> +};
> +
> +/***********************************************************************/
> +
> +static void stxxtc_fixup_fs_pdata(struct platform_device *pd, int fs_no)
> +{
> + struct fs_platform_info *fpi;
> + bd_t *bd;
> + int idx;
> +
> + idx = fs_get_fec_index(fs_no);
> + if (idx == -1) {
> + printk(KERN_ERR "stxxtc_setup: Only FEC ethernets supported by STXXTC.\n");
> + return;
> + }
> +
> + fpi = &mpc8xx_fec_pdata[idx];
> +
> + bd = (bd_t *)__res;
> +
> + memcpy(fpi->macaddr, bd->bi_enetaddr, 6);
> + fpi->macaddr[5] += idx; /* different per interface */
> +
> + pd->dev.platform_data = fpi;
> +
> + /* we don't setup *any* pins, we trust the bootloader */
> +}
> +
> +static void stxxtc_fixup_fec_pdata(struct platform_device *pd, int idx)
> +{
> + int fs_no = fsid_fec1 + pd->id - 1;
> +
> + stxxtc_fixup_fs_pdata(pd, fs_no);
> +}
> +
> +static int stxxtc_platform_notify(struct device *dev)
> +{
> + static struct {
> + const char *bus_id;
> + void (*rtn)(struct platform_device * pdev, int idx);
> + } dev_map[] = {
> + { "fsl-cpm-fec", stxxtc_fixup_fec_pdata },
> + };
> + struct platform_device *pdev;
> + int i, j, idx;
> + const char *s;
> +
> + if (dev && dev->bus_id)
> + for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
> + idx = -1;
> + if ((s = strrchr(dev->bus_id, '.')) != NULL)
> + idx = (int)simple_strtol(s + 1, NULL, 10);
> + else
> + s = dev->bus_id + strlen(s);
> +
> + j = s - dev->bus_id;
> +
> + if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
> + pdev = container_of(dev, struct platform_device, dev);
> + dev_map[i].rtn(pdev, idx);
> + }
> + }
> +
> + return 0;
> +}
Isnt a lot of this common code between all boards? (other than the dev_map array
definition).
> +
> +int __init
> +stxxtc_init(void)
> +{
> + immap_t *imap = (immap_t *)IMAP_ADDR;
> +
> + spin_lock_init(&port_spinlock);
> +
> + imap->im_siu_conf.sc_sypcr |= 0x0000FF00;
> +
> + /* configure SPI pins */
> + _PIN_CFG_OUT_HI(SPI_TXD);
> + _PIN_CFG_OUT_HI(SPI_CLK);
> + _PIN_CFG_IN(SPI_RXD);
> +
> + /* configure NAND pins */
> + _PIN_CFG_OUT_LO(F_ALE);
> + _PIN_CFG_OUT_LO(F_CLE);
> + _PIN_CFG_OUT_HI(F_CE);
> + _PIN_CFG_IN(F_RY_BY);
> +
> + platform_notify = stxxtc_platform_notify;
> +
> + identify_ppc_sys_by_name("MPC885");
> +
> + /* remove these devices */
> + ppc_sys_device_remove(MPC8xx_CPM_SCC1);
> + ppc_sys_device_remove(MPC8xx_CPM_SCC2);
> + ppc_sys_device_remove(MPC8xx_CPM_SCC3);
> + ppc_sys_device_remove(MPC8xx_CPM_SCC4);
> +
> + return 0;
> +}
> +
> +arch_initcall(stxxtc_init);
> +
> diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
> --- a/arch/ppc/syslib/m8xx_setup.c
> +++ b/arch/ppc/syslib/m8xx_setup.c
> @@ -370,16 +370,26 @@ m8xx_map_io(void)
> #if defined(CONFIG_NETTA)
> io_block_mapping(_IO_BASE,_IO_BASE,_IO_BASE_SIZE, _PAGE_IO);
> #endif
> +#if defined(CONFIG_STXXTC)
> + io_block_mapping(_IO_BASE,_IO_BASE,64 << 10, _PAGE_IO);
64<<10 = IO_BASE_SIZE?
> +#endif
> }
>
> void __init
> platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> unsigned long r6, unsigned long r7)
> {
> + bd_t *bd;
> +
> parse_bootinfo(find_bootinfo());
>
> - if ( r3 )
> - memcpy( (void *)__res,(void *)(r3+KERNELBASE), sizeof(bd_t) );
> + if ( r3 ) {
> + bd = (bd_t *)(r3+KERNELBASE);
> + /* skip OF tree if present */
> + if (*(u32 *)bd == 0xd00dfeed)
> + bd = (bd_t *)((char *)bd + ((u32 *)bd)[1]);
> + memcpy(__res, bd, sizeof(bd_t));
> + }
Separate patch?
>
> #ifdef CONFIG_PCI
> m8xx_setup_pci_ptrs();
> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> --- a/drivers/mtd/maps/Kconfig
> +++ b/drivers/mtd/maps/Kconfig
> @@ -639,5 +639,11 @@ config MTD_PLATRAM
>
> This selection automatically selects the map_ram driver.
>
> +config MTD_STXXTC_NOR
> + tristate "NOR Map driver for STXXTC NOR flash"
> + depends on STXXTC && MTD_CONCAT && MTD_PARTITIONS && MTD_CFI_INTELEXT
> + help
> + Map driver for Silicon Turnkey eXpress XTc NOR flash.
> +
> endmenu
Would be easier if the flash driver was a separate patch.
^ permalink raw reply
* Re: [PATCH] Support 8xx based Silicon Turnkey XTc
From: Wolfgang Denk @ 2005-12-06 16:01 UTC (permalink / raw)
To: pantelis.antoniou; +Cc: Robert Applebaum, linuxppc-embedded
In-Reply-To: <200512052115.45858.pantelis.antoniou@gmail.com>
Dear Pantelis,
in message <200512052115.45858.pantelis.antoniou@gmail.com> you wrote:
> Support of Silicon Turnkey's XTc.
Ummm .. a few questions...
> arch/ppc/platforms/stxxtc.h | 285 +++++++++++++
Here you include a lot of inlined code, but I have problems finding
out what it is good for. For example, there is a full-blown
bit-banging SPI driver included which is nowhere referenced.
Am I missing something, or should this be cleaned up a bit?
> drivers/mtd/maps/stxxtc_nor.c | 326 +++++++++++++++
I think it is not a good idea to embed spaces in the flash map names,
as this will make it impossible to select such devices from the
kernel command line which you seem to intend (at least you have
CONFIG_MTD_CMDLINE_PARTS enabled in your default configuration) ?
And a design question: Why are you using the concatenating (NOR)
flash driver? Why don't you simply map the flashes (in U-Boot) such
that you have one contiguous region? That would make flash use in
U-Boot much more convenient, too.
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
Where would we be without rhetorical questions?
^ permalink raw reply
* Denx vs kernel.org
From: Matt Jerdonek @ 2005-12-06 16:42 UTC (permalink / raw)
To: linuxppc-embedded
I'm looking at embedding linux into a PowerPC-based
system. I found the DENX website to be very helpful,
but I'm struggling to understand a few items:
1) The source from kernel.org appears to have support
for the powerpc (arch/powerpc/8xx_io). But when using
'make xconfig' I cannot select PowerPC from the list
of processors. Is this just a limitation on the the
configuration utility?
2) What is the difference between the sources on DENX
and kernel.org? Are there other places where PPC
linux kernel source is stored? I'm not opposed to
using the DENX source, I'm just trying to understand
it.
3) I've used eCos before and I'm familiar with
RedBoot. Is there a compelling reason to use U-Boot
over RedBoot? For example, I think U-boot contains an
NFS client while RedBoot does not. Is this important?
Thanks in advance,
-- Matt
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
^ permalink raw reply
* Re: [PATCH] Support 8xx based Silicon Turnkey XTc
From: Pantelis Antoniou @ 2005-12-06 17:02 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Robert Applebaum, linuxppc-embedded
In-Reply-To: <20051206153659.GA6771@dmt.cnet>
On Tuesday 06 December 2005 17:36, Marcelo Tosatti wrote:
> Hi Panto!
>
Hi Marcelo!
> On Mon, Dec 05, 2005 at 09:15:43PM +0200, Pantelis Antoniou wrote:
> > Support of Silicon Turnkey's XTc.
> >
> > ---
> > commit fac9bbd80d8f8ab3c6af5a417f804dbf8537c700
> > tree 7863f94249651a26ca3eb29aed4c65c214968dda
> > parent e4f5c82a92c2a546a16af1614114eec19120e40a
> > author Pantelis Antoniou <pantelis.antoniou@gmail.com> Mon, 05 Dec 2005 21:13:56 +0200
> > committer Pantelis Antoniou <pantelis.antoniou@gmail.com> Mon, 05 Dec 2005 21:13:56 +0200
> >
> > arch/ppc/Kconfig | 5
> > arch/ppc/configs/stxxtc_defconfig | 804 +++++++++++++++++++++++++++++++++++++
> > arch/ppc/platforms/Makefile | 1
> > arch/ppc/platforms/stxxtc.h | 285 +++++++++++++
> > arch/ppc/platforms/stxxtc_setup.c | 193 +++++++++
> > arch/ppc/syslib/m8xx_setup.c | 14 +
> > drivers/mtd/maps/Kconfig | 6
> > drivers/mtd/maps/Makefile | 1
> > drivers/mtd/maps/stxxtc_nor.c | 326 +++++++++++++++
> > drivers/mtd/nand/Kconfig | 8
> > drivers/mtd/nand/Makefile | 1
> > drivers/mtd/nand/stxxtc_nand.c | 277 +++++++++++++
> > include/asm-ppc/mpc8xx.h | 4
> > 13 files changed, 1922 insertions(+), 3 deletions(-)
> >
>
> > +# CONFIG_PIN_TLB is not set
>
> Might want to enable by default?
>
Not a bad idea.
> > diff --git a/arch/ppc/platforms/stxxtc.h b/arch/ppc/platforms/stxxtc.h
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/ppc/platforms/stxxtc.h
> > @@ -0,0 +1,285 @@
> > +/*
> > + * A collection of structures, addresses, and values associated with
> > + * the STXXTC systems.
> > + *
> > + * Copyright (c) 2005 Pantelis Antoniou <pantelis.antoniou@gmail.com>
> > + * Dan Malek <dan@embeddedalley.com>
> > + *
> > + */
> > +#ifndef __MACH_STXXTC_DEFS
> > +#define __MACH_STXXTC_DEFS
> > +
> > +#include <linux/config.h>
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +#include <asm/ppcboot.h>
> > +
> > +#include <asm/8xx_immap.h>
> > +#include <asm/commproc.h>
> > +#include <asm/mpc8xx.h>
> > +#include <asm/delay.h>
> > +
> > +#endif
> > +
> > +#define IMAP_ADDR 0xFF000000 /* physical base address of IMMR area */
>
> Extra TAB (or missing tab below, whatever you prefer ;)
>
Nice catch.
> > +#define IMAP_SIZE (64 * 1024) /* mapped size of IMMR area */
>
> > +
> > +/* We don't use the 8259.
> > +*/
> > +#define NR_8259_INTS 0
> > +
> > +#define NAND_SIZE 0x00010000
> > +#define NAND_BASE 0xF1000000
> > +
> > +/*-----------------------------------------------------------------------
> > + * PCMCIA stuff
> > + *-----------------------------------------------------------------------
> > + *
> > + */
> > +#define PCMCIA_MEM_SIZE ( 64 << 20 )
> > +
> > +#define MAX_HWIFS 1 /* overwrite default in include/asm-ppc/ide.h */
> > +
> > +/*
> > + * Definitions for IDE0 Interface
> > + */
> > +#define IDE0_BASE_OFFSET 0
> > +#define IDE0_DATA_REG_OFFSET (PCMCIA_MEM_SIZE + 0x320)
> > +#define IDE0_ERROR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 1)
> > +#define IDE0_NSECTOR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 2)
> > +#define IDE0_SECTOR_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 3)
> > +#define IDE0_LCYL_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 4)
> > +#define IDE0_HCYL_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 5)
> > +#define IDE0_SELECT_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 6)
> > +#define IDE0_STATUS_REG_OFFSET (2 * PCMCIA_MEM_SIZE + 0x320 + 7)
> > +#define IDE0_CONTROL_REG_OFFSET 0x0106
> > +#define IDE0_IRQ_REG_OFFSET 0x000A /* not used */
> > +
> > +#define IDE0_INTERRUPT 13
> > +
> > +/* XXX FUCK!, for IDE disk set to 0, for normal PCMCIA set to 1 */
> > +/* XXX don't ask me why.. */
>
> Can you make the comment a bit nicer? :)
>
OK. We don't want to offend our politically correct viewers, don't we? :)
> > +#if 1
> > +/* define IO_BASE for PCMCIA */
> > +#define _IO_BASE 0x80000000
> > +#define _IO_BASE_SIZE (64<<10)
> > +#endif
> > +
> > +/***********************************************************************/
> > +
> > +/* shorthand for the ports data registers */
> > +#define PORTA (((volatile immap_t *)IMAP_ADDR)->im_ioport.iop_padat)
> > +#define PORTB (((volatile immap_t *)IMAP_ADDR)->im_cpm.cp_pbdat)
> > +#define PORTC (((volatile immap_t *)IMAP_ADDR)->im_ioport.iop_pcdat)
> > +#define PORTD (((volatile immap_t *)IMAP_ADDR)->im_ioport.iop_pddat)
> > +#define PORTE (((volatile immap_t *)IMAP_ADDR)->im_cpm.cp_pedat)
> > +
> > +/********************************************************************************/
> > +
> > +#define PIN_PORT_EQ(p, x) ((void *) & x ## _PORT == (void *) & p)
> > +#define PIN_PORT_NE(p, x) ((void *) & x ## _PORT != (void *) & p)
> > +
> > +#define PIN_PORT_RW(x) (PIN_PORT_NE(PORTXWO, x) && PIN_PORT_NE(PORTXRO, x))
> > +#define PIN_PORT_RO(x) PIN_PORT_EQ(PORTXRO, x)
> > +#define PIN_PORT_WO(x) PIN_PORT_EQ(PORTXWO, x)
> > +
> > +/********************************************************************************/
> > +
> > +#define PIN_SFT(x) ((sizeof(x ## _PORT) * 8 - 1) - x ## _BIT)
> > +#define PIN_MSK(x) (1U << PIN_SFT(x))
> > +
> > +/********************************************************************************/
> > +
> > +/* normal m8xx pins */
> > +#define _PIN_HI(x) \
> > + do { \
> > + x ## _PORT |= PIN_MSK(x); \
> > + } while(0)
> > +
> > +#define _PIN_LO(x) \
> > + do { \
> > + x ## _PORT &= ~PIN_MSK(x); \
> > + } while(0)
> > +
> > +#define _PIN_TGL(x) \
> > + do { \
> > + x ## _PORT ^= PIN_MSK(x); \
> > + } while(0)
> > +
> > +#define _PIN_GET(x) \
> > + (!!(x ## _PORT & PIN_MSK(x)))
> > +
> > +#define _PIN_SET(x, v) \
> > + do { \
> > + if (__builtin_constant_p(v)) { \
> > + if ((v) != 0) \
> > + _PIN_HI(x); \
> > + else \
> > + _PIN_LO(x); \
> > + } else \
> > + x ## _PORT = ( x ## _PORT & ~PIN_MSK(x)) | (!!(v) << PIN_SFT(x)); \
> > + } while(0)
> > +
> > +#define _PIN_CFG_IN(x) \
> > + do { \
> > + if (PIN_PORT_EQ(PORTA, x)) \
> > + PORTA_config(PIN_MSK(x), 0, 0); \
> > + if (PIN_PORT_EQ(PORTB, x)) \
> > + PORTB_config(PIN_MSK(x), 0, 0); \
> > + if (PIN_PORT_EQ(PORTC, x)) \
> > + PORTC_config(PIN_MSK(x), 0, 0); \
> > + if (PIN_PORT_EQ(PORTD, x)) \
> > + PORTD_config(PIN_MSK(x), 0, 0); \
> > + if (PIN_PORT_EQ(PORTE, x)) \
> > + PORTE_config(PIN_MSK(x), 0, 0); \
> > + } while(0)
> > +
> > +#define _PIN_CFG_INT_ANY(x) \
> > + do { \
> > + if (PIN_PORT_EQ(PORTC, x)) \
> > + PORTC_config(PIN_MSK(x), 0, 0); \
> > + } while(0)
> > +
> > +#define _PIN_CFG_INT_FALL(x) \
> > + do { \
> > + if (PIN_PORT_EQ(PORTC, x)) \
> > + PORTC_config(PIN_MSK(x), 0, 0); \
> > + } while(0)
> > +
> > +#define _PIN_CFG_OUT(x, v) \
> > + do { \
> > + _PIN_SET(x, v); \
> > + if (PIN_PORT_EQ(PORTA, x)) \
> > + PORTA_config(0, PIN_MSK(x), 0); \
> > + if (PIN_PORT_EQ(PORTB, x)) \
> > + PORTB_config(0, PIN_MSK(x), 0); \
> > + if (PIN_PORT_EQ(PORTC, x)) \
> > + PORTC_config(0, PIN_MSK(x), 0); \
> > + if (PIN_PORT_EQ(PORTD, x)) \
> > + PORTD_config(0, PIN_MSK(x), 0); \
> > + if (PIN_PORT_EQ(PORTE, x)) \
> > + PORTE_config(0, PIN_MSK(x), 0); \
> > + } while(0)
> > +
> > +#define _PIN_CFG_OUT_HI(x) _PIN_CFG_OUT(x, 1)
> > +#define _PIN_CFG_OUT_LO(x) _PIN_CFG_OUT(x, 0)
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +static inline void PORTA_config(uint inmsk, uint outmsk, uint dummy)
> > +{
> > + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> > + ushort msk = (ushort)inmsk | (ushort)outmsk;
> > +
> > + imap->im_ioport.iop_padir = (imap->im_ioport.iop_padir & ~(ushort)inmsk) | (ushort)outmsk;
> > + imap->im_ioport.iop_paodr &= ~msk;
> > + imap->im_ioport.iop_papar &= ~msk;
> > +}
> > +
> > +static inline void PORTB_config(uint inmsk, uint outmsk, uint dummy)
> > +{
> > + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> > + uint msk = inmsk | outmsk;
> > +
> > + imap->im_cpm.cp_pbdir = (imap->im_cpm.cp_pbdir & ~inmsk) | outmsk;
> > + imap->im_cpm.cp_pbodr &= ~msk;
> > + imap->im_cpm.cp_pbpar &= ~msk;
> > +}
> > +
> > +static inline void PORTC_config(uint inmsk, uint outmsk, uint fallmsk)
> > +{
> > + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> > + ushort msk = (ushort)inmsk | (ushort)outmsk;
> > +
> > + imap->im_ioport.iop_pcdir = (imap->im_ioport.iop_pcdir & ~(ushort)inmsk) | (ushort)outmsk;
> > + imap->im_ioport.iop_pcso &= ~msk;
> > + imap->im_ioport.iop_pcint = (imap->im_ioport.iop_pcint & ~(ushort)inmsk) | ((ushort)fallmsk & (ushort)inmsk);
> > + imap->im_ioport.iop_pcpar &= ~msk;
> > +}
> > +
> > +static inline void PORTD_config(uint inmsk, uint outmsk, uint dummy)
> > +{
> > + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> > + ushort msk = (ushort)inmsk | (ushort)outmsk;
> > +
> > + imap->im_ioport.iop_pddir = (imap->im_ioport.iop_pddir & ~(ushort)inmsk) | (ushort)outmsk;
> > + imap->im_ioport.iop_pdpar &= ~msk;
> > +}
> > +
> > +static inline void PORTE_config(uint inmsk, uint outmsk, uint dummy)
> > +{
> > + volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
> > + uint msk = inmsk | outmsk;
> > +
> > + imap->im_cpm.cp_pedir = (imap->im_cpm.cp_pedir & ~inmsk) | outmsk;
> > + imap->im_cpm.cp_peodr &= ~msk;
> > + imap->im_cpm.cp_pepar &= ~msk;
> > +}
>
> I don't like this macros being board specific - can't you simplify/beautify
> this all?
>
Understood. I'll try to clean & clarify the rationale between these
(admitably) obscure macros.
> > +
> > +/**********************************************/
> > +
> > +unsigned long pin_lock(void);
> > +void pin_unlock(unsigned long flags);
> > +
> > +#endif /* __ASSEMBLY */
> > +
> > +/******************************************************************************/
> > +
> > +/* NAND flash pins */
> > +
> > +#define F_ALE_PORT PORTC
> > +#define F_ALE_BIT 15
> > +
> > +#define F_CLE_PORT PORTB
> > +#define F_CLE_BIT 23
> > +
> > +#define F_CE_PORT PORTA
> > +#define F_CE_BIT 7
> > +
> > +#define F_RY_BY_PORT PORTA
> > +#define F_RY_BY_BIT 6
> > +
> > +/***********************************************************************/
> > +
> > +/* SPI pin definitions */
> > +
> > +#define SPI_RXD_PORT PORTB
> > +#define SPI_RXD_BIT 28
> > +
> > +#define SPI_TXD_PORT PORTB
> > +#define SPI_TXD_BIT 29
> > +
> > +#define SPI_CLK_PORT PORTB
> > +#define SPI_CLK_BIT 30
> > +
> > +#define SPI_DELAY() udelay(1)
> > +
> > +#ifndef __ASSEMBLY__
> > +
> > +static inline unsigned int spi_transfer(unsigned int tx)
> > +{
> > + unsigned int rx;
> > + int i;
> > +
> > + rx = 0;
> > + for (i = 0; i < 8; i++) {
> > + _PIN_SET(SPI_TXD, tx & 0x80);
> > + tx <<= 1;
> > + _PIN_TGL(SPI_CLK);
> > + SPI_DELAY();
> > + rx <<= 1;
> > + rx |= _PIN_GET(SPI_RXD);
> > + _PIN_TGL(SPI_CLK);
> > + SPI_DELAY();
> > + }
> > +
> > + return rx;
> > +}
> > +
> > +#endif
> > +
> > +#define BOARD_CHIP_NAME "MPC870"
> > +
> > +#endif /* __MACH_STXXTC_DEFS */
> > +
> > diff --git a/arch/ppc/platforms/stxxtc_setup.c b/arch/ppc/platforms/stxxtc_setup.c
> > new file mode 100644
> > --- /dev/null
> > +++ b/arch/ppc/platforms/stxxtc_setup.c
> > @@ -0,0 +1,193 @@
> > +/*
> > + * arch/ppc/platforms/stxxtc.c
> > + *
> > + * Platform setup for the Silicon Turnkey eXpress XTc
> > + */
> > +
> > +#include <linux/config.h>
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/param.h>
> > +#include <linux/string.h>
> > +#include <linux/ioport.h>
> > +#include <linux/device.h>
> > +
> > +#include <asm/delay.h>
> > +#include <asm/io.h>
> > +#include <asm/machdep.h>
> > +#include <asm/page.h>
> > +#include <asm/processor.h>
> > +#include <asm/system.h>
> > +#include <asm/time.h>
> > +#include <asm/ppcboot.h>
> > +#include <asm/ppc_sys.h>
> > +
> > +#include <linux/stddef.h>
> > +
> > +#include <linux/fs_enet_pd.h>
> > +
> > +#include <platforms/stxxtc.h>
> > +
> > +/***********************************************************************/
> > +
> > +#ifdef CONFIG_FW_ENV
> > +#include <syslib/fw_env.h>
> > +
> > +static const char *ro_vars[] = {
> > + "ethaddr", "eth1addr", "adsladdr", "serial#", "usbaddr", "usb1addr", "ver", "board",
> > + NULL
> > +};
> > +#endif
> > +
> > +/***********************************************************************/
> > +
> > +static spinlock_t port_spinlock;
> > +
> > +unsigned long pin_lock(void)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&port_spinlock, flags);
> > + return flags;
> > +}
> > +EXPORT_SYMBOL(pin_lock);
> > +
> > +void pin_unlock(unsigned long flags)
> > +{
> > + spin_unlock_irqrestore(&port_spinlock, flags);
> > +}
> > +EXPORT_SYMBOL(pin_unlock);
>
> Unused? Why do you need this?
>
It's not used in these drivers. I need the lock to protect
potential port accesses coherent.
> > +
> > +/***********************************************************************/
> > +
> > +static struct fs_mii_bus_info fec_mii_bus_info = {
> > + .method = fsmii_fec,
> > + .id = 0,
> > +};
> > +
> > +static struct fs_platform_info mpc8xx_fec_pdata[2] = {
> > + [0] = {
> > + .phy_addr = 0x01,
> > + .phy_irq = -1,
> > + .fs_no = fsid_fec1,
> > + .rx_ring = 128,
> > + .tx_ring = 16,
> > + .napi_weight = 17,
> > + .bus_info = &fec_mii_bus_info,
> > + .rx_copybreak = 240,
> > + .use_napi = 1,
> > + .use_rmii = 0,
> > + },
> > + [1] = {
> > + .phy_addr = 0x03,
> > + .phy_irq = -1,
> > + .fs_no = fsid_fec2,
> > + .rx_ring = 128,
> > + .tx_ring = 16,
> > + .napi_weight = 17,
> > + .bus_info = &fec_mii_bus_info,
> > + .rx_copybreak = 240,
> > + .use_napi = 1,
> > + .use_rmii = 0,
> > + }
> > +};
> > +
> > +/***********************************************************************/
> > +
> > +static void stxxtc_fixup_fs_pdata(struct platform_device *pd, int fs_no)
> > +{
> > + struct fs_platform_info *fpi;
> > + bd_t *bd;
> > + int idx;
> > +
> > + idx = fs_get_fec_index(fs_no);
> > + if (idx == -1) {
> > + printk(KERN_ERR "stxxtc_setup: Only FEC ethernets supported by STXXTC.\n");
> > + return;
> > + }
> > +
> > + fpi = &mpc8xx_fec_pdata[idx];
> > +
> > + bd = (bd_t *)__res;
> > +
> > + memcpy(fpi->macaddr, bd->bi_enetaddr, 6);
> > + fpi->macaddr[5] += idx; /* different per interface */
> > +
> > + pd->dev.platform_data = fpi;
> > +
> > + /* we don't setup *any* pins, we trust the bootloader */
> > +}
> > +
> > +static void stxxtc_fixup_fec_pdata(struct platform_device *pd, int idx)
> > +{
> > + int fs_no = fsid_fec1 + pd->id - 1;
> > +
> > + stxxtc_fixup_fs_pdata(pd, fs_no);
> > +}
> > +
> > +static int stxxtc_platform_notify(struct device *dev)
> > +{
> > + static struct {
> > + const char *bus_id;
> > + void (*rtn)(struct platform_device * pdev, int idx);
> > + } dev_map[] = {
> > + { "fsl-cpm-fec", stxxtc_fixup_fec_pdata },
> > + };
> > + struct platform_device *pdev;
> > + int i, j, idx;
> > + const char *s;
> > +
> > + if (dev && dev->bus_id)
> > + for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
> > + idx = -1;
> > + if ((s = strrchr(dev->bus_id, '.')) != NULL)
> > + idx = (int)simple_strtol(s + 1, NULL, 10);
> > + else
> > + s = dev->bus_id + strlen(s);
> > +
> > + j = s - dev->bus_id;
> > +
> > + if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
> > + pdev = container_of(dev, struct platform_device, dev);
> > + dev_map[i].rtn(pdev, idx);
> > + }
> > + }
> > +
> > + return 0;
> > +}
>
> Isnt a lot of this common code between all boards? (other than the dev_map array
> definition).
>
True. But currently I see no other way to do it, since it is not totally generic.
> > +
> > +int __init
> > +stxxtc_init(void)
> > +{
> > + immap_t *imap = (immap_t *)IMAP_ADDR;
> > +
> > + spin_lock_init(&port_spinlock);
> > +
> > + imap->im_siu_conf.sc_sypcr |= 0x0000FF00;
> > +
> > + /* configure SPI pins */
> > + _PIN_CFG_OUT_HI(SPI_TXD);
> > + _PIN_CFG_OUT_HI(SPI_CLK);
> > + _PIN_CFG_IN(SPI_RXD);
> > +
> > + /* configure NAND pins */
> > + _PIN_CFG_OUT_LO(F_ALE);
> > + _PIN_CFG_OUT_LO(F_CLE);
> > + _PIN_CFG_OUT_HI(F_CE);
> > + _PIN_CFG_IN(F_RY_BY);
> > +
> > + platform_notify = stxxtc_platform_notify;
> > +
> > + identify_ppc_sys_by_name("MPC885");
> > +
> > + /* remove these devices */
> > + ppc_sys_device_remove(MPC8xx_CPM_SCC1);
> > + ppc_sys_device_remove(MPC8xx_CPM_SCC2);
> > + ppc_sys_device_remove(MPC8xx_CPM_SCC3);
> > + ppc_sys_device_remove(MPC8xx_CPM_SCC4);
> > +
> > + return 0;
> > +}
> > +
> > +arch_initcall(stxxtc_init);
> > +
> > diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
> > --- a/arch/ppc/syslib/m8xx_setup.c
> > +++ b/arch/ppc/syslib/m8xx_setup.c
> > @@ -370,16 +370,26 @@ m8xx_map_io(void)
> > #if defined(CONFIG_NETTA)
> > io_block_mapping(_IO_BASE,_IO_BASE,_IO_BASE_SIZE, _PAGE_IO);
> > #endif
> > +#if defined(CONFIG_STXXTC)
> > + io_block_mapping(_IO_BASE,_IO_BASE,64 << 10, _PAGE_IO);
>
> 64<<10 = IO_BASE_SIZE?
>
Ugh, yes.
> > +#endif
> > }
> >
> > void __init
> > platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> > unsigned long r6, unsigned long r7)
> > {
> > + bd_t *bd;
> > +
> > parse_bootinfo(find_bootinfo());
> >
> > - if ( r3 )
> > - memcpy( (void *)__res,(void *)(r3+KERNELBASE), sizeof(bd_t) );
> > + if ( r3 ) {
> > + bd = (bd_t *)(r3+KERNELBASE);
> > + /* skip OF tree if present */
> > + if (*(u32 *)bd == 0xd00dfeed)
> > + bd = (bd_t *)((char *)bd + ((u32 *)bd)[1]);
> > + memcpy(__res, bd, sizeof(bd_t));
> > + }
>
> Separate patch?
>
If you say so.
> >
> > #ifdef CONFIG_PCI
> > m8xx_setup_pci_ptrs();
> > diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> > --- a/drivers/mtd/maps/Kconfig
> > +++ b/drivers/mtd/maps/Kconfig
> > @@ -639,5 +639,11 @@ config MTD_PLATRAM
> >
> > This selection automatically selects the map_ram driver.
> >
> > +config MTD_STXXTC_NOR
> > + tristate "NOR Map driver for STXXTC NOR flash"
> > + depends on STXXTC && MTD_CONCAT && MTD_PARTITIONS && MTD_CFI_INTELEXT
> > + help
> > + Map driver for Silicon Turnkey eXpress XTc NOR flash.
> > +
> > endmenu
>
> Would be easier if the flash driver was a separate patch.
>
Hrmf. OK
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH] ppc32: Adds MPC885ADS, MPC866ADS and MPC8272ADS-specific platform stuff for fs_enet
From: Marcelo Tosatti @ 2005-12-06 17:13 UTC (permalink / raw)
To: Vitaly Bordug, Pantelis Antoniou; +Cc: BLandau, linuxppc-embedded list
In-Reply-To: <438B379B.6090904@ru.mvista.com>
On Mon, Nov 28, 2005 at 08:00:11PM +0300, Vitaly Bordug wrote:
> Added proper ppc_sys identification and fs_platform_info's for MPC 885ADS,
> 866ADS and 8272ADS. Assuming setbitsXX/clrbitsXX patch is applied.
>
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
diff --git a/arch/ppc/platforms/mpc8272ads_setup.c b/arch/ppc/platforms/mpc8272ads_setup.c
new file mode 100644
index 0000000..4f76b1b
--- /dev/null
+++ b/arch/ppc/platforms/mpc8272ads_setup.c
@@ -0,0 +1,253 @@
+/*
+ * arch/ppc/platforms/82xx/pq2ads_pd.c
+ *
+ * MPC82xx Board-specific PlatformDevice descriptions
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug <vbordug@ru.mvista.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
<snip>
+static int __init mpc8272ads_platform_notify(struct device *dev)
+{
+ static struct {
+ const char *bus_id;
+ void (*rtn) (struct platform_device * pdev, int idx);
+ } dev_map[] = {
+ {"fsl-cpm-fcc", mpc8272ads_fixup_enet_pdata},
+ };
+ struct platform_device *pdev;
+ int i, j, idx;
+ const char *s;
+ if (dev && dev->bus_id)
+ for (i = 0; i < ARRAY_SIZE(dev_map); i++) {
+ idx = -1;
+
+ if ((s = strrchr(dev->bus_id, '.')) != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id;
+ j = s - dev->bus_id;
+ if (!strncmp(dev->bus_id, dev_map[i].bus_id, j)) {
+ pdev =
+ container_of(dev, struct platform_device,
+ dev);
+ dev_map[i].rtn(pdev, idx);
+ }
+ }
+ return 0;
+}
Seems this loop is common to all boards and should be moved to a helper
function?
^ permalink raw reply related
* Re: MPC85xx i2c interface bug
From: Kumar Gala @ 2005-12-06 17:24 UTC (permalink / raw)
To: Dan Wilson; +Cc: ppc list
In-Reply-To: <200511292318160218.0499BB92@smtp.dslextreme.com>
Dan,
I'm in agreement with your change for the 2.4 kernel. It looks like
the 2.6 kernel driver is handing TXAK correctly. The following is a
snippet from the 2.6 driver:
if (length) {
if (length == 1)
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA
| CCR_TXAK);
else
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA);
/* Dummy read */
readb(i2c->base + MPC_I2C_DR);
}
for (i = 0; i < length; i++) {
if (i2c_wait(i2c, timeout, 0) < 0)
return -1;
/* Generate txack on next to last byte */
if (i == length - 2)
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_MSTA
| CCR_TXAK);
/* Generate stop on last byte */
if (i == length - 1)
writeccr(i2c, CCR_MIEN | CCR_MEN | CCR_TXAK);
data[i] = readb(i2c->base + MPC_I2C_DR);
}
If I'm reading it correctly it matches your changes. If you dont
mind looking at this and verifying that you agree that we are setting
TXAK as expected.
- kumar
On Nov 30, 2005, at 1:18 AM, Dan Wilson wrote:
> On 11/30/2005 at 12:14 AM Kumar Gala wrote:
>
>> Dan,
>>
>> Did you see an issue this change fixed? If so can you provide more
>> details. Also, can you provide your diff as a unified diff (diff -
>> u) so
>> its easier to see where the changes where.
>>
>> I'm trying to figure out if the same issue exists in the 2.6
>> driver (and
>> if so, why we havent seen it)
>>
>> thanks
>>
>> - kumar
>>
>
> Yes, there was an issue that this change fixed. Our I2C bus has a
> number of devices on it. The first device is at address 0x2c, and
> is an Analog Device AD5173BRM50 software programmable 50K ohm
> resistor. We connected a logic analyzer to the device and watched
> the bus activity as linux booted and the i2c bus scan took place.
> During this scan, the 8541 attempts to address each device and then
> read a byte from the device. With the original code, the 8541
> would reply to the byte read by sending a zero as the TXACK bit,
> which instructed the 5173 to send an additional byte, but the 8541
> didn't attempt to retrieve that byte, since it was already moving
> on, trying to stop the bus and go on to the next device. The 5173
> appeared to not be able to see the stop command since it had
> received a command to transmit the next byte. The bus didn't seem
> to ever recover from this: if we allowed linux to complete it's
> boot and then told it to reboot, the u-boot code was no longer able
> to identify and configure the SDRAM, since it is also connected to
> the now non-functional I2C. With the new code, linux correctly
> identifies all of the devices on the I2C, boots quickly and
> cleanly, and after a reboot the u-boot code has no problem coming
> up again.
>
> Here is the diff -u that you requested:
>
> @@ -299,11 +299,11 @@
>
> if(pm->flags & I2C_M_RD) {
> /* Change to read mode */
> - priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX);
> + priv->write(®s->i2ccr, 0, MPC_I2CCR_MTX |
> MPC_I2CCR_TXAK);
>
> /* If there is only one byte, we need to TXAK now */
> if(len == 1)
> - priv->write(®s->i2ccr, 0, MPC_I2CCR_TXAK);
> + priv->write(®s->i2ccr, MPC_I2CCR_TXAK,
> MPC_I2CCR_TXAK);
>
> /* Do a dummy read, to initiate the first read */
> priv->read(®s->i2cdr);
> @@ -321,7 +321,7 @@
> /* If this is the 2nd to last byte, send
> * the TXAK signal */
> if(i == len - 2) {
> - priv->write(®s->i2ccr, 0,
> MPC_I2CCR_TXAK);
> + priv->write(®s->i2ccr,
> MPC_I2CCR_TXAK, MPC_I2CCR_TXAK);
> }
>
> /* If this is the last byte, send STOP */
> @@ -383,7 +383,6 @@
> priv->write(®s->i2csr, 0, MPC_I2CSR_MIF);
>
> mpc_i2c_start(priv);
> -
> /* Send each message, chaining them together with repeat
> STARTs */
> for(i = 0; i < num && !err; ++i) {
> err = mpc_doAddress(priv, &msgs[i]);
>
>
> Hope this helps,
>
> Dan.
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] Support 8xx based Silicon Turnkey XTc
From: Pantelis Antoniou @ 2005-12-06 17:41 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Robert Applebaum, linuxppc-embedded
In-Reply-To: <20051206160122.DC581353F5E@atlas.denx.de>
On Tuesday 06 December 2005 18:01, Wolfgang Denk wrote:
> Dear Pantelis,
>
> in message <200512052115.45858.pantelis.antoniou@gmail.com> you wrote:
> > Support of Silicon Turnkey's XTc.
>
> Ummm .. a few questions...
>
> > arch/ppc/platforms/stxxtc.h | 285 +++++++++++++
>
> Here you include a lot of inlined code, but I have problems finding
> out what it is good for. For example, there is a full-blown
> bit-banging SPI driver included which is nowhere referenced.
>
> Am I missing something, or should this be cleaned up a bit?
>
It is used in drivers not submitted at this point...
They'll be forthcoming when the time comes.
> > drivers/mtd/maps/stxxtc_nor.c | 326 +++++++++++++++
>
> I think it is not a good idea to embed spaces in the flash map names,
> as this will make it impossible to select such devices from the
> kernel command line which you seem to intend (at least you have
> CONFIG_MTD_CMDLINE_PARTS enabled in your default configuration) ?
>
>
Well, I guess you're right. Though I never used the kernel command
line for selecting the devices.
> And a design question: Why are you using the concatenating (NOR)
> flash driver? Why don't you simply map the flashes (in U-Boot) such
> that you have one contiguous region? That would make flash use in
> U-Boot much more convenient, too.
>
Unfortunately is not possible. Due to the way the flash is mapped on boot it
is not possible to have it continuous. Believe me I've tried :)
> 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
> Where would we be without rhetorical questions?
>
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH] Support 8xx based Silicon Turnkey XTc
From: Dan Malek @ 2005-12-06 17:45 UTC (permalink / raw)
To: pantelis.antoniou; +Cc: linuxppc-embedded, Robert Applebaum
In-Reply-To: <200512061941.37502.pantelis.antoniou@gmail.com>
On Dec 6, 2005, at 9:41 AM, Pantelis Antoniou wrote:
> Unfortunately is not possible. Due to the way the flash is mapped on
> boot it
> is not possible to have it continuous. Believe me I've tried :)
I can take the blame for this :-) We used the high boot address mode
which isn't good for the larger flashes due to the address aliasing.
I'm going to make an even bigger mess and in the next round of boards
will change to the low boot memory. Fortunately, there aren't too many
of this first version of boards, and those of us that have them will
just
have to adapt. :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: Denx vs kernel.org
From: White @ 2005-12-06 16:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051206164212.82779.qmail@web33505.mail.mud.yahoo.com>
Am Tue, 6 Dec 2005 08:42:12 -0800 (PST) schrieb Matt Jerdonek
<maj1224@yahoo.com> :
Hello
> I'm looking at embedding linux into a PowerPC-based
> system. I found the DENX website to be very helpful,
> but I'm struggling to understand a few items:
Welcome to our Club :)
>
> 1) The source from kernel.org appears to have support
> for the powerpc (arch/powerpc/8xx_io). But when using
> 'make xconfig' I cannot select PowerPC from the list
> of processors. Is this just a limitation on the the
> configuration utility?
Try setting ARCH=ppc or so...
make ARCH=ppc CROSS_COMPILE=xxx menuconfig uImage and so on
>
> 2) What is the difference between the sources on DENX
> and kernel.org? Are there other places where PPC
> linux kernel source is stored? I'm not opposed to
> using the DENX source, I'm just trying to understand
> it.
>
The Kernel Source is tested and released from many Developers.
The Denx Kernel is a kind of specialized.
Some parts are missing, some special patches aare in this Kernel,
the Mainstream Kernel developer dont want to add.
There are Other Sources too.
Google or some Docu Site fpr ppc linux can help.
> 3) I've used eCos before and I'm familiar with
> RedBoot. Is there a compelling reason to use U-Boot
> over RedBoot? For example, I think U-boot contains an
> NFS client while RedBoot does not. Is this important?
i'm booting the kernel in uboot over tftp.
You dont need nfs in u-boot...
i dont know redboot, but in uboot you can do many diagnostoc or
maintaining work at the Console.
Its easy to extend by special needs and support a lot of platforms.
>
> Thanks in advance,
> -- Matt
Good luck...
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Michael Neuling @ 2005-12-06 18:59 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1133816807.8577.50.camel@cashmere.sps.mot.com>
> dtc source code can be found at
> <http://ozlabs.org/~dgibson/dtc/dtc.tar.gz>
>
> WARNING: This version is still in early development stage; the
> resulting device-tree "blobs" have not yet been validated with the
> kernel.
This has been done now. We added an insert blob option to the kexec
tools so that a blob generated with dtc could be used by a kernel
booted with kexec. See:
http://lists.osdl.org/pipermail/fastboot/2005-October/002061.html
Mikey
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Arnd Bergmann @ 2005-12-06 19:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev
In-Reply-To: <1133816807.8577.50.camel@cashmere.sps.mot.com>
On Maandag 05 Dezember 2005 22:06, Jon Loeliger wrote:
> Included below is a proposed Revision 0.5 of the
> "Booting the Linux/ppc kernel without Open Firmware"
> document. This modification primarily extends the
> Revision 0.4 by adding definitions for OF Nodes that
> cover the System-On-a-Chip features found on PPC parts.
> It also generalizes some earlier wording that pertained
> to only PPC64 parts and covers the new, merged PPC 32
> and 64 parts together. Finally, minor typos, style
> consistency and grammar problems were corrected.
A few points are not clear yet, either because I don't understand the
document or one it references correctly or because I might have
different requirements:
- Do we need a way to identify the type of soc bus? There are different
standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
My initial idea was to have different device-type properties for these,
but I now think that device_type = "soc" makes sense for all of them.
Maybe we could add a model or compatible property for them.
- It does not really belong into this document, but is related anyway:
how do you want to represent this in Linux? Currently, most of these
would be of_platform_device, but I think it would be good to have
a new bus_type for it. The advantage would be that you can see the
devices in /sys/devices/soc@xxx/ even if the driver is not loaded
and the driver can even be autoloaded by udev.
Also, which properties should show up in sysfs? All of them or just
those specified in this document or a subset of them?
- What do we do with pci root devices? They are often physically connected
to the internal CPU bus, so it would make sense to represent them
this way in the device tree. Should we add them to the specification
here? Would it even work the expected way in Linux?
- For some devices, you mandate a model property, for others you don't.
Is this intentional? It might be easier to find the right device
driver if the match string always contains a model name.
- How would I represent nested interrupt controllers? E.g. suppose I
have a Cell internal interrupt controller on one SOC bus and
and an external interrupt controller on another SOC bus but have
that deliver interrupts to the first one.
- Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
PLB5 bus?
- The title says 'without Open Firmware', but it should also be allowed
to use the same SOC bus layout when using SLOF or some other OF
implementation, right?
- Also not new in this version, but still: Should there be support for
specifying CPUs with multiple SMT threads?
Arnd <><
^ permalink raw reply
* RE: PPC 32bits and big RAM mapping problem
From: Rune Torgersen @ 2005-12-06 19:55 UTC (permalink / raw)
To: Laurent Lagrange, Matt Porter; +Cc: linuxppc-embedded
> -----Original Message-----
> From: Rune Torgersen
> Sent: Thursday, December 01, 2005 12:43
> To: Laurent Lagrange
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: PPC 32bits and big RAM mapping problem
>=20
> > -----Original Message-----
> > From: Laurent Lagrange
> > Sent: Thursday, December 01, 2005 11:48
> > To: linuxppc-embedded@ozlabs.org
> > Subject: PPC 32bits and big RAM mapping problem
>=20
> > So I'm under the impression to be cornered in my shoes.
> > Any idea, book, article, prediction would be welcome.
>=20
> I have 2GB of ram working on my PPC32 board.
>=20
> You have to change the following in the kernel config:
> Under Advanced Setup:
> Set Maximum Low memory (Set to 0x40000000)
> Set Custom Kernel config address (Set to 0xA0000000)
>=20
> I do not remember if I had to change anything else.
Finally got enough history ripped out of my old bitkeeper repos...
All I had to do to get 2GB of RAM to work on a 8266 was:
CONFIG_ADVANCED_OPTIONS=3Dy
CONFIG_HIGHMEM_START_BOOL=3Dy
CONFIG_HIGHMEM_START=3D0xee000000
CONFIG_LOWMEM_SIZE_BOOL=3Dy
CONFIG_LOWMEM_SIZE=3D0x40000000
CONFIG_KERNEL_START_BOOL=3Dy
CONFIG_KERNEL_START=3D0xa0000000
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmwa re
From: Jon Loeliger @ 2005-12-06 20:08 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev@ozlabs.org, linuxppc64-dev
In-Reply-To: <20051206125910.9f83d230.mikey@neuling.org>
On Tue, 2005-12-06 at 12:59, Michael Neuling wrote:
> > dtc source code can be found at
> > <http://ozlabs.org/~dgibson/dtc/dtc.tar.gz>
And on that note, I should probably make people aware
that the current form of this document can now be found
as part of the DTC tree!
> > WARNING: This version is still in early development stage; the
> > resulting device-tree "blobs" have not yet been validated with the
> > kernel.
>
> This has been done now. We added an insert blob option to the kexec
> tools so that a blob generated with dtc could be used by a kernel
> booted with kexec. See:
>
> http://lists.osdl.org/pipermail/fastboot/2005-October/002061.html
>
> Mikey
OK.
So, do we want to have patches (versus the DTC version)
sent to this list for changes to this document now too?
jdl
^ permalink raw reply
* Re: PowerBook5,8 - TrackPad update
From: Michael Hanselmann @ 2005-12-06 21:12 UTC (permalink / raw)
To: Andy Botting
Cc: Stelian Pop, Parag Warudkar, linux-kernel, linuxppc-dev,
debian-powerpc, johannes
In-Reply-To: <1133840316.10415.4.camel@localhost>
Hello Andy
On Tue, Dec 06, 2005 at 02:38:36PM +1100, Andy Botting wrote:
> I managed to get this working on my 15" PowerBook, but the USB id for my
Thanks for testing.
> Keyboard/Trackpad is 0x0214 as opposed to the 0x0215 you have in the
> patch. Are you going to add 0x0214 (and any others?) to this patch
> before sending it off?
Yes, I can add that one. I don't know about any other IDs that will work
with this patch, so I can't add them.
> Also, I found that the patch didn't apply cleanly on my kernel
> 2.6.15-rc5 kernel. I think many of the line numbers were out, so I ended
> up patching the file manually.
A friend of mine tested it today with a fresh unpacked 2.6.15-rc15 and
it applied cleanly.
Greets,
Michael
^ permalink raw reply
* Re: [PATCH 1/2] Move Virtex-II Pro / ML300 port over to the platform bus.
From: Grant Likely @ 2005-12-06 21:12 UTC (permalink / raw)
To: Rick Moleres; +Cc: linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C017395E1@XCO-EXCHVS1.xlnx.xilinx.com>
Rick Moleres wrote:
>Grant,
>
>Would it be possible for me to take a closer look at the work you're
>doing in this regard? We've been hatching some ideas around with ways
>to separate the dependency on xparamters.h/_g.c files to accommodate
>run-time configuration, but our workload and priorities haven't allowed
>us to spend much time here.
>
>
Certainly. I'm getting my env cleaned up today, and I'll be sending
patches to the mailing list shortly.
Essentially what I'm doing is making any non-xilinx code get parameters
from platform bus devices instead of xparameters.h (Things like
processor speed, interrupts, etc). This of course is only a first
step. It allows xparameters to change w/o recompiling the world.
Xilinx drivers are another matter since each of them include xparameters
directly.
>We're taking a baby step towards that by just moving _LookupConfig out
>of the main driver .c file and adding a new _Init function that takes a
>_Config structure as an argument rather than depend internally on the
>_g.c table.
>
You're making me happy here. :)
> It would be nice to know, though, that work we're doing
>won't completely conflict with work others like yourself are doing.
>
>
It doesn't sound like it will. A _Config struct could be built up from
data in the platform device (or embedded in the platform device
itself). Once the flattened device tree work is in, we could build up
the whole thing from data provided by the bootloader. No recompile
needed at all. :)
g.
>-----Original Message-----
>From: linuxppc-embedded-bounces@ozlabs.org
>[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Grant Likely
>Sent: Monday, December 05, 2005 9:52 AM
>To: Peter Korsgaard; linuxppc-embedded
>Subject: Re: [PATCH 1/2] Move Virtex-II Pro / ML300 port over to the
>platform bus.
>
>Peter Korsgaard wrote:
>
>
>
>>On 9/20/05, Grant Likely <glikely@gmail.com> wrote:
>>
>>
>>
>>
>>>On 9/20/05, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>
>>>
>>>
>>>
>>>>>>>>>" " == Grant Likely <glikely@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>>This is a large patch that moves the ML300 to the platform bus.
>>>>>It also isolates most of the linux tree from changes to the
>>>>>xparameters.h file. Ultimately, the goal is to move everything
>>>>>over to the flattened device tree for telling the kernel about
>>>>>devices. That way xparameters.h can go away entirely for the
>>>>>kernel proper. (Isolated to the bootloader)
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>Hi,
>>
>>Any news on submitting this to mainline?
>>
>>
>>
>>
>
>Yeah, I'm back working on it again after being pulled away on consulting
>priorities. I hope to have a public git tree up soon, and I'll be
>sending patches to mainline shortly thereafter.
>
>Cheers
>g.
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
^ 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