[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