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

[robert lazarski]

On 9/20/07, Steve Williams <steve at parsonscroft.plus.com> wrote:
>
>
> Just one point here my u-boot for our custom MPC8548 board starts at
> 0xfff80000 not 0xff800000. Unless you changed the linker map won't this
> mean that the code that is supposed to live at the reset vector is not
> actually there?
>
> Try looking right at the top of flash (the last 16 bytes) for the jump.
>
> Maybe I have missed something obvious here but I just thought I point it out
>
> Regards
>
> Steve Williams
>

Hi Steve. What board are you referring to - is it open sourced ?  I
can't get any signs of life yet so I tried 0xfff80000 (0xfffff01c is
_start_e500 in start.S) :

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

In a nutshell I'm trying to figure out what the pc is doing and why -
I can't hit breakpoints nor see any signs of code running. The docs do
say:

4.4.3.3 Boot ROM Location
The MPC8548E defines the default boot ROM address range to be 8 Mbytes
at address 0x0_FF80_0000
to 0x0_FFFF_FFFF. However, which peripheral interface handles these
boot ROM accesses can be
selected at power on.

As I said I could be reading this wrong. The 8548 cds code in 1.3 rc1 has:

#define CFG_BOOT_BLOCK          0xff000000      /* boot TLB block */
#define CFG_FLASH_BASE          CFG_BOOT_BLOCK  /* start of FLASH 16M */
#define CFG_FLASH_BANKS_LIST    {0xff800000, CFG_FLASH_BASE}

Am I reading all this to mean I should load uboot to 0xff800000  - is
that wrong ?

Incidently, I'm going thru the docs trying to find exceptions in the
registers - these aren't changing for me:

ATUM4>rd spefscr
spefscr        : 0x00000000  0
ATUM4>rd dear
dear           : 0x00000000  0
ATUM4>rd esr
esr            : 0x00000000  0

In fact, I'm seeing the behavior running u-boot and with the flash
erased via typing "go uboot address" - I can't see any difference in
any registers.

I wrote an email to freescale tech support to see if there is some
register I can see to find the error or some other type of help they
can offer.

Thanks all!
Robert