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

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

[robert lazarski]

Hi all, been spending a few days with my board and I see no signs of
life from u-boot. I'm running my code in u-boot pulled from sept
18th's git repo - rc1 I think. I've tried:

/home/iksrazal/eldk2/usr/bin> ./ppc_85xx-gdb /home/iksrazal/u-boot/u-boot
GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
The target architecture is set automatically (currently powerpc:e500)
..
(gdb) set verbose on
(gdb) target remote 10.101.43.42:2001
Remote debugging using 10.101.43.42:2001
0x00000000 in ?? ()
(gdb) mon break hard
(gdb) b board_init_f
Reading in symbols for board.c...done.
Breakpoint 1 at 0xfff896e8: file board.c, line 365.
(gdb) c
Continuing.

Where it just hangs. I've tried 'go' in the bdi to no avail. I see no
life on the serial port.
While I have 128MB of flash positioned at 0xf8000000 , I've loaded
u-boot to 0xff8000000 - the default boot rom location for the 8548. I
suppose one of the things to try is booting from low memory - but I
haven't figured out how to do that via the boot sequencer or another
register just yet. I also tried loading uboot to 0xf8000000 but it
didn't work either.

The first culprit is probably our memory - 1GB of DDR2 ram. The
hardware guys tell me our DDR2 is exactly like the MPC8548CDS
reference board. I have the memory mapped to 0x00000000 , and I can do
this:

ATUM>mmh 0x00000000 0xcafe
ATUM>mdh 0x00000000 1
0_00000000 : 0xcafe  -13570  ..
ATUM>

I get the feeling that somehow that u-boot isn't being executed yet -
how can I verify that? Maybe setting a breakpoint in start.S ? Pins on
the 8548 ? Googling has turned up a few posts saying that perhaps my
bdi config could be the culprit. Since I can erase the flash and load
u-boot into it, and seemingly read and write the memory, I'm going to
post my latest bdi config version but its most definetly a work in
progress! Any help appreciated.

;  - BDI2000 - Atum
;---------------------------------------------------
;
;
;	3 TLBs: 1 para CCSBAR - 1 para DDR (1GB) - 1 para Flash (1GB)
;

[INIT]

DELAY 5000
;

;#######################################################################
; Errata PCI-Ex 26 workaround
WM32    0xFF70A000  0x0000005C  ;Clear bit 1 & 0 in Link Control &
Status Register
WM32    0xFF70A004  0x00000000  ;(PCIconfiguration space register at
offset 0x5C)
WM32    0xFF7E0F08  0x00000008  ;Clear bit 30 in the engineering only register
                                ;(CCSR space register at offset 0xe0f08)
;#######################################################################


;#######################################################################
; use the following two lines for STARTUP HALT
;WSPR    63          0xffff0000  ;IVPR to boot core
;WSPR    415         0x0000f000  ;IVOR15 : Debug exception
;
;#######################################################################


;#######################################################################
; Move the L2SRAM to the initial MMU page
WM32    0xFF720E44  0x0000001C  ;L2ERRDIS: disable parity error
WM32    0xFF720000  0x60010000  ;L2CTL - 0110	0000	0000	0001	0000	0000	0000	0000
WM32    0xFF720100  0x0FFF8000  ;L2SRBAR0: map to 0x0_FFF80000
WM32    0xFF720000  0xA0010000  ;L2CTL

; load and execute some boot code
WM32    0xfffffffc      0x48000000      ;loop
EXEC    0xfffffffc
;
;#######################################################################


;##################################################################################
;# MMU initialization
;#
;# MAS0: MMU read/write and replacement control
;# MAS1: descriptor context and configuration control
;# MAS2: EPN and page attributes
;# MAS3: RPN and access control
;# MAS4: Hardware replacement assist configuration

;----------------------------------------------------------------------------------
;# define 1MB TLB1 entry 1: 0x40000000 - 0x400FFFFF
;# for CCSR

