[U-Boot] U-Boot (porting) problem on MCF5445x board

[U-Boot] U-Boot (porting) problem on MCF5445x board

[Wolfgang Wegner]

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] U-Boot (porting) problem on MCF5445x board

[Wolfgang Wegner]

Hi,

two more observations:

- there are some entries in the linker script reminiscent from
  and embedded environment forcing .text from start.o, traps.o,
  interrupts.o, dlmalloc.o and zlib.o to the beginning of the
  .text section; if I remove these, U-Boot crashes without
  any output (did not yet find out where)
- when debugging properly, I can break in console.c:printf()
  and get these:
  Breakpoint 1, printf (fmt=0x40030000 "`? RR\213$(") at console.c:381
381             i = vsprintf(printbuffer, fmt, args);
(gdb) c
Continuing.

Breakpoint 1, printf (
    fmt=0x4003e556 "Freescale MCF%d (Mask:%01x Version:%x)\n") at console.c:381
381             i = vsprintf(printbuffer, fmt, args);
(gdb) c

0x40030000 is in the middle of the .text section. Furthermore, when
stepping further with 'c' U-Boot again crashes sometime before printing
the unexpected exception report. I do not understand where this different
behaviour with and without breakpoints results from.

Maybe this gives someone more experienced a hint what I am doing
wrong.

Regards,
Wolfgang

[U-Boot] U-Boot (porting) problem on MCF5445x board

[Wolfgang Wegner]

Sorry for another self-followup...

With the modified linker script, I already have a failure in
board.c/board_init_f():

(gdb) break board.c:249
Breakpoint 1 at 0x4002089e: file board.c, line 249.
(gdb) c
Continuing.

Breakpoint 1, board_init_f (bootflag=0) at board.c:249
249             memset ((void *) gd, 0, sizeof (gd_t));
(gdb) n
252                     if ((*init_fnc_ptr)() != 0) {
(gdb) print init_fnc_ptr
$1 = (init_fnc_t **) 0x40040000
(gdb) print init_sequence
$2 = {0x40033aca <get_clocks>, 0x4002e22e <env_init>, 
  0x400205ca <init_baudrate>, 0x40026ad2 <serial_init>, 
  0x4002ce4e <console_init_f>, 0x40030262 <display_options>, 
  0x400338e8 <checkcpu>, 0x4002ff80 <checkboard>, 0x40020596 <init_func_i2c>, 
  0x4002056c <init_func_spi>, 0x40020510 <init_func_ram>, 0}
(gdb) print *init_fnc_ptr
$3 = (init_fnc_t *) 0x1010101
(gdb) s
[gdb hangs here, does not reach get_clocks()]

The addresses from "print init_sequence" correspond to those found in
u-boot.map. I have to admit I am a bit puzzled by the behaviour of gdb
when printing pointers (did not use it for some years now...), but to
me the init_fnc_ptr looks ... weird. And somehow truncated (?) like the
fmt string in the debugged printf() from the last mail. I tried disabling
the cache which was formerly enabled already in cpu_init_f(), but this
did not change anything.

Have to give up for today, hopefully I see more clearly next morning.

Regards,
Wolfgang

[U-Boot] Solved: U-Boot (porting) problem on MCF5445x board

[Wolfgang Wegner]

Hi list,

sorry for the noise!

The problem turned out to be a simple SDRAM setup problem.
I had set "burst read to read/precharge delay" and "burst write
to read/write/precharge delay" by 1 too low.

Don't know how I messed these values up, but these lead to all
memory accesses in single-step mode and via BDM to work correctly
but gave erroneous results in real program execution.

[note to self: in case of strange errors, always check memory
interface. If triple-checked: check again...]

Sorry again,
Wolfgang

PS: just in case anybody is interested, I am using two pieces of
MT47H32M16HR-3IT on an MCF54455 with this setup:

; SDRAM init
; SDCS0:
mem write 0xFC0B8110 0x40000019
; SDCS1:
mem write 0xFC0B8114 0x44000019
; SDCFG1:
mem write 0xFC0B8008 0x66311720
; SDCFG2:
mem write 0xFC0B800C 0x6A670000
; SDCR (PALL):
mem write 0xFC0B8004 0xE9062002
; SDMR (EMode2):
mem write 0xFC0B8000 0x80010000
; SDMR (EMode3):
mem write 0xFC0B8000 0xC0010000
; SDMR (EMode)
mem write 0xFC0B8000 0x40010412
; SDMR (Mode)
mem write 0xFC0B8000 0x00010333
wait 10
; SDCR:
mem write 0xFC0B8004 0xE9062C02
mem write 0xFC0B8004 0xE9062C04
mem write 0xFC0B8004 0xE9062C04
; SDMR (MODE)
mem write 0xFC0B8000 0x00010233
; SDMR (EMODE, OCD default)
mem write 0xFC0B8000 0x40010792
; SDMR (EMODE, OCD exit)
mem write 0xFC0B8000 0x40010412
; SDCR:
mem write 0xFC0B8004 0x79062C00

[U-Boot] Solved: U-Boot (porting) problem on MCF5445x board

[Wolfgang Denk]

Dear Wolfgang Wegner,

In message <20100119131716.GC23389@leila.ping.de> you wrote:
> 
> The problem turned out to be a simple SDRAM setup problem.
> I had set "burst read to read/precharge delay" and "burst write
> to read/write/precharge delay" by 1 too low.
> 
> Don't know how I messed these values up, but these lead to all
> memory accesses in single-step mode and via BDM to work correctly
> but gave erroneous results in real program execution.
> 
> [note to self: in case of strange errors, always check memory
> interface. If triple-checked: check again...]

Congrats for fixing it - note that y ou are not the first one to
discover this. There is a reason why this topic has a top entry in the
FAQ.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The use of COBOL cripples the mind; its teaching  should,  therefore,
be regarded as a criminal offense.                   - E. W. Dijkstra