Skip to contentSkip to conversation

u-boot's own boot process

U-Boot-Users Seb James 1 participant 3 messages Aug 15, 2003

lore
Share & tools
lore

Seb James

author
#0 lore raw

Hi,

I've got some hardware which has a problem somewhere. It's a board with a tqm823l on it and the tqm should happily boot u-boot. The module plugged into another board works fine, but in our new hardware the code hangs.

I've checked out u-boot from cvs today, making it 0.4.5, and I applied a tqm8xx specific patch to boards/tqm8xx/flash.c which Wolfgang Denk posted in reply to a message a couple of days ago. I enabled debugging in config.mk and recompiled with no problems.

Running the code (using gdb through an Abatron BDI2000):

The problem occurs at program re-location. I set a breakpoint in cpu/mpc8xx/start.S thus:

(gdb) break start.S:575
Breakpoint 2 at 0x4000231c: file /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S, line 575. (gdb) c
Continuing.

Breakpoint 2, relocate_code ()

    at /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S:575

575 addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET
(gdb) s
576 mtlr r0
(gdb) s
577 blr
(gdb) s

Program received signal SIGSTOP, Stopped (signal). 0x3ffffffc in ?? ()
(gdb)

And you can see where the trouble occurs (console output given below). It's just at the point in start.S where u-boot is relocated from flash to RAM (correct me if that's wrong).

Where's the code going from and to? In start.S I read that the code starts executing from flash, with the program counter starting at 0x100. What is boardinit? From start.S:

"board_init lies at a quite high address and when the cpu has jumped there, everything is ok."

Anyone have any ideas as to what might be wrong in the hardware to cause this behaviour?

regards,

Seb James

Here's the output at the terminal:

U-Boot 0.4.5 (Aug 15 2003 - 13:18:07)

CPU:   PPC823EZTnnB2 at 50 MHz: 16 kB I-Cache 8 kB D-Cache
Board: ### No HW ID - assuming TQM8xxL
DRAM:  16 MB
Top of RAM usable for U-Boot at: 01000000
Reserving 204k for U-Boot at: 00fcc000
Reserving 128k for malloc() at: 00fac000

Reserving 60 Bytes for Board Info at: 00fabfc4
Reserving 52 Bytes for Global Data at: 00fabf90
Stack Pointer at: 00fabf78
New Stack Pointer is: 00fabf78
N?wr?ni?gi?
A? " ?-&o?t*a?:.%?82x?F?A?H? ?e?h?d?r?i?a?d?
?#?G?t?f?a?h?b?n? ? ?i?e?@?0?%?8?
#? e?

(Then some more garbage is output until things stop).

author
#1 lore raw
Quoted 33 lines · Seb James

Hi,

I've got some hardware which has a problem somewhere. It's a board with a tqm823l on it and the tqm should happily boot u-boot. The module plugged into another board works fine, but in our new hardware the code hangs.

I've checked out u-boot from cvs today, making it 0.4.5, and I applied a tqm8xx specific patch to boards/tqm8xx/flash.c which Wolfgang Denk posted in reply to a message a couple of days ago. I enabled debugging in config.mk and recompiled with no problems.

Running the code (using gdb through an Abatron BDI2000):

The problem occurs at program re-location. I set a breakpoint in cpu/mpc8xx/start.S thus:

(gdb) break start.S:575
Breakpoint 2 at 0x4000231c: file /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S, line 575. (gdb) c
Continuing.

Breakpoint 2, relocate_code ()
at /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S:575
575 addi r0, r10, in_ram - _start + EXC_OFF_SYS_RESET
(gdb) s
576 mtlr r0
(gdb) s
577 blr
(gdb) s

Quoted 3 lines

Program received signal SIGSTOP, Stopped (signal). 0x3ffffffc in ?? ()
(gdb)

If I instead use stepi commands, the following happens:

Breakpoint 4, relocate_code ()

    at /eldk/ppc_8xx/usr/src/u-boot/cpu/mpc8xx/start.S:577

577 blr
(gdb) stepi
0x00fce328 in ?? ()
(gdb) stepi
0x00fce32c in ?? ()
(gdb) stepi
0x00fce330 in ?? ()
(gdb) stepi
0x00fce334 in ?? ()
(gdb) stepi
0x00fce338 in ?? ()
(gdb) stepi
0x00fce33c in ?? ()
(gdb) stepi
0x00fce340 in ?? ()
(gdb) stepi
0x00fce344 in ?? ()
(gdb) stepi
0x00fce348 in ?? ()
(gdb) stepi

and.. he code ends up looping around these 4 program counters:

0x00fce34c in ?? ()
(gdb) stepi
0x00fce340 in ?? ()
(gdb) stepi
0x00fce344 in ?? ()
(gdb) stepi
0x00fce348 in ?? ()

Quoted 31 lines

And you can see where the trouble occurs (console output given below). It's just at the point in start.S where u-boot is relocated from flash to RAM (correct me if that's wrong).

Where's the code going from and to? In start.S I read that the code starts executing from flash, with the program counter starting at 0x100. What is boardinit? From start.S:

"board_init lies at a quite high address and when the cpu has jumped there, everything is ok."

Anyone have any ideas as to what might be wrong in the hardware to cause this behaviour?

regards,

Seb James

Here's the output at the terminal:

U-Boot 0.4.5 (Aug 15 2003 - 13:18:07)

CPU:   PPC823EZTnnB2 at 50 MHz: 16 kB I-Cache 8 kB D-Cache
Board: ### No HW ID - assuming TQM8xxL
DRAM:  16 MB
Top of RAM usable for U-Boot at: 01000000
Reserving 204k for U-Boot at: 00fcc000
Reserving 128k for malloc() at: 00fac000
Quoted 5 lines

Reserving 60 Bytes for Board Info at: 00fabfc4
Reserving 52 Bytes for Global Data at: 00fabf90
Stack Pointer at: 00fabf78
New Stack Pointer is: 00fabf78
N?wr?ni?gi?

A? " ?-&o?t*a?:.%?82x?F?A?H? ?e?h?d?r?i?a?d?

Quoted 21 lines

?#?G?t?f?a?h?b?n? ? ?i?e?@?0?%?8?
#? e?

(Then some more garbage is output until things stop).

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

author
#2 lore raw
Quoted 8 lines
Quoted 5 lines · I wrote:

Hi,

The problem occurs at program re-location. I set a breakpoint in cpu/mpc8xx/start.S thus:

I think the most likely cause of this problem is a short between address (or maybe data) lines on the hardware into which my tqm is plugged. Anyone agree?