Early boot problem with MPC8247 and Linux 2.6.26

Early boot problem with MPC8247 and Linux 2.6.26

[Chris Skepper]

Hi all,

I have a custom MPC8247 based board which has been running U-boot 1.3.5 
and Linux 2.6.26.  It has been working fine with ARCH=ppc, but I now want 
to make it work using ARCH=powerpc.

However, using ARCH=powerpc I have encountered a problem.  Whatever I do 
it always appears to reset in the very early stages of booting the kernel. 
This is before the kernel can print anything on the console, so the last 
thing you see is this from the bootloader:

## Booting kernel from Legacy Image at 00400000 ...
    Image Name:   Linux-2.6.26
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    1555842 Bytes =  1.5 MB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK
## Current stack ends at 0x07bb6c68
*  fdt: cmdline image address = 0x00800000
## Checking for 'FDT'/'FDT Image' at 00800000
*  fdt: raw FDT blob
## Flattened Device Tree blob at 00800000
    Booting using the fdt blob at 0x800000
    of_flat_tree at 0x00800000 size 0x00000d3d
## device tree at 0x00800000 ... 0x00800D3C (len=15677=0x3D3D)
    Loading Device Tree to 007fc000, end 007ffd3c ... OK
## Transferring control to Linux (at address 00000000) ...
    Booting using OF flat tree...

I am using U-boot to pass a DTB, which could be buggy or incomplete, 
however, I think it encounters problems before the DTB is accessed by the 
kernel.

Using code to flash an LED I have traced execution from the entry point in 
head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into 
setup_common_caches in cpu_setup_6xx.S.  It appears to reset when enabling 
the cache on the CPU:

setup_common_caches:
 	mfspr	r11,SPRN_HID0
 	andi.	r0,r11,HID0_DCE
 	ori	r11,r11,HID0_ICE|HID0_DCE
 	ori	r8,r11,HID0_ICFI
 	bne	1f			/* don't invalidate the D-cache */
 	ori	r8,r8,HID0_DCI		/* unless it wasn't enabled */
1:	sync
     /* Chris: Reaches here. */
 	mtspr	SPRN_HID0,r8		/* enable and invalidate caches */
 	sync
 	mtspr	SPRN_HID0,r11		/* enable caches */
 	sync
 	isync
     /* Chris: Never gets to here. */
 	blr

FWIW, commenting out the lines above causes it to hang when attempting to 
enable the MMU, which is the next step in the process.

I assume it's likely that something has already gone wrong before this 
point.  Has anyone got any idea how the CPU could have got into a state 
where trying to enable the caches could cause it to reset?

Also, can anyone confirm that the MPC8247 is supported by a 2.6.26 kernel 
with ARCH=powerpc mode?  I think it should be, but it would be good to 
know that someone has tried it.

Cheers,

Chris.

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Scott Wood]

Chris Skepper wrote:
> Using code to flash an LED I have traced execution from the entry point 
> in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and 
> into setup_common_caches in cpu_setup_6xx.S.  It appears to reset when 
> enabling the cache on the CPU:
> 
> setup_common_caches:
>     mfspr    r11,SPRN_HID0
>     andi.    r0,r11,HID0_DCE
>     ori    r11,r11,HID0_ICE|HID0_DCE
>     ori    r8,r11,HID0_ICFI
>     bne    1f            /* don't invalidate the D-cache */
>     ori    r8,r8,HID0_DCI        /* unless it wasn't enabled */
> 1:    sync
>     /* Chris: Reaches here. */
>     mtspr    SPRN_HID0,r8        /* enable and invalidate caches */
>     sync
>     mtspr    SPRN_HID0,r11        /* enable caches */
>     sync
>     isync
>     /* Chris: Never gets to here. */
>     blr
> 
> FWIW, commenting out the lines above causes it to hang when attempting 
> to enable the MMU, which is the next step in the process.

How are you determining that it never gets to that point?  If it's via 
serial I/O or similar, be aware that I/O isn't going to work when caches 
are enabled but the MMU is not.

> Also, can anyone confirm that the MPC8247 is supported by a 2.6.26 
> kernel with ARCH=powerpc mode?  I think it should be, but it would be 
> good to know that someone has tried it.

I've booted an MPC8248 (and some other 82xx) on 2.6.26.  MPC8247 should 
work.

-Scott

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Chris Skepper]

>> I have a custom MPC8247 based board which has been running U-boot 1.3.5
>> and Linux 2.6.26.  It has been working fine with ARCH=ppc, but I now want
>> to make it work using ARCH=powerpc.
>
>> However, using ARCH=powerpc I have encountered a problem.  Whatever I do
>> it always appears to reset in the very early stages of booting the kernel.
>
> could this be the hardware watchdog resetting the CPU ? Do you disable
> it in u-boot ?

