ELDK help

ELDK help

[Jack Liu]

hi,all
     ELDK worked for me greatly before. Just a few days ago,I found that
when I not use make clean, things work ok. However when I make clean and
make uImage, the following error message appears:

 scripts/mkversion > .tmpversion
ppc_82xx-gcc -D__KERNEL__ -I/root/new/4.1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/root/new/4.1/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring  -DUTS_MACHINE='"ppc"' -DKBUILD_BASENAME=version -c -o init/version.o init/version.c
make CFLAGS="-D__KERNEL__ -I/root/new/4.1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/root/new/4.1/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring " -C  kernel
......
make[2]: Entering directory `/root/new/4.1/drivers/char'
make -C joystick
make[3]: Entering directory `/root/new/4.1/drivers/char/joystick'
make all_targets
make[4]: Entering directory `/root/new/4.1/drivers/char/joystick'
make[4]: Nothing to be done for `all_targets'.
make[4]: Leaving directory `/root/new/4.1/drivers/char/joystick'
make[3]: Leaving directory `/root/new/4.1/drivers/char/joystick'
make all_targets
make[3]: Entering directory `/root/new/4.1/drivers/char'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -I/root/new/4.1/arch/ppc -o conmakehash conmakehash.c
/tmp/cck3aG7b.s: Assembler messages:
/tmp/cck3aG7b.s:2: Warning: Unrecognized .section attribute: want a,m,s,w,x
/tmp/cck3aG7b.s:2: Warning: Unrecognized .section attribute: want a,m,s,w,x
/tmp/cck3aG7b.s:155: Warning: Unrecognized .section attribute: want a,m,s,w,x
/tmp/cck3aG7b.s:155: Warning: Unrecognized .section attribute: want a,m,s,w,x
/usr/local/bin/ld: unrecognized option '--eh-frame-hdr'
/usr/local/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status
make[3]: *** [conmakehash] Error 1
make[3]: Leaving directory `/root/new/4.1/drivers/char'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/root/new/4.1/drivers/char'
make[1]: *** [_subdir_char] Error 2
make[1]: Leaving directory `/root/new/4.1/drivers'
make: *** [_dir_drivers] Error 2

  It seems that the toolchain is broken since it used gcc instead of
ppc_82xx-gcc which caused error happen. I reinstalled the ELDK and not
help. So what could be the problem? Some configuration changes?

Best regards
Jack Liu

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ELDK help

[Wolfgang Denk]

In message <200405180149.i4I1niRV001354@ms.usish.com> you wrote:
>
>      ELDK worked for me greatly before. Just a few days ago,I found that
> when I not use make clean, things work ok. However when I make clean and
> make uImage, the following error message appears:

What host system are you running? Are you sure your  native  compiler
is working?

Which kernel tree is this? How did you configure the kernel? What  is
the _exact_ sequence of commands you are using?

> make[3]: Entering directory `/root/new/4.1/drivers/char'
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -I/root/new/4.1/arch/ppc -o conmakehash conmakehash.c
> /tmp/cck3aG7b.s: Assembler messages:
> /tmp/cck3aG7b.s:2: Warning: Unrecognized .section attribute: want a,m,s,w,x
> /tmp/cck3aG7b.s:2: Warning: Unrecognized .section attribute: want a,m,s,w,x
> /tmp/cck3aG7b.s:155: Warning: Unrecognized .section attribute: want a,m,s,w,x
> /tmp/cck3aG7b.s:155: Warning: Unrecognized .section attribute: want a,m,s,w,x
> /usr/local/bin/ld: unrecognized option '--eh-frame-hdr'
> /usr/local/bin/ld: use the --help option for usage information
...

>   It seems that the toolchain is broken since it used gcc instead of
> ppc_82xx-gcc which caused error happen. I reinstalled the ELDK and not

You are wrong. This is one of the source files  which  gets  compiled
using the host's native compiler; the Makefile has this rule for it:

	conmakehash: conmakehash.c
		$(HOSTCC) $(HOSTCFLAGS) -o conmakehash conmakehash.c

