[U-Boot-Users] Debugging u-boot on a custom 8548 board

Erik Christiansen
2007-09-21T09:02:57Z

On Fri, Sep 21, 2007 at 08:25:43AM +0100, Demke Torsten-atd012 wrote:
> >
> > Errm, having just done an initial build for the ep8248e, I
> > first looked in the generated u-boot.map file. In my case, it says:
> >
> > .text
> > ...
> > 0xfff00100 _start
> And...?

The helpful intent was to communicate the benefit of looking up the
address of symbols, and suggesting where they might be found. (My
ep8248e example can only use the symbols it has. I'm sure Robert does
not need to be belaboured with "do same for your symbol, _start_e500"
;-)

> _start is at 0xfff00100 at my board too, but go 0xfff01000
> will probably fail, because this address is outside the 4K page and
> MMU is not properly configured...

You may well be right about 0xfff01000, but please compare that with the
address I mentioned. ;-)

Ah, I shouldn't have brought up the ep8248e, because the MMU is inactive
immediately after reset, in contrast to the 8548 case, IIUC. (But it's
the only example I have.)

> see start.S:
> ...
> _start_e500:
> ...
> /* Jump out of the last 4K page and continue to 'normal' start */
> 1: bl 3f
> b _start
> ...

Though the cpu differs by only one digit, the start-up differs
significantly. For 8248, it looks pretty dang old-fashioned to my naive
eye:

$ ppc_6xx-objdump -D u-boot > u-boot.mydump # Just to confirm that
# mpc824x/start.S is
# used.
fff00100 <_start>:
fff00100: 3a a0 00 01 li r21,1
fff00104: 60 00 00 00 nop
fff00108: 48 00 00 10 b fff00118 <boot_cold>
fff0010c: 00 00 00 00 .long 0x0

fff00110 <_start_warm>:
fff00110: 3a a0 00 02 li r21,2
fff00114: 48 00 00 04 b fff00118 <boot_cold>

fff00118 <boot_cold>:
fff00118: 7c a0 00 a6 mfmsr r5
fff0011c: 3c 60 f0 00 lis r3,-4096

Now, I'll have to succeed in burning it to flash, before I can say
anything about how well it works for me.

Avagoodweekend,
Erik