[U-Boot-Users] Debugging u-boot on a custom 8548 board
Erik Christiansen
erik at dd.nec.com.au
Fri Sep 21 08:59:04 CEST 2007
On Fri, Sep 21, 2007 at 07:14:20AM +0100, Demke Torsten-atd012 wrote:
>
> > ATUM4>mdh 0xfff80000
> > 0_fff80000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30 '..VU-Boot 1.3.0
> >
> > ATUM4>bi 0xfffff01c
> > Breakpoint identification is 0
> > ATUM4>go 0xfff80000
> > ATUM4>halt
> > Target CPU : MPC85xx (e500v2 rev.2)
> > Target state : halted
> > Debug entry cause : COP halt
> > Current PC : 0xf0000000
> > Current CR : 0x00000000
> > Current MSR : 0x00000200
> > Current LR : 0x00000000
> > Current CCSRBAR : 0x0_e0000000
> >
> This cannot work, as your own memory dump shows (above).
> You have the "magic word" and some ASCCI string at 0xfff80000.
> These are not valid ppc assembler instructions, but the begin of the
> u-boot image.
> Please check/dump address 0xfffffffc. There should be a valid
> jump instruction (see resetvec.S) which jumps to an address
> within a 4kbyte page at the end of the address space.
> ((0xfffff000, _start_e500()).
> There will be code that initializes the MMU that you can access
> the rest of the flash device(s), including the u-boot image (e.g
> cpu_init_f().
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
so I'm planning to "go 0xfff00100", and if that doesn't do it, then "go
0x100", because CS0 is then hopefully mapping flash to put _start at the
reset vector, so it'll work at power-on. (Just an optimistic WAG at this
stage.)
Anyway, what does robert's u-boot.map say?
Erik
(Sorry, just subscribed, and it's Friday, so couldn't resist rashly
chiming in. :)
More information about the U-Boot
mailing list