Thanks for the suggestion, but I've just double-checked and the watchdog 
is disabled in U-boot.  In any case, I have been using an infinite loop 
flashing an LED to trace where execution gets to, and it never resets once 
it has started doing that.

Any other ideas?

Cheers,

Chris.

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Chris Skepper]

On Fri, 22 Aug 2008, Scott Wood wrote:

> Chris Skepper wrote:
>> Using code to flash an LED I have traced execution from the entry point in 
>> head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into 
>> setup_common_caches in cpu_setup_6xx.S.  It appears to reset when enabling 
>> the cache on the CPU:
>> 
>> setup_common_caches:
>>     mfspr    r11,SPRN_HID0
>>     andi.    r0,r11,HID0_DCE
>>     ori    r11,r11,HID0_ICE|HID0_DCE
>>     ori    r8,r11,HID0_ICFI
>>     bne    1f            /* don't invalidate the D-cache */
>>     ori    r8,r8,HID0_DCI        /* unless it wasn't enabled */
>> 1:    sync
>>     /* Chris: Reaches here. */
>>     mtspr    SPRN_HID0,r8        /* enable and invalidate caches */
>>     sync
>>     mtspr    SPRN_HID0,r11        /* enable caches */
>>     sync
>>     isync
>>     /* Chris: Never gets to here. */
>>     blr
>> 
>> FWIW, commenting out the lines above causes it to hang when attempting to 
>> enable the MMU, which is the next step in the process.
>
> How are you determining that it never gets to that point?  If it's via serial 
> I/O or similar, be aware that I/O isn't going to work when caches are enabled 
> but the MMU is not.

Hi Scott,

I'm triggering an LED which is connected to port A.  Are you saying that 
wouldn't work once the caching is enabled?

Cheers,

Chris.

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Scott Wood]

On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote:
> >How are you determining that it never gets to that point?  If it's via 
> >serial I/O or similar, be aware that I/O isn't going to work when caches 
> >are enabled but the MMU is not.
> 
> I'm triggering an LED which is connected to port A.  Are you saying that 
> wouldn't work once the caching is enabled?

It's quite possible.  What other registers are in the same cache line as
the LED, and are any of them non-memory-like?  And even if all registers
in the cache line are OK with this sort of access, you need to use dcbf
afterwards.

It's usually easiest to just trust that that part of the code works (in
my experience, that's rarely where a hang actually occurs when bringing
up a new board), and resume tracing after the MMU is on and you've
inserted a caching-inhibited BAT entry.

-Scott

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Chris Skepper]

On Tue, 26 Aug 2008, Scott Wood wrote:

> On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote:
>
>> I'm triggering an LED which is connected to port A.  Are you saying that
>> wouldn't work once the caching is enabled?
>
> It's quite possible.  What other registers are in the same cache line as
> the LED, and are any of them non-memory-like?

There are some ethernet signals, a compact flash card detect, other LEDs 
and a push button also on port A.  Are those what you'd call 
non-memory-like?

> It's usually easiest to just trust that that part of the code works (in
> my experience, that's rarely where a hang actually occurs when bringing
> up a new board), and resume tracing after the MMU is on and you've
> inserted a caching-inhibited BAT entry.

Where can I find out how to do that?  Since I have this board working with 
the old ARCH=ppc, can I copy anything from there?

Also, where would be a good place in the code to resume tracing?

Thanks for your help so far.  I see now it's probably not the code for 
enabling the cache that's causing the problem, it just masks my attempts 
at tracing using the LED.

Cheers,

Chris.

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Scott Wood]

Chris Skepper wrote:
> On Tue, 26 Aug 2008, Scott Wood wrote:
> 
>> On Tue, Aug 26, 2008 at 01:00:05PM +0100, Chris Skepper wrote:
>>
>>> I'm triggering an LED which is connected to port A.  Are you saying that
>>> wouldn't work once the caching is enabled?
>>
>> It's quite possible.  What other registers are in the same cache line as
>> the LED, and are any of them non-memory-like?
> 
> There are some ethernet signals, a compact flash card detect, other LEDs 
> and a push button also on port A.  Are those what you'd call 
> non-memory-like?

Would any of them object to spurious reads, and writebacks of the value 
that was read?

>> It's usually easiest to just trust that that part of the code works (in
>> my experience, that's rarely where a hang actually occurs when bringing
>> up a new board), and resume tracing after the MMU is on and you've
>> inserted a caching-inhibited BAT entry.
> 
> Where can I find out how to do that?  Since I have this board working 
> with the old ARCH=ppc, can I copy anything from there?

See setup_cpm_bat in arch/powerpc/kernel/head_32.S.

> Also, where would be a good place in the code to resume tracing?

