having a hard time getting SBF to work... (MCF5445x) - help needed

[w_wegner]

Dear all,

I am trying to get SBF to work on my proprietary MCF5445x (360-pin) board.

I started with U-Boot for M54455EVB and modified it such that I can run it from the debugger with CONFIG_MONITOR_IS_IN_RAM. Now I want to get it into the serial flash (MX25L6405M), but without success yet.

What I did:

- add a binary SBF header to my U-Boot image:

> od -t x1 -A x1 /srv/tftp/u-boot.bin | head -10
000000 03 ff 03 00 00 00 00 00 00 00 00 00 00 00 00 00
000010 64 0a 30 00 00 00 00 80 00 00 8c 40 00 04 84 40
000020 00 04 84 40 00 04 84 40 00 04 84 40 00 04 84 40
*
000090 00 04 84 00 00 00 00 00 03 00 00 40 00 00 00 46
0000a0 fc 27 00 20 7c fc 00 80 18 20 bc c0 00 00 00 20
0000b0 7c fc 00 80 20 20 bc 00 00 fd c0 20 7c fc 00 80
0000c0 1c 20 bc 00 1f 00 01 20 7c c0 00 00 0c 70 00 30

The first 19 bytes are the SBF header (I made a small C program to generate it). I do not use PCI, and am supplying 50MHz to the processor running with VCO=500MHz, Core = 250 MHz, the PLL value is the same I am writing to PCR[PFDR] from the debugger.

When resetting the board, it does a little more initialization than with the serial flash erased, but does not work *). From the debugger, I can access the core and dump the memory:

 mcf5445x> memory read 0x80000000 64

0x80000000: 0x00000000 0x8000008C 0x40000484 0x40000484
0x80000010: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000020: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000030: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000040: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000050: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000060: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000070: 0x40000484 0x40000484 0x40000484 0x40000484
0x80000080: 0x00000000 0x00030000 0x40000000 0x46FC2700
0x80000090: 0x207CFC00 0x801820BC 0xC0000000 0x207CFC00
0x800000A0: 0x802020BC 0x0000FDC0 0x207CFC00 0x801C20BC

This looks fine to me, giving SP, PC, vectors (they pointing to SDRAM, but as interrupts are disabled, this should not matter, I guess?), SBF header and beginning of code. The first strange thing is the SBF control register:

mcf5445x> memory read16 0xfc0a0020
0xFC0A0020: 0x0004
mcf5445x> memory read16 0xfc0a0018
0xFC0A0018: 0x03FF

BLL is OK (I wrote 0x3ff), but why is BLDIV set to 4?

I can then even start the code by calling "go 0x8000008c" in the debugger (I have some debug LEDs I can access via early flexbus access, so I see the code execution starts).

Does anybody have an idea what I am doing wrong so that code execution does not start via SBF itself?

Regards,

Wolfgang

*) with the serial flash erased, I can not access the CPU from the debugger after reset. This works with my SBF header/U-Boot in place.

[w_wegner]

Hi all,

I am one step further now:

- my SDRAM init was wrong

- I have to set the PLL config in the first assembler lines (which puzzles me because it is not done in the M54455EVB code)

- I have to enable CS0 (which is used lateron by an FPGA on my board) in the first assembler lines

so when setting:

move.l #0xfc0c4000, %a0
move.l #0x0a779731, (%a0)

move.l #0xfc008004, %a0
move.l #0x1fff0001, (%a0)

in the first assembler lines, the board boots up correctly in SBF mode.

Additionally, there was a typo in my SBF header (offset 0x12 0x30->0x20):

000000 03 ff 03 00 00 00 00 00 00 00 00 00 00 00 00 00
000010 64 0a 20 00 00 00 00 80 00 00 8c 40 00 04 84 40
000020 00 04 84 40 00 04 84 40 00 04 84 40 00 04 84 40

Still, I would rather like to understand this, but at least I can get my board up and running standalone now.

Regards,

Wolfgang

[lmhdoms]

Hi Wolfgang,