WSPR	624 	0x10010000	;# MAS0
WSPR	625 	0x80000500	;# MAS1
WSPR	626 	0x40000008	;# MAS2
WSPR	627 	0x4000003f	;# MAS3
WSPR	628 	0x00000000	;# MAS4

;# write tlb entry
WM32	0xFFFFF000	0x7C0007A4	;# tlbwe
WM32	0xFFFFF004	0x4C00012C	;# isync
WM32	0xFFFFF008	0x7C0004AC	;# msync
WM32	0xFFFFF00C	0x38600055	;# li r3, 0x55 to confirm the running
WM32	0xFFFFF010	0x48000000	;# infinite loop
WM32	0xfffffffc	0xfffff000

EXEC    0xfffff000

;----------------------------------------------------------------------------------
;

;----------------------------------------------------------------------------------
;# define 1GB TLB1 entry 2: 0x00000000 - 0x3FFFFFFF
;# for DDR

WSPR	624 	0x10020000		;# MAS0
WSPR	625 	0x80000A00		;# MAS1  - 	1000	0000	0000	0000	0000	1010	0000	0000
WSPR	626 	0x00000000		;# MAS2
WSPR	627 	0x0000003f		;# MAS3

;# write tlb entry
WM32	0xfffffffc	0xfffff000
EXEC    0xfffff000
;----------------------------------------------------------------------------------


;----------------------------------------------------------------------------------
;# define 64MBytes TLB entry 3: 0xF8000000 - 0xFFFFFFFF
;# for FLASH bank #0 and bank #1

WSPR	624 0x10030000		;# MAS0
WSPR	625 0x80000800		;# MAS1
WSPR	626 0xF8000008		;# MAS2
WSPR	627 0xF800003f		;# MAS3

;# write tlb entry
WM32	0xfffffffc	0xfffff000
EXEC    0xfffff000
;----------------------------------------------------------------------------------





;##################################################################################
;# move CCSR at 0xE0000000
;# CCSRBAR
;# bit 12 - 23 - BASE_ADDR

WM32	0xFF700000	0x000E0000
;
;##################################################################################


;##################################################################################
;# config BPTR register (Boot Page Translation Register)
;# remove the 4k boot page from 0xFFFFF000 address
;WM32  	0xE0000020  0x00000000

;# Invalidate again BR0 to prevent flash data damage in case
;# the boot sequencer re-enables CS0 access
;WM32	0xE0005000 0x00001000
;##################################################################################



;##################################################################################
;# configure internal SRAM at 0x40100000
;# L2CTL
;# bit 0 = 0 		- L2E: L2 SRAM disabled
;# bit 4-5 = 01 		- L2BLKSZ: = 512KB
;# bit 13-15 = 001 	- L2SRAM: Block 0 = SRAM 0
WM32	0xE0020000	0x00010000

;# L2SRBAR0
;# bit 0-17 = BASE addr: 0x40100000
WM32	0xE0020100	0x40100000

;# L2CTL
;# bit 0 = 1 		- L2E: L2 SRAM enable
;# bit 4-5 = 01 		- L2BLKSZ: = 512KB
;# bit 13-15 = 001 	- L2SRAM: Block 0 = SRAM 0
WM32	0xE0020000	0x80010000
;##################################################################################



; Setup flash programming workspace in L2SRAM
WM32 0xE0020000 0x68010000 ;L2CTL
WM32 0xE0020100 0xf0000000 ;L2SRBAR0
WM32 0xE0020000 0xA8010000 ;L2CTL
WSPR 63 0xf0000000 ;IVPR to workspace
WSPR 415 0x0001500 ;IVOR15 : Debug exception
WM32 0xf0001500 0x48000000 ;write valid instruction



;##################################################################################
;#	
;#	Memory Windows
;#
;#	0x00000000	0x3ffffff	LAW0	DDR
;#	0xc0000000	0xfffffff	LAW1	Local Bus
;#
;##################################################################################



