Motorola MPC8260-ADS Boot hassel

Motorola MPC8260-ADS Boot hassel

[Steve Tarr]

OK, I' stumped. I'm trying to do a port to Motorola's
MPC8260 evaluation board using 2.3.99-pre7. Aside from
hacking the loader and the 8260_io/uart.c to handle
the console on SCC1, I've done nothing. The following is the
boot messages:

loaded at:     00600000 0060B288
relocated to:  00400000 0040B288
board data at: 00407140 00407164
relocated to:  00200100 00200124
zimage at:     00606000 00675258
initrd at:     00675258 0084C0A3
avail ram:     0084D000 01000000

Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel
Total memory = 16MB; using 0kB for hash table (at 00000000)
Linux version 2.3.99-pre7 (tarr@norton) (gcc version 2.95.2 19991024
(release))0
Boot arguments: root=/dev/ram ip=off
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Calibrating delay loop... 66.15 BogoMIPS
Memory: 12884k available (876k kernel code, 364k data, 48k init)
[c0000000,c100]
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
CPM UART driver version 0.02
ttyS00 at 0x8000 is a SCC
ttyS01 at 0x8100 is a SCC
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: registered device at major 7
loop: enabling 8 loop devices
RAMDISK: Compressed image found at block 0
NIP: C0010D90 XER: 20000000 LR: C0010D8C REGS: c085f260 TRAP: 0300
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c085e000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00000000 C085F310 C085E000 00000001 00009032 C085F348 C085F368
01234567
GPR08: C085E000 C0008540 00000000 C085F358 00000000 FFFFFFFF 00000000
00000400
GPR16: 00000000 C0876C00 00007000 00001000 00000100 00001000 0000099C
C0120000
GPR24: 00000000 00000000 C085F358 C085F348 C01033E0 C0100000 00000000
C085F310
Call backtrace:
C0005038 C00347AC C0032080 C0032124 C00381C8 C01198BC C0080AA4
C00814F0 C0081638 C00816C4 C0081BDC C0119A24 C01193B4 C0119794
C0117AF4 C01137E0 C0113878 C0003A1C C0008C08
Kernel panic: kernel access of bad area pc c0010d90 lr c0010d8c address
3C tsk 1Rebooting in 180 seconds..

Based on my simple attempts it appears that I am taking a DSI exception
on an access to
0xC010000 which should be a pointer to a struct task_struct.

I noticed in System.map that data does not the first data entry is at
c0101000 - empty_zero_page

My guess is that I don't memory properly configured or something like
that.
Note: they put the SUNI-Lite and board registers at
0x04500000-0x04700000.

Any thoughts?

Thanks --

--
Steven Tarr
Lucent Technologies - Bell Labs
303-538-4056
tarr@lucent.com

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

Re: Motorola MPC8260-ADS Boot hassel

[Steve Tarr]

Sorry for the confusion. I am not familiar with the
Linux PANIC messages.

1. NIP 0xC0010D90 is in wake_up_process()

>From System.map:
c0010930 t show_task
c0010b70 T render_sigset_t
c0010c78 T show_state
c0010cec T daemonize
c0010d50 T wake_up_process
c0010ebc T get_dma_list
c0010f30 T request_dma
c0010f9c T free_dma
c0011010 T free_uid
c0011084 T alloc_uid

2. The wake_up_process() is in sched.c

3. Disasembling sched.o gave me a file offset of 0x1dc0 for
wake_up_process(). The failing
   instruction is 0x40 down from the start of wake_up_process().

    1dc0:   94 21 ff d0     stwu    r1,-48(r1)
    1dc4:   7c 08 02 a6     mflr    r0
    1dc8:   bf 81 00 20     stmw    r28,32(r1)
    1dcc:   90 01 00 34     stw r0,52(r1)
    1dd0:   7c 3f 0b 78     mr  r31,r1
    1dd4:   7c 7e 1b 78     mr  r30,r3
    1dd8:   3f a0 00 00     lis r29,0
    1ddc:   3b 9d 00 00     addi    r28,r29,0
    1de0:   81 3c 00 0c     lwz r9,12(r28)
    1de4:   38 7f 00 08     addi    r3,r31,8
    1de8:   7d 28 03 a6     mtlr    r9
    1dec:   4e 80 00 21     blrl
    1df0:   80 1d 00 00     lwz r0,0(r29)
    1df4:   7c 08 03 a6     mtlr    r0
    1df8:   4e 80 00 21     blrl
    1dfc:   38 00 00 00     li  r0,0
 >> 1e00:   81 3e 00 3c     lwz r9,60(r30)
    1e04:   90 1e 00 00     stw r0,0(r30)
    1e08:   2c 09 00 00     cmpwi   r9,0
    1e0c:   40 82 00 f8     bne 1f04 <wake_up_process+0x144>

    Note: r30 is loaded from the paramenter passed in, r3.

