problem with booting linux on MPC8260

[eugenetodoruk]

UPD:

My idea to debug kernel with BDI was wrong. BDI not working with memory at the current frequency... And I can't fix this problem.

Now I debug kernel with the GPIO led

My next problem in caches and MMU. When Linux tryed to setup instruction cache or data cache or both, board going to reset (in u-boot both caches turned off). If I not turned on both caches, then my board hangs after turning on the MMU for real:

/* Now turn on the MMU for real! */

li>-r4,MSR_KERNEL

FIX_SRR1(r4,r5)

lis>r3,start_kernel@h

ori>r3,r3,start_kernel@l

mtspr    SPRN_SRR0,r3

mtspr    SPRN_SRR1,r4

SYNC

RFI

Can you answer me why caches can not work? This may be due to wrong initialization of memory or local bus?

Where should I look for the MMU problem?

Sorry for my english

>> previous message:

Hello,

I have a problem with booting linux on our board with MPC8260 processor.

The thing is we made a custom board for our own needs, and it resets after u-boot transfers control to 0x0 address. I've tried to debug it using BDI2000. What I do is catching the instruction on 0x0 and then going on step by step. Sometimes it resets from a random address, sometimes it jumps to the non-sdram memory address. And it does so almost right after catching the instruction, and I don't advance in debugging very far.

Can you help me?

U-Boot 2013.07-rc1-00012-g7315cfd-dirty (Aug 07 2013 - 18:39:32)

MPC8260 Reset Status: Check Stop, External Soft, External Hard

MPC8260 Clock Configuration

- Bus-to-Core Mult 3x, VCO Div 2, 60x Bus Freq  33-100, Core Freq 100-300

- dfbrg 0, corecnf 0x08, busdf 3, cpmdf 1, plldf 0, pllmf 1, pcidf 3

- vco_out  133333332, scc_clk   33333333, brg_clk   33333333

- cpu_clk   99999999, cpm_clk   66666666, bus_clk   33333333

CPU:   MPC8260 (HiP4 Rev 14, Mask B.1 4K25A) at 100 MHz

Board: PR1-2

DRAM:  64 MiB

Flash: 128 MiB

In:    serial

Out:   serial

Err:   serial

Net:   FCC1, FCC2

Hit any key to stop autoboot:  0

U-Boot > run nfsboot

Using FCC1 device

TFTP from server 192.168.0.5; our IP address is 192.168.0.23

Filename 'uImage.bin'.

Load address: 0x500000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         ##################################################

         587.9 KiB/s

done

Bytes transferred = 1585226 (18304a hex)

Using FCC1 device

TFTP from server 192.168.0.5; our IP address is 192.168.0.23

Filename 'uImage-mpc8260-pr1-2.dtb'.

Load address: 0x400000

Loading: ###

         479.5 KiB/s

done

Bytes transferred = 12288 (3000 hex)

## Current stack ends at 0x03f87618

*  kernel: cmdline image address = 0x00500000

## Booting kernel from Legacy Image at 00500000 ...

   Image Name:   Angstrom/2.6.39/mpc8260-pr1-2

   Image Type:   PowerPC Linux Kernel Image (gzip compressed)

   Data Size:    1585162 Bytes = 1.5 MiB

   Load Address: 00000000

   Entry Point:  00000000

   Verifying Checksum ... OK

   kernel data at 0x00500040, len = 0x0018300a (1585162)

## Flattened Device Tree blob at 00400000

   Booting using the fdt blob at 0x400000

   Uncompressing Kernel Image ... OK

   kernel loaded at 0x00000000, end = 0x00315d20

   Loading Device Tree to 007f9000, end 007fefff ... OK

## Transferring control to Linux (at address 00000000) ...

   Booting using OF flat tree...

Original Attachment has been moved to: pr1-2.c.zip

Original Attachment has been moved to: defconfig.zip

Original Attachment has been moved to: pr1-2.dts.zip

Original Attachment has been moved to: pr1-2.h.zip

[scottwood]

I do not recommend using JTAG to debug early Linux startup on this chip (at least until you're running in C code).

First, make sure the device tree toplevel compatible ("fsl,PR1-2") is recognized by the platform code you're trying to use.  BTW, you shouldn't us "fsl," as the vendor prefix because this isn't a Freescale board.  Also make sure that the addresses are correct for how you've got U-Boot configuring things like the IMMR, and that you're describing the right serial port.

Next, try using CONFIG_PPC_EARLY_DEBUG_CPM.  If that doesn't output anything, double check sure that CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is set properly for how U-Boot is initializing the serial port.  If that doesn't help, try manually outputting a character immediately after __start in head_32.S.

[eugenetodoruk]

Thanks for the answer.

I tried to setup CONFIG_PPC_EARLY_DEBUG_CPM, but I don't see the debug information. Do I understand correctly that CONFIG_PPC_EARLY_DEBUG_CPM_ADDR is the registers address of my console? I know that my SMC1 registers live at 0xf0011a82, and I set CONFIG_PPC_EARLY_DEBUG_CPM_ADDR=0xf0011a82.

>>If that doesn't help, try manually outputting a character immediately after __start in head_32.S.

How can I do it? Can you give me example? Thank you very much

[eugenetodoruk]

Can you tell exactly what kind of "tx ring buffer set up by U-Boot"?

I can not understand :smileysad:

Early debug can realy help me

[scottwood]

No, the address is for the tx ring buffer set up by U-Boot.

[sinanakman]

Scott, what would be your reservation running BDI on 82xx ? It might be a useful info for future. Thanks.

[scottwood]

I'm not sure -- I may have been thinking of 85xx where there are sections of the init that can't be stepped through due to a hardware quirk (needing to have a valid mapping in AS0 for IVOR15 in order for a JTAG device to receive debug events).

[sinanakman]

Eugene, this sounds like a memory setup problem.  Also make sure you are running BDI  initially with caches disabled.

[eugenetodoruk]

Thanks for the answer.

I agree that it looks like a memory problem. But u-boot working right.

What does it mean "running BDI  initially with caches disabled"? I must set "DCACHE FLUSH" in BDI configuration?