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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