4. I made a seemingly foolish assumption that the TRAP: 0300
   was the exception vector. Hence that it was a DSI exception.
   Looking at the register dump shows r30 = 0xc0100000. Hence
   my question.

5. The SUNI-lite is an SDH/ATM framer for the Fiber that uses FCC2. I
mention the
   addresses only in so far as I have done anything about them. Again,
   I am certain the code is fine, I just have a configuration/setup
problem.

cheers --
tarr

Dan Malek wrote:
>
> Steve Tarr wrote:
>
> I haven't tried ramdisks recently......
>
> > RAMDISK: Compressed image found at block 0
> > NIP: C0010D90 XER: 20000000 LR: C0010D8C REGS: c085f260 TRAP: 0300
>
> What function is this (0xc0010d90)?  It is hard to help without some
> basic information like this.
>
> > GPR08: C085E000 C0008540 00000000 C085F358 00000000 FFFFFFFF 00000000
> > 00000400
>
> > Kernel panic: kernel access of bad area pc c0010d90 lr c0010d8c address
> > 3C tsk 1Rebooting in 180 seconds..
> >
> > Based on my simple attempts it appears that I am taking a DSI exception
> > on an access to
> > 0xC010000......
>
> How did you determine this?  The panic message prints the faulting
> address, which happens to be 0x3c.  GPR8, 9, 10, 11, and 12 are typical
> sources for intermediate pointers, two of those are zero.  I would
> guess a NULL pointer to a data structure trying to access the contents
> at offset 0x3c.
>
> > I noticed in System.map that data does not the first data entry.....
>
> Next time notice and tell us the function at NIP....much more useful.
>
> > Note: they put the SUNI-Lite and board registers at
> > 0x04500000-0x04700000.
>
> Who is they, what's a SUNI-Lite, and does it matter?  Best of all,
> if you don't like the address you can change it.
>
> We need more info.
>
>         -- Dan

--
Steven Tarr
Lucent Technologies - Bell Labs
303-538-4056
tarr@lucent.com

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

Re: Motorola MPC8260-ADS Boot hassel

[Dan Malek]

Steve Tarr wrote:

I haven't tried ramdisks recently......


> RAMDISK: Compressed image found at block 0
> NIP: C0010D90 XER: 20000000 LR: C0010D8C REGS: c085f260 TRAP: 0300

What function is this (0xc0010d90)?  It is hard to help without some
basic information like this.



> GPR08: C085E000 C0008540 00000000 C085F358 00000000 FFFFFFFF 00000000
> 00000400

> Kernel panic: kernel access of bad area pc c0010d90 lr c0010d8c address
> 3C tsk 1Rebooting in 180 seconds..
>
> Based on my simple attempts it appears that I am taking a DSI exception
> on an access to
> 0xC010000......

How did you determine this?  The panic message prints the faulting
address, which happens to be 0x3c.  GPR8, 9, 10, 11, and 12 are typical
sources for intermediate pointers, two of those are zero.  I would
guess a NULL pointer to a data structure trying to access the contents
at offset 0x3c.

> I noticed in System.map that data does not the first data entry.....

Next time notice and tell us the function at NIP....much more useful.

> Note: they put the SUNI-Lite and board registers at
> 0x04500000-0x04700000.

Who is they, what's a SUNI-Lite, and does it matter?  Best of all,
if you don't like the address you can change it.


We need more info.


	-- Dan

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

Re: Motorola MPC8260-ADS Boot hassel

[Dan Malek]

