[U-Boot-Users] u-boot's own boot process

[U-Boot-Users] u-boot's own boot process

[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
 
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?w\x12r?n\x16i?g\x1ai? 
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?
\x02#? \x06e?

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

[U-Boot-Users] u-boot's own boot process

[Seb James]

Seb James wrote:

> 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)

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 ?? ()
 

>
> 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?w\x12r?n\x16i?g\x1ai? 
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?
> \x02#? \x06e?
>
> (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
>
>

[U-Boot-Users] u-boot's own boot process

[Seb James]

> 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?