How to debug 2.6 PReP boot hang?

How to debug 2.6 PReP boot hang?

[Meelis Roos]

I have a Motorola Powerstack II Pro4000 that has PReP and OF and is not
booting in 2.6. I hangs very early, the display stays in OF graphics
mode and nothing is printed. So it does not reach vga_init in
load_kernel, and I'm not sure it even reaches load_kernel.

What is the best suggestion to debugging this? I have serial cable and
could output chars there but what is the platform-specific code snippet
that should output a char on serial port?

-- 
Meelis Roos (mroos@linux.ee)

Re: How to debug 2.6 PReP boot hang?

[Tom Rini]

On Wed, Jul 28, 2004 at 12:19:42PM +0300, Meelis Roos wrote:

> I have a Motorola Powerstack II Pro4000 that has PReP and OF and is not
> booting in 2.6. I hangs very early, the display stays in OF graphics
> mode and nothing is printed. So it does not reach vga_init in
> load_kernel, and I'm not sure it even reaches load_kernel.

My suggestion is to go back in releases until one does work, see where
the changes are that break it, and work from there.  It should be
possible to fix what broke. :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: How to debug 2.6 PReP boot hang?

[Meelis Roos]

> My suggestion is to go back in releases until one does work, see where
> the changes are that break it, and work from there.  It should be
> possible to fix what broke. :)

OK, did some compiling and testing and fout that my suspicion was right:
BK changeset 1.1371.384.5 boots ok but 1.1371.384.6 makes it hang.

It's the one that reorganizes boot code:
PPC32: Kill off arch/ppc/boot/prep and rearrange some files.

-- 
Meelis Roos (mroos@linux.ee)

Re: How to debug 2.6 PReP boot hang?

[Tom Rini]

On Mon, Aug 16, 2004 at 05:39:19PM +0300, Meelis Roos wrote:

> > My suggestion is to go back in releases until one does work, see where
> > the changes are that break it, and work from there.  It should be
> > possible to fix what broke. :)
> 
> OK, did some compiling and testing and fout that my suspicion was right:
> BK changeset 1.1371.384.5 boots ok but 1.1371.384.6 makes it hang.
> 
> It's the one that reorganizes boot code:
> PPC32: Kill off arch/ppc/boot/prep and rearrange some files.

Sadly, that is what I expected.  Try narrowing down the differences
between prep/head.S and simple/head.S (or rather head.s via make
arch/ppc/boot/prep/head.s and simple/head.s to strip out comments, etc).

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: How to debug 2.6 PReP boot hang?

[Meelis Roos]

> > It's the one that reorganizes boot code:
> > PPC32: Kill off arch/ppc/boot/prep and rearrange some files.
>
> Sadly, that is what I expected.  Try narrowing down the differences
> between prep/head.S and simple/head.S (or rather head.s via make
> arch/ppc/boot/prep/head.s and simple/head.s to strip out comments, etc).

I replaced the whole head.S with old prep one. Works, so head.S is
probably the culprit.

1. L1 cache disabling was moved. I moved it back to before cheking OF
address (but after recording link register into r3 since I left the
disabling a subroutine), it still hangs.

2. The address that the code is relocated to is computed differently.
Old code relocates itself to hardcoded 8M (start), new code to
max(load+size, end).

3. Relocation loop is different (see ms to be memmove, not memcpy, at
the first glance).

I replaced the calculation and relocate with old unconditional relocate,
it still hangs.

Replaced head.S with first half of old head.S (relocate from old,
start_ldr from new), still hangs.

Put a couple of debugging traps around. Trap before load_kernel is
executed, trap after load_kernel is never reached. So head.S changes
cause load_kernel to hang.

Some more changes and the only difference is load_kernel vs
decompress_kernel. Changing load_kernel call in relocate.S to
decompress_kernel makes the kernel boot. Oh, finally.

BTW, the address of OF residual data bounces around in
r3->r29->r4->r11->r6. The old code only did r3->r11->r6 but the new code
uses r11 for cache disabling.

This is the patch I'm using currently. I understand that this is
probably not the right patch for inclusion :)

===== arch/ppc/boot/simple/relocate.S 1.11 vs edited =====
--- 1.11/arch/ppc/boot/simple/relocate.S	2004-04-03 06:13:47 +03:00
+++ edited/arch/ppc/boot/simple/relocate.S	2004-08-18 23:27:39 +03:00
@@ -183,7 +183,7 @@
 	mr	r5,r6		/* Checksum */
 	mr	r6,r11		/* Residual data */
 	mr	r7,r25		/* Validated OFW interface */
-	bl	load_kernel
+	bl	decompress_kernel

 	/*
 	 * Make sure the kernel knows we don't have things set in

-- 
Meelis Roos (mroos@linux.ee)

Re: How to debug 2.6 PReP boot hang?

[Tom Rini]

On Wed, Aug 18, 2004 at 11:29:02PM +0300, Meelis Roos wrote:

> > > It's the one that reorganizes boot code:
> > > PPC32: Kill off arch/ppc/boot/prep and rearrange some files.
> >
> > Sadly, that is what I expected.  Try narrowing down the differences
> > between prep/head.S and simple/head.S (or rather head.s via make
> > arch/ppc/boot/prep/head.s and simple/head.s to strip out comments, etc).
[snip]
> Some more changes and the only difference is load_kernel vs
> decompress_kernel. Changing load_kernel call in relocate.S to
> decompress_kernel makes the kernel boot. Oh, finally.
> 
> BTW, the address of OF residual data bounces around in
> r3->r29->r4->r11->r6. The old code only did r3->r11->r6 but the new code
> uses r11 for cache disabling.
> 
> This is the patch I'm using currently. I understand that this is
> probably not the right patch for inclusion :)
> 
> ===== arch/ppc/boot/simple/relocate.S 1.11 vs edited =====
> --- 1.11/arch/ppc/boot/simple/relocate.S	2004-04-03 06:13:47 +03:00
> +++ edited/arch/ppc/boot/simple/relocate.S	2004-08-18 23:27:39 +03:00
> @@ -183,7 +183,7 @@
>  	mr	r5,r6		/* Checksum */
>  	mr	r6,r11		/* Residual data */
>  	mr	r7,r25		/* Validated OFW interface */
> -	bl	load_kernel
> +	bl	decompress_kernel
> 
>  	/*
>  	 * Make sure the kernel knows we don't have things set in

Interesting..  Can you do some nm'ing to see what versions of
load_kernel / decompress_kernel end up in your image on a stock config?
And what gcc / binutils versions are you using?

-- 
Tom Rini
http://gate.crashing.org/~trini/