Hi list,

I am trying to get U-Boot to run on my new MCF5445x board and have some problems.

What I did: - use M54455EVB as a starting point (non-SBF mode) - comment out RAM setup to start U-Boot from the debugger [debugger does RAM setup with my init script] - change flexbus and clock settings for my board [meanwhile tried some various settings, but without any change] The stack configuration is as follows: #define CONFIG_SYS_INIT_RAM_ADDR 0x80000000 #define CONFIG_SYS_INIT_RAM_END 0x8000 /* End of used area in internal SRAM */ #define CONFIG_SYS_INIT_RAM_CTRL 0x221 #define CONFIG_SYS_GBL_DATA_SIZE 128 /* size in bytes reserved for initial data */ #define CONFIG_SYS_GBL_DATA_OFFSET ((CONFIG_SYS_INIT_RAM_END - CONFIG_SYS_GBL_DATA_SIZE) - 32) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET

I can get U-boot to start and print out some messages, but even those are garbled in a way I do not understand. Here is what I get:

`¼ RR$(`¼ RR$(`¼ RR$( CPU CLK 250 MHz BUS CLK 125 MHz FLB CLK `¼ RR$(. 250 MHz INP CLK 50 MHz VCO CLK 500 MHz Board: ASTRO MCF5445x board I2C: ready SPI: ready `¼ RR$(128 MB`¼ RR$(FLASH:

*** Unexpected exception *** Vector Number: 0 Format: 0 Fault Status: 0

PC: 47da0080 SR: 00002700 SP: 47d6ff5c D0: 00000000 D1: 47d6fe84 D2: 47dca0e4 D3: 00000003 D4: 47db7dbc D5: 47dca0d8 D6: 66f36213 D7: 47d86f76 A0: 47d86f76 A1: 47db2e2a A2: 47d60080 A3: 47dca0e8 A4: 47dca0e4 A5: 47dc7c00 A6: 47d6ffb4

*** Please Reset Board! ***

As can be seen, the first lines are missing (or replaced by some fixed string), and even within printing the processor clocks (mcf5445x/cpu.c), this fixed string shows up as part of the "strmhz" output. The flash probably can not be initialised because I did not yet check if the serial flash settings are correct as I did not see a sense in it if there are errors in earlier stages. RAM is 128MB located at 0x40000000-0x47ffffff, I set TEXT_BASE and CONFIG_SYS_LOAD_ADDR to 0x40020000 (I am used to this address because I used it on MCF5373L, too), I can read back the U-Boot image after the above crash and it is identical to what I wrote to RAM before, so I would exclude a SDRAM configuration or other access problem. When changing anything in the code, the "pattern" of which printfs do work and which show the erroneous string changes, but I could not see a scheme in it.

When trying to debug the program (using PEEDI) I tried to step into printf, but without reproducible success: (gdb) break cpu.c:81 Breakpoint 1 at 0x40033966: file cpu.c, line 81. (gdb) c Continuing.

Breakpoint 1, checkcpu () at cpu.c:81 81 printf("Freescale MCF%d (Mask:%01x Version:%x)\n", id, msk, (gdb) s 83 printf(" CPU CLK %s MHz BUS CLK %s MHz FLB CLK %s MHz\n", (gdb) s 81 printf("Freescale MCF%d (Mask:%01x Version:%x)\n", id, msk, (gdb) s 83 printf(" CPU CLK %s MHz BUS CLK %s MHz FLB CLK %s MHz\n", (gdb) s 81 printf("Freescale MCF%d (Mask:%01x Version:%x)\n", id, msk, (gdb) s

Program received signal SIGTRAP, Trace/breakpoint trap. 0x47db9392 in ?? ()

I once managed to step into printf using ddd as a frontend, but was not able to print the address of printbuffer (which I wanted to check to see if there are maybe stack problems). As far as I understand, the first printfs are executed before relocation (and thus using a stack in internal SRAM). The relocation itself seems to work as 0x47da0080 seems a reasonable PC value.

Any hints on how I can debug this are highly appreciated, seems I am making some wrong assumptions or am overlooking another fundamental (or stupid) mistake here. Probably there are few people here using Coldfire, but maybe parts of the problem are common to other processors, too.

Thank you, Wolfgang