;##################################################################################
;# configure local access windows
;#
;# window 0: DDR = F
;# window 1: Local Bus = 4

;----------------------------------------------------------------------------------
;# LAWBAR0
;# bit 12 - 31 = 0x00000000 - base addr
WM32	0xE0000c08 	0x00000000

;# LAWAR0
;# bit 1 = 1 - enable window
;# bit 8-11 = F - DDR
;# bit 26 - 31  = 1GB - size
WM32	0xE0000c10	0x80f0001D
;----------------------------------------------------------------------------------

;----------------------------------------------------------------------------------
;# LAWBAR1
;# bit 12 - 31 = 0xF8000000 - base addr
WM32	0xE0000c28 	0x000F8000


;# LAWAR1
;# bit 1 = 1 - enable window
;# bit 8-11 = 4 - local bus
;# bit 26 - 31  = 256MB - size
WM32	0xE0000c30	0x8040001A ;- 1D
;----------------------------------------------------------------------------------
;###################################################################################


;###################################################################################
;#
;# DDR initalization
;#
;###  Clocks: CPU: 990 MHz, CCB: 396 MHz, DDR: 198 MHz

;# DDR_SDRAM_CFG 	0100	0011	0000	0000	0000	0000	0000	0000
;# bit 0 = 0 - MEM_EN SDRAM interface logic is disabled
;# bit 1 = 1 - SREN enable self refresh during sleep
;# bit 2 = 0 - ECC_EN disable ECC interrupt generation
;# bit 3 = 0 - RD_EN unbuffered DIMMs
;# bit 6 - 7 = 2 - SDRAM_TYPE DDR2 SDRAM
;# bit 10 = 0 - DYN_PWR power management disabled

WM32	0xE0002110 0x43000000

;# configure the appropriate DDR controller registers

;# CS0_BNDS
;# bit 8-15 - starting address
;# bit 24-31 - ending address
WM32	0xE0002000 0x0000000f ; DDR CS0

;# CS0_CONFIG
WM32	0xE0002080 0x80000102

;# TIMING_CFG_0
WM32	0xE0002104 0x00260802

;# TIMING_CFG_1
WM32	0xE0002108 0x38355322

;# TIMING_CFG_2
WM32	0xE000210C 0x039048c7

;# DDR_SDRAM_MODE
WM32	0xE0002118 0x00000432

;# DDR_SDRAM_INTERVAL
WM32	0xE0002124 0x05150100

;# DDR_SDRAM_CFG2
WM32	0xE0002114 0x24000000

;# DDR_SDRAM_CLK_CNTL
WM32	0xE0002130 0x03000000

DELAY 200

;# enable the memory interface
;# DDR_SDRAM_CFG
;# enable the memory interface
WM32	0xE0002110 0xc3000000
;##################################################################################



;##################################################################################
;# configure local bus memory controller

;# CS0 - Flash Bank #0
WM32	0xE0005000 0xf8001001 ;# BR0 base address at 0xF8000000, port
size 16 bit, GPCM, valid
WM32	0xE0005004 0xf8006e65 ;# OR1 64MBytes flash size
;##################################################################################


;WM16 0xf8000AAA 0x5500 ;
;WM16 0xf8000554 0xAA00 ;
;WM16 0xf8000AAA 0x0100 ;
;WM16 0xf8000AAA 0x5500 ;
;WM16 0xf8000554 0xAA00 ;
;WM16 0xf8000AAA 0x0800 ;
;;WM16 0xfbffffff 0x0010 ;WM16 0xf8000000 0x0010 ;

;WM32 0xf8000AAA 0x00AA ;
;WM32 0xf8000554 0x0055 ;
;WM32 0xf8000AAA 0x00A0 ;
;DELAY 2000
;WM32 0xf8000F00 0x5555 ;






