* Re: [PATCH] Ebony's UBoot awareness
From: Matt Porter @ 2005-02-23 21:24 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05022310396240c8ac@mail.gmail.com>
On Wed, Feb 23, 2005 at 10:39:34AM -0800, Shawn Jin wrote:
> Hi,
>
> This adds UBoot support on Ebony board and also sets emac's PHY mode
> explicitly during initialization as Eugene Surovegin provided.
<snip>
> + if (!strncmp(__res.bi_enetaddr, "\0xFF\0xFF\0xFF\0xFF\0xFF\0xFF", 6))
> + memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
> + else
> + memcpy(emacdata->mac_addr, EBONY_NA0_ADDR(vpd_base), 6);
Can you use the ocotea/luan approach and create an openbios stub
in arch/ppc/boot to create the bi_enetaddr infos? The PIBS stub
in arch/ppc/boot does this so we can have one path in the platform
file that parses the bootinfos.
-Matt
^ permalink raw reply
* Re: [PATCH] Ebony's UBoot awareness
From: Matt Porter @ 2005-02-23 21:20 UTC (permalink / raw)
To: Tom Rini, Shawn Jin, ppcembed
In-Reply-To: <20050223191247.GC6670@gate.ebshome.net>
On Wed, Feb 23, 2005 at 11:12:47AM -0800, Eugene Surovegin wrote:
> On Wed, Feb 23, 2005 at 12:01:23PM -0700, Tom Rini wrote:
> > > +#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
> >
> > This will not work with O= for example. The correct method is to modify
> > the Makefile with a CFLAGS_foo.o += -Idrivers/net/ibm_emac
>
> I just tested and it does work even with O= :).
>
> OTOH, I agree this is ugly hack (it was copied from ocotea.c, so blame
> Matt for it :) and should be fixed correctly by moving those PHY
> defines to some common include.
Ugh, yes...in my defense I clearly stated it was an "ugly hack". :)
-Matt
^ permalink raw reply
* PATCH: add ppc PVR register values for 7447A and 7457 CPUs
From: James Chapman @ 2005-02-23 20:48 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
Signed-off-by: James Chapman <jchapman@katalix.com>
Trivial patch to add 7447A and 7457 CPU defs.
[-- Attachment #2: ppc_cpu_regs.patch --]
[-- Type: text/plain, Size: 737 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/23 16:17:49+00:00 jchapman@katalix.com
# Add ppc PVR definitions for 7447A and 7457 CPUs.
#
# include/asm-ppc/reg.h
# 2005/02/23 16:17:40+00:00 jchapman@katalix.com +2 -0
# Add ppc PVR definitions for 7447A and 7457 CPUs.
#
diff -Nru a/include/asm-ppc/reg.h b/include/asm-ppc/reg.h
--- a/include/asm-ppc/reg.h 2005-02-23 16:18:45 +00:00
+++ b/include/asm-ppc/reg.h 2005-02-23 16:18:45 +00:00
@@ -471,7 +471,9 @@
#define PVR_750P PVR_740P
#define PVR_7400 0x000C0000
#define PVR_7410 0x800C0000
+#define PVR_7447A 0x80030000
#define PVR_7450 0x80000000
+#define PVR_7457 0x80020000
#define PVR_8540 0x80200000
#define PVR_8560 0x80200000
/*
^ permalink raw reply
* PATCH: add mv64x60 GPP IO pin/IRQ register definitions
From: James Chapman @ 2005-02-23 20:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 103 bytes --]
Add mv64x60 GPP IO pin/IRQ register definitions
Signed-off-by: James Chapman <jchapman@katalix.com>
[-- Attachment #2: mv64x60_gpp_defs.patch --]
[-- Type: text/plain, Size: 2400 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/23 16:14:11+00:00 jchapman@katalix.com
# Add mv64x60 GPP IO pin/IRQ register definitions.
#
# include/asm-ppc/mv64x60_defs.h
# 2005/02/23 16:14:03+00:00 jchapman@katalix.com +41 -0
# Add mv64x60 GPP IO pin/IRQ register definitions.
#
diff -Nru a/include/asm-ppc/mv64x60_defs.h b/include/asm-ppc/mv64x60_defs.h
--- a/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:14:56 +00:00
+++ b/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:14:56 +00:00
@@ -43,6 +43,10 @@
#define MV64x60_IRQ_TIMER_2_3 9
#define MV64x60_IRQ_TIMER_4_5 10
#define MV64x60_IRQ_TIMER_6_7 11
+#define MV64x60_IRQ_P1_GPP_0_7 24
+#define MV64x60_IRQ_P1_GPP_8_15 25
+#define MV64x60_IRQ_P1_GPP_16_23 26
+#define MV64x60_IRQ_P1_GPP_24_31 27
#define MV64x60_IRQ_DOORBELL 28
#define MV64x60_IRQ_ETH_0 32
#define MV64x60_IRQ_ETH_1 33
@@ -53,11 +57,48 @@
#define MV64x60_IRQ_MPSC_0 40
#define MV64x60_IRQ_MPSC_1 42
#define MV64x60_IRQ_COMM 43
+#define MV64x60_IRQ_P0_GPP_0_7 56
+#define MV64x60_IRQ_P0_GPP_8_15 57
+#define MV64x60_IRQ_P0_GPP_16_23 58
+#define MV64x60_IRQ_P0_GPP_24_31 59
#define MV64360_IRQ_PCI0 12
#define MV64360_IRQ_SRAM_PAR_ERR 13
#define MV64360_IRQ_PCI1 16
#define MV64360_IRQ_SDMA_1 38
+
+#define MV64x60_IRQ_GPP0 64
+#define MV64x60_IRQ_GPP1 65
+#define MV64x60_IRQ_GPP2 66
+#define MV64x60_IRQ_GPP3 67
+#define MV64x60_IRQ_GPP4 68
+#define MV64x60_IRQ_GPP5 69
+#define MV64x60_IRQ_GPP6 70
+#define MV64x60_IRQ_GPP7 71
+#define MV64x60_IRQ_GPP8 72
+#define MV64x60_IRQ_GPP9 73
+#define MV64x60_IRQ_GPP10 74
+#define MV64x60_IRQ_GPP11 75
+#define MV64x60_IRQ_GPP12 76
+#define MV64x60_IRQ_GPP13 77
+#define MV64x60_IRQ_GPP14 78
+#define MV64x60_IRQ_GPP15 79
+#define MV64x60_IRQ_GPP16 80
+#define MV64x60_IRQ_GPP17 81
+#define MV64x60_IRQ_GPP18 82
+#define MV64x60_IRQ_GPP19 83
+#define MV64x60_IRQ_GPP20 84
+#define MV64x60_IRQ_GPP21 85
+#define MV64x60_IRQ_GPP22 86
+#define MV64x60_IRQ_GPP23 87
+#define MV64x60_IRQ_GPP24 88
+#define MV64x60_IRQ_GPP25 89
+#define MV64x60_IRQ_GPP26 90
+#define MV64x60_IRQ_GPP27 91
+#define MV64x60_IRQ_GPP28 92
+#define MV64x60_IRQ_GPP29 93
+#define MV64x60_IRQ_GPP30 94
+#define MV64x60_IRQ_GPP31 95
/* Offsets for register blocks */
#define GT64260_ENET_PHY_ADDR 0x2000
^ permalink raw reply
* PATCH: fix mv64360 pic code to handle non-zero mv64x60_irq_base
From: James Chapman @ 2005-02-23 20:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
New version of patch addressing Mark Greer's comments.
- Fix mv64360 pic code to handle non-zero mv64x60_irq_base
- Cleanup mv64360 entries in /proc/interrupts
Signed-off-by: James Chapman <jchapman@katalix.com>
[-- Attachment #2: mv64360_pic.patch --]
[-- Type: text/plain, Size: 4579 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/23 16:01:12+00:00 jchapman@katalix.com
# Fix mv64360 pic to handle non-zero IRQ offset.
# Cleanup /proc/interrupts.
#
# include/asm-ppc/mv64x60_defs.h
# 2005/02/23 16:01:02+00:00 jchapman@katalix.com +1 -0
# Add #define for doorbell interrupt bit value (28).
#
# arch/ppc/syslib/mv64360_pic.c
# 2005/02/23 16:01:02+00:00 jchapman@katalix.com +17 -12
# Cleanup /proc/interrupts output to make mv64360 entries line up.
# Use #define for dorrbell interrupt bit (28).
# Fix several bugs to do with non-zero mv64360_irq_base.
#
diff -Nru a/arch/ppc/syslib/mv64360_pic.c b/arch/ppc/syslib/mv64360_pic.c
--- a/arch/ppc/syslib/mv64360_pic.c 2005-02-23 16:07:02 +00:00
+++ b/arch/ppc/syslib/mv64360_pic.c 2005-02-23 16:07:02 +00:00
@@ -64,7 +64,7 @@
/* ========================== local declarations =========================== */
struct hw_interrupt_type mv64360_pic = {
- .typename = " mv64360_pic ",
+ .typename = " mv64360 ",
.enable = mv64360_unmask_irq,
.disable = mv64360_mask_irq,
.ack = mv64360_mask_irq,
@@ -155,9 +155,10 @@
*/
int cpu_nr = smp_processor_id();
if (cpu_nr == 1) {
- if (!(mv64x60_read(&bh, MV64360_IC_MAIN_CAUSE_LO) & (1 << 28)))
+ if (!(mv64x60_read(&bh, MV64360_IC_MAIN_CAUSE_LO) &
+ (1 << MV64x60_IRQ_DOORBELL)))
return -1;
- return 28;
+ return mv64360_irq_base + MV64x60_IRQ_DOORBELL;
}
#endif
@@ -171,7 +172,7 @@
if (irq == -1)
irq = -2; /* bogus interrupt, should never happen */
else {
- if ((irq >= 24) && (irq < 28)) {
+ if ((irq >= 24) && (irq < MV64x60_IRQ_DOORBELL)) {
irq_gpp = mv64x60_read(&bh,
MV64x60_GPP_INTR_CAUSE);
irq_gpp = __ilog2(irq_gpp &
@@ -217,8 +218,9 @@
{
#ifdef CONFIG_SMP
/* second CPU gets only doorbell interrupts */
- if ((irq - mv64360_irq_base) == 28) {
- mv64x60_set_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO, (1 << 28));
+ if ((irq - mv64360_irq_base) == MV64x60_IRQ_DOORBELL) {
+ mv64x60_set_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO,
+ (1 << MV64x60_IRQ_DOORBELL));
return;
}
#endif
@@ -257,8 +259,9 @@
mv64360_mask_irq(unsigned int irq)
{
#ifdef CONFIG_SMP
- if ((irq - mv64360_irq_base) == 28) {
- mv64x60_clr_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO, (1 << 28));
+ if ((irq - mv64360_irq_base) == MV64x60_IRQ_DOORBELL) {
+ mv64x60_clr_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO,
+ (1 << MV64x60_IRQ_DOORBELL));
return;
}
#endif
@@ -371,7 +374,7 @@
/* Clear old errors and register CPU interface error intr handler */
mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
+ if ((rc = request_irq(MV64x60_IRQ_CPU_ERR + mv64360_irq_base,
mv64360_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
@@ -380,7 +383,7 @@
/* Clear old errors and register internal SRAM error intr handler */
mv64x60_write(&bh, MV64360_SRAM_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64360_IRQ_SRAM_PAR_ERR,
+ if ((rc = request_irq(MV64360_IRQ_SRAM_PAR_ERR + mv64360_irq_base,
mv64360_sram_error_int_handler,SA_INTERRUPT,SRAM_INTR_STR, 0)))
printk(KERN_WARNING "Can't register SRAM error handler: %d",rc);
@@ -397,7 +400,8 @@
/* Clear old errors and register PCI 0 error intr handler */
mv64x60_write(&bh, MV64x60_PCI0_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64360_IRQ_PCI0, mv64360_pci_error_int_handler,
+ if ((rc = request_irq(MV64360_IRQ_PCI0 + mv64360_irq_base,
+ mv64360_pci_error_int_handler,
SA_INTERRUPT, PCI0_INTR_STR, (void *)0)))
printk(KERN_WARNING "Can't register pci 0 error handler: %d",
rc);
@@ -407,7 +411,8 @@
/* Clear old errors and register PCI 1 error intr handler */
mv64x60_write(&bh, MV64x60_PCI1_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64360_IRQ_PCI1, mv64360_pci_error_int_handler,
+ if ((rc = request_irq(MV64360_IRQ_PCI1 + mv64360_irq_base,
+ mv64360_pci_error_int_handler,
SA_INTERRUPT, PCI1_INTR_STR, (void *)1)))
printk(KERN_WARNING "Can't register pci 1 error handler: %d",
rc);
diff -Nru a/include/asm-ppc/mv64x60_defs.h b/include/asm-ppc/mv64x60_defs.h
--- a/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:07:02 +00:00
+++ b/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:07:02 +00:00
@@ -43,6 +43,7 @@
#define MV64x60_IRQ_TIMER_2_3 9
#define MV64x60_IRQ_TIMER_4_5 10
#define MV64x60_IRQ_TIMER_6_7 11
+#define MV64x60_IRQ_DOORBELL 28
#define MV64x60_IRQ_ETH_0 32
#define MV64x60_IRQ_ETH_1 33
#define MV64x60_IRQ_ETH_2 34
^ permalink raw reply
* ppc32 weirdness with gcc-4.0 in 2.6.11-rc4
From: Mikael Pettersson @ 2005-02-23 20:28 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
2.6.11-rc4 built with gcc-3.4.3 works fine on my eMac.
Building with gcc-4.0.0 (20050220) however gives me a kernel
with dead USB, and thus no keyboard or mouse, but everything
else seems to be working.
A diff between dmesg on the two kernels has an interesting nugget:
--- dmesg-2.6.11-rc4-gcc343 2005-02-23 20:57:54.000000000 +0100
+++ dmesg-2.6.11-rc4-gcc400 2005-02-23 21:14:44.000000000 +0100
@@ -1,5 +1,5 @@
Total memory = 256MB; using 512kB for hash table (at c0300000)
-Linux version 2.6.11-rc4-gcc343 (mikpe@darwin) (gcc version 3.4.3) #1 Wed Feb 23 20:53:57 CET 2005
+Linux version 2.6.11-rc4-gcc400 (mikpe@darwin) (gcc version 4.0.0 20050220 (experimental)) #1 Wed Feb 23 21:10:27 CET 2005
Found UniNorth memory controller & host bridge, revision: 210
Mapped at 0xfdf00000
Found a Intrepid mac-io controller, rev: 0, mapped at 0xfde80000
@@ -26,11 +26,11 @@
OpenPIC timer frequency is 4.160000 MHz
PID hash table entries: 2048 (order: 11, 32768 bytes)
GMT Delta read from XPRAM: 0 minutes, DST: off
-time_init: decrementer frequency = 41.600661 MHz
+time_init: decrementer frequency = 41.600571 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
-Memory: 255872k available (1788k kernel code, 976k data, 144k init, 0k highmem)
+Memory: 255872k available (1776k kernel code, 0k data, 144k init, 0k highmem)
AGP special page: 0xcffff000
Calibrating delay loop... 830.66 BogoMIPS (lpj=4153344)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
@@ -132,13 +132,7 @@
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 144k init 4k chrp 8k prep
usb 3-2: new full speed USB device using ohci_hcd and address 2
-hub 3-2:1.0: USB hub found
-hub 3-2:1.0: 3 ports detected
-usb 3-2.1: new low speed USB device using ohci_hcd and address 3
-input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0001:10:1b.0-2.1
-usb 3-2.3: new full speed USB device using ohci_hcd and address 4
-input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:1b.0-2.3
-input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:1b.0-2.3
+usb 3-2: can't connect bus-powered hub to this port
EXT3 FS on hda5, internal journal
Adding 1048568k swap on /dev/hda3. Priority:-1 extents:1
SCSI subsystem initialized
Note: "Memory: ... 0k data ..." !? Surely that can't be correct.
/Mikael
^ permalink raw reply
* Re: PowerPC4xx Watchdog
From: Takeharu KATO @ 2005-02-23 19:15 UTC (permalink / raw)
To: Takeharu KATO; +Cc: ppcembed
In-Reply-To: <421CD2B3.4020805@ybb.ne.jp>
Hi
Sorry, I sent the mail before checking it by mistake.
I meant to say as follows:
I am working on developing WatchDog Driver for PowerPC4xx on Linux-2.6.
Does anyone have a plan or a patch to make WatchDog Driver on
PowerPC4xx(405GP/405GPr/440GP/440GX) for Linux-2.6?
Takeharu KATO wrote:
> Hi
>
> I am trying to WatchDog Driver for PowerPC4xx on Linux-2.6.
> Does anyone have a plan to WatchDog Driver on this architecture?
>
--
Takeharu KATO
^ permalink raw reply
* Re: [PATCH] Ebony's UBoot awareness
From: Eugene Surovegin @ 2005-02-23 19:12 UTC (permalink / raw)
To: Tom Rini; +Cc: ppcembed
In-Reply-To: <20050223190123.GI345@smtp.west.cox.net>
On Wed, Feb 23, 2005 at 12:01:23PM -0700, Tom Rini wrote:
> > +#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
>
> This will not work with O= for example. The correct method is to modify
> the Makefile with a CFLAGS_foo.o += -Idrivers/net/ibm_emac
I just tested and it does work even with O= :).
OTOH, I agree this is ugly hack (it was copied from ocotea.c, so blame
Matt for it :) and should be fixed correctly by moving those PHY
defines to some common include.
--
Eugene
^ permalink raw reply
* PowerPC4xx Watchdog
From: Takeharu KATO @ 2005-02-23 19:00 UTC (permalink / raw)
To: ppcembed
Hi
I am trying to WatchDog Driver for PowerPC4xx on Linux-2.6.
Does anyone have a plan to WatchDog Driver on this architecture?
--
Takeharu KATO
^ permalink raw reply
* Re: [PATCH] Ebony's UBoot awareness
From: Tom Rini @ 2005-02-23 19:01 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05022310396240c8ac@mail.gmail.com>
On Wed, Feb 23, 2005 at 10:39:34AM -0800, Shawn Jin wrote:
> This adds UBoot support on Ebony board and also sets emac's PHY mode
> explicitly during initialization as Eugene Surovegin provided.
[snip]
> +#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
This will not work with O= for example. The correct method is to modify
the Makefile with a CFLAGS_foo.o += -Idrivers/net/ibm_emac
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PPC32][update] Report chip version in /proc/cpuinfo for 85xx boards
From: Tom Rini @ 2005-02-23 18:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: akpm, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0502222257230.7799@blarg.somerset.sps.mot.com>
On Tue, Feb 22, 2005 at 10:59:17PM -0600, Kumar Gala wrote:
> Andrew,
>
> Here here is an updated version of the previous patch which fixes a
> build problem. It is for post 2.6.11.
>
> Report the chip version in /proc/cpuinfo on 85xx ADS and CDS platforms.
How about doing it in arch/ppc/kernel/setup.c with a test for it being
non-null (if needed?).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH] Ebony's UBoot awareness
From: Shawn Jin @ 2005-02-23 18:39 UTC (permalink / raw)
To: ppcembed
[-- Attachment #1: Type: text/plain, Size: 155 bytes --]
Hi,
This adds UBoot support on Ebony board and also sets emac's PHY mode
explicitly during initialization as Eugene Surovegin provided.
Regards,
-Shawn.
[-- Attachment #2: ebony-emac.diff --]
[-- Type: text/plain, Size: 3192 bytes --]
diff -Nur orig/linux-2.6.10/arch/ppc/platforms/4xx/ebony.c code/linux-2.6.10/arch/ppc/platforms/4xx/ebony.c
--- orig/linux-2.6.10/arch/ppc/platforms/4xx/ebony.c 2004-12-24 13:35:40.000000000 -0800
+++ code/linux-2.6.10/arch/ppc/platforms/4xx/ebony.c 2005-02-23 10:05:32.043954000 -0800
@@ -49,10 +49,14 @@
#include <asm/todc.h>
#include <asm/bootinfo.h>
#include <asm/ppc4xx_pic.h>
+#include <asm/ppcboot.h>
#include <syslib/gen550.h>
+#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
+
static struct ibm44x_clocks clocks __initdata;
+bd_t __res;
/*
* Ebony IRQ triggering/polarity settings
@@ -182,6 +186,41 @@
(writel(value, (u32)pcix_reg_base+offset))
/*
+ * Set mac address for each EMAC
+ * If uboot sets MAC addresses for each EMAC, use them.
+ * Otherwise fetch from Ebony VPD.
+ *
+ */
+static void __init
+ebony_set_emacdata(void)
+{
+ unsigned char * vpd_base;
+ struct ocp_def *def;
+ struct ocp_func_emac_data *emacdata;
+
+ vpd_base = ioremap64(EBONY_VPD_BASE, EBONY_VPD_SIZE);
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
+ emacdata = def->additions;
+ emacdata->phy_mode = PHY_MODE_RMII;
+ if (!strncmp(__res.bi_enetaddr, "\0xFF\0xFF\0xFF\0xFF\0xFF\0xFF", 6))
+ memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
+ else
+ memcpy(emacdata->mac_addr, EBONY_NA0_ADDR(vpd_base), 6);
+
+ def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
+ emacdata = def->additions;
+ emacdata->phy_mode = PHY_MODE_RMII;
+ if (!strncmp(__res.bi_enet1addr, "\0xFF\0xFF\0xFF\0xFF\0xFF\0xFF", 6))
+ memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);
+ else
+ memcpy(emacdata->mac_addr, EBONY_NA1_ADDR(vpd_base), 6);
+
+ iounmap(vpd_base);
+
+}
+
+/*
* FIXME: This is only here to "make it work". This will move
* to a ibm_pcix.c which will contain a generic IBM PCIX bridge
* configuration library. -Matt
@@ -309,19 +348,7 @@
static void __init
ebony_setup_arch(void)
{
- unsigned char * vpd_base;
- struct ocp_def *def;
- struct ocp_func_emac_data *emacdata;
-
- /* Set mac_addr for each EMAC */
- vpd_base = ioremap64(EBONY_VPD_BASE, EBONY_VPD_SIZE);
- def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
- emacdata = def->additions;
- memcpy(emacdata->mac_addr, EBONY_NA0_ADDR(vpd_base), 6);
- def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
- emacdata = def->additions;
- memcpy(emacdata->mac_addr, EBONY_NA1_ADDR(vpd_base), 6);
- iounmap(vpd_base);
+ ebony_set_emacdata();
/*
* Determine various clocks.
@@ -368,7 +395,20 @@
void __init platform_init(unsigned long r3, unsigned long r4,
unsigned long r5, unsigned long r6, unsigned long r7)
{
- parse_bootinfo((struct bi_record *) (r3 + KERNELBASE));
+ parse_bootinfo(find_bootinfo());
+
+ /*
+ * If we were passed in a board information, copy it into the
+ * residual data area.
+ */
+ if (r3)
+ __res = *(bd_t *)(r3 + KERNELBASE);
+
+ /* Copy the kernel command line arguments to a safe place. */
+ if (r6) {
+ *(char *) (r7 + KERNELBASE) = 0;
+ strcpy(cmd_line, (char *) (r6 + KERNELBASE));
+ }
ibm44x_platform_init();
^ permalink raw reply
* Re: any hints using gcc 3.4.3 for 2.4.25 kernel?
From: Gerhard Jaeger @ 2005-02-23 15:42 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: Wojciech Kromer, linuxppc-embedded
In-Reply-To: <421CA367.1010604@eircom.net>
On Wednesday 23 February 2005 16:38, Bryan O'Donoghue wrote:
> Gerhard Jaeger wrote:
> > On Monday 21 February 2005 15:12, Wojciech Kromer wrote:
> >
> >>a)first i have:
> >>- 2.4.25 kernel (from denx cvs)
> >>- eldk with 2.95.4 compiler
> >>this one set works fine :)
> >>
> >>b)then, i've tried to same sources with:
> >>gcc-3.4.3 , self build from uClibc buildroot
> >>new hernel hangs just after decompressing :(
> >>
> >>any tricks?
> >>
> >
> >
> > you can use the include/linux/init.h and compiler.h from 2.4.29
> > kernel + patching some header files, where the inlining does not
> > work any longer. I also suggest comparing with 2.4.29 kernel.
> >
> > ciao,
> > Gerhard
> >
>
> If all you want is a cross compiler to make a kernel why not try this
> procedure ?
>
> Tested with :
>
> gcc-3.4.2
> binutils-2.15.90.0.3
> dietlibc-0.28 or dietlibc cvs
>
> 1
> untar all sources
>
> 2
> binutils:
>
> ./configure --prefix=/usr/local/powerpc-linux --target=powerpc-linux
>
> make
> make install
>
> 3
> gcc:
>
> ./configure --prefix=/usr/local/powerpc-linux --target=powerpc-linux
> --with-ecos --disable-nls --enable-threads=posix --disable-shared
> --enable-languages=c --with-headers=../dietlibc/include
>
> make
> make install
>
> There might be a little error in gcc/unwind-dw2-fde-glibc.c and
> gcc/unwind-dw2-fde.h
>
> I can't remember the exact errors in those two files, but, hopefully
> those should be easy enough to fix.
>
> Once you work around the slight inconsistency between dietlibc & gcc in
> those two files, and make install, you should have a full toolchain in
> /usr/local/powerpc-linux
>
> I had been thinking about making a small script for kernel people such
> as yourself, who wanted just a toolchain for kernel cross compiles.
> Maybe I'll do that.
>
> But, in any case, the above procedure gives me a 3.4.2 which is quite
> happy to compile a 2.4.28-rc3 (though I haven't tried out the denx
> 2.4.25... but, I can't see why that would fail).
>
> Hope this helps.
I'm pretty sure, that it won't help on a 2.4.25 kernel. The 2.4.28-rc3 already
has the needed patches/changes applied, that's why it works for you ;)
ciao,
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Re: any hints using gcc 3.4.3 for 2.4.25 kernel?
From: Bryan O'Donoghue @ 2005-02-23 15:38 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: Wojciech Kromer, linuxppc-embedded
In-Reply-To: <200502231554.56860.g.jaeger@sysgo.com>
Gerhard Jaeger wrote:
> On Monday 21 February 2005 15:12, Wojciech Kromer wrote:
>
>>a)first i have:
>>- 2.4.25 kernel (from denx cvs)
>>- eldk with 2.95.4 compiler
>>this one set works fine :)
>>
>>b)then, i've tried to same sources with:
>>gcc-3.4.3 , self build from uClibc buildroot
>>new hernel hangs just after decompressing :(
>>
>>any tricks?
>>
>
>
> you can use the include/linux/init.h and compiler.h from 2.4.29
> kernel + patching some header files, where the inlining does not
> work any longer. I also suggest comparing with 2.4.29 kernel.
>
> ciao,
> Gerhard
>
If all you want is a cross compiler to make a kernel why not try this
procedure ?
Tested with :
gcc-3.4.2
binutils-2.15.90.0.3
dietlibc-0.28 or dietlibc cvs
1
untar all sources
2
binutils:
./configure --prefix=/usr/local/powerpc-linux --target=powerpc-linux
make
make install
3
gcc:
./configure --prefix=/usr/local/powerpc-linux --target=powerpc-linux
--with-ecos --disable-nls --enable-threads=posix --disable-shared
--enable-languages=c --with-headers=../dietlibc/include
make
make install
There might be a little error in gcc/unwind-dw2-fde-glibc.c and
gcc/unwind-dw2-fde.h
I can't remember the exact errors in those two files, but, hopefully
those should be easy enough to fix.
Once you work around the slight inconsistency between dietlibc & gcc in
those two files, and make install, you should have a full toolchain in
/usr/local/powerpc-linux
I had been thinking about making a small script for kernel people such
as yourself, who wanted just a toolchain for kernel cross compiles.
Maybe I'll do that.
But, in any case, the above procedure gives me a 3.4.2 which is quite
happy to compile a 2.4.28-rc3 (though I haven't tried out the denx
2.4.25... but, I can't see why that would fail).
Hope this helps.
--
Bryan
^ permalink raw reply
* AW: mpc5200: "len bad" messages from tftp (u-boot 1.1.1)
From: Martin Krause @ 2005-02-23 15:03 UTC (permalink / raw)
To: Caruso, Nick; +Cc: linuxppc-embedded
Hi Caruso
linuxppc-embedded-bounces@ozlabs.org wrote on Mittwoch, 23. Februar
2005 15:12:=20
> We are seeing repeated errors during downloads using the tftp client
> built into u-boot version 1.1.1.
This is not the correct mailing list for U-Boot related questions.
Please use the u-boot users list (u-boot-users@lists.sourceforge.net)
next time.
Attached is a patch for the mpc5xxx FEC driver, which fixes a variable-
not-defined-as-volatile bug. I had similar Problems with the tftp =
command
and this patch helps. The patch ist against top of cvs. Wolfgang Denk=20
sends it to me last week, so I am a bit surprised, that it didn't find=20
its way into cvs, yet.
Regards,
Martin
Index: cpu/mpc5xxx/fec.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/u-boot/u-boot/cpu/mpc5xxx/fec.c,v
retrieving revision 1.18
diff -u -r1.18 fec.c
--- cpu/mpc5xxx/fec.c 16 Dec 2004 15:52:41 -0000 1.18
+++ cpu/mpc5xxx/fec.c 16 Feb 2005 09:16:55 -0000
@@ -115,7 +115,7 @@
}
=20
/********************************************************************/
-static void mpc5xxx_fec_rbd_clean(mpc5xxx_fec_priv *fec, FEC_RBD * =
pRbd)
+static void mpc5xxx_fec_rbd_clean(mpc5xxx_fec_priv *fec, volatile =
FEC_RBD * pRbd)
{
/*
* Reset buffer descriptor as empty
@@ -141,7 +141,7 @@
/********************************************************************/
static void mpc5xxx_fec_tbd_scrub(mpc5xxx_fec_priv *fec)
{
- FEC_TBD *pUsedTbd;
+ volatile FEC_TBD *pUsedTbd;
=20
#if (DEBUG & 0x1)
printf ("tbd_scrub: fec->cleanTbdNum =3D %d, fec->usedTbdIndex =3D =
%d\n",
@@ -354,10 +354,10 @@
/*
* Initialize SmartDMA parameters stored in SRAM
*/
- *(int *)FEC_TBD_BASE =3D (int)fec->tbdBase;
- *(int *)FEC_RBD_BASE =3D (int)fec->rbdBase;
- *(int *)FEC_TBD_NEXT =3D (int)fec->tbdBase;
- *(int *)FEC_RBD_NEXT =3D (int)fec->rbdBase;
+ *(volatile int *)FEC_TBD_BASE =3D (int)fec->tbdBase;
+ *(volatile int *)FEC_RBD_BASE =3D (int)fec->rbdBase;
+ *(volatile int *)FEC_TBD_NEXT =3D (int)fec->tbdBase;
+ *(volatile int *)FEC_RBD_NEXT =3D (int)fec->rbdBase;
=20
/*
* Enable FEC-Lite controller
@@ -688,7 +688,7 @@
* 6-byte Ethernet addresses.
*/
mpc5xxx_fec_priv *fec =3D (mpc5xxx_fec_priv *)dev->priv;
- FEC_TBD *pTbd;
+ volatile FEC_TBD *pTbd;
=20
#if (DEBUG & 0x20)
printf("tbd status: 0x%04x\n", fec->tbdBase[0].status);
@@ -779,7 +779,7 @@
* This command pulls one frame from the card
*/
mpc5xxx_fec_priv *fec =3D (mpc5xxx_fec_priv *)dev->priv;
- FEC_RBD *pRbd =3D &fec->rbdBase[fec->rbdIndex];
+ volatile FEC_RBD *pRbd =3D &fec->rbdBase[fec->rbdIndex];
unsigned long ievent;
int frame_length, len =3D 0;
NBUF *frame;
^ permalink raw reply
* Re: any hints using gcc 3.4.3 for 2.4.25 kernel?
From: Gerhard Jaeger @ 2005-02-23 14:54 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Wojciech Kromer
In-Reply-To: <4219EC67.1070602@dgt-lab.com.pl>
On Monday 21 February 2005 15:12, Wojciech Kromer wrote:
> a)first i have:
> - 2.4.25 kernel (from denx cvs)
> - eldk with 2.95.4 compiler
> this one set works fine :)
>
> b)then, i've tried to same sources with:
> gcc-3.4.3 , self build from uClibc buildroot
> new hernel hangs just after decompressing :(
>
> any tricks?
>
you can use the include/linux/init.h and compiler.h from 2.4.29
kernel + patching some header files, where the inlining does not
work any longer. I also suggest comparing with 2.4.29 kernel.
ciao,
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* mpc5200: "len bad" messages from tftp (u-boot 1.1.1)
From: Caruso, Nick @ 2005-02-23 14:12 UTC (permalink / raw)
To: ppcembed
[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]
Hello,
We are seeing repeated errors during downloads using the tftp client built into u-boot version 1.1.1.
The error message we see is:
"len bad 494 < 544"
I believe the messages must be generated by the following snippet of code from u-boot-1.1.1/net/net.c:
case PROT_IP:
#ifdef ET_DEBUG
puts ("Got IP\n");
#endif
if (len < IP_HDR_SIZE) {
debug ("len bad %d < %d\n", len, IP_HDR_SIZE);
return;
}
if (len < ntohs(ip->ip_len)) {
printf("len bad %d < %d\n", len, ntohs(ip->ip_len));
return;
}
The error is recoverable and occurs erratically - sometimes we see long strings of "#"'s between errors, and other times errors occur every couple of "#"'s. We always seem to end up with a good download.
We don't see this problem using the freescale Lite5200 boards, but we do see it on our custom mpc5200 boards.
Can anyone suggest where we should look to diagnose this problem? Perhaps it's hardware related, although I suppose it could be a configuration problem in the way u-boot is setting up the ethernet device - once we boot into linux we don't see many errors -- according to ifconfig, anyway.
Pinging the board from another machine also shows no errors.
thanks and best regards
Nick Caruso
[-- Attachment #2: Type: text/html, Size: 2932 bytes --]
^ permalink raw reply
* Re: Ethernet doesn't work in linux for PPC440GP?
From: Eugene Surovegin @ 2005-02-23 9:38 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b050223000217714e92@mail.gmail.com>
On Wed, Feb 23, 2005 at 12:02:04AM -0800, Shawn Jin wrote:
> > > zmii0: input 0 in SMII mode
> > > eth0: IBM emac, MAC 00:04:ac:e3:1b:bb
> > > eth0: Found Generic MII PHY (0x08)
> > > zmii0: input 1 in RMII mode
> > > eth1: IBM emac, MAC FF:FF:FF:FF:FF:FF
> > > eth1: Found Generic MII PHY (0x09)
> >
> > I already told you that this is wrong, why are you asking again?
> > Please, if you asking questions, spend some time reading answers
> > given to you, before asking again.
>
> Well, don't be mad at me first. The question may bring out another
> round of arguments whether it's a bug related to uboot or linux EMAC
> driver. Wolfgang makes it very clear that this is a bug in linux
> ethernet driver. And I agree with him. This argument happened before
> and I just forgot what specific ethernet driver was in the argument.
This is really irrelevant.
>
> > Ebony uses RMII, so SMII is obviously wrong. Most probably your
> > firmware doesn't set correct mode and autodetection in the EMAC driver
> > fails.
>
> So the EMAC driver does expect a boot loader (the firmware you
> mentioned here) to set something for it. Then I think I need to fix it
> in this driver instead of in uboot.
Current EMAC driver uses autodetection logic if PHY mode wasn't
specified by the board support code. It works for Ebony + OpenBIOS.
You can try the following patch (untested) to set PHY mode explicitly:
===== arch/ppc/platforms/4xx/ebony.c 1.10 vs edited =====
--- 1.10/arch/ppc/platforms/4xx/ebony.c 2005-02-03 06:42:41 -08:00
+++ edited/arch/ppc/platforms/4xx/ebony.c 2005-02-23 01:28:04 -08:00
@@ -52,6 +52,13 @@
#include <syslib/gen550.h>
+/*
+ * This is a horrible kludge, we eventually need to abstract this
+ * generic PHY stuff, so the standard phy mode defines can be
+ * easily used from arch code.
+ */
+#include "../../../../drivers/net/ibm_emac/ibm_emac_phy.h"
+
static struct ibm44x_clocks clocks __initdata;
/*
@@ -267,9 +274,11 @@
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
emacdata = def->additions;
memcpy(emacdata->mac_addr, EBONY_NA0_ADDR(vpd_base), 6);
+ emacdata->phy_mode = PHY_MODE_RMII;
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
emacdata = def->additions;
memcpy(emacdata->mac_addr, EBONY_NA1_ADDR(vpd_base), 6);
+ emacdata->phy_mode = PHY_MODE_RMII;
iounmap(vpd_base);
/*
--
Eugene
^ permalink raw reply
* Re: FCC on 8560 ADS
From: Jose Almeida @ 2005-02-23 8:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <421B0C70.1070301@apes.fr>
All,
Please cancel this request, I found the problem.
I had a switch (SW4) with the wrong setup.
Thanks - Jose
Jose Almeida wrote:
> All,
>
> I'm trying to get a linux 2.6 kernel up and running on an freescale
> 8560 ADS board. I have every peace of this up and running apart from
> the FCC ethernet.
>
> I've switched to the legacy mode, which now allow me to talk to the
> PHY and negocite properly @ 100BT FD.
>
> But I don't seem to get any ethernet packet going out. The FCC
> controller does not seem to read the BDs, and all the packet's I'm
> placing in the BD just stay there for ever !
>
> I'm wondering if you have a driver which works properlly ? I'm
> thinking on some wrong setup in the ioports, but is all seems to be
> correct !
>
> I'm using a 2.6.9 kernel, but I also tryed other versions (2.6.11r4),
> with the same problems ...
>
> Thanks
> Jose
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* [PATCH] ppc32: Wrong vaddr in flush_hash_one_pte()
From: Benjamin Herrenschmidt @ 2005-02-23 8:02 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: David S. Miller, linuxppc-dev list
Hi !
Reworking the ppc32 mm helps me find interesting bugs in the existing bug,
well, brown paper bag for me, I made this one a while ago. The routine
flush_hash_one_pte() used by ptep_test_and_clear_young() wasn't properly
recaclulating the vaddr from the pte pointer & page->index. This fixes
it. The result is that we probably never flushed things from the hash,
so that's at least the _second_ bug affecting ptep_test_and_clear_young(),
swap on ppc32 must have been really broken :(
Please, apply to 2.6.11...
(I hope by early 2.6.12, we'll have David's patch that removes the need for
those hacks though, and just pass us the vaddr (and mm or vma) to all the
PTE accessors...)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/mm/tlb.c
===================================================================
--- linux-work.orig/arch/ppc/mm/tlb.c 2005-01-24 17:09:23.000000000 +1100
+++ linux-work/arch/ppc/mm/tlb.c 2005-02-23 18:53:49.000000000 +1100
@@ -62,7 +62,7 @@
ptepage = virt_to_page(ptep);
mm = (struct mm_struct *) ptepage->mapping;
ptephys = __pa(ptep) & PAGE_MASK;
- addr = ptepage->index + (((unsigned long)ptep & ~PAGE_MASK) << 9);
+ addr = ptepage->index + (((unsigned long)ptep & ~PAGE_MASK) << 10);
flush_hash_pages(mm->context, addr, ptephys, 1);
}
^ permalink raw reply
* Re: Ethernet doesn't work in linux for PPC440GP?
From: Shawn Jin @ 2005-02-23 8:02 UTC (permalink / raw)
To: Shawn Jin, uboot, ppcembed
In-Reply-To: <20050223042931.GB31255@gate.ebshome.net>
> You are welcome to submit patch with U-Boot support for Ebony.
> Currently only OpenBIOS is supported.
>
> Look at the way it was done for Ocotea, 2.6 now supports both U-Boot
> and PIBS.
I've done this and will submit it to the list soon.
Regards,
-Shawn.
^ permalink raw reply
* Re: Ethernet doesn't work in linux for PPC440GP?
From: Shawn Jin @ 2005-02-23 8:02 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <20050223042234.GA31255@gate.ebshome.net>
> > zmii0: input 0 in SMII mode
> > eth0: IBM emac, MAC 00:04:ac:e3:1b:bb
> > eth0: Found Generic MII PHY (0x08)
> > zmii0: input 1 in RMII mode
> > eth1: IBM emac, MAC FF:FF:FF:FF:FF:FF
> > eth1: Found Generic MII PHY (0x09)
>
> I already told you that this is wrong, why are you asking again?
> Please, if you asking questions, spend some time reading answers
> given to you, before asking again.
Well, don't be mad at me first. The question may bring out another
round of arguments whether it's a bug related to uboot or linux EMAC
driver. Wolfgang makes it very clear that this is a bug in linux
ethernet driver. And I agree with him. This argument happened before
and I just forgot what specific ethernet driver was in the argument.
> Ebony uses RMII, so SMII is obviously wrong. Most probably your
> firmware doesn't set correct mode and autodetection in the EMAC driver
> fails.
So the EMAC driver does expect a boot loader (the firmware you
mentioned here) to set something for it. Then I think I need to fix it
in this driver instead of in uboot.
-Shawn.
^ permalink raw reply
* [patch] make ppc build with 64-bit resource.start, end
From: Andrew Morton @ 2005-02-23 7:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Greg KH
Could someone please double-check that this is an equivalent
transformation?
(wtf is that code doing, btw?)
Greg's tree changes resource.start and resource.end to u64. So ppc fails to
link due to missing 64-bit divide helpers. Fix.
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
25-akpm/arch/ppc/kernel/pci.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff -puN arch/ppc/kernel/pci.c~ppc32-64-bit-resource-fix arch/ppc/kernel/pci.c
--- 25/arch/ppc/kernel/pci.c~ppc32-64-bit-resource-fix 2005-02-22 23:27:09.000000000 -0800
+++ 25-akpm/arch/ppc/kernel/pci.c 2005-02-22 23:27:33.000000000 -0800
@@ -21,6 +21,7 @@
#include <asm/byteorder.h>
#include <asm/irq.h>
#include <asm/uaccess.h>
+#include <asm/div64.h>
#undef DEBUG
@@ -1088,6 +1089,18 @@ do_update_p2p_io_resource(struct pci_bus
#endif
}
+
+static u64 push_end(struct resource *res, u64 size)
+{
+ u64 end;
+
+ end = res->end + size;
+ do_div(end, size + 1);
+ end *= size + 1;
+ end += size;
+ return end;
+}
+
/* This function is pretty basic and actually quite broken for the
* general case, it's enough for us right now though. It's supposed
* to tell us if we need to open an IO range at all or not and what
@@ -1100,10 +1113,6 @@ check_for_io_childs(struct pci_bus *bus,
int i;
int rc = 0;
-#define push_end(res, size) do { unsigned long __sz = (size) ; \
- res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
- } while (0)
-
list_for_each_entry(dev, &bus->devices, bus_list) {
u16 class = dev->class >> 8;
@@ -1117,7 +1126,7 @@ check_for_io_childs(struct pci_bus *bus,
for (i=0; i<PCI_NUM_RESOURCES; i++) {
struct resource *r;
- unsigned long r_size;
+ u64 r_size;
if (dev->class >> 8 == PCI_CLASS_BRIDGE_PCI
&& i >= PCI_BRIDGE_RESOURCES)
_
^ permalink raw reply
* [PPC32][update] Report chip version in /proc/cpuinfo for 85xx boards
From: Kumar Gala @ 2005-02-23 4:59 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
Andrew,
Here here is an updated version of the previous patch which fixes a
build problem. It is for post 2.6.11.
Report the chip version in /proc/cpuinfo on 85xx ADS and CDS platforms.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
--- a/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-02-22 22:55:17 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_ads_common.c 2005-02-22 22:55:17 -06:00
@@ -43,6 +43,7 @@
#include <asm/mpc85xx.h>
#include <asm/irq.h>
#include <asm/immap_85xx.h>
+#include <asm/ppc_sys.h>
#include <mm/mmu_decl.h>
@@ -128,6 +129,7 @@
pvid = mfspr(PVR);
svid = mfspr(SVR);
+ seq_printf(m, "chip\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name);
seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
switch (svid & 0xffff0000) {
diff -Nru a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-22 13:22:09 -06:00
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c 2005-02-22 13:22:09 -06:00
@@ -145,6 +145,7 @@
pvid = mfspr(PVR);
svid = mfspr(SVR);
+ seq_printf(m, "chip\t\t: %s\n", cur_ppc_sys_spec->ppc_sys_name);
seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
seq_printf(m, "Machine\t\t: CDS (%x)\n", cadmus[CM_VER]);
seq_printf(m, "clock\t\t: %dMHz\n", freq / 1000000);
^ permalink raw reply
* Re: Ethernet doesn't work in linux for PPC440GP?
From: Eugene Surovegin @ 2005-02-23 4:29 UTC (permalink / raw)
To: Shawn Jin; +Cc: uboot, ppcembed
In-Reply-To: <c3d0340b050222190712ee7dff@mail.gmail.com>
On Tue, Feb 22, 2005 at 07:07:44PM -0800, Shawn Jin wrote:
> However with Uboot, the emac driver cannot read MAC addresses from VPD
> correctly. The original 2.6.10 code didn't recognize uboot's bd_info.
You are welcome to submit patch with U-Boot support for Ebony.
Currently only OpenBIOS is supported.
Look at the way it was done for Ocotea, 2.6 now supports both U-Boot
and PIBS.
--
Eugene
^ 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