> help. So what could be the problem? Some configuration changes?

Obviously your hostcompiler (gcc) and/or  you  host's  binutils  have
some problems. This is not a problem with the ELDK.

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
Wait!  You have not been prepared!
	-- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

 > We've been trying to get linux-2.5-ocp up and running on the ebony
 > board. Thanks to those who have helped, but we are still stuck, and have
 > figured out a
 > few things, but need some advice on others.
 >
 > Using the default ebony config (ebony_defconfig) we found that the default
 > bootargs (ip=on) always overrode whatever we passed from the bootargs in
 > u-boot. This always ended up with retries and NFS timeouts...
 >
 > When we recompiled linux with the default boot args off, we were able to
 > use the bootargs as laid out in the DULG for booting with an NFS root, but
 > the kernel panics...
 >
 > One thing that looks very odd is the Mac Address. The u-boot printenv
 > shows the mac address as we've listed it in the dhcp information. But, it
 > isn't clear that
 > the linux kernel can get access to the Mac Address....
 >
 >
 > Clearly, we are missing something obvious??
 >
 > Any help would be appreciated.
 >
 > Here's our dhcpd.conf.
 >
 > /* generic network stuff and router and other information deleted ... */
 > 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 "/uImage-rd";
 > }
 >
 > showmount -e indicates that it is exported:
 >
 > 2 > showmount -e
 > export list for orion:
 > /eldk/ppc_4xx (everyone)
 >
 >
 > We can tftp just fine from it, but when we attempt to boot with an NFS
root...
 >
 > When booting using the version without the default bootargs (ip=on) and the
 > arguments laid out in the DULG, we get the following:
 >
 > Linux version 2.6.5 (root@feimer) (gcc version 3.3.3) #1 Fri May 14
 > 12:13:24 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:
 > 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 <benh@kernel.crashing.org>
 > zmii0: input 0 in SMII mode
 > eth0: IBM emac, MAC ff:ff:ff:ff:ff:ff
 > 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)
 > 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
 > Root-NFS: No NFS server available, giving up.
 > VFS: Unable to mount root fs via NFS, trying floppy.
 > Kernel panic: VFS: Unable to mount root fs on unknown-block(2,0)
 > <0>Rebooting in 180 seconds..<6>eth0: Link is Up
 > eth0: Speed: 100, Full duplex.
 >
 >


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Gerhard Jaeger]

Hi,

sorry if this is too obvious, but could it be, that you missed to set the
following kernel option:
CONFIG_IP_PNP_DHCP=y
Also setting bootarg to ip=auto will be a good idea. What made me suspicious
from your logs is, that I do not see any output from the kernel sayin'
something about received IP-addresses etc...

Correct me if I'm wrong (I use bootp and tftp here), but at least you should
get something like this even for DHCP:

Sending BOOTP requests .. OK
IP-Config: Got BOOTP answer from 172.40.1.130, my address is 172.40.1.131
IP-Config: Complete:
      device=eth0, addr=192.168.1.131, mask=255.255.255.0, gw=255.255.255.255,
     host=pappnase, domain=, nis-domain=(none),
     bootserver=192.168.1.130, rootserver=192.168.130, rootpath=/tftpboot/pappnase

Hope this helps,
  Gerhard


On Tuesday 18 May 2004 18:32, Brian Hawley wrote:
>  > We've been trying to get linux-2.5-ocp up and running on the ebony
>  > board. Thanks to those who have helped, but we are still stuck, and have
>  > figured out a
>  > few things, but need some advice on others.
>  >
>  > Using the default ebony config (ebony_defconfig) we found that the
>  > default bootargs (ip=on) always overrode whatever we passed from the
>  > bootargs in u-boot. This always ended up with retries and NFS
>  > timeouts...
[SNIPSNAP]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

Thanks for the reply.

I looked at the .config, and DHCP is not set, although BOOTP is.

