From: Wolfgang Denk <hidden> Date: 2004-05-19 19:54:00
In message [off-list ref] you wrote:
Is there something special that must be done for the kernel to be
configured for use
with u-boot? A kernel config option, perhaps?
See the README file in the U-Boot source tree. No, this is not a
kernel config option for most boards.
I double checked the include/asm-ppc/u-boot.h in u-boot against
include/asm-ppc/ppcboot.h in linux...and
did find a section with a #define for CONFIG_405, but not 440. We'll see
if that makes a difference.
The question is: does your "arch/ppc/platforms/ebony.h" include
<asm/ppcboot.h> or not, i. e. does it use the U-Boot definitions at
all?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Of all the things I've lost, I miss my mind the most.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Brian Hawley <hidden> Date: 2004-05-19 19:36:50
At 09:54 PM 5/19/04 +0200, Wolfgang Denk wrote:
The question is: does your "arch/ppc/platforms/ebony.h" include
<asm/ppcboot.h> or not, i. e. does it use the U-Boot definitions at
all?
There is no ebony.h in arch/ppc/platforms...the board isn't listed there at
all, neither
is the walnut [ 405 ], but I've seen numerous people discuss the fact that
they have
the ebony board working with this (linux-2.5-ocp from bk) working.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Brian Hawley <hidden> Date: 2004-05-19 20:01:23
Correction,
The platform stuff is down in arch/ppc/platforms/4xx for the PPC4xx
stuff. There is an ebony.h [ and several others ],
but they don't include the ppcboot.h...which would explain why it isn't
getting any information passed from u-boot.
At 09:54 PM 5/19/04 +0200, Wolfgang Denk wrote:
.
The question is: does your "arch/ppc/platforms/ebony.h" include
<asm/ppcboot.h> or not, i. e. does it use the U-Boot definitions at
all?
Best regards,
Wolfgang Denk
From: Brian Hawley <hidden> Date: 2004-05-19 20:24:21
Thanks Eugene.
Actually, I had no intention of trying to port ebony to u-boot. I just wanted
to get something to work.
Unfortunately, we've had no luck getting it to boot with the default ibm
bootloader either.
At 02:04 PM 5/19/04 -0700, Eugene Surovegin wrote:
On Wed, May 19, 2004 at 12:36:50PM -0700, Brian Hawley wrote:
quoted
At 09:54 PM 5/19/04 +0200, Wolfgang Denk wrote:
It's arch/ppc/platforms/4xx/ebony.[ch]
And no, ebony.[ch] doesn't support u-boot. So it cannot work with u-boot
if you
didn't change ebony.[ch].
You cannot just substitute boot loader without changing board support in
Linux
kernel and expect it to work.
.
From: Brian Hawley <hidden> Date: 2004-05-19 20:52:25
Actually, a lot of people succefully boot Ebony using stock IBM boot
loader (me
included)
Please, post boot log for the _default_ Ebony configuration (using IBM
bootlader
_not_ u-boot and build with ebony_defconfig), maybe we can help you.
We're in the process of trying to get the IBM bootloader to work. We think
perhaps
what came with the board from the vendor was somehow not correct. So, we
are trying to find another source for the IBM bootloader that we can flash.
The ebony_defconfig doesn't have support for initrd, and since, at present,
the EMAC
driver seems to only find ff:ff:ff:ff:ff:ff as the Mac address, we aren't
able to boot over
the network [ ebony_defconfig default bootargs ].
Am I correct in assuming that u-boot will not be capable of booting linux
on the ebony
regardless? It does appear to boot linux okay, but we haven't been
successful in getting
it to mount the ramdisk [ which is in u-boot format -- although we've also
tried just the ramdisk_image.gz
and pRamdisk directly tftp'd into memory ]. And, with the network MAC
address issue, we haven't
had any luck with the network stuff either.
Thanks for offering assistance.
-- Brian
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, May 19, 2004 at 12:36:50PM -0700, Brian Hawley wrote:
At 09:54 PM 5/19/04 +0200, Wolfgang Denk wrote:
quoted
The question is: does your "arch/ppc/platforms/ebony.h" include
<asm/ppcboot.h> or not, i. e. does it use the U-Boot definitions at
all?
There is no ebony.h in arch/ppc/platforms...the board isn't listed there at
all, neither
is the walnut [ 405 ], but I've seen numerous people discuss the fact that
they have
the ebony board working with this (linux-2.5-ocp from bk) working.
It's arch/ppc/platforms/4xx/ebony.[ch]
And no, ebony.[ch] doesn't support u-boot. So it cannot work with u-boot if you
didn't change ebony.[ch].
You cannot just substitute boot loader without changing board support in Linux
kernel and expect it to work.
I can only suggest the same thing I told you before, get Ebony running with
standard IBM boot loader (OpenBIOS), study how Linux kernel interact with _this_
bootloader, study how u-boot differs from IBM OpenBIOS and only after having
full understanding how things work, try to port Ebony to using u-boot.
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, May 19, 2004 at 01:24:21PM -0700, Brian Hawley wrote:
Actually, I had no intention of trying to port ebony to u-boot. I just
wanted
to get something to work.
Unfortunately, we've had no luck getting it to boot with the default ibm
bootloader either.
From your previous e-mails I got an impression that booting with OpenBIOS was
OK.
Actually, a lot of people succefully boot Ebony using stock IBM boot loader (me
included)
Please, post boot log for the _default_ Ebony configuration (using IBM bootlader
_not_ u-boot and build with ebony_defconfig), maybe we can help you.
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Brian Hawley <hidden> Date: 2004-05-19 21:27:49
At 03:11 PM 5/19/04 -0700, Eugene Surovegin wrote:
inird option has nothing to do with MAC address. MAC address is read by
ebony.c directly from OpenBIOS VPD area (see ebony.c::ebony_setup_arch())
regardless whether initrd is enabled or not.
I understand that. The point I was trying to make is that with the MAC
address invalid,
we can not use the ebony_defconfig, because it wants to boot and use an NFS
root.
Probably, you have erased this area on your box.
You can hard code MAC address into ebony.c to see whether this helps you
do go
further in boot process.
I'll check ebony.c...the other place I noticed I could do that was in the
ethernet driver itself...
Thanks for the tip.
From: Brian Hawley <hidden> Date: 2004-05-19 21:34:29
At 03:11 PM 5/19/04 -0700, Eugene Surovegin wrote:
inird option has nothing to do with MAC address. MAC address is read by
ebony.c directly from OpenBIOS VPD area (see ebony.c::ebony_setup_arch())
regardless whether initrd is enabled or not.
Probably, you have erased this area on your box.
I don't think so, it always appears correct when I print the
environment variables in uboot. It also appears to be correct when the
IBM boot prom displays the emac parameters.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, May 19, 2004 at 01:52:25PM -0700, Brian Hawley wrote:
The ebony_defconfig doesn't have support for initrd, and since, at present,
the EMAC
driver seems to only find ff:ff:ff:ff:ff:ff as the Mac address, we aren't
able to boot over
the network [ ebony_defconfig default bootargs ].
inird option has nothing to do with MAC address. MAC address is read by
ebony.c directly from OpenBIOS VPD area (see ebony.c::ebony_setup_arch())
regardless whether initrd is enabled or not.
Probably, you have erased this area on your box.
You can hard code MAC address into ebony.c to see whether this helps you do go
further in boot process.
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Brian Hawley <hidden> Date: 2004-05-19 22:19:54
It's possible that after you did something with OpenBIOS, e.g. rebuilt it,
VPD
area moved to some other place. Or probably you have an old or new boot
loader
:)
We are using the one which came with the board about 3 months ago.
Using the default bootloader [ which came with the board ], and the
zImage.ebony which
is produced by:
target=powerpc-eabi-elf
PATH=/opt/rtems/bin:/home/engr/tools/linux2powerpc-eabi-elf/bin:$PATH
OUTPUT=/home/engr/users/bhawley/projects/thirdparty/kernel/ebony_def
make ARCH=ppc O=$OUTPUT mrproper
make CROSS_COMPILE=$target- ARCH=ppc O=$OUTPUT ebony_defconfig
make CROSS_COMPILE=$target- ARCH=ppc O=$OUTPUT
We get:
The IBM boot, looks the same as the uboot boot. But, the EMAC addresses
are correct. However, it still has the same problem in that at the point where
the kernel starts trying to do bootp requests and doesn't get a
response. The DHCP
server is configured [ and we are obviously loading the kernel from it
]. But, at
the point it starts sending BOOTP requests, there is no network
traffic. We are sniffing
the traffic to the dhcp server for the MAC address of the ebony board...and
while we
see the tftp requests...no dhcp requests ever come.
Our dhcpd.conf for ebony looks like:
host ebony {
hardware ethernet 00:04:ac:e3:23:b2;
fixed-address 162.10.98.190;
option root-path "/eldk/ppc_4xx";
option host-name "ebony";
filename "/zImage.ebony";
}
->0
EMAC0: Speed is 100 MBPS, FULL duplex connection
EMAC0: Ethernet Test OK.
Booting from [EMAC0] Ethernet 0 ...
Sending bootp request ...
Loading file "/zImage.ebony" ...
Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at: 00500000 005C81DC
relocated to: 01000000 010C81DC
zimage at: 01005847 010C4136
avail ram: 00400000 00800000
Linux/PPC load: ip=on
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.5 (bnh-engr@feimer) (gcc version 3.3.3) #1 Wed May 19
15:41:31 PDT 2004
IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:8
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: ip=on
PID hash table entries: 1024 (order 10: 8192 bytes)
Memory: 127584k available (1212k kernel code, 428k data, 84k init, 0k
highmem)
Calibrating delay loop... 598.01 BogoMIPS
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: Probing PCI hardware
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt [off-list ref]
zmii0: input 0 in SMII mode
eth0: IBM emac, MAC 00:04:ac:e3:23:b2
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC 00:04:ac:e3:23:b3
eth1: Found Generic MII PHY (0x09)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: Link is Up
eth0: Speed: 100, Full duplex.
Sending BOOTP requests ...... timed out!
IP-Config: Retrying forever (NFS root)...
eth0: Speed: 100, Full duplex.
Sending BOOTP requests ...
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, May 19, 2004 at 02:34:29PM -0700, Brian Hawley wrote:
At 03:11 PM 5/19/04 -0700, Eugene Surovegin wrote:
quoted
inird option has nothing to do with MAC address. MAC address is read by
ebony.c directly from OpenBIOS VPD area (see ebony.c::ebony_setup_arch())
regardless whether initrd is enabled or not.
Probably, you have erased this area on your box.
I don't think so, it always appears correct when I print the
environment variables in uboot.
This is irrelevant, ebony.c doesn't know about u-boot.
It also appears to be correct when the
IBM boot prom displays the emac parameters.
It's possible that after you did something with OpenBIOS, e.g. rebuilt it, VPD
area moved to some other place. Or probably you have an old or new boot loader
:)
ebony.h uses hardcoded addresses:
/* Macros to get at Ebony VPD info */
#define EBONY_VPD_BASE 0x00000001fffffe00ULL
#define EBONY_VPD_SIZE 0x24
#define EBONY_NA0_OFFSET 0x0c
#define EBONY_NA1_OFFSET 0x18
#define EBONY_NA0_ADDR(base) (base + EBONY_NA0_OFFSET)
#define EBONY_NA1_ADDR(base) (base + EBONY_NA1_OFFSET)
P.S. There is another possible solution for your problems, you can hire somebody
who knows this stuff.
I bet there are people here who are available. Just send a message to the list
with appropriate subject :)
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Brian Hawley <hidden> Date: 2004-05-19 23:09:13
Thanks Eugene.
We've been sniffing that for several weeks now. That Mac address
does not send out any packages once it moves to the BOOTP stage.
We can get past this point, if we manually set the default boot args and fill
in all the root/nfsroot/ip= args and not do auto config. At that point we get
past IP-Config, but then no traffic after that...and, it appears that in
all cases,
the board is not responding to any 'ping's once it hits the BOOTP request or
RPC lookup stage. We must be missing something extremely obvious.
Loading file "/zImage.ebony.nfs" ...
Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at: 00500000 005D11DC
relocated to: 01000000 010D11DC
zimage at: 010058BB 010CDC4F
avail ram: 00400000 00800000
Linux/PPC load: root=/dev/nfs rw nfsroot=162.10.98.2:/eldk/ppc_4xx
ip=162.10.98.190:162.10.98.2:162.10.98.1:255.255.255.
0:ebony:eth0:off
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.5 (bnh-engr@feimer) (gcc version 3.3.3) #2 Wed May 19
16:33:55 PDT 2004
IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:8
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: root=/dev/nfs rw nfsroot=162.10.98.2:/eldk/ppc_4xx
ip=162.10.98.190:162.10.98.2:162.10.98.1:255.255
.255.0:ebony:eth0:off
PID hash table entries: 1024 (order 10: 8192 bytes)
Memory: 127488k available (1280k kernel code, 440k data, 92k init, 0k
highmem)
Calibrating delay loop... 598.01 BogoMIPS
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: Probing PCI hardware
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt [off-list ref]
zmii0: input 0 in SMII mode
eth0: IBM emac, MAC 00:04:ac:e3:23:b2
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC 00:04:ac:e3:23:b3
eth1: Found Generic MII PHY (0x09)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: Link is Up
eth0: Speed: 100, Full duplex.
IP-Config: Complete:
device=eth0, addr=162.10.98.190, mask=255.255.255.0,
gw=162.10.98.1,
host=ebony, domain=, nis-domain=(none),
bootserver=162.10.98.2, rootserver=162.10.98.2, rootpath=
Looking up port of RPC 100003/2 on 162.10.98.2
At 04:42 PM 5/19/04 -0700, Eugene Surovegin wrote:
On Wed, May 19, 2004 at 03:19:54PM -0700, Brian Hawley wrote:
quoted
Loading file "/zImage.ebony" ...
Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at: 00500000 005C81DC
relocated to: 01000000 010C81DC
zimage at: 01005847 010C4136
avail ram: 00400000 00800000
Linux/PPC load: ip=on
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.5 (bnh-engr@feimer) (gcc version 3.3.3) #1 Wed May 19
15:41:31 PDT 2004
IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:8
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: ip=on
PID hash table entries: 1024 (order 10: 8192 bytes)
Memory: 127584k available (1212k kernel code, 428k data, 84k init, 0k
highmem)
Calibrating delay loop... 598.01 BogoMIPS
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: Probing PCI hardware
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt [off-list ref]
zmii0: input 0 in SMII mode
eth0: IBM emac, MAC 00:04:ac:e3:23:b2
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC 00:04:ac:e3:23:b3
eth1: Found Generic MII PHY (0x09)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: Link is Up
eth0: Speed: 100, Full duplex.
Sending BOOTP requests ...... timed out!
IP-Config: Retrying forever (NFS root)...
eth0: Speed: 100, Full duplex.
Sending BOOTP requests ...
Looks fine until BOOTP stage. Use any sniffer to check whether BOOTP requests
are coming out.
Please, check that your DHCP server allows BOOTP clients.
Eugene.
From: Brian Hawley <hidden> Date: 2004-05-19 23:40:48
Thanks. I checked out the linux-2.5-ocp using the site you recommended
before. Perhaps
there have been some patches in the last couple months...
However, I will also download from kernel.org's kernel since the ocp stuff
has been merged in.
At 05:19 PM 5/19/04 -0700, Eugene Surovegin wrote:
On Wed, May 19, 2004 at 04:42:28PM -0700, Eugene Surovegin wrote:
[snip]
quoted
quoted
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt [off-list ref]
zmii0: input 0 in SMII mode
This is quite suspicious (SMII) ^^^^
quoted
quoted
eth0: IBM emac, MAC 00:04:ac:e3:23:b2
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
... and this (RMII) ^^^^
[snip]
Please, make sure you are using the latest linux-2.5-ocp or just latest
kernel.org's kernel (OCP stuff was just merged in).
Eugene
On Wed, May 19, 2004 at 03:19:54PM -0700, Brian Hawley wrote:
Loading file "/zImage.ebony" ...
Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at: 00500000 005C81DC
relocated to: 01000000 010C81DC
zimage at: 01005847 010C4136
avail ram: 00400000 00800000
Linux/PPC load: ip=on
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.5 (bnh-engr@feimer) (gcc version 3.3.3) #1 Wed May 19
15:41:31 PDT 2004
IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
On node 0 totalpages: 32768
DMA zone: 32768 pages, LIFO batch:8
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: ip=on
PID hash table entries: 1024 (order 10: 8192 bytes)
Memory: 127584k available (1212k kernel code, 428k data, 84k init, 0k
highmem)
Calibrating delay loop... 598.01 BogoMIPS
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: Probing PCI hardware
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt [off-list ref]
zmii0: input 0 in SMII mode
eth0: IBM emac, MAC 00:04:ac:e3:23:b2
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC 00:04:ac:e3:23:b3
eth1: Found Generic MII PHY (0x09)
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: Link is Up
eth0: Speed: 100, Full duplex.
Sending BOOTP requests ...... timed out!
IP-Config: Retrying forever (NFS root)...
eth0: Speed: 100, Full duplex.
Sending BOOTP requests ...
Looks fine until BOOTP stage. Use any sniffer to check whether BOOTP requests
are coming out.
Please, check that your DHCP server allows BOOTP clients.
Eugene.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Wed, May 19, 2004 at 04:42:28PM -0700, Eugene Surovegin wrote:
[snip]
quoted
mal0: Initialized, 4 tx channels, 2 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt [off-list ref]
zmii0: input 0 in SMII mode
This is quite suspicious (SMII) ^^^^
quoted
eth0: IBM emac, MAC 00:04:ac:e3:23:b2
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
... and this (RMII) ^^^^
[snip]
Please, make sure you are using the latest linux-2.5-ocp or just latest
kernel.org's kernel (OCP stuff was just merged in).
Eugene
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/