[TARGET]
CPUTYPE     8548        ;the CPU type
JTAGCLOCK   0           ;use 16 MHz JTAG clock
STARTUP     HALT        ;halt core while HRESET is asserted
BREAKMODE   HARD      	;SOFT or HARD, HARD uses PPC hardware breakpoint
STEPMODE    HWBP        ;JTAG or HWBP, HWBP uses a hardware breakpointeraserase
WAKEUP      2000        ;give reset time to complete
POWERUP     5000        ;start delay after power-up detected in ms



[HOST]
IP          10.101.42.16
FILE        uboot.bin
FORMAT      BIN
LOAD        MANUAL              ;load code MANUAL or AUTO after reset
DUMP        dump.bin
PROMPT      ATUM>


[FLASH]
CHIPTYPE    MIRRORX16           ;S29GL01GP
CHIPSIZE    0x8000000           ;The size of one flash chip in bytes
BUSWIDTH    16                  ;The width of the flash memory bus in
bits (8 | 16 | 32)
;WORKSPACE   0xf0000000 	 	;workspace in L2SRAM
ERASE       0xf8000000 CHIP; erase chip


[REGS]
FILE        $reg8548.def


Thanks!
Robert

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

[Jerry Van Baren]

robert lazarski wrote:
> Hi all, been spending a few days with my board and I see no signs of
> life from u-boot. I'm running my code in u-boot pulled from sept
> 18th's git repo - rc1 I think. I've tried:
> 
> /home/iksrazal/eldk2/usr/bin> ./ppc_85xx-gdb /home/iksrazal/u-boot/u-boot
> GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
> The target architecture is set automatically (currently powerpc:e500)
> ..
> (gdb) set verbose on
> (gdb) target remote 10.101.43.42:2001
> Remote debugging using 10.101.43.42:2001
> 0x00000000 in ?? ()
> (gdb) mon break hard
> (gdb) b board_init_f
> Reading in symbols for board.c...done.
> Breakpoint 1 at 0xfff896e8: file board.c, line 365.
> (gdb) c
> Continuing.