As soon as you can set up a BAT -- though first, I would try just 
enabling the CPM debug console and see if you get anything from that.

-Scott

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Chris Skepper]

On Tue, 26 Aug 2008, Scott Wood wrote:

>>> It's usually easiest to just trust that that part of the code works (in
>>> my experience, that's rarely where a hang actually occurs when bringing
>>> up a new board), and resume tracing after the MMU is on and you've
>>> inserted a caching-inhibited BAT entry.
>> 
>> Where can I find out how to do that?  Since I have this board working with 
>> the old ARCH=ppc, can I copy anything from there?
>
> See setup_cpm_bat in arch/powerpc/kernel/head_32.S.
>
>> Also, where would be a good place in the code to resume tracing?
>
> As soon as you can set up a BAT -- though first, I would try just enabling 
> the CPM debug console and see if you get anything from that.

Thanks very much for your help so far.  I tried enabling the console and 
didn't get anything output.  So I resumed tracing and discovered it gets 
much further, as far as udbg_init_cpm and udbg_putc_cpm in cpm_common.c 
However, it never gets that first 'X' printed because it appears to hang 
when it gets to this bit:

   out_8(txbuf, c);
   out_be32(&cpm_udbg_txdesc[0], 0xa0000001);

I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2? 
Is that likely to be correct for SMC1?  (I tried looking in the MPC8272 
reference manual, but couldn't find it.)

Is it likely the port isn't set up properly?  udbg_early_init and 
udbg_init_cpm get called before it probes the machine so there's been no 
chance to do cpm2_set_pin or anything.

Cheers,

Chris.

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Scott Wood]

On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
> I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2? 
> Is that likely to be correct for SMC1?  (I tried looking in the MPC8272 
> reference manual, but couldn't find it.)

The value depends on how the port was set up by firmware (or by the
bootwrapper).  It should be set to wherever the descriptor is, and there
should only be one descriptor that loops back on itself.

-Scott

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Scott Wood]

On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
> Is it likely the port isn't set up properly?  udbg_early_init and 
> udbg_init_cpm get called before it probes the machine so there's been no 
> chance to do cpm2_set_pin or anything.

For the early console to work, the pins must have been set up properly by
firmware.

-Scott

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Chris Skepper]

On Wed, 27 Aug 2008, Scott Wood wrote:

> On Wed, Aug 27, 2008 at 02:30:47PM +0100, Chris Skepper wrote:
>> I just left CONFIG_PPC_EARLY_DEBUG_CPM_ADDR at the default value for CPM2?
>> Is that likely to be correct for SMC1?  (I tried looking in the MPC8272
>> reference manual, but couldn't find it.)
>
> The value depends on how the port was set up by firmware (or by the
> bootwrapper).  It should be set to wherever the descriptor is, and there
> should only be one descriptor that loops back on itself.

Hi Scott,

Thanks so much for your help so far.  I was able to find out this address 
from the bootloader and get some output on the early debug console which 
was very pleasing.  It now gets as far as console_init() called from 
init/main.c, which completes but then any printk seems to stall it and 
you get no more output.

I am using SMC1 and have this in the DTS file for the linux,stdout-path:

serial@11a80 {
 	device_type = "serial";
 	compatible = "fsl,mpc8247-smc-uart",
 	            "fsl,cpm2-smc-uart";
 	reg = <0x11a80 0x20 0x87fc 2>;
 	interrupts = <4 8>;
 	interrupt-parent = <&PIC>;
 	fsl,cpm-brg = <7>;
 	fsl,cpm-command = <0x1d000000>;
};

Any ideas what sorts of things I should check next?

Cheers,

Chris.

Re: Early boot problem with MPC8247 and Linux 2.6.26

[Scott Wood]

Chris Skepper wrote:
> Thanks so much for your help so far.  I was able to find out this 
> address from the bootloader and get some output on the early debug 
> console which was very pleasing.  It now gets as far as console_init() 
> called from init/main.c, which completes but then any printk seems to 
> stall it and you get no more output.
> 
> I am using SMC1 and have this in the DTS file for the linux,stdout-path:
> 
> serial@11a80 {
>     device_type = "serial";
>     compatible = "fsl,mpc8247-smc-uart",
>                 "fsl,cpm2-smc-uart";
>     reg = <0x11a80 0x20 0x87fc 2>;
>     interrupts = <4 8>;
>     interrupt-parent = <&PIC>;
>     fsl,cpm-brg = <7>;
>     fsl,cpm-command = <0x1d000000>;
> };
> 
> Any ideas what sorts of things I should check next?

Check the BRG frequency (clock-frequency in the brg node), and the baud 
rate that the driver is trying to set.  As a quick check, you can 
disable calls to cpm2_setbrg() to see if that's the problem.

-Scott