The reason there aren't any BOOTP requests is that we changed the default
bootargs from ip=on
to putting the ip=ourip:serverip: ... directly....because we were never
seeing any bootp/dhcp responses
come out.  We think that is because linux is thinking the MAC address is
ff:ff:ff:ff:ff:ff instead of what
it really is.  u-boot doesn't seem to have a problem getting the MAC
address out of the ebony board, but
this linux kernel seems to.

At 09:23 AM 5/19/04 +0200, Gerhard Jaeger wrote:
>Hi,
>
>sorry if this is too obvious, but could it be, that you missed to set the
>following kernel option:
>CONFIG_IP_PNP_DHCP=y
>Also setting bootarg to ip=auto will be a good idea. What made me suspicious
>from your logs is, that I do not see any output from the kernel sayin'
>something about received IP-addresses etc...
>
>Correct me if I'm wrong (I use bootp and tftp here), but at least you should
>get something like this even for DHCP:
>
>Sending BOOTP requests .. OK
>IP-Config: Got BOOTP answer from 172.40.1.130, my address is 172.40.1.131
>IP-Config: Complete:
>       device=eth0, addr=192.168.1.131, mask=255.255.255.0,
> gw=255.255.255.255,
>      host=pappnase, domain=, nis-domain=(none),
>      bootserver=192.168.1.130, rootserver=192.168.130,
> rootpath=/tftpboot/pappnase
>
>Hope this helps,
>   Gerhard
>
>
>On Tuesday 18 May 2004 18:32, Brian Hawley wrote:
> >  > We've been trying to get linux-2.5-ocp up and running on the ebony
> >  > board. Thanks to those who have helped, but we are still stuck, and have
> >  > figured out a
> >  > few things, but need some advice on others.
> >  >
> >  > Using the default ebony config (ebony_defconfig) we found that the
> >  > default bootargs (ip=on) always overrode whatever we passed from the
> >  > bootargs in u-boot. This always ended up with retries and NFS
> >  > timeouts...
>[SNIPSNAP]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Mark Chambers]

We think that is because linux is thinking the MAC address is
> ff:ff:ff:ff:ff:ff instead of what
> it really is.  u-boot doesn't seem to have a problem getting the MAC
> address out of the ebony board, but
> this linux kernel seems to.
>

A MAC address of  ff:ff:ff:ff:ff:ff  is the broadcast address, so that's a
problem.  I'm not familiar with 440, but the thing is, you've got to find
your ethernet specific code in the kernel and see where it's getting the MAC
from.  u-boot passes a bd_t pointer to the kernel (a struct with a bunch of
board data), but there's probably some kind of mis-match between u-boot and
the platform config of the kernel.

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

Thanks.

In a previous kernel, I had sync'd up the bd_t...but in the 2.5-ocp,
I did not add the "defined(CONFIG_440)" to the 405 around the
ethernet section.

Not out of the woods yet...but a little closer.

Thanks.

At 01:37 PM 5/19/04 -0400, Mark Chambers wrote:

>We think that is because linux is thinking the MAC address is
> > ff:ff:ff:ff:ff:ff instead of what
> > it really is.  u-boot doesn't seem to have a problem getting the MAC
> > address out of the ebony board, but
> > this linux kernel seems to.
> >
>
>A MAC address of  ff:ff:ff:ff:ff:ff  is the broadcast address, so that's a
>problem.  I'm not familiar with 440, but the thing is, you've got to find
>your ethernet specific code in the kernel and see where it's getting the MAC
>from.  u-boot passes a bd_t pointer to the kernel (a struct with a bunch of
>board data), but there's probably some kind of mis-match between u-boot and
>the platform config of the kernel.
>
>Mark Chambers
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Wolfgang Denk]

In message <4.2.2.20040519091201.05090ce0@bhawley.mailhost.luminex.com> you wrote:
>
...
> come out.  We think that is because linux is thinking the MAC address is
> ff:ff:ff:ff:ff:ff instead of what
> it really is.  u-boot doesn't seem to have a problem getting the MAC
> address out of the ebony board, but
> this linux kernel seems to.

