MBX boot problems

MBX boot problems

[Brent]

So I've searched the archives and read the readme's, and it still won't
boot. :)

Story so far- I got the mbxboot.min downloaded and put on a box with tftp
and NFS access. The initial load seems to work fine, based on the
following portion of output:

EPPC-Bug>pl 20 0
Network Booting from: MPC860, Controller 20, Device 0
Loading: zImage
Client IP Address = 205.170.190.252
Server IP Address = 205.170.190.3
Gateway IP Address = 0.0.0.0
Subnet IP Address Mask = 255.255.255.0
Boot File Name = zImage
Argument File Name =

Bytes Received =&492532, Bytes Loaded =&492532
Bytes/Second =&246266, Elapsed Time =2 Secondloaded at:  00210000 0030E42C

relocated to:	00100000 001FE42C
board data at:	043F4558 043F4580
relocated to:	00200100 00200128
zimage at:	00216000 00276D6D
avail ram:	0030E42C 043F5000

Linux/PPC load:

At this point, things go bad.  I've tried two things. 1) hitting enter and
letting things fall as they may.  This didn't work since there seemed to
be a problem with it dropping the middle digit of the first octet of the
src/dst IP addresses in the boot args.  2)  explicitly defining the boot
arguments with appropriate settings.

Both return approximately the same results (shown below).


Uncompressing Linux...done.
Now booting the kernel
Linux version 2.1.119 (dan@pbdan.clearone.com) (gcc version egcs-2.90.25
980302 (egcs-1.0.2 prerelease)) #31 Mon Sep 7 18:14:20 EDT 1998
Boot arguments: root=/dev/nfs nfsaddrs=205.170.190.252:205.170.190.3
nfsroot=205 .170.190.3:/nfs/mbxroot
time_init: decrementer frequency = 187500000/60
Memory: 67572k available (732k kernel code, 1292k data, 36k init)
[c0000000,c440 0000]
PCI: Probing PCI hardware
NIP: C00085A4 XER: 20000000 LR: C0008314 REGS: c00ce958 TRAP: 0200
MSR: 00001932 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c00ccb08[0] 'swapper' mm->pgd c00ca000 Last syscall: 0
last math 00000000
GPR00: 0000000C C00CEA48 C00CCB08 00000086 00000000 0000000E C00CEA80
00000000
GPR08: FA210500 0000000D 0000000C FA210500 C00CEA68 00000000 00000000
00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 043F4558 00000000
FFFFFFFF
GPR24: C011FD30 C00CEA90 00000000 00000000 00000000 C011FD20 00000000
C00CEA84
Call backtrace: 00000182 C00CEAD0 C00E1E84 C00E2340 C00DB6A4 C00021A8
Kernel panic: kernel access of bad area pc c00085a4 lr c0008314 address
C000FFF0 tsk swapper/0 In swapper task - not syncing
Rebooting in 180 seconds..

I'm sure that all means something to someone, but not me. :)  Can anyone
offer suggestions?

Thanks

-brent


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

Re: MBX boot problems

[Graham Stoney]

Hi Brent,

Brent writes:
> At this point, things go bad.  I've tried two things. 1) hitting enter and
> letting things fall as they may.  This didn't work since there seemed to
> be a problem with it dropping the middle digit of the first octet of the
> src/dst IP addresses in the boot args.  2)  explicitly defining the boot
> arguments with appropriate settings.

Do you by any chance have the CPU6 workarounds enabled?

If so, try commenting out the following lines in
arch/ppc/kernel/head.S:set_dec:

        lis     r7, cmd_line@h                  ###
        ori     r7, r7, cmd_line@l              ###
        li      r4, 0x2c00                      ###
        stw     r4, 12(r7)                      ###
        lwz     r4, 12(r7)                      ###

This workaround will cause your kernel command line to get trashed.

Regards,
Graham
--
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

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

Re: MBX boot problems

[Wolfgang Denk]

In message <Pine.GSO.4.05.10005211739380.9894-100000@ns1.planetspork.com> you wrote:
>
> So I've searched the archives and read the readme's, and it still won't
> boot. :)

Well, let's see...

> At this point, things go bad.  I've tried two things. 1) hitting enter and
> letting things fall as they may.  This didn't work since there seemed to
> be a problem with it dropping the middle digit of the first octet of the
> src/dst IP addresses in the boot args.  2)  explicitly defining the boot
> arguments with appropriate settings.

Graham Stoney commented on # 2, so I'll give a try on # 1 :-)

There  once  was  a   bug   with   the   IP   address   handling   in
arch/ppc/mbxboot/misc.c   ;   if   you   can   find   a  place  where
"nfsaddrs_string" you should be able to figure out how to replace the
existing code with the following snippet:

		...
		dp = nfsaddrs_string;		/* nfsaddrs=x.x.x.x:y.y.y.y	*/
		while (*dp) {
			putc(*cp++ = *dp++);
		}
		/* add IP addresses as <my_ip>:<serv_ip> */
		for (i=0; i<4; ++i, ++byte) {
			unsigned char outbuf[4];	/* 3 digits + '\0' */
			unsigned char *optr = &outbuf[sizeof(outbuf)-1];

			*optr = '\0';

			do {
				*--optr = (*byte % 10) + '0';
				*byte /= 10;
			} while (*byte);

			while (*optr) {
				putc (*cp++ = *optr++);
			}

			if (i<3) {
				putc(*cp++ = '.');
			}
		}
		putc(*cp++ = ':');
		...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Today's robots are very primitive, capable of understanding  only  a
few  simple  instructions  such  as 'go left', 'go right', and 'build
car'."                                                  - John Sladek

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

Re: MBX boot problems

[Dan Malek]

Brent wrote:

> Memory: 67572k available (732k kernel code, 1292k data, 36k init)
> [c0000000,c440 0000]
> PCI: Probing PCI hardware
> NIP: C00085A4 XER: 20000000 LR: C0008314 REGS: c00ce958 TRAP: 0200
> MSR: 00001932 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
> TASK = c00ccb08[0] 'swapper' mm->pgd c00ca000 Last syscall: 0
> last math 00000000
> GPR00: 0000000C C00CEA48 C00CCB08 00000086 00000000 0000000E C00CEA80
> 00000000
> GPR08: FA210500 0000000D 0000000C FA210500 C00CEA68 00000000 00000000
> 00000000

The kernel is built for a system that has the Tundra QSpan PCI
bridge.  Your system doesn't have one or it is not working.  The
machine check exception occurred when it tried to probe for devices.

Some evidence for this.....First, the message was printed and the
system immediately failed.  Registers 8 and 11, typically used for
indirect references, hold the address of the PCI configuration
registers, and it failed with a machine check exception.....


	-- Dan

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