Is 0xfff896e8 actually board.c line 365 (gdb's symbols OK)?  Low 
probability of error, but worth verifying.

You might want to telnet directly into the BDI and use the BDI 
breakpoint and go commands directly.

I see you told gdb to use hard breakpoints (good).  Using the BDI 
command interface instead of gdb would eliminate one more piece of 
software to screw up.

Did you dump flash (disassemble if you are using gcc), did it match what 
you programmed?

> Where it just hangs. I've tried 'go' in the bdi to no avail. I see no
> life on the serial port.
> While I have 128MB of flash positioned at 0xf8000000 , I've loaded
> u-boot to 0xff8000000 - the default boot rom location for the 8548. I
> suppose one of the things to try is booting from low memory - but I
> haven't figured out how to do that via the boot sequencer or another
> register just yet. I also tried loading uboot to 0xf8000000 but it
> didn't work either.

I wouldn't switch to low boot until you've exhausted your current 
options.  I would suspect you would work hard for no different results.

> The first culprit is probably our memory - 1GB of DDR2 ram. The
> hardware guys tell me our DDR2 is exactly like the MPC8548CDS
> reference board. I have the memory mapped to 0x00000000 , and I can do
> this:

board_init_f is the flash-based board initialization, run before RAM is 
used.  If you aren't getting there, it isn't RAM's fault.

> ATUM>mmh 0x00000000 0xcafe
> ATUM>mdh 0x00000000 1
> 0_00000000 : 0xcafe  -13570  ..
> ATUM>

It may be RAM's fault later, but not yet...

> 
> I get the feeling that somehow that u-boot isn't being executed yet -
> how can I verify that? Maybe setting a breakpoint in start.S ?

YES!  Set hardware breakpoints right at the start and see if you hit 
them (and I would do it directly with the BDI, since I'm paranoid).

I would also check what your PC register is when you start out, perhaps 
you aren't even starting where you think you are.

When you go/continue and no breakpoints are hit, halt the CPU... where 
is the PC?

Your BDI config file is pretty complex, can you trim out all but the 
essentials?  I see a lot of "moving" and "mapping" and "TLB"ing.  Your 
memory map may be completely different from the normal power up 
configuration, which is what u-boot expects.

Makes me ask my memory readback question again: can you read the flash 
holding u-boot at the memory location you think u-boot lives at???

[snip]

> Thanks!
> Robert

Yerwelcome.  Hope it helps.
gvb

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

[Detlev Zundel]

Hi Jerry and Robert,

> You might want to telnet directly into the BDI and use the BDI 
> breakpoint and go commands directly.

Additionally I wanted to hint at the fact that all the BDI "telnet
commands" can be accessed through the "monitor" gdb command.  So
without switching any terminal you can easily do a "mon info" from gdb
for example.

The convenience of this is worth the risk of iterating well known
facts :)

Cheers
  Detlev

-- 
Alisa Sherer (AMD) suggested that consumer demand will not follow
faster clock speeds. Marketing might help with this problem, she
added.                                            -- 2004/02/20
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

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

[robert lazarski]

On 9/19/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> robert lazarski wrote:

Thanks for the help Jerry...
>
> Is 0xfff896e8 actually board.c line 365 (gdb's symbols OK)?  Low
> probability of error, but worth verifying.

In vim with line numbers enabled, editing lib_ppc/board.c I get:

364 void board_init_f (ulong bootflag)
365 {

>
> You might want to telnet directly into the BDI and use the BDI
> breakpoint and go commands directly.
>
> I see you told gdb to use hard breakpoints (good).  Using the BDI
> command interface instead of gdb would eliminate one more piece of
> software to screw up.
>

Good idea, see below.

> Did you dump flash (disassemble if you are using gcc), did it match what
> you programmed?
>

Will try that if I can't grab low hanging fruit.

>
> I wouldn't switch to low boot until you've exhausted your current
> options.  I would suspect you would work hard for no different results.
>
> > The first culprit is probably our memory - 1GB of DDR2 ram. The
> > hardware guys tell me our DDR2 is exactly like the MPC8548CDS
> > reference board. I have the memory mapped to 0x00000000 , and I can do
> > this:
>
> board_init_f is the flash-based board initialization, run before RAM is
> used.  If you aren't getting there, it isn't RAM's fault.
>
> > ATUM>mmh 0x00000000 0xcafe
> > ATUM>mdh 0x00000000 1
> > 0_00000000 : 0xcafe  -13570  ..
> > ATUM>
>
> It may be RAM's fault later, but not yet...
>

I looked at the code after you mentioned that - thanks for pointing that out.

> >
> > I get the feeling that somehow that u-boot isn't being executed yet -
> > how can I verify that? Maybe setting a breakpoint in start.S ?
>
> YES!  Set hardware breakpoints right at the start and see if you hit
> them (and I would do it directly with the BDI, since I'm paranoid).
>

I'm using the bdi now directly, and googling turned this up:

http://www.ultsol.com/faq_p304.htm

"For an MPC85xx family processor the MSR[DE] bit must be set.
Breakpoints will only trigger if this bit is set."

So after reset, info shows:

ATUM>info
    Target CPU        : MPC85xx (e500v2 rev.2)
    Target state      : halted
    Debug entry cause : COP halt
    Current PC        : 0xfffffffc
    Current CR        : 0x00000000
    Current MSR       : 0x00000200
    Current LR        : 0x00000000
    Current CCSRBAR   : 0x0_e0000000

MSR[DE] in the 8548 manual at 6-12 says:

bit   name   description
---------------------------------------------------------------------------------------------------------------------------
54   DE      Debug interrupt enable. See the description of the
DBSR[UDE] in Section
                 6.13.2, "Debug Status Register
                 (DBSR)."
                 0 Debug interrupts are disabled.
                 1 Debug interrupts are enabled if DBCR0[IDM] = 1.

I read this all as saying the MSR needs to be 0x00000220 - bit 54 off
the MSR seems to be cleared by the bdi as shown above - seems odd to
me.

Using gdb just to read the elf symbols and _not_ connected to the bdi, I get:

(gdb) b _start_e500
Breakpoint 1 at 0xfffff01c

So I do (ATUM> is my bdi prompt) :

ATUM>rm msr 0x00000220
ATUM>rd msr
msr            : 0x00000220  544
ATUM>bi 0xfffff01c
Breakpoint identification is 0
ATUM>go

After waiting for minute or so, I do:

ATUM>halt
    Target CPU        : MPC85xx (e500v2 rev.2)
    Target state      : halted
    Debug entry cause : COP halt
    Current PC        : 0x00000000
    Current CR        : 0x00000000
    Current MSR       : 0x00000200
    Current LR        : 0x00000000
    Current CCSRBAR   : 0x0_e0000000

So the MSR bit I believe I need is getting cleared.

> I would also check what your PC register is when you start out, perhaps
> you aren't even starting where you think you are.
>
> When you go/continue and no breakpoints are hit, halt the CPU... where
> is the PC?
>

As shown above the PC is 0x00000000 - the start of my DDR2. What does
that mean?

> Your BDI config file is pretty complex, can you trim out all but the
> essentials?  I see a lot of "moving" and "mapping" and "TLB"ing.  Your
> memory map may be completely different from the normal power up
> configuration, which is what u-boot expects.
>

Will try that so that its easier to help me - was quite an effort to
create that file.

> Makes me ask my memory readback question again: can you read the flash
> holding u-boot at the memory location you think u-boot lives at???
>

This seems right to me:

ATUM>mdh 0xff800000
0_ff800000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30  '..VU-Boot 1.3.0

>
> Yerwelcome.  Hope it helps.
> gvb
>

Helping quite a bunch as I have plenty of ideas to try  - thanks!
Robert

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

[Steve Williams]

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


> This seems right to me:
> 
> ATUM>mdh 0xff800000
> 0_ff800000 : 2705 1956 552d 426f 6f74 2031 2e33 2e30  '..VU-Boot 1.3.0
> 
>

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

[robert lazarski]

On 9/20/07, Steve Williams <steve@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

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

[Demke Torsten-atd012]

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

> 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 ?
This means your Boot flash devices starts is at address 0xff800000, 
not that your boot code starts at this address.

For a start I would use the 8548 cds linker script unchanged,
build your u-boot image, flash it to 0xfff80000 and single-step
with your BDI.


Regards,
Torsten

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

[Erik Christiansen]

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

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

[Demke Torsten-atd012]

 

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Erik Christiansen
> Sent: Freitag, 21. September 2007 08:59
> To: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Debugging u-boot on a custom 8548 board
> 
> 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
And...?
_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...

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

Regards,
Torsten
 
> 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. :)
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all 
> challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/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] Debugging u-boot on a custom 8548 board

[Erik Christiansen]

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

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

[Demke Torsten-atd012]

> Though the cpu differs by only one digit, the start-up 
> differs significantly. For 8248, it looks pretty dang 
Do you speak about 8248 or 8548 (topic)??
Im somewhat confused - I m referreing to 85xx only!

Regards,
Torsten

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

[robert lazarski]

On 9/21/07, Demke Torsten-atd012 <torsten.demke@motorola.com> wrote:
>

Thanks all, I can now debug! Please see below...

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

Seems so clear now - thank you very much for the kind help.

> > Am I reading all this to mean I should load uboot to
> > 0xff800000  - is that wrong ?
> This means your Boot flash devices starts is at address 0xff800000,
> not that your boot code starts at this address.
>
> For a start I would use the 8548 cds linker script unchanged,
> build your u-boot image, flash it to 0xfff80000 and single-step
> with your BDI.
>

So I executed:

/home/iksrazal/eldk2/usr/bin> ./powerpc-linux-objdump -D
/home/iksrazal/u-boot/u-boot > ~/u-boot.mydump

For clearer debugging, I compiled u-boot with:

OPTFLAGS= -Os -fno-schedule-insns -fno-schedule-insns2

After a reset in the bdi, I can now single step via 'ti' until:

ATUM>ti
    Target CPU        : MPC85xx (e500v2 rev.2)
    Target state      : halted
    Debug entry cause : single step
    Current PC        : 0xfffff20c
    Current CR        : 0x00000000
    Current MSR       : 0x00000200
    Current LR        : 0xfffff0b4
    Current CCSRBAR   : 0x0_e0000000
ATUM>ti
    Target CPU        : MPC85xx (e500v2 rev.2)
    Target state      : halted
    Debug entry cause : COP halt
    Current PC        : 0xfff80e00
    Current CR        : 0x00000000
    Current MSR       : 0x00000000
    Current LR        : 0xfffff210
    Current CCSRBAR   : 0x0_e000000

Where in ~/u-boot.mydump :

fffff208 <tlb1_entry>:
fffff208:       7c 28 02 a6     mflr    r1
fffff20c:       48 00 00 b9     bl      fffff2c4 <tlb1_entry+0xbc>

And:

fff80e00 <InstructionTLBError>

fffff20c is seemingly my init.S code - how can I find out for sure?
The first lines I have are:

#define entry_start \
        mflr    r1      ;       \
        bl      0f      ;

Thanks all more than words can tell,
Robert

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

[robert lazarski]

On 9/21/07, Demke Torsten-atd012 <torsten.demke@motorola.com> wrote:
>
>
> For a start I would use the 8548 cds linker script unchanged,
> build your u-boot image, flash it to 0xfff80000 and single-step
> with your BDI.
>

Hi all, I'm stuck again. I can now single step and hit some
breakpoints. However, I'm failing early in cpu/mpc85xx/start.S . I
keep on getting:

ATUM>bi  0xfffff0c0
Breakpoint identification is 0
ATUM>go
- TARGET: stopped
ATUM>rd
GPR00: fffff210 fffff0b4 00010001 00000000
GPR04: 0000000b fffff210 00000000 00000000
GPR08: 00000000 00000000 00000000 00000000
GPR12: 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000
GPR20: 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000
GPR28: 00000000 00000000 00000000 00000000
CR   : 00000000     MSR: 00000200
ATUM>ti
- Core status is 0x0041
*** Core is stopped, no debugging possible
# PPC: timeout while waiting for halt
ATUM>    Target CPU        : MPC85xx (e500v2 rev.2)
    Target state      : running
# Step timeout detected

0xfffff0c0 maps as cpu/mpc85xx/start.S, line 163:

162
163 0:      lwzu    r6,4(r5)
164         lwzu    r7,4(r5)

Output from powerpc-linux-objdump on b-boot.bin:

fffff0c0:       84 c5 00 04     lwzu    r6,4(r5)

When this happens, I seemingly can't read any registers or do any
further analysis.
I spent the last few days trying to develop the exact cause, but I'm
getting inconsistent behavior from the bdi. The farthest I can go
consistently is set a breakpoint this far on line 163.

The code on Line 163 happens after "bl      tlb1_entry" , which calls
my init.S . After trying a hundred times or so, once or twice I've
been able to step further or set a slightly further breakpoint than
line 163 - but not consistently. I've tried:

1) Doing 'ti' after reset, it gives 'Step timeout detected' at
different locations on every run.
2) Taking out the init section of the bdi.
3) General tweaking of the init section in the bdi.
4) Making the jtag clock slower in the bdi config.
5) Making my tlb1_entry bare bones.
6) Using the cds tlb1_entry .
7) Flashing the cds code into my flash.
8) Setting the breakpoint much further, board_init_f , and typing go
after reset.

Everything I've tried doesn't get me consistently past line 163 of
cpu/mpc85xx/start.S. However, I've tried single stepping slightly
before that and I've failed to single step consistently to line 163.
So I'm having a hard time developing a pattern of failure. Any ideas
on what I could try? I still haven't got as far as getting the serial
port working. Thanks!
Robert