I think the SBF shift clock adjustment step probably finds that the divisor 5 (BLDIV=4) is appropriate for your device. That is why you read 4h and not 3h (divisor = 4). Did you try to set 0x4 in the sbfhdr?

Regards,

- Lars

[w_wegner]

I am still having trouble getting SBF to work reliably on my board running U-Boot.

Because I want to support different memory configurations via strap pins, I implemented a private SDRAM configuration in my board_config.h and hooked it up in start.S like this:

 /* Dram Initialization a1, a2, and d0 */ /* mscr sdram */ move.l #0xFC0A4074, %a1 move.b #(CONFIG_SYS_SDRAM_DRV_STRENGTH), (%a1) nop /* SDRAM Chip 0 and 1 */ move.l #0xFC0B8110, %a1 move.l #0xFC0B8114, %a2#if defined(BOARD_ASM_SDRAM_INIT)BOARD_ASM_SDRAM_INIT#else /* calculate the size */ move.l #0x13, %d1 move.l #(CONFIG_SYS_SDRAM_SIZE), %d2

 The start of my BOARD_ASM_SDRAM_INIT looks like this:

#define BOARD_ASM_SDRAM_INIT \ move.l #0xfc008018, %a0; \ move.l #0xc0000000, (%a0); \ move.l #0xfc00801c, %a0;\ move.l #0x001F0001, (%a0); \ move.l #0xfc008020, %a0; \ move.l #0x0000fdc0, (%a0); \ move.l #0xc000000c, %a0; \ move.w #0x000e, (%a0); \ move.l #0xfc0a0012, %a0; \ move.l #0xfc0c4000, %a0; \ move.l #0x0a770F31, (%a0); \ move.l #0xc000000c, %a0; \ move.w #0x07, (%a0); \ \[real SDRAM init starts here]

 The first lines init CS2 because I have a CPLD hooked up there with some LEDs that I can use for debugging. The lower nibble of the word written to 0xc000000c is directly output to the LEDs.

I set PLL_PCR  there because I once made the observation that PLL_PCR had some strange values after reset which prevented the SDRAM from being correctly initialized. The problem is that, while most of the times this works, sometimes the write to PLL_PCR crashes the CPU. This happens even in cases when only OUTDIV3 and OUTDIV4 are different from the value found there before. (When connected to the debugger, the debugger stops the core after loading RCON from SBF, and I can check register values before starting execution.)

I tried putting the CPU to LIMP mode before setting PLL_PCR:

#define BOARD_ASM_SDRAM_INIT \ move.l #0xfc008018, %a0; \ move.l #0xc0000000, (%a0); \ move.l #0xfc00801c, %a0;\ move.l #0x001F0001, (%a0); \ move.l #0xfc008020, %a0; \ move.l #0x0000fdc0, (%a0); \ move.l #0xc000000c, %a0; \ move.w #0x000e, (%a0); \ move.l #0xfc0a0012, %a0; \ move.w (%a0), %d0; \ and.l #0xff, %d0; \ move.w %d0, (%a0); \ /* enable limp mode */ \ move.l #0xfc0a0010, %a0; \ move.w (%a0), %d0; \ and.l #0xEFFF, %d0; \ move.w %d0, (%a0); \ move.l #0xfc0c4000, %a0; \ move.l #0x0a770F31, (%a0); \ move.l #0xc000000c, %a0; \ move.w #0x07, (%a0); \ /* disable LIMP mode */ \ move.l #0xfc0a0010, %a0; \ move.w (%a0), %d0; \ or.l #0x1000, %d0; \ move.w %d0, (%a0); \ /* wait for pll lock */ \ move.l #0xc000000c, %a0; \ move.w #0x0B, (%a0); \ move.l #0xfc0c4004, %a0; \pll_unlock: \ move.l (%a0), %d0; \ and.l #0x2, %d0; \ cmp.l #0, %d0; \ beq pll_unlock; \ \

 but this did not help either, still I see that sometimes code execution stops before writing 0x07 to 0xc000000c while the value of 0x0e gets written.

Does anybody have a clue what I am doing wrong here, or what I can do to get a reliable startup?

Regards,

Wolfgang