Steve Tarr wrote:
>
> Sorry for the confusion. I am not familiar with the
> Linux PANIC messages.

You will be soon :-).

> 1. NIP 0xC0010D90 is in wake_up_process()

> 3. Disasembling sched.o gave me a file offset of 0x1dc0 for
> wake_up_process(). The failing

Thanks, this was good and it all makes sense now......


>     1dd4:   7c 7e 1b 78     mr  r30,r3

>  >> 1e00:   81 3e 00 3c     lwz r9,60(r30)

>     Note: r30 is loaded from the paramenter passed in, r3.

Yep.

> 4. I made a seemingly foolish assumption that the TRAP: 0300
>    was the exception vector. Hence that it was a DSI exception.

Not foolish, that's correct.

>    Looking at the register dump shows r30 = 0xc0100000. Hence
>    my question.

Mistake.  R30 is zero.  Null pointer.  Decimal 60 is the offset 0x3c.
The wake_up_process() was passed a NULL task pointer.  Track it down
through the stack backtrace.

> 5. The SUNI-lite is an SDH/ATM framer for the Fiber that uses FCC2.

Cool.  That shouldn't be causing any trouble at this point.


	-- Dan

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

Re: Motorola MPC8260-ADS Boot hassel

[Murray Jensen]

>OK, I' stumped. I'm trying to do a port to Motorola's
>MPC8260 evaluation board using 2.3.99-pre7. Aside from
>hacking the loader and the 8260_io/uart.c to handle
>the console on SCC1, I've done nothing. The following is the
>boot messages:
>
>loaded at:     00600000 0060B288
>relocated to:  00400000 0040B288
>board data at: 00407140 00407164 <= this is within range on line above
>relocated to:  00200100 00200124
>zimage at:     00606000 00675258
>initrd at:     00675258 0084C0A3
>avail ram:     0084D000 01000000

The secondary boot code is being relocated over the top of the board data
(before it is relocated). Perhaps this is your problem?

Also, check that your uncompressed kernel image size (use objdump on vmlinux
in the top level directory - only the important sections are copied) is less
than 2Mbyte (0x200000) - if it's bigger, it will overwrite the kernel boot
arguments and relocated board data.

Finally, I have found that a NULL pointer access in wakeup_process() is
usually because something early on has prevented an essential kernel task
from being started, but somewhere else wants to wake that kernel task up
(in particular bdflush, which is woken up when buffers are low). Fix the
early problem and the NULL access goes away. But to be safe, try this:

diff -u -r1.1.1.12 buffer.c
--- buffer.c	2000/05/16 01:31:41	1.1.1.12
+++ buffer.c	2000/06/02 04:26:16
@@ -2336,7 +2336,7 @@
 {
 	DECLARE_WAITQUEUE(wait, current);

-	if (current == bdflush_tsk)
+	if (bdflush_tsk == 0 || current == bdflush_tsk)
 		return;

 	if (!block) {

Hope this helps. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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

Re: Motorola MPC8260-ADS Boot hassel

[Dan Malek]

Murray Jensen wrote:

> >relocated to:  00400000 0040B288
> >board data at: 00407140 00407164 <= this is within range on line above
> >relocated to:  00200100 00200124

> The secondary boot code is being relocated over the top of the board data
> (before it is relocated). Perhaps this is your problem?

This is telling you everything is fine.  The initial board data in
this case is part of the first relocated image.  This is moved to
the following address (0x200100).  It's irrelevant in this case to
move the data, but to simplify the logic it is always done.  In the
case where the initial board data is part of the flash rom or (the
right way) passed to you by the boot rom, it must be relocated.

> -       if (current == bdflush_tsk)
> +       if (bdflush_tsk == 0 || current == bdflush_tsk)


This is the real solution to the problem.  Thanks.


	-- Dan

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

Re: Motorola MPC8260-ADS Boot hassel

[Steve Tarr]

Mr. Jensen --

You hit the nail on the head. Congrates. Have an ice cream cone on me.

I can now state that I have Linux up and running on the
MPC8260-ADS board....Minus the Ethernet controller.

Thanks to all for the help

--
Steven Tarr
Lucent Technologies - Bell Labs
303-538-4056
tarr@lucent.com

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