U-Boot passes the MAC address to the Linux kernel, so if your  kernel
is  configured  for use with U-Boot, then it will pick up the correct
MAC address. Maybe it is not?

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
No one may kill a man.  Not for any purpose.  It cannot be condoned.
	-- Kirk, "Spock's Brain", stardate 5431.6

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

Is there something special that must be done for the kernel to be
configured for use
with u-boot?  A kernel config option, perhaps?

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.

At 07:59 PM 5/19/04 +0200, Wolfgang Denk wrote:
>In message <4.2.2.20040519091201.05090ce0@bhawley.mailhost.luminex.com>
>you wrote:
> >
>...
> > come out.  We think that is because linux is thinking the MAC address is
> > ff:ff:ff:ff:ff:ff instead of what
> > it really is.  u-boot doesn't seem to have a problem getting the MAC
> > address out of the ebony board, but
> > this linux kernel seems to.
>
>U-Boot passes the MAC address to the Linux kernel, so if your  kernel
>is  configured  for use with U-Boot, then it will pick up the correct
>MAC address. Maybe it is not?
>
>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
>No one may kill a man.  Not for any purpose.  It cannot be condoned.
>         -- Kirk, "Spock's Brain", stardate 5431.6


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Wolfgang Denk]

In message <4.2.2.20040519101456.0509d340@bhawley.mailhost.luminex.com> 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/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

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/

Re: Ebony Board, PPC440GP and NFS panics

[Eugene Surovegin]

On Wed, May 19, 2004 at 12:36:50PM -0700, Brian Hawley wrote:
>
> 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.

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/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

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:
> >
> > 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.
>
>.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Eugene Surovegin]

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/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

>
>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/

Re: Ebony Board, PPC440GP and NFS panics

[Eugene Surovegin]

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/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

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.

>Eugene.
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

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/

Re: Ebony Board, PPC440GP and NFS panics

[Eugene Surovegin]

On Wed, May 19, 2004 at 02:34:29PM -0700, Brian Hawley wrote:
> 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.

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/

Re: Ebony Board, PPC440GP and NFS time out

[Brian Hawley]

>
>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 <benh@kernel.crashing.org>
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/

Re: Ebony Board, PPC440GP and NFS time out

[Eugene Surovegin]

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 <benh@kernel.crashing.org>
> 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/

Re: Ebony Board, PPC440GP and NFS time out

[Brian Hawley]

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 <benh@kernel.crashing.org>
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:
> > 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 <benh@kernel.crashing.org>
> > 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/

Re: Ebony Board, PPC440GP and NFS time out

[Eugene Surovegin]

On Wed, May 19, 2004 at 04:42:28PM -0700, Eugene Surovegin wrote:

[snip]

> > mal0: Initialized, 4 tx channels, 2 rx channels
> > emac: IBM EMAC Ethernet driver, version 2.0
> > Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > zmii0: input 0 in SMII mode

This is quite suspicious (SMII) ^^^^

> > 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/

Re: Ebony Board, PPC440GP and NFS time out

[Brian Hawley]

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]
>
> > > mal0: Initialized, 4 tx channels, 2 rx channels
> > > emac: IBM EMAC Ethernet driver, version 2.0
> > > Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > zmii0: input 0 in SMII mode
>
>This is quite suspicious (SMII) ^^^^
>
> > > 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/

Re: Ebony Board, PPC440GP and NFS panics

[Brian Hawley]

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


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Ebony Board, PPC440GP and Ramdisk

[Brian Hawley]

We aren't too successful at getting a ramdisk up either.


## Checking Image at 00100000 ...
Image Name: Linux-2.6.5
Created: 2004-05-19 19:39:09 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 787934 Bytes = 769.5 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Checking Image at 00200000 ...
Image Name: ramdisk image
Created: 2004-05-19 20:40:12 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1476478 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK

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/ram rw
PID hash table entries: 1024 (order 10: 8192 bytes)
Memory: 127552k available (1220k kernel code, 436k data, 92k init, 0k highmem)
[ *chopped extraneous msgs * ]
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
Kernel panic: VFS: Unable to mount root fs on ram0
<0>Rebooting in 180 seconds..<6>eth0